I've been planning to properly revisit and complete Equilibria, although I've been chipping away it quite a bit since the DOS Games July 2024 Jam it was originally created for/submitted to. This is a bit of a rambling review of where it's been, and where I think it's going, as I'm planning on submitting it to the DOSember Game Jam which has just begun - hopefully in a completed state, or at least in a kind of "early access" state. We'll see!

For context, below is a capture of the rolling preview, or you can download and run it yourself. I had to abandon my initial design, which meant I ran out of time to make the jam submission playable in any representative way. Note that, as will be discussed below, the game design has changed significantly again since this preview.

The premise is that you must repair a derelict android since it's become the only hope of interfacing with the black-box technology your people rely on for survival. The initial idea was for a kind of "engineering puzzle" game, but it ended up evolving into a form of real-time strategy.

My technical aims for the project were (and still are) that it would run on a mid-tier 486 (ideally 66MHz) with plain VGA and 4MB RAM, have OPL2 & Sound Blaster audio, be quite compact on disk, and not be too heavy on the art production requirements. I'm a very "audio-visual" person; I love drawing/painting and making music - they've been my main hobbies for decades - but too many of my projects run afoul of the sheer art volume which ends up being required. In future I'd love to collaborate with art-focussed folks, but for now and for this project I'm flying solo.

I'm on my third design of the core gameplay. My initial design, which stalled early, was for a puzzle game where you would repair "circuits" in order to balance energy levels at fixed output points. Unfortunately I very quickly hit a roadblock in puzzle design. The simplest approach was to make a balanced circuit, then break it in certain ways, which the player would have to repair. That's a simplified description, but either way the result wasn't fun in the least. You'd essentially just have to trial-and-error your way towards replicating what was there originally - it was tedious work, with emphasis on "work". It's a concept that could be done well, I'm sure, but under jam time contraints I decided just to drop it.

The way the circuits functioned was via "cellular automata" - the classic example being Conway's Game of Life. Cellular automata have always fascinated me and I've used them for all kinds of purposes over the years, be it simulating cloud formation/extinction or animating logos. The "electrons" would zoom around the circuit driven by simple rules, and more advanced rules - and the interactions between the rules - could give rise to interesting effects.

As seen above (and in the rolling demo), for my second design I leaned completely into the cellular automata and made the whole field "active". Now there were two distinct sides; the android's defensive systems, and a virus which had caused its decomissioning in the first place. Your job is to assist the friendly agents by giving them high-level directions and activating various abilities to assist them, or even attack/delay the virus directly. In gameplay terms it was somewhat similar to Creeper World, perhaps crossed with a bit of Dungeon Keeper with its indirect approach.

Where the problems emerged here were in performance. For the density and diversity of behaviours I was trying to implement, targetting a mid-486 was stretching things very thin, especially running at full (70Hz) framerate. I ended up writing essentially the whole gameplay loop in fairly-optimised ASM, and even then the complexity required for deep-enough gameplay and the performance on target hardware just weren't going to converge where I needed them to be, even with many layers of bandwidth-saving trickery.

I could've bumped the requirements up to a Pentium and it might've been alright, but honestly I may revisit "pure" cellular automata like this in something for modern systems in future. I think there's a lot to explore there, and it naturally lends itself to multicore, or even modern GPU compute... Anyway, that's for another time. I'm also personally committed to that mid-486 sort of level. Firstly it's where my fondest recollections of DOS games come from (having previously gamed mostly on the Amiga, NES and GameBoy), but also in a more practical sense it's very stable emulation-wise and is (at time of writing) the current upper limit of common FPGA systems like the MiSTer (via ao486).

So my thoughts moved to ways I could detach the simulation from the rendering; run it at a much lower rate, and have a large field which the player can scroll around instead. This led to the idea to make this into more of a unit-based RTS, where the cellular automata drives the "terrain" the units operate on. This unfortunately means a significantly higher art load, but I think I can manage it. I have many thoughts on RTS design itself, which I won't go into in this post, but suffice to say I hope this one will have a pretty broad appeal; I don't intend for it to require intense multi-tasking micromanagement as some RTSes do.

I initially experimented with deforming pseudo-3D triangle-based terrain, and came up with an interesting rendering method for it, but the aesthetics weren't really lining up - perhaps something for a different future project. What I arrived at was an isometric grid where each cell can raise or lower to create terrain features. Here's a stress-test; the look isn't remotely final, and the terrain won't be this random/messy:

