Dev Log: Makin’ Tools

Avatar photoPosted by

I’m in the midst of porting my current project to the Defold game engine. It’s going pretty well. I’m getting used to Lua and learning my way around the engine’s particulars. Most recently I wrote some tools to improve my workflow which, thanks to the efforts of the fine people at the Defold Foundation, can be integrated directly into the editor.

My game consists of interconnected rooms of the same dimensions (think the original Legend of Zelda for NES). The game loads each of these rooms into memory when you enter them and unloads them when you leave. A global table of world data maintains their relationships. This contains things like which rooms connect to each other based on the positions of their doors.

The camera’s not moving and the rooms don’t exist in memory at the same time!

The global world data is a Lua script I load when the game starts. Each room has a Defold .tilemap file describing its geometry and a .collection file describing the placement of entities.

I could add (and have added) these rooms manually. But it requires a lot of copying and pasting. Trying to track door locations would be even more tedious. I’d have to divide each doors’ coordinates by 16 to get their grid positions and manually add them to the world data.

With my tools though, I just have to fill out a small form in a popup dialog and click a few times. VoilĂ , new room.

These tools took a while to build. As I was working on them I had a growing sense that I wasn’t really working on the game. But, could I have made my whole game using the manual process? Technically yes. It is possible. But I’m not sure I would make my whole game if I was doing it that way. I would have to constantly shift focus from designing and building things to writing a bunch of boilerplate. I’d make mistakes and have to debug them. I could very well burn out.

There’s certainly a tradeoff involved in making your own tools. There are some cases where it’s probably better to just do the extra bit of manual work when necessary, rather than putting things on hold to make a whole automated process. You can also become obsessed with making tools, because it’s cool. But I think it’s worth it once the process becomes complex or tedious enough to automate.

In the end, a game engine itself is a tool to make it easier to make games. You could read “easier” here as “practically possible at all”, but people do write their own engines. Some recommend it for the control it gives you over what and how things are implemented.

If you do it right, it would probably be a more efficient tool for making your specific game than a 3rd party engine. You could even go a step further and write your own programming language, like the inimitable Jonathan Blow is doing.

A screenshot of the Defold game engine editor with a tool I wrote open.
Look at that dialog box! Fancy!

At some point though you’ll have to stop and use someone else’s work as a foundation for your own (assuming you don’t build your own hardware, at least). The question, I guess, is how much you stand to lose or gain when picking where to build your foundation.

I was actually working on my own engine, but I switched because I decided it was more important to me to get some games done than to build the technology myself. Defold handles a lot of things for me that I find no need to handle myself (rendering, reading input, an entity component system).

There’s also another benefit that I’ve just begun to reflect on. I’m pretty new to all this, and using a 3rd party engine gives me a set of limitations to work within. Rather than asking “How do I make X happen?” I can ask “How do I make this engine do what I want?” Then, if I can’t make it do what I want directly, maybe I can write a tool. They say limitations breed creativity, and I think they’re right. Starting from greater than 0 also breeds creativity.

Leave a Reply

Your email address will not be published. Required fields are marked *