Should Try Lua Later

I was reading some Wiki and other info about Lua, a scripting language. It seems very nice and a lot of games are using it, in different areas. I think I should learn about this language and try it out later. There should be a lot of info online, and I think one of those Game Programming Gems book also mentioned it. I should check them out when I have time.

http://www.lua.org/

Finally...

Finally get the picking done. It seems to work well. The problem I had was putting gluPickMatrix inside GL_PROJECTION matrix mode and before gluPerspective. It's funny how they usually don't mention this type of calling sequence in the obvious place in the book etc. I only found this out in Lesson 32 of NeHe production example code. Without knowing the details of the function it's hard to evaluate what the problem is. But it's a good lesson about OpenGL.
Now I will have to start the next phase, which is...how am I going to add in a tile etc?

Picking Frustration

I think I almost got the picking to work, but for some reason it's off. The only explaination is the drawing during the picking operation is different from the normal rendering. But I check and re-check and can't find the difference. I might have to search the internet a bit and see if I can find the glitch.

Plan on Picking

After some testing and thinking, I think I will try to simplest way: rendering grid and use them for mouse picking. A side benefits of this design is I can also have a very simple implementation for multi-level selections. The user will select different height, and I will just draw and pick grids at that height. It's simple and clear.
The disadvantage of this is I can't use the mouse to cycle through different faces of a tile by letting the user click on the face. I think I might be able to add another window maybe that let the user select it using drop down or scroll bar (ideally).
But first thing first, I will have to get the simple stuff done before I get to the finer details.

Picking and Thoughts on Titan Quest

This weekend I attempted to implement the mouse function back into the editor. Of course the first thing to do is change the OpenGL picking setup, and of course it didn't work properly. I didn't tried too much because I was busy with other stuff and didn't spend a lot of time on it, but right now it's effecting the performance, and might not even pick the right spot. If possible I should develop some sort of module ore class to handle this picking things more easily so next time I need it I can just plug it in. It may or may not be possible...will have to see.

One thing that distracted me from game development is me playing Titan Quest trying to entertain myself. But now I think about it...what a waste of time, haha... But hey sometimes one has to relax. I did come up with some interesting thoughts about APRG genre though. It seems to me on PC the only successful ARPG is Diablo series. Even some developers break off from Blizzard, forming their own companies, they still can't best Diablo in my opinion, even with new technologies. Different gimmicks, skill trees, stories, different amount of side quests etc etc have been tried in different games, and a lot of them sound more impressive than Diablo, but still, it can't be beat in my opinion. At least Diablo gave me more enjoyable time than the others. After playing Titan Quest, here is few of my observation on making good ARPG (obviously my opinions might have high probability of being incorrect, since so many others have failed to beat Diablo):

1. Fine tuning of level of difficulties and type of challenge: ARPG should be simple, dumb but not too dumb I think. It means that control of the character should be simple. The difficulty should be easy, but not to the point of dumbness. The games should offer player some challenge but not to the point of frustrations (die often, heavy punishment on death which include long reroute after death, long loading time after death etc)...Another way to say it might be it should be convenient for player to die, but rewarding to stay alive and kill a bunch of monsters,...I think.
2. Look Good: This sounds shallow but I think it's extremely important for ARPG to have everything look extremely good and cool in the game. This actually a bit related to point 1's reward aspect as well. I highly doubt any player will feel good if he gain a knife with +200 attack but looks like a banana. With a bad look, number and stats don't matter. It would be nice to make the player feel his character has become more powerful by the look of the equipments, statures and the attacks. Actually I think that's one of the problem with Titan Quest: equipments look blend and better equipment don't look that different or better. Titan Quest's expansion Immortal Throne did a much better job in my opinion. The armor etc actually make your character look nice. Few ARPG try to make the attack looks different when level up (except more varieties of skills) but I think that's actually one cool thing that can be done. The enemy also need to look nice, and they have to look better and better as the player progress, because it gives player more satisfaction when the players destroy them. If every enemies look like Tofu of course no one will get any satisfaction out of it, even if you make the Tofu extremely hard to kill. Blizzard's Diablo I think, actually did a good job in this area. The only exception to this "Look Good" rule might be some "need help" NPC since it might be better to make them look sorry to trigger player's sympathies.
3. Varieties: This kind of games need varieties...whether it's in the environment, type of enemies, quests, story etc. Anything that can shock and ow the players would be nice. But in my opinion it doesn't mean "a lot of" side quests. Because usually a lot of side quests means a lot of blend side quests. Plus, people are lazy, and might just ignore the side quests, or frustrated by it. It might be better...to force the varieties onto the player, challenge them visually and mentally rather than give them a bunch of similar challenges.

That's my thought so far. In general I think the expansion Immortal Throne is done much better than Titan Quest, it shows that the company did learn something. Unfortunately I heard the developer Iron Lore is closing now.
Another thing that makes me wonder is...Consoles should be the better platforms for this type of ARPG. I knew a few from the SNES etc. But consoles offer more possibilities with the control etc in my opinion. Yea, puzzling, how come not a lot of developers attempted ARPG on consoles.

Finally....

Finally get the visual system integrated into the editor. Now the editor can see the stage as the players see it. The camera control is also implemented.
But this is only a start. Tough road ahead. Hopefully there won't be any unforeseen obstacle that will block the way. The biggest challenge is probably porting the conditional logic in the stage build system into the editor's adding and removing tile function.
The next step would be trying to add the mouse control (mouse indication) back in.

