Watch the video
Last time I made a basic physics engine that could cope with collisions against different physics bodies. This time I’ve been adding the ability to have a level that is made from tiles, some of which are solid.
Making a tilemap for a game is a traditional way to represent the game’s background and scenery. Testing for collisions with tiles is quite an easy thing to do, but does require more care when a physics library is involved. Normally the sprites simply look up their position in the tilemap and if there’s a solid tile under them, the sprite system moves the sprite to the closest edge before drawing it.
With a physics engine the physics system also needs to know about the tilemap. However what I didn’t want to do was tightly couple the sprite system, physics system and tilemap system together. What I chose to do was make the sprite system in control of everything, and it works out when to call the physics code, or when to move the sprites out of collision with the tilemap.
After a few false starts that did have some amusing bugs I managed to make it work.
This is one of those programming challenges that seems impossible to achieve, and for a while I did wonder whether I’d created a mess that I couldn’t solve. However with some careful redesigning of the code I made it all work in a very satisfying manner.
To save a lot of time and effort I used the tile editing tool Tiled which exports its data as easy to read XML files
and then a severe performance issue which lead me down the path of dirty rectangle optimisation.
By the end I had a robust and reasonably performant sprite system that had physics and a tilemap.
Now I have the majority of the basic game engine working, I can focus on designing an actual game, and then starting to make parts of it. It’s still a complete work in progress and I am sure things will continue to evolve over time.
