Sunday, February 28, 2010

Doodle Blast! - Day 1 - The Prototype

Stats: 38 code files, 2562 lines of code, 2 textures, 6 sounds

As I said earlier, day 1 consisted of me cheating because instead of spending the promised one day, I actually spent a weekend getting a running prototype together. I ended up borrowing code heavily from Pop Fizz. I didn’t have to re-implement asynchronous data load, animated particle systems, and persistent state storage. What I did end up writing was the basic structure of the game, a class to abstract out the tank guns, and a class to abstract out projectiles.

The big question I wanted to answer was whether to use a full-blown physics simulation or whether it would be sufficient to just fake it. All I really needed was a position, velocity, and acceleration vectors for every item on the screen and a full physics engine seemed like an overkill, not to mention a computational overhead. I also needed to solve collision detection. Simplified collision detention can be easy to implement, but I needed it to be fast. So, I sat down and started to write a spatial hash mechanism that would help me speed up the process. Half way through that effort I realized that I’m not being very smart because a physics engine would give me all of these things for free. I hence gave up and embraced Chipmunk all the way.

In the end, that ended up being a great decision. The final game uses Chipmunk not only to move things around the screen and detect collisions, but also to simulate bumps on the ground, stack guns on top of each other, and model the final explosion of the tank when the player dies. As far as overhead goes, it turns out that Chipmunk is pretty efficient at what it does. More importantly, version 5.0 came up with some really useful enhancements that allow you disregard unnecessary computations early on. In addition to breaking objects up into layers and groups, you can specify custom collision handlers that can have up to 4 callbacks through out each collision event:

  • Begin: Two shapes just started touching for the first time this step. Chipmunk has not yet calculated collision forces for this collision, and the preSolve() and postSolve() callbacks have not yet been called.
  • Pre Solve: Two shapes are touching. Some collision force computation has already taken place.
  • Post Solve: Two shapes are touching and their collision response has been processed.
  • Separate: Two shapes have just stopped touching for the first time this frame.
(adapted from Chipmunk docs)

For the most part, all I care about is the Begin event. It signifies that a bullet has hit an enemy or a player. I don’t actually care about the collision forces, so the calculation is pretty cheap and can stop right there.

The physics decision out of the way, I wrapped some sprites around Chipmunk bodies and this was the final result:


You will notice that I added a simple tutorial place-holder right from the start. My tendency is always to leave the tutorial until the very end at which point it’s a pain in the butt to stitch it into the game. So, with this project, I wanted to make sure that tutorial was built into the game from the get-go. The final tutorial ended up being pretty much identical to this one and having it there from the start saved me some head scratching later on.

You will also notice that the guns themselves are animated. That was a big part of the visual appeal for me, so I wanted to test that behavior right away. The initial gun logic was pretty straightforward – aim, shoot, and cool. As I will talk about in a later post, this implementation was too simplistic and I had to create a whole state machine to model each gun. But more on that later.

For now, this was as far as the two days have gotten me, but the results looked promising enough to keep going.

3 comments:

  1. this is just what the developer community needs. please continue posting about how you made this great game!

    ReplyDelete
  2. Would it be possible if you could please post an article about how you animate the guns and the soldiers and everything else. I'm just curious how you can make the soldiers run and how you can rotate the barrel of a gun up and down... They are just images that you load are they not? How can you then 'break' the images at certain points to allow movement of of certain parts about that point? That would be awesome if you could explain that.

    Kind regards,

    J_Mak.

    ReplyDelete
  3. Basically, the are "composite" images. Each gun consists of two images: the turret image (which doesn't move) and the gun image (which moves and scales when the gun fires). I overlay one on top of the other, and animate the "gun image" based on user's interaction. End result: animated gun sitting on top of a tank.

    As far as the soldiers go, it's a simple animation of 6 frames, I think, that I drag across the screen at a constant speed. It looks like the soldier is running, but, really, he's just sliding along.

    That's all the magic there is to it.

    ReplyDelete