Turbo Tomato: Maps and Levels

In the previous devlog I spent some time chopping out problematic features from the game in an attempt not to get sued and control the scope.

Now it's time to see what's left and start fixing it up.

I eased into the week with a small change to reset the initial gameplay settings from "super amped developer mode with all powerups" to a more normal level. That was  straightforward (look at me doing 68k again!) until I came to change the time limit on each level.

Each level in Turbo Tomato is defined in an assembly language source file that is built into a binary blob for runtime use. The level timer is part of this source, so to change the timer I just had to modify the source, make the correct VASM incantations to produce a binary blob and integrate into my build system.

Easy, right? No. This turned in to quite the rabbit hole. Sigh.

Some source code of The First Level

The level source, you see, also requires the level tilemaps - separate files for tiles and one for tile attributes - but I only had these in the original Amiga MapEd binary format. A converter was required to parse the MapEd binary maps to JSON maps for Tiled. I already knew I would want to edit the maps on the Mac side at some point so I didn't mind this so much.

However, Tiled JSON maps also require Tiled JSON tilesets, so another pipeline step was required to convert my Amiga IFF format tileset images to GIF for use in Tiled (and editing in Grafx2), and another to convert from GIF to Amiga interleaved bitplane format for the game, and then finally the map converter extended to output tileset JSON and link it to the appropriate map JSON.

PHEW!

The easy small change had taken a week.

F5 is the "make game" button

All of this is now wrapped up in a few make targets for ease of use. I can press F5 in VSCode and any updated levels, along with their associated maps and tilesets, will be wrangled into the required Amiga binary format file in the right location, and a game binary created and launched in UAE, all in a matter of seconds. Nice.

I've been developing the Mac-side asset pipeline tools in Python with the Pillow image handling library. Python is proving to be adept at handling conversions to and from the funny Amiga binary formats, though an IFF loader for Pillow would be useful. At present, I have to do the initial IFF to GIF step manually in Grafx2 as the batch tools like ImageMagick I tried all scrambled the palette order. That doesn't matter on modern un-paletted game engines but it made the output unusable for TT.

I'm working in GIF because this format allows Grafx2 to support layers in the images, which in turn allows me to place alignment grids behind the sprites to ensure they line up on their 16x24 (or whatever) pixel boundaries - essential for the rest of the asset pipeline to function. There are a few idosyncrasies in how Grafx2 uses this format that I need to fully explore to solidify my Pyython converter tools, but it mostly works as you'd expect.

So, a lot of behind the scenes shaving of yaks this week, with not much visible progress on the game as such, but at least now I have a decent editing pipeline for levels and tiles!

I'm expecting a lot of this type of background work in the early stages, as the assets are still mostly in the original Amiga formats and will certainly need some kind of conversion applied and pipleline steps created in order to use them again.

Onward, then, to the next small change...