Starship Troopers After thoughts

Another interesting thing worth mentioning is I read the sci-fi military classic Starship Troopers by Robert A. Heinlein. Of course it's much better than the movie, haha....It's a controversial book, and I can see why some people might dislike some of the ideas in the book. Some ideas seem plausible, but because it's so different you wonder if it's actually good to think that way. Nevertheless the book has some very interesting ideas about politics and military.
What's important here though is it might give me some new ideas about my games etc.

Starts on Tile System Improvement

I finished the fire direction joint modification I mentioned in the last blog, but I think I sort of run out of steam on the weapon system. Therefore I am going to take a break from it and do some stage construction improvement. I already setup the weapon system to be quite flexible so it should be very easy for me to come back to the weapon system and finish it off later.

The stage construction improvement is actually a big job. I think it can be broken down into the following tasks in order:

1. Improvement of the existing level editor's visualization.
2. Improve tile varieties.
3. Height map offset.

For the first step, currently the editor's visual is a basic 2D display, with symbols representing each layers. It was first constructed by his excellency Mr. Evil Dan, and later on I added new functions etc. But right now it seems in order to make the stage look better and to make the construction of stages easier, a 3D visualization is required.
There are bunch of details regarding step 2, which I still need to think about. But for now step 1 is enough work for me.

Multi-Missiles Progress

I took a little break, and now I am back into the multi-missiles launcher implementation. I have already setup the model and the XML setup files, and start the implementation. I have to change the firing direction to use the fire_dir joint in the 3D model like the fire particle system. This seems reduntent at first since the angle offset I implemented for the shotgun can already do this, but actually they serve different purpose and also it make more sense both for convenience and logic to have the projectile fire in the same direction of the particle. If I just use the angle offset, it would be hard if I need the direction of projectile and fire particle to be exactly the same because one is adjusted by setting the joint the other by setting number in XML. If I just use the joint, it would be difficult to implement shotgun (needs lot of direction joints) and guns that fire bullet in small random offset angle to simulate inaccuracy (often used in machine gun type of weapon in other action games, this feature I might implement as well).
Another thing I am concerned about is the Launcher class design:

1. Every Item has 1 launcher, each laucher can have multiple fire points
2. Every Item can have multiple launcher, each launcher only has 1 fire point

It's hard to say which one is better, or should I say I am not sure which level of abstraction the launcher class should be in. But right now I pick the first option, because it seems to keep the details of weapon lauch system in lower levels and in tighter control. Of course if later I found option 2 to be better I can always modify the code.

Shotgun Complete!

The first new addition of the robot's arsenal is finally complete. The effect is pretty good.
The next thing to do would be the missile swarm, which shouldn't be too difficult because some implementation is already done by the shotgun feature. The only thing I might have to think about is each missile might have to track different targets, so things like target selection might require some design.

Weapon Sys Improvement Continue

In the past few days I have clean up some code, and added in projectile speed, damange, range etc into the property file. I am now start to add in the multiple missile and bullet launch feature, and explosive amunitions. Two more projectile property settings need to be added. One is the firing angle offset, for multishots feature. The other is the damage radius, for explosive shells.
One thing I haven't made a decision yet is: am I going do a grenade throw trajectory thing like in Gears of War, using the mouse indicator as the destination, or do I just make the grenade fly in a straigt line and detonate on the destination? The first option is definitely more work, so most likely I will use the second option to keep things simple.
I already started to implement the shotgun feature. The shotgun I am trying to do is more similar to Contra one rather than FPS ones. Seems quite easy to implement actually. By adding multiple projectile properties into one item property file in XML format, I have good control and flexibility. It's also possible to make a gun firing different shots with the system, although most likely I am not going to do that. I have already setup the angle offset property, but still need to do the proper matrix transformation using the given angle to get the proper firing direction of each shot.

Projectile Setup Improvement and Starcraft Observations