The corrupted virus areas will look different - the concept of pushing back the corruption will still be there. I have this comfortably running at full frame-rate while scrolling around (although the game will probably target half-refresh), and the levels can be huge while using only a relatively small amount of RAM. I'm still hoping to stick to my original goal of only requiring 4MB, but the unit frames may blow it out to 8MB, we'll see.

Speaking of units, I've been working on a tool for creating voxel-based objects; inspired partly by Command & Conquer: Tiberian Sun. I couldn't find any voxel tools I was really happy with, especially since none of them handled the whole process as I wanted. It handles creating the voxels, painting them, animating them via transforms/skeleton, and finally rendering them voxel-for-pixel to sprites. It can also generate effects, which I plan to use for unit destruction, explosions etc.

I was hoping to have this tool complete by the time the jam rolled around but there's still work to be done on it. Hopefully not too much, but it's going to eat into my time a little - probably at least a week or two depending on work and other commitments. You can see it above too, but below is a preview of sprite output for an attempt at a large late-game virus unit - as it appeared a while ago, I've improved it (and the renderer) since, added proper emissiveness etc... All of this will change rapidly as development continues.

The sprite renderer renders a single pixel per voxel as seen below - slice by slice - with simple false perspective which matches the isometric perspective of the game. The latest version does much nicer sampling; it also uses an interpolated SDF for lighting, while the image above just used simple cube/grid raymarching. I'll show off the improved output in a future devlog.

I've also written several other tools; apart from a lot of boring logistical/pipeline stuff and a tool for building/testing the game palette, the largest other tool is for non-destructive downsampling, palette reduction, dithering and so on. I'm not particularly adept at pixel art, and I much prefer working in ArtRage or Clip Studio Paint where possible. Below I was just experimenting with bringing some Roger Dean art down to 320x200 and 16 colours:

The existing art I've made for Equilibria will go through another full pass - some needs polish, others I may repaint; I can achieve much better results pulling the high-res art through this new tool (prior to final manual touch-ups). I only had an extremely rudimentary (command-line!) incarnation of it during the last jam which produced quite a few ugly artefacts... But I still preferred the results to what I could achieve with GIMP and similar things. I'm also planning some simple animation for the game intro and outro, but we'll see how that lines up with reality.

I might release these tools eventually, although for the sake of dev speed I've tried not to think of them as "products", so I'd want to do a proper pass over them to polish them up and make them a bit more user-friendly before that happens... All hypothetical at this stage.

Music-wise one of the more interesting things I wanted to do with Equilibria (and is present in the rolling demo) is using a mixed PCM/OPL2 approach. For the first jam I didn't really have time to fully evaluate the options, so I ended up jerry-rigging quite a clunky setup, using Renoise and the ADLplug VST. This worked, in a loose sense of the term, and I converted the .XRNS to my own internal module format. In the time since, however, I discovered Furnace, which naturally supports all kinds of weird and wonderful custom setups. I've converted the old tracks over to Furnace, and I'll be using that going forward.

Code-wise Equilibria is written in C and ASM, using OpenWatcom v2. Currently the only library I'm using is miniz, but I may switch to something more DIY if I get the chance. I use CodeLite for code editing and cross-compile for DOS, with some custom build tools to tie it all together. For debugging I use OW's TCP remote debugging "locally" with DOSBox-X doing the execution. Setting that up was quite a pain (and needed some components from OW 1.9 since v2's were broken at the time), but I think it was worth the hassle.

Although I mainly use DOSBox, I do test on 86box too - especially when doing low-level ASM, as it's a vastly more accurate emulation of real hardware. I'm also lucky enough to have some real hardware to test on, but so far I've never encountered a case where 86box would run code which didn't also work on real hardware. I can't say the same for DOSBox or any of its forks - and to be completely fair that's not what DOSBox is for, and the accuracy of 86box (or PCem) comes with other costs, e.g. lower ease-of-use and higher CPU usage.

The rolling demo used plain VGA mode 13h (320x200), as that was what I set out for myself for the last jam, but I've since switched over to Mode X (320x240). This is partly because I want the game to run at 60Hz rather than 70Hz. For folks without real hardware or a Variable Refresh Rate monitor this makes the experience much nicer; since 70Hz tears like mad on common 60Hz displays, with no compromise-free way to fix it. Support for sound devices will probably remain the same - any Sound Blaster-compatible with OPL2+ (thus supporting things like the PicoGUS).

I'm really looking forward to seeing what comes out of the DOSember jam (and hopefully Equilibria is one of those things!) - good luck to everyone, and thanks to emmfoolery for organising it!