This Is a Small Step For a Zombie, But a Big Step For a Developer

This week I’ve been working on the physics system for my game. Initially I was wondering a about how much work it would be, but so far the progress has been as good as I could have hoped. While I’ve been getting physics simulations (and faster collision detection that comes with it) I got couple of good practices that have been helping me so far.

Prototype outside your game (at least some features)
Okay, this might be pretty clear to many developers, but not perhaps for everybody. Some developers might try prototype inside their game. This means loading the levels might take time, compiling might take more time, and testing might take long time (unless you happen to have some sort of real-time scripting system in place – which probably won’t help when integrating physics in the game).

Anyway – instead of trying to get boxes and spheres move in the game, it’s better to do prototypes that first work outside the game. This worked for me, and made doing physics related code faster.

Break big changes into smaller changes (and prepare for changes)
This tip might also seem quite obvious, but it’s easy to forget. I prefer working on small steps – completing little by little than by trying to do a dramatic change all at once. When putting something like physics in the game for the first time, it probably requires quite big changes. Instead of trying to get all done at once, I split the big task to smaller pieces. Instead of changing the whole movement code, I simply added physics and let them work side-by-side with the other code.

After I saw that physics stuff was working, I started removing the other code little by little (or ‘module by module’). This way there wasn’t like a 3 day period when I could not have been able to build and test the game, but rather so that the game could be tested almost all the time (since I was making sure it was working after I was doing changes).

Do things only once…
I had done a very rough level editor for the game. When I started doing the physics system, I started to wonder if it was worth the extra effort to have separate level editor. I realized that with some changes in the main game code, I could integrate the level editor inside the game.

I decided to have level editor inside the game, and within just a few minutes I was able to save levels inside the game. I need to move some functionality from the old level editor code to the main code, but with this change, creating levels (and testing them) without external editor will be a really pleasant to users as it all can be done inside the one program.

Pretty funny thing is that I’m quite certain that the level editing might work during a multiplayer session (if you play as the server): you could be editing levels while playing the game with others. No idea if that’s any useful feature (or whether I intend to leave that in the final version since I have no guarantees how stable it would be), but I think it could make a fine feature when tuning the gameplay.

…and surprisingly good things will follow
One another good thing occurred. When putting level editor inside the game, I realized that I had (accidentally) created a save & load functionality. I could use the same code that’s used to save levels, to save (and load) player progression. Saved files would really be levels, with certain starting conditions.

The floating zombie
Oh, and here’s the video I made after seeing the first physics code inside the game. I had first created several physics prototypes outside the game (without using any models from the game) where I could move, jump, shoot and so on, and then started porting these prototypes to my game. You can bet your left leg that seeing pieces from the prototypes inside the game felt darn good (I know in this video all the 3d models are in messed up positions and the physics models aren’t done, but at least I’m controlling a game character and seeing physics working inside the game).

Please notice that this is very, VERY early video where the physics models, animations & 3d models don’t match at all.

Juuso Hietalahti


  1. I think textures do take time to load, but not because what you might have thought.
    I found(and I might be wrong about this), that decompressing the texture files into a raw bit map, might take alot longer than reading a raw texture bitmap from the hard disk.
    Reading from a hard disk that is not SCSI could take as fast as 70MB/Sec.
    A SCSI HD would read at about 1.5GB/Sec.
    While using the CPU to decompress textures might be suprisngly slow, in some cases.

  2. psycho: good tips.

    Leadwerks. ODE has worked greatly for me (and it’s something I’ve used in the past – so I’m familiar with it) so I see no reason to change it to newton, but thanks for tip. I’m sure others appreciate your tips as well.

    Jake: yeh.

  3. loading – i’m not sure whats the bottleneck of loading, but it could be textures, so in that case, you can use some default texture for everything.. and compiling should not be a problem in well designed code, it should always compile only the changed files (so if you dont change some core engine stuff, it should be quick).. also try /MP for compilator to use multiple cores, halves the time on dual cores..)
    but yeah, prototype outside :)

Comments are closed.