Load Complete

Finally got a chance to finish the loading tile part. The implementation went smoothly. Looks like I am ready to move on to the next step...

I think next I will attempt to add in the enemies. Also have to scale the model into the right size...hmm...I should be able to do this with proper export setup though.

After that I should try to add the weapons...and projectiles...that is going to be interesting. This part is probably going to be another big section though...although weapons and projectile looks like small things but they can be a totally separated system on their own...perhaps I need to separate this into finer tasks:

• particle and explosion animation system
• weapon and equipment model attachment
• weapon control
• projectile and projectile collision calculations

Damn...that looks like a lot actually...

Editor Stage Save and Load

Right now I am still working on the save and load feature of the editor and application. But so far it doesn't look complicated. Each object will save its own data. When loading though, object might need to be created with those data as parameter so it's probably not possible every object loads its own data.

One thing I did significantly different on the editor from the last game is the way the program determine which tile block to put, and it seems to work out much better. The way I am doing now is "dynamically" determine the block to use when each time a tile is added to the stage. The way I have set it up (adding 4 tile at a time), each time a tile is added, the tiles around it and itself has to determine which block to use (2 border, no border, 1 border etc). The important thing is: the recalculation does not traverse beyond the immediate surrounding tiles. Even if it does, it's actually ease to use recursive functions algorithm to go beyond the surrounding tiles, which is much more CPU intensive, but I am 99% certain that is not necessary. To be 100% sure I probably need to do a mathematical proof on this lol...that would be a nice computer science exam question, but hey, I am just trying to make a game here.

The algorithm I used last time is to do the block determination after all the tiles placement has been determined. Doing it this way has 2 disadvantage:

• The determining functions became long and complex. Very difficult to manage. Although I am not totally sure, but I think the new way will actually cut the complexity down.
• The user cannot see exactly what they will see in game when they are using the editor. Obviously it can be remanded with a refresh button or just do recalculation of the whole thing when the user add a tile. But both are inferior to the new one, in which the user has immediate feed back with much less recalculation resource.

I actually thought of the new algorithm half way during my development of the old algorithm. But I wasn't too sure if the new one is easy to do and I was already half way through. It seems now the new idea is much better.

Interesting, 10 Commandments for Management from Capcom

Gamespot Report Link