Interesting to note that...it took me more than half a month to get this integration done, ouch. I always thought it would take less time. But I guess it's fortunately enough that any got done at all since I only work on this during spare time.

Thoughts on Tools

I was able to get some message displayed properly on the editor view. I wasn't sure of the cause, but something wasn't setup correctly and nothing get drawn. Then I use the old code, and re-setup with the new classes and function. Now at least something get drawn properly. Now I am just working on the camera etc to get the proper control and the view. After those basic setup I can start working on the meat itself, but I think it should be easier.

I realize now how important tool sets are to game developments. The following analogy can probably sum it up. I can probably build a shelter with just stones and woods, but that is going to take a while, with lots of expenses, and the result might not be very good. If I have hammers, saws, nails etc, the result would be much better, and with shorter period of time and less expenses. If I have robots...then maybe I can build a house or a castle in a week without much expenses, but of course the robots are actually more expensive than the building itself, with today's technology level.

Games development is not exactly the same, but very similar I think. To build a simple game, I don't need much. But as I go further and further, I need more and more tools to make the work manageable. A lot of the tools and tool integration etc has to be done by the programmers, and some tools like 3D modellers etc might have to be purchased from 3rd party because to construct one would be redundant and cost too much (like construct a robot on your own). I think as the game development progress, more and more programming resource would be put into tools instead of the game itself. Of course there are the "Engines" (graphics and physics engines etc), which I think can be considered as "run-time" tools. So I guess there are 3 major parts in a game program:

1. Game Logic
2. Engine (graphics, physics, sounds,...things that makes the game run well)
3. Construction Tools (level editors, particle editors, modellers..., some available to the gamers for mod, but not necessary components for the players)

The amount of integration in all these different components might vary from game to game I think. For example, in the making of God of War 2 documentary, the game's engine and tools seem to be tightly integrated . So in a way, game construction would be similar to other engineering. But because it's all software (game ideas, art works, programs), there might be some significant differences as well. In any case, it's quite clear that the power of a well constructed tool sets cannot be underestimated and are one of the key in a successful game or franchise.

Ha...

Well, I guess here is the current result of the editor modification. Obviously it's not working properly. Looks like there are still quite some work to be done. No idea why the video card shows some left over image pieces from some games I was playing though.

Some Ideas

I am still developing the upgraded tile editor system, but looks like it's going to take a while since I don't have much time each day to work on it.

But here I will just post some game ideas:

• The background story I thought of would be typical: Some adversary (crazy AI or alien or...) has control of a space fortress (either taken over from human or constructed themselves). The fortress is constructed on and within a satellite or an asteroid (to give player different terrain to look at). The adversary is moving it slowly toward earth after the hyper space jump into the solar system. The earth's space fleets attempted to destroy it and fought with the fortress and its battle groups, but lost. Now the fleet is mostly disabled. The earth is attempting to re-muster the remain of the fleet to make a last stand before the fortress reaches to firing distance of its main cannons. In the mean time, the earth government hire the mercenaries to land on the fortress and attempt to neutralize or weaken it, that's where the player comes in. Now I know this sounds a bit like Star Wars or whatever other sci-fi and fantasy stories...but hey, what other kinds of story can get the players to save the day by shooting everything up in their path?
• When the game starts, the player will land on the drop zone. Drop zone will be the combination of town, save point, and way point in other RPG games. In drop zone, player can communicate with NPC like CODEC in MGS, save progress, buy/sell, revive henchmen and transport to another drop zone. The story behind drop zone would be that the player locate and secure an area safe enough for drop ships to come in, sometimes by defeating mini-bosses. The drop ships will bring necessary reinforcement and material to establish temporary base and up links.
• The quests would be something like the following: destroy fortress engine, destroy enemy main cannons, sabotage enemy fleets harbors and fighters hangers, destroy the core...etc. The player will travel through the fortress to their targets and establishing drop zone in the process. Obviously I can't actually do this with my current resource but if this is actually going to be a fully game, it would be something like that. Maybe in between add in some stories and drama of course, haha...

Tile System Upgrade Progress and Design

The tile system upgrade is progressing slowly. I am still in the stage of setting things up. The first thing is to get a stage displayed properly.

I think I have finalized the design on the tile system variety part though. There will be 3 types of decorations in the tile system, which is illustrated in the above picture. I won't go into the technical details because it's difficult to explain in words, although it's simple concept. The first one shows floor consists of similar tiles. There are small differences, but they can all be connected together. The second one is best described as a "lawn" or cover, a tiled decoration on top of the tiles. The third one is already implemented, in which 2 different sets is used in one stage.

Originally I have something that might be more flexible in mind, but it's way too complicated and might not even work properly. The added flexibility might not matter that much at all, and this design require less work. So I think I will stick with this design, unless something ingenious pop ups in my mind later.

Created GameEngine Project

After some development on the editor's visual system, I suddenly realize it might be a good idea to move all the classes etc from the main project into a separated LIB project. By doing this, my editor in theory can just reuse the same code my game is using for the visual. For example, if I just initialize and use battleView class I should be able to see the same thing I see in the game. Also, it makes logical sense, seems to me, to group code above the lower level independent LIB into a LIB of its own.
I am thinking if I can just use the same classes such as stage etc, but I have to make some additional functions such as addUnits, deleteUnits etc into the classes to make it more dynamic and easier to be used by the editor.
I have already moved the files and setup the project properly. Necessary backups are also created. Now I am ready to commence the next step.