So it turns out game physics is quite hard to code. Who knew, right? Well… you, probably. And me. And also just about everyone we know. And yet for some reason I just had to go and code it anyway.
This has been a tough month of development. The fact that it ended up five weeks long, which is unusual for June, should tell you all you need to know. And to think I thought this would only take me a couple of weeks.
In my defence, as I noted in my last post, I only wanted to do very simple physics where you move around my landscape and don’t fall through it, but apparently even that is really hard to code if your main qualification is in English Literature.
The problem with game physics in a nutshell: physics is a continuous process, videogames can only simulate it in discrete chunks. If your game runs at 60 frames per second, then 60 times a second your physics code gets a chance to update the simulation, but there’s a tiny microsecond gap between each update, while your PC is off doing something else. If your objects are just flying through space this isn’t a problem, but if they collide it suddenly is, and a huge one. In fact technically, the physics isn’t even the problem: it’s the collisions.
Your objects will collide between the nothingths of a second in which your physics code runs, which means by the time your code tells you about it it’s already happened. How bad can that be? Let me put it this way: because of physics, when a crate is resting on the ground in your simulation, it is actually colliding with the ground 60 times a second. Ah.
Physics: Hi Tony! While we were away some downward acceleration called “gravity” was happening to that crate, so I moved it down a bit. Into that stuff called “ground”. Hope that’s OK?
Me: You idiot.
You have to move the crate back, and you also have to remove the velocity it gained during its little sojourn into the ground, which now never happened. And you have to get the numbers right, or it will start to vibrate as your code gets caught up in a mad spiral of overcompensating and undercompensating at 60 frames a second.
And vibrations will always happen, because you’re working with clumsy approximations rather than the infinite continuity of the real world. Fix one bit and you mess up something else. It’s like trying to mend a watch while wearing boxing gloves. As the month I’d allotted for coding the physics drew to a close, I seriously considered jacking the whole thing in and using an off-the-shelf physics engine such as Bullet Physics instead. But that would have meant maybe another month getting that to work, and maybe finding at the end that it wasn’t a better solution anyway.
Finally, I found what was causing the vibrations and how to fix it. Then I found another problem. Sometimes, running downhill made you bounce up and down. Note the “sometimes”. That took most of this week to solve. Then I had a problem with jumping.
Ah, it’s good to write about these problems in the past tense, from the comfy perspective of having solved them. Which is kind of why I didn’t post anything earlier. Maybe I should try to do that in future, to keep this blog more real.
Anyway. Ever since I started coding this terrain engine, well over a year ago [edit: two years ago], it’s been my ambition to one day run around on its world, just like in a real game, rather than simply flying around (and through) it. The difference in realism is immeasurable, and hard to put into words. How does it feel, after all this time and a final, brutal slog through seemingly unsolvable physics problems? It feels like this: