"Code is tedious? Why are you coding a game then?"

I love coding, I love the problem solving associated with that. I do not love mindlessly entering pixel coordinates into a text file. Sure, sometimes manually hard coded setups are necessary, and they definitely help in designing new systems, to have some data before committing to tooling.

But after a certain point, you really need tooling.

As has already been mentioned before, I started writing an editor to handle doing the room layout. But how to define the sprites/objects that the editor could use? How should all of this be packaged into something that the game can actually use?

At the end of the previous post, I described a spritesheet cutter, that took the spritesheet json file and created the relevant assembly files to link in with the game. Additional to this a very small application was written to act as a frontend for the tooling, which would list all of the rooms able to be edited, as buttons, and would load the room editor with that one when clicked. It would also run the spritesheet cutter, and it could run the game directly from it - although in this case, because the data files are compiled into the executable, it actually rebuilt the game.

The next thing would be to actually define the sprites.

A quick tool dev time later (2 streams, ~4 hours total) and I have this quick and dirty editor. It shows the locations of the sprites in the json file, allows you to move, resize, and label the sprites. It even allows for creating animated sprites, although there's no way to view them right now, so it's a bit clunky. Upon saving, not only does it save the json file, but it also calls the cutter application, so that the game is automatically provided with the latest sprite data.

One thing I was considering when starting to develop these tools was: Should I make a mega-tool, or separate small ones. I went for the latter option, even if it might be a bit non-standard (when compared to modern game engines) because it would allow me to work on small functional tools, and develop them relatively quickly, without having to care too much about architecting it so that the mega-tool can be extensible. It doesn't need to be an extensible tool. It needs to do its job, and other tools do their job.

Overall, this means that, to create a room layout, you can now load the editor, open the sprite editor, define some new sprites, save that out, then drop back and select the room I'm working on, place the new sprites, save, drop back out, and hit play to test it in game.

This has dropped my room layout iteration time significantly. The only improvement that could be made would be, being able to define these in the game itself… I'm just not really sure how I could get the data back out of the game…

Right now, the sprite sheet editor only works for backgrounds. As with all the tools, it has some hardcoded values, to reduce the scope, but these can be "easily" changed, so that I should be able to use the spritesheet editor to also handle character spritesheets. Also, adding an animation viewer would probably be a good idea, as would be creating composite sprites, to define single objects out of multiple sprites. After that, a separate tool to set up the states for characters, using this sprite data, is a probably a fairly trivial thing to add.

But first, let's lay out some rooms.