Today I did some work on implementation of the projectile setup in XML. Before the projectile property, such as speed, trail texture, hit explosion effects etc are hard coded for different type of projectile, such as bullet and missile. But with the new property setup in the item property file, I have greater control over the projectile property. Now I can have different missile type, different guns etc. It make the weapon system more complete. I still need to finish the rest of setup property off, clean up and test. The next step in the weapon system development would be more different type of firing such as spread shots, and new type of weapon like grenade. The screen shot shows the new particles from submachine gun bullets and missiles.
Also I reinstalled Starcraft, play it a little, and test out its campaign editor. As expected, it gave me some new ideas about my stage editor. From my observation so far, it seems my stage constructor is a bit more complex and versatile in some way. For example, my stage can have elevation of different height, while the Starcraft's stage seems to have only 1 higher elevation, 1 middle and 1 lower elevation, and some impassable terrain (like water, ceiling and bottomless pit).
The ideas Starcraft given me is great. From my observation, it seems the sides and top of a tile's texture is randomized. It meant in one tile set, there are different sides and tops, each can be combine with the others, which is unlike mine, which only has 1 type of top and 1 type of side for a tile set. But I think it's actually not too difficult for me to implement multiple sides and tops for a tile set, ie it will fit well in my current system. This implementation will give me more vividness and variety into my stage environment. Another interesting thing I observed is the "ceiling" tile in the installation environment. From my current understanding it's just a impassable obstacle. I actually had the same idea before: tile that indicated as wall so the player can't jump onto it. I wasn't sure if it should be done or how it should be done, but the SC editor might give me some ideas.

Further Particle Refinement and New Models

Today I was able to further refine the particle animation. There are some problems in terms to determining when the particle should disappear etc for the loop animation particle currently used for jet and gun fire animation particle. It was actually a small miscalculation in the update function that either cause the last from not to show up or particle not disappearing when it should. There are further refinements still that I wanted to be done with the particle system:

• With the new trail particle class I think I might be able to do some of those explosion smoke.
• Some of the artwork such as gun fire and missile fire needs some refinement.
• Adding particle color definition in the particle XML setup file might also help quite a bit.
• Double check the particle system code, and refactor the codes if necessary.

Another thing I am doing recently is refining the weapon system. I have recently added a new backpack and submachine gun model, as can be seen in the partial screen shot. The one thing I notice is with a top down view it's hard to distinguish equipment etc, if you try to make them "realistic." (like grayish, dull color used on most of the firearms) I guess that's one of the reason why a lot of games like Starcraft 2 uses brighter and more colorful scheme for the units and weapons etc. There are also a few things I wanted to do with the weapon system, some have been thought of for quite a while but haven't been implemented. I will just list them here for a record:

• Shot Gun (spread gun)
• Missile Swarm
• Traditional ballistic bullet (currently all the bullet in game looks like plasma type of weapon)
• Laser weapon
• Charge up weapon (hold mouse button to charge)
• Grenade type (explosive fire and detonate on the location indicated by mouse cursor)

Some of this idea can be implemented fast, but some require a bit more collaboration between game engine mechanism. For example, the grenade weapon would need area damage effects.

Another interesting game mechanism I thought of is an "Special Relativity Field." It's just a fancy name of the circular field in which all enemy projectile enter would slow down. It might be an interesting thing to implement because in a lot of side scroll shooter, the enemy bullets fly slower than the player bullets, to give player the possibility to dodge bullets. I also want the player in this game to dodge bullet like the side scroll shooter, so the SR Field would give a reasonable explanation on that. The amount of slow down would depends on the player robot stats and equipments. But I have to say this idea is not new. I might have been subconsciously inspired by the Starcraft 2 Mother ship special ability seen in the trailer.

At this point I start to appreciate having a team working on a project instead of one person. Because game development has so many different component in it that requires full time attention. If someone can work on the weapon and particle system, I can focus on the level look and feel and tool kit aspect.

Trail Particle Refinement

I have finished the basic step of refining the missile trail particle. Originally the trail particle clamp 1 texture, which causes stretch. The stretch effects the control over the trail image. For example, when the missile fly fast and the trail is long, the image get over stretched.
So I changed it to use repeat texturing, and separated the trail into 2 parts: the head and the trail. The head just use half of the texture image with no repeat, so it has a specific shape. The trail use the other half of the image, and use repeat texturing to cover the rest of the trail particle.
The screen shot is the current result, but further refinement and testing is needed. Most likely on the texture needs to be changed.