1. Keep staff turnover below 10 percent per year
2. Maintain ability and cash reserves to increase personnel by 10 percent each year
3. Keep development cost fluctuations within 10 percent
4. Investment in new IP needs to be kept within 20 percent of company-wide development budget
5. The structure and organization of the company needs the flexibility to change in response to growth; goals and objectives must constantly be reviewed
6. Goals and objectives must be adaptable to external forces (see Square Enix's decision to move its Dragon Quest series to the Nintendo DS)
7. Objectives and aims must be set from the top-down
8. Reform must always be undertaken from the bottom-up
9. There should be no taboo areas when it comes to reform. Reform must be undertaken at all costs. (This lesson from Toyota, where management and developers worked together to create a problem-free work environment.)
10. Set achievable targets; unachievable goals bring down motivation

"But more than any of those rules, Takeuchi said the most important aspect of Capcom's success comes down to one simple rule: Whether the users enjoy the game or not. All of the company's development efforts must be focused on making things fun, he said."

Interesting Stuff...

Editor Progress

The basic tile construction function are now setup. It's far from over...but it's progressing nicely.

Editor Setup

I was able to get some basic setup into the editor. I have added a new class EditorLogic, in parallel with GameLogic, that will take care of the general editor operation (add entities, remove entities, save, load). So far the system seems to work out well. I was able to add in tiles with mouse clicks quite easily. Also I was able to use the same debugging message mechanism I used in the game application, except it's display in Windows Form instead of CEGUI. It seems to show that the initial architecture of the system is quite adequate, and working out well so far.

But right now the "picking" system doesn't seem to work accurately. Right now I am just using the same Project and Unproject technique I used for the robot movement boundary detection, but it seems to be off. Now I think of it...it could be that the sprites are drawn half way off from it's position, in another word they are drawn with their center on the position, not the corner. While when I am calculating the picking position I am using the corner...that's why it seems off. Anyway, I should try to figure this out and use a consistent coordinate system (either use the corner or the center). Another thing that really got me confused is I need to multiply the 2D sprite entity's position with it's width and height...it's just weird. I have to review how I calculated the size and position of the sprite etc.

And if the picking is still not accurate enough...then I have to consider using a more conventional method:
http://www.toymaker.info/Games/html/picking.html
http://www.mvps.org/directx/articles/improved_ray_picking.htm

Progression

Some progress has been made. I have now the basic setup:

• A robot with aim and move animation setup. Possible further animation and refinement on the leg animation can be added later, but right now it's not priority. Weapons, Jet pack and weapon pack is now also possible to be added in.
• 3D coordinate to 2D screen coordinate calculation and its reverse, 2D to 3D, has been setup in camera. The function D3DXVec3Project and D3DXVec3Unproject basically do all the work. The calculation has been used to bound the player inside the screen. Later it would be used for HUD Gui such as lock-on symbols etc.
• Encounter some weird problem regarding incompatibility of managed and unmanaged code on GetInst function of Engine class, when trying to compile the editor. It's using static for Singleton pattern. The implementation has been changed to follow exactly the code in the book Design Pattern, and the error is avoided. I am not certain what exactly is the problem though. It's probably safer to make other Singleton class use the same setup for consistency and safety later.

Here is a list of possible things to do next, other than the ones mentioned above already:

• Stage setup in the editor...this is long over due, and without it the game cannot be setup properly. I should take this one slow and easy though,...rushing it will only cause problems probably. One thing I have to first is to check if I have something setup before already, and if there are reusable stuff from previous project.
• Add in enemies.
• Stage scroll process...most likely just need a universal scroll speed, which will be added to the player robot and camera.
• HUD GUI setup...this is probably on the lower priority. This time also I should keep things really simple.

Design Simplification

Boy...the more I thought about it the more it become obvious that my initial design of robot control is still too complex. It's not just the possible amount of code and animation it required but also the design of motion etc is just mind bugling.

The problem is regarding how the robot should look, which angle, how to rotate the upper and lower body, does the robot do side slide motion, or does the lower body just do it independent orientation? Would the motion look awkward.

Plus the amount of code, animation etc that is potentially required...and I am not even sure if the end result would be good gameplay or would it looks good.

I think with my limited resources, it's better to keep it simple. Creativity is essential but when it's costing a lot of my effort I should trim it down. The most important goal is to have a working game that's fun to play after all. Although it's nice to put new ideas in, but some of the ideas, require a lot of prototyping I think, because they weren't done before and there it's hard "visualize" the result. So perhaps for me right now I should keep to what I know would work, and finish those first.

So here is a new simplified design: Just do it the side scroll shooter way, and let the player aim from approximately 45 degree above and 45 degree below ahead. Later, if gameplay requires, a key can be added which will just turn the robot 180 degree, facing away from where the stage is scrolling, allowing the player to shoot behind.

I think doing it this way could potentially be more fun to play, because it limited the complexity of 360 degree aiming. 90 degree aiming might be more manageable in shooters without demolish the original idea behind it.

Of course...this new design was made possible due to my experimentation on the animation control...so it's not all a waste of time...

Animation Progress and Adjustment in Design

I finally have some sort of full control over the animation, and I am also able to have arms and leg animation at the same time. The above is a screen shot.

I have also setup the debugging message window properly...not much work, but it actually helps a lot. I think real time message window is particularly helpful in game development. Of course other tools like debugger is very useful as well in certain situation.

Also, I have decided to separate the upper body from the lower body again...due to complexity in terms of aiming animation and rotation of upper body etc. This is also due to a change of design in rotation and aiming angle calculation, because the original design has a small flaw in it...it's all kind of complicated and hard to describe in words...

But right now I have another set of problems. For some reason the arms are rotating in opposite direction...I wonder why.

Animation has been far more complicated than I thought...perhaps I should really have just stick with triangles and other geometric shapes when I am doing this game...but then again there won't be much challenge and fun doing that...Still, perhaps I should have setup simple triangles etc before I jump into the complicated stuff. Anyway...I guess after I finish this animation thing I should really get back to the actually game logic codes. But with this setup though I should not have too much trouble setting up the enemies etc because the basic structure and functions are already there to be utilized.

Another thing I have to keep in mind is perhaps that the animation and 3D model should be the "most" complicated part of the game. Nothing else should exceed these complicity until I finish the game...this is to keep things clean and simple, until I finish it. Afterward, further steps can be determined. But right now I really just have to focus on finish the first "cut."

PS. Something small but worth noting in the recent development is that CEGUI seem to disable z-buffer test, which caused the weird graphics problem I noticed recent. After I re-enable the test things look much better.