Man...part 2

After all the trouble, I finally found out the cause of the exception...basically I can't use any CLR compilation in any of my projects with CEGUI library. I might be able to do it if I compile CEGUI from its source code, but I think I won't bother to try that. For now, I will just have 2 compile setting, 1 for the game application, the other for the editor. In editor, it will use CLR and not using CEGUI, and in the application, the reverse will be set. That should solve the problem finally.

But man, I should have thought of this earlier.

Another thing is...it seems CEGUI changes the renderer states after it renders. Hm...shouldn't it restore the states instead of me trying do it myself? Yep...looks like nothing is perfect in this world.

Man...

It now becomes obvious to me that programming is a tough job. Actually I realized it before already but then I thought it would become easier. But now although I have learned a lot during the past few years, I still encounter problems which I just have no answer of.
For example, now I have setup the basic robot model and WASD control, I encounter a weird problem. Actually I have no idea if it's a problem at all. But it just looks to me the animation stagger a little every few 0.1 second. I have set things up, including the timer, the same as the previous project, so why do I see this thing which I have never seen before? I have no clue what it is.
So next I thought it would be nice to setup the frame rate display to check if it's just the lower frame rate in Debug mode that's causing the problem. I thought I would setup CEGUI first because I always wanted to try library, and I am too lazy to setup my own GUI library again when someone else already did a similar thing. And ha...after I set it up all the problems starts to pop up and burying me alive. First of all there seem to be a incompatible issues between CEGUI and Windows Form (or CLR), then after I setup another project using Win32 project, it compiles but has a StackOverflow problem...which I have absolutely no clue how it occurs.
Eventually I will solve the problem most likely. But I just realize once again how tough software development can be even if I have certain amount experience in it...no wonder people usually underestimate time required during development, because it looks straight forward but then problems big and small just keep poping up. I wonder if most programmers in this world have similar experience.


And here is how the game looks now. No proper lighting has been set yet, only color value is used. I think this time I should also try Cel shading...it might be a cheap way to make things look good (I highly doubt it but it's worth a try)

Now Attempting to Setup Robot

I have setup the basic tile system. The tile image selection algorithm has not been implemented yet, but it's more cosmetic and therefore can be implemented later.
I will do it step by step. First I will try to export the model to X file used by directX, then make it show up on screen. Next I will try to animate it.

Thoughts On 3DLTS

I invented 3DLTS approximately 1.5 years ago. Originally I got most of the game to work but the stage just looks blend, and I was looking for ways to make interesting stage or maze without too much work on using 3D modellers. I was hoping to have an easy to edit systems which I can use to create a lot of different stages without too much efforts in creating art assets. It was a great idea at first I think, but the system proves to be complicated and hard to implement. In the end I get it to work, but it's still difficult to manage, create its art assets and it's hard to debug. Various improvement has been made to simplify the process. But during development, not much consideration has been given to the editor. So when an editor is required, it creates further complications. Although most of the difficulties have been overcome, it's not a system that works perfectly. Other unforeseen complexities effecting the game play etc also occurs. In the end it's a system that cost more than it's worth.
So yea, the system works and looks nice, but after some thoughts I think I still made the right decision to abandon it for now and to create a simpler version of it first. Perhaps later my other game ideas can use it. But first I have to make a simpler version of it to work well, before I can make a more complex version of it.
Keeping it simple is still the key, especially for this no budget project.

Tiles Data Structure

Currently I am setting things up in GameLogic and StageMap classes so I can have the tiles entity shows up according to the specified XML file.
It brings me to the design issues with the data structure storing the tiles. There are several possibilities I can think of currently:

1. Using array: use an array, and each tile keep track of it's position.
2. Using double array: use a double array to represent the position of each tile.
3. Using "Link": each tile has a pointer to the tile next to it.

I might end up using combinations. Perhaps what I need to do is try to implement the feature (tile setup, multiple set of tile, randomizing, fusing, collision detection), and using search function (GetTile(X, Y)...etc) to access the tile, regardless of the data structure I am using. Then improve the data structure to minimize the access cost. I think that will minimize the change I have to make, also leave room for possible improvement.

Perliminary Setup

Here is an image of the prototype setup. Some of the game classes etc has been set, but this is just a test scene using Microsoft Direct X example and using D3DXSprite.
This time around when I design the program etc I think I will also take into account the editor at the same time. It might make things easier. Maybe even develop them concurrently. Still, I have to remember the principle this time: keep things simple.

Robot Control Design and Animation

Here is the design of the robot control after some thought:
The idea will be the same as the previous OMA. IE. The robot's upper body will be rotating and can fire in all 360 degrees. However, this time the robot will be view in complete side way (no tilting). So, at the same time the body is rotating, the arm (and the body will partial tilt as well) will tilt to aim 360 degree with Z axis. IE. the body will rotate with Y axis at the same time the arm will rotate with Z axis, while the view will be complete side way, looking down the Z axis. Ex, arm tilt 45 degree, body rotate 45 degree (counter clock wise). The rough picture above will illustrate the concept.
This way, the mechanism of shooting in all direction will be maintained, while the style of the game is good as well. To implement this, the most likely method I thought of now is to use 3D editor, to do a complete arm direction animation, with key frame at 0, 45, 90, 45, 0, -45, -90, -45 and back to 0 degree. Setting the frame between this animation as 360, I should be able to use each frame according to the direction the player is aiming. The rotation of the body will be the same as the previous OMA.
Another thing is the boomerang throwing animation. It poses another problem. But I think if I tilt the upper body a little, and making the animation of the throw a vertical movement (arm raise then goes downward to throw), I can get away with it. (It will look like the robot is throwing it upward or downward etc). Another way is to make just 1 set of throwing animation, but tilt the whole robot robot to face the direction it's throwing (ie if it's throw down, the whole robot will face down). This might work as well. But these are aesthetic concerns which won't impact the game play.