That’s it – I finally have a basic physical engine for my game. I should probably have gotten used to it by now, but I’m still surprised at how tiny the code / time ratio is – it took me probably two weeks to complete what takes a few dozen lines of code. It’s generally like this everywhere in programming – before you get serious about it, you imagine a programmer writes code all the time, so a week’s work must be a lot of code, and then when you start doing it seriously you realize that much more time goes to thinking than coding[1]. And this code was particularly heavy in that way[2].

The main problem here is collisions. If you’ve ever had the slightest interest in game programming, you must have heard the phrase “collision detection” – it gets a lot of attention, probably because it’s so universal (it’s a part of almost every kind of game), so I expected it to dominate my time as well. But then I learned that detecting a collision is only the begining – sometimes the real tricky business is deciding what to do after a collision.

First of all, what is collision detection? Very simple, it’s the code that checks when to objects in the game world collide. When you play Tekken you know that Kazuya and Anna are two different objects that can’t be in the same place at the same time, but the computer won’t know it unless the programmer tells it so. It’s not a simple problem, and you can see that in many games (especially older ones, but not only): in some games, the object’s physical appearance doesn’t quite correspond with it’s collideable area (there’s even a tvtrope about it), sometimes the game will adopt annoying limitations on it’s engine to make collision detection easier (remember how in Warcraft 2 everything was an axis-oriented rectangle, so you could have a knight hitting the grass near a lumber mill at it will be damaged?), and sometimes you could get different results depending on which direction to collided from (if you’ve ever played Dangerous Dave, you might remember that if you fell down at the side of a wall, Dave’s leg could get “inside” the wall – which you couldn’t do if you approached the wall walking).

And this is just detection. After detecting a collision, you have to decide what to do about it – it’s easy if the game is about humanoid characters who can stop and move at will, but what if you have vehicles, that have to follow the laws of physics (it might be cartoon physics, but still physics) – if a car hits a wall, it can’t just stop, it should get hit and move back. And that gets much more complicated – more on that later. But as an example of what happens when this goes wrong, you can look at some extremely new games – in Achievement Hunter’s Fails of the weak (if you don’t know what it is, try it. It’s pretty amusing), almost every chapter has a case where some character starts flying super fast across the world for no reason – while I can’t be sure, it certainly looks like collision handling gone wrong. And that’s in the best, newest Halo games.

More technical details will come later.

[1] Back in my office-working days, people were often amused by how much of my time was spent walking around the room – I’m not a fan of thinking while sitting down.

[2] Also, Fallout: Tactics turned out to be a really good game, so I allowed myself to do a little less working lately…