Sabbatical Log: November 7th

This blog series is running about a week behind my actual work, giving me time to clean things up.  The date the actual work was done is in the title, horizontal lines indicate when I stopped writing and started coding.

I found one last issue with the collision system, which is around the very rare exact-vertex collision. For this case I’m just going to draw a line between the vertices and then act like the collision was with the normal to that line.

I’m not all that interested in writing a map editor, since that would take a lot of time away from actually working on the game parts of this project. Looking around, it looks like Tiled is the best free option available – so I’m going to start there and see how well it works for me.

(ed note: at time of writing I was still evaluating Tiled, as of time of publishing I know I’m going to stick with it and have kicked the suggested $14 their way)

After wrestling with map creation and XML parsing – I’ve got a solid parser for Tiled’s format, a test map, and have integrated map loading and rendering into the codebase (including updating all the tests that relied on the old “an image is the bounds”-behavior). I’ve also got the same hot-reloading logic that I have for assets working, so while I’m actually recreating Kakariko I can watch it load up without a restart.

Now I’m going to spend some time finish up the proper background of Kakariko, and then move on to adding some real objects. Probably going to start with simple animating objects (like flowers) and static obstacles (like walls and cliffs).


All the actual background bits have been implemented (and no issues found). I’ll be in a good spot to start implementing some actual things to interact with tomorrow.

Right now, the room system is pretty simple. The game state only cares about the name of the room (since no objects exist yet), and “room template” (which is backed by Tiled’s XML files) is pretty simple (though has some hints of things to come):

TileMap is just a name and an array of AssetNames (the same enum used to render sprites), and Tiles are just a (X, Y, TileIndex)-tuple.

As with Assets, Rooms have a corresponding RoomManager that is used to hide the “MonoGame-y” bits from the actual game logic.

I’m pretty happy with today’s progress, all said and done.

Continue onto November 8th