Last time we talked, I was working on Falldown in Python. Since then, I’ve switched over to C++. I switched because I got as far as I wanted to go in Python; but, my end game was always to write the game in C++.

Now that the code is in C++, I have been working at incorporating some best practices of game development. One particular best-practice that I spent some time implementing is a fixed simulation timestep. I applied a technique that a game developer, named Glenn Fiedler, described on his blog. I will not rehash what he wrote, because (a) I couldn’t say it better than he already did, and also (b) his blog deserves a read-through (well, after you read through my blog). However, I will attempt to show you what it looks like.

In my code, the fixed timestep is .016 s. On my machine, Falldown can render anywhere from 800 to 1000 frames/sec, which means that the system spends anywhere from .001 to 0.00125 seconds drawing. In words, the game can render a frame 12 to 16 times in between each simulation step. To figure out what to draw in between simulation steps, the game interpolates between the latest known simulation state and the previous known state.

The green outlines in the animation above represent the latest-known simulation state. You can see that the green outlines update not-that-often, relative to the rendering refresh rate. The ball and the rows appear to “catch up” to the positions of the green outlines.

Stay tuned; I still have more work to do.