Tools are an important part of game making. I am not talking about those “big” tools that come with your engine of choice, rather there are many little things over the course of making a game that can be automated. Here’s a little overview of the tools I coded and/or planning to make for myself in the future.
Currently, my engine of choice is YoYo’s Game Maker Studio which is nice but not perfect, especially not for my workflow, because I like to code a lot and not use any of the provided drag-n-drop functions apart from “Run Script” in each of my objects’ Create, Step and Draw events. Since hooking up these scripts is tedious, I coded a little tool in PureBasic that does this for me. I call it GMOC, Game Maker Object Creator and you can download it
Then, two years ago I was also toying around with PureBasic creating a tile editor, or rather, an engine to display tiles. The special thing about it was that you could edit your level in Excel and load it into the engine which would interpret your Xs and @s as walls, roads, player location, etc.
MS Excel should not be overlooked by game makers. It is such an ubiquitous tool that almost everybody knows how use it and do basic stuff with it. Especially when you need some kind of input from people not directly involved in your game, Excel is key. For example, localization. In my first localized game, Fine Sweeper, I did everything in a neat .JSON file. For my translators, I even added inline comments to the spec and provided them with a many pages long PDF detailing every line, where it appeared in the game, what it meant and what its pop-cultural reference was. While also working pretty much full time on the game, this took weeks and was a lot of effort. For my next game I will have every string in an easy to read and edit .xlsx file that I can convert to a .fods (Flat XML ODF Spreadsheet) which is nothing more than an XML file.
But it can also go the other way round: Because the community of Fine Sweeper felt that the game’s difficulty was increasing too harshly, I needed to rework the simple linear progression into something more forgiving. I am a rather visual person, so need something nice to look at in order to better grasp what I was doing, my mental imaging is very rudimentary. That’s why I added a feature to the game that would run from level 1 through 100 and writing stats into a .csv file such as the tile to bomb ratio, playfield dimensions, maximum allowed item count, etc. which allowed me to see the results of my tweaked algorithm at work. The implementation is a bit hacky but it did the job and saved me lots of hours playtesting or even, *shudder*, manually compiling these statistics by going through the levels one by one.
So my point is: Do yourself a favor and include Excel (or Open/Libre Calc for that matter) in your toolbox. The implementation is pretty fast actually (esp. for the XML-based .fods format), unless you want to include support for fancy colored borders, formulas and diagrams. Any why the hell would you anyway?
