June 18, 2016


#1

I wonder sometimes why I add the year in the title of these, then I remember that yes, I’ll probably still be working on Moonman in 2017, so it’s good to yearstamp these. Of course, the game will be out this year, but we’ll be continually developing it until final release, and other platforms may appear in 2017. That’s still 12 years before the singularity, so it’s all good.

This week has been all optimisation and editor. Sam has been tuning the game, and reduced the number of OpenGL calls from 20000 (per-frame!) to 4000. Of course I feel partially responsible for this inefficiency :stuck_out_tongue: but it turns out that SFML trades a lot of speed for API simplicity. Optimising all this stuff will mean the game will run better on older machines and (potentially) mobile platforms, and will give me some headroom for more sophisticated effects for the high-performance version.

I’ve pretty much finished what I set out to do in the editor: you can now create small structures and export them. We’ll be using this to make a lot of the world features I mentioned in a previous devlog. We’ll show some of our creations next week.

The basic workflow is that you first build your structure using the tools: place blocks, attach world objects, add fluid, etc. Then you can add annotations to the world: notes, anchors, and object bounds (the rectangle below). Then when you click export the system gets all the things within a bounds and exports it out to a game-compatible template file.

Here’s some more complex test shapes.

The format, like most of Moonman’s resource files, is a .json file. This is an earlier version but shows some of the interesting components. The block_data field is just a Base64 encoded width*height length array of all the block data. The format also stores a block database, the “fg_db” field, which maps block type to block name. I need this so I can load templates made in an older version of the game, which will happen often during the next few months. Also it means that I don’t have to re-export all the templates just because I modify the block list. (I mentioned a similar database feature last week in relation to serialisation.)