Tile System Look And Feel

Today I saw more screenshot of Starcraft 2: http://www.gamespot.com/pc/strategy/starcraft2/news.html?sid=6187499&tag=topslot;title;2&om_act=convert&om_clk=topslot

It make me realize once again: that is the look and feel I want to have in my game. Imagin controlling a robot, battling other robots and aliens in that environment. In fact my game's tile system is inspired first by Metal Gear Solid: VR mission, Starcraft and Neverwinter Nights.
Of course I am not sure how things are done in Starcraft 2, but obviously I cannot do it exactly the same way as SC2 because I don't have that much art and programming resources to achieve the same effect. It looks simple but I think there are a lot of details that require quite some work when observe closely. I think that's one of the reason Starcraft feels different from other RTS such as Supreme Commander and Command & Conquer series. Neverthless I think I will reinstall Starcraft or Warcraft 3 and then use it's editor to recheck if there are other ideas I can use.

Right now I think the tile system is working ok, so for sure I won't make any major changes. But recently I also thought of other things that can be added into the tile system, although not sure if I am going to do them at all:

• One Piece Tile idea: allow the level designer to add in 1 3D model as a whole piece of tile (similar idea to my one piece GUI and tile gui type separation)
• Height Map layer: allow the level designer to manipulate height difference using on a tile layer. The existing tile layer system would be used but the vertice will be manipulated according to the height map.
• Decoration pieces such as cans, rubbles etc often seen in games.

The height map layer and decoration pieces idea is probably very easy to implement. The one piece tile idea might be easy to do but the collision detection and game play effect would have to be considered. Also, all 3 of this ideas require an improvement on the current level editor (have to use 3D instead of 2D). Talking about the editor...another thing I should do is to move the which tile to use decision from the game into the editor probably.

I think this level design and construction in games is a huge part of game development. All the different possibilities that can be considered, and so many different ways of going about it (Gears of War, Neverwinter, Morrowwind, Starcraft level construction are all different). Even in simple things like how would you represent a "wall" in the game can have an essay behind it. I think you can actually write a book on this topics.

Limited Resource Generates Creativity?

Today I was pondering on how to do a missile swarm type of attack often seen in robot anime and other games. The problem is I don't think firing the swarm forward would look good, because most of the time it will just go toward the targets in almost straight line, without much turning. To create a good looking swarm, the missiles might have to be fired backward or in other direction first, like most of the other anime and games have done.
For the past week I was thinking of using the backpack as missile firing module, but that idea always make me feel like I am making a mutation in the current game design that would destroy the elegancy. The original idea is left mouse button and right mouse button for firing weapons. If I use the backpack to fire then I have to count it as a special ability, add in a new key for firing missile, like the space bar. Or I have to count it as a left or right hand weapon setup. Either way doesn't seem to be good.
So in the end I decide to stay with the current way, and keep things simple. The only thing I have to come up with is a special type of arm-hold or shoulder mount missile launcher that would launch missile swarm.

Progressing

Today I was able to add in some small details:

• Made and test with new level tile set, and fix the stage change exception (there might be some problem in the editor save which I have to double check later. The HUD seems to work well with the new tile set, so I guess there is not much problems with the HUD setup now.
  
• Made the mouse cursor location limit circular instead of rectangular.
• Backpack model texturing
• Add model for the entry point.

The next thing I have to do is adding in the rotating animation for the entry point, and a label indicating the name of next stage, which shouldn't be too big of a problem. But now I am facing another deli ma...the robot model doesn't seem to look good from too far away.
Another thing I really have to do is add in a boss, and see how it plays out. Because I need to see if the current setup and handle a giant enemy units with bullets flying all over the places.

Switch

Hehe...just found out google has blog service so I am just going to switch from yahoo geocity and try it out. Previous blog here: http://geocities.com/xcom542000/blog.html

I have implemented the zoning system mention before and here is one of the screen shot. Although I still have to refine it, like make the cursor go only inside of a circle instead of square, and adjust the radius etc to make the play easy.

But right now I am busy adding a new tile set because I want to see the HUD work and can be seen clearly in different background.