Enemy Unit Intergration

Finally, I integrated the enemy entities into the game. Actually I don't have to do anything. But I forgot to tell the GameLogic class to load the DataManager as well, which result in empty enemy model paths. Took me a while to debug but now it's fine...Once again I guess it shows a good low level software design can save a lot of headache and time, but I would also say nothing is without flaws, especially in software...But I wonder would software development experience help in this? But in the past it seems to show the older software developers have a disadvantage because they cannot learn as fast also the mental power of the brain just cannot compete with the younger people...This is indeed an interesting question. So I would guess...the better programmers are probably those that have already acquire substantial experience and knowledge in software development but is also very young...hmm...sounds more like athletes...That sucks.

Enemy Units Setup

Last week was able to setup the enemy unit setup function in the editor. Now the editor allow the user to select an unit type and then put it into place. I am now working on the loading part of system, but was unable to work on it for a while due to other things I have to do.

The nice thing about it is the user can see the units right on the screen of the editor. I am quite convinced that a good game requires a good editor now.

UPDATE: The load function is completed...what I should do now is probably to make sure the game can load all these in.

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.

Animation Track Control

I have finishing the setup of the animation control structure, and is now in process of implementing the actually control calculation. Currently it's still not functional and further experiment is required.

The first thing I have to verify clearly is if negative speed in track works, or if only positive speed works. I think what I need to do is just to modify the SetTime function to use positive speed if the unit goes right, and negative speed if it goes left. Only after I confirm the validity of negative speed, can I proceed to the next step.

Though I already have a clear idea about the next step. If the negative speed works, then I just have to try to tell it to use negative speed, and making sure the target time calculation is correct for both positive and negative speed. If the negative speed doesn't work, then I have to create a "negative" track in the model animation, and covert the track position from positive to negative track according to the situation.

UPDATE (Jan 27): It looks like the negative speed doesn't work. I have setup the "negative track" in the model and develop the control code accordingly. It still doesn't quite work but I think it's due to minor bug in timing calculations. After I fix them, I should have a working and quite robust animation control.

EntityAnimator Construction

After some more development, I found it appropriate to separate out a new class, basically a controller of the animation's entity. It will be build around LPD3DXANIMATIONCONTROLLER to take command from Unit class to control the animation tracks, timing and their calculation.

Like always, I am not totally sure this is a right design decision. But right now it looks like a good one. It makes the code look more manageable and it does make logical sense. Makes me wonder...when can I actually be 100% sure in software design? Could it be never? lol

Animation Control Development

After quite some experimentation, progress has been made on the animation control. Now I can stop the animation and set animation time position. I think next I will continue to setup the functions and structure, to support multiple tracks and tracks blending. Hopefully eventually things will work out well and the upper and lower body animation control and blending will work as I expected.

Inspiration from Space Rangers 2: Rise of the Dominators

Recently I didn't do a lot of programming...guess I was taking break, but now I am ready to get back into it I think.

But time was not wholly wasted, because I went back and play a little Space Rangers 2, and got some new game inspirations. |0| To describe the idea in full, I have dissect my view on the pros and cons of the SR2 gameplay:

Pros:

• Freedom and Open World, but still Entertaining - a lot of open type of games are extremely boring, such as Oblivion (a lot of people will disagree, but I just find it boring for some reason) and quite a lot of those free MMORPG. This game gives player a lot of freedom but is surprisingly entertaining and addictive. Perhaps it's because it presents an achievable Meta objective: solving the Dominators problem and save the galaxy.
• Sci-fi Space Opera Adventure/Comedy - It's a rare genre in game...perhaps a lot more games should be made in this area.
• Some interesting Combat Idea - during combat players can call other ships around the area for joint attack. Also player can go with fleets to attack Dominators, to defend and liberate systems etc. It's like participating in the grand opera and have small dungeon crawls in the same game. Other games also attempted similar things before but in my opinion this game seems to have a major break through in this area, although there are still possible improvements.

Cons:

• Combat Could be Boring - not much to do for players during combat. The player of course still has to decide which targets to attack and whether to run away. But it seems the combat could be more exciting.
• A lot of Traveling - a lot of flying around between planets, which take times, during which players don't do much. For more casual game market this can be detrimental because a lot of times players want to have the most enjoyment in a short period of time. While traveling player can relax and take it easy, too much of it make the more enjoyable parts of the game far in between. It will make the player feel they have to invest a lot of time and "labor" in one session to enjoy the game.
• Some of the Mini-Game - some of the text mini-game is just a bit too tedious. The worst one is the one in which the player has to read a lot, and it does not help when the font is tiny.

So taking this into account, I think it's possible to make a new game but retaining some of the pros of SR2:

1. Open space and freedom of action like SR2
2. Better convoy / strike group supports: The player can forms convoy with cargo ship, warship and fighter crafts to do trade or transportation mission. Or they can follow fleets to engage enemies. The elements is present in SR2 but it seems more user friendliness on this feature might be very possible.
3. Space Sim combat: Use Freespace 2 type of combat instead, but with a greater variety of ships which the player can command, ie larger vassals.
4. Faster travel for travelling between planet and star systems: Have a time speed adjustable button, like in x-com, to speed up the time in long travel. Use a more abstract maps with 2D icons overlay 3D star system scape etc. This can look potentially very cool if done right, making the player feeling like they are really planing operations etc. When the player meet hostile forces and need to engage in combat etc, the game will lock onto normal time and zoom in to player's "cockpit" and let the player fight, or escape the field.
5. Scrape Some of the Mini-game: scrape the 3D ground RTS portion of the game IMO is probably a good idea. Put the efforts instead on the space combat. Keep some of the more interesting mini-games. Present the text game in a more interesting way with shorter text etc, perhaps.

The game might sound ambitious and might seems difficult to make (due to expense might go up geometrically because of combined randomness in SR2 gameplay system and the required 3D engine). However, I think with the power of computer still increasing...it might not be out of question in a few years.

Milkshape DirectX (JT) Export

After a second attempt, I was able to export using DirectX (JT), with the following setup:

• uncheck all options in geometry
• uncheck all options in animation, except "Exclude Options"
• Format: DirectX Skin and Bones
• uncheck all 3 (binary, template, S&B template) options

I think I will try to export with different animation set, and combine them into 1 file to see if it multiple animation sets works in this way.

I was also able to make further setup in animation control in the program. Basic animated mesh is finally close to completion.

Prince of Persia (2008) After Thoughts: Where Is The Donkey?

The following contains spoilers.

After finishing Prince of Persia (2008), the first thing that came to my mind is "where is my donkey?" The second thing is "ouch!"

After all the effort the player went through, in the end, the player is forced to do something that negates all the efforts they put in. Seriously, I never thought the main character is capable of such an act. What went through his head and what will happen next is a big question. I guess that's why they end the story like this, to make ways for a sequel. But the "cool meter" of the main character went down somewhat I think, and I don't think that's what the developers intended,...or maybe that's what they want? I don't know. It will be "explained" in the sequel I guess. But man...if I am the Prince, I will just go find my donkey. That will be a happier ending as well.

Overall the game is not too bad. The fighting is interesting, but not as good as Soul Caliber, which is expected. Still it could use some improvement I think. Another thing is perhaps they should somehow add back in one vs. multiple enemies scenario...because always fighting one on one isn't that fun without reaching Soul Caliber depth, and it doesn't make much sense in the story.