Like most estimates in software development, it turned out that integrating with the Tiled Map Editor format was trickier than I expected. I finally got it working:
Other than switching map formats, the only other change I made was to double the tile size to 64 pixels on a side. I’ll be doing some experimentation with character control this week to see if this is a good idea or not, but my gut feeling at this point is that showing too much of the world at once will be bad for fundamental aspects of gameplay.
The biggest stumbling point in the integration was the fact that the library I was using reads the map data as gzip-compressed, and newer versions of Tiled use zlib compression by default. There were also a couple minor bugs in the source itself that I may release corrections to at some point if someone wants them, although at the moment my version of the code is a little entangled with my game-specific logic.
But overall things went surprisingly smoothly, once I figured out how the map reader library worked. This was a “blind refactoring,” where the change I was making was so large and fundamental that there was no clear step-wise progression of small, testable changes to get from where I started to where I wanted to go. I went way, way out in the weeds: I made a copy of my existing level system, changed the name, switched a couple using statements around, then went hunting for red squigglies in Visual Studio. This style of refactoring is more effective than you might expect, and is one of the main reasons that I prefer statically typed languages for large projects. Still, even after all the red squigglies were taken care of, it took quite a bit of head-scratching and experimentation to find my way back in from the weeds. And as it turns out, I introduced a new graphical artifact, which you can see in the video above: when using single-sheet tilesets with floating point drawing operations, it’s possible for your graphics card to draw a little more of the area than what you wanted. Like many floating-point problems, it takes place at the hardware level and is basically unavoidable, although several good workarounds exist. In my case, the answer is to simply provide a buffer margin of one pixel around each of the tiles in the sprite sheet. That seems to be a lot more palatable than translating everything to be integer-based, especially since Box2D uses floating point math.
Tomorrow is dedicated to getting the controls to feel nice and tight, locking down things like horizontal acceleration curves, jump height and speed, bullet speed, and so on. After that I’ll begin experimenting with different weapons and enemies, possibly moving into screen overlays at the same time.