In my spare time, I work on a video game called Harmonious Creatures. It's a Minecraft-like game about building living things using a redstone-like logic system; but instead of pistons, wires, and inverters, it's about enzymes, binding sites and water gradients, and instead of building machines in a world, you build organisms as part of an ecosystem.

It's still in development, but it's the biggest project I've ever worked on, so I feel I should feature it a little on my website. I plan to have a demo here very soon. In the meantime, here are some bits from development. All the video clips here are heavily compressed to save on server costs. If you'd like high-res versions of any of the videos, email me.

Harmonious Creatures is written from scratch in the Odin Programming Language, and only depends on SDL. I've written the gameplay engine and the renderer myself. I wrote this Vulkan graphics API wrapper to make this kind of development easier.

I wrote this article about the DDA algorithm used in the game.

The game has a concept of energy, so each block has an energy value, and energy spreads from block to block on each gametick. The game only has a couple kinds of blocks, so this is how we color things in:

Here are some tests of movement, physics, and separation of block objects.

This is a stress test of 200 separate objects at once. This was done to test the renderer–the physics engine is bugging out a little here because each object is affecting all the other objects with its gravity.

Logic is done using "enzymes" and "binding sites". Enzmyes of different shapes can block other enzymes, forcing them to go somewhere else. This is a turing-complete system.

Early on, I tested binary calculators to ensure the logic system is usable. I've made several calculators since then.

Instead of a boring, limited, command-based scripting language, the game uses a turing-complete FORTH implementation that runs in a VM. For people who aren't familiar, FORTH is a way of shaping a programming language that allows not only for new function definitions, but also macros, and a complete replacement of the interpreter. Hypothetically, you could write a C compiler in the game's scripting langauge, and then boot into it. It's a hard thing to describe in words, but here are a couple clips from the game's debugger:

Early on, I used a command-based scripting language, with a terminal and autocompletion. This was thrown away.

I've tested a lot of different kinds of gravity, with many different algorithms for defining gravity fields on planets with arbitrary shapes. Ideally, gravity should always 'just work' for all kinds of user-built planet shapes, from Mario Galaxy-style planetoids to Halo-style rings.

I've tried lots of methods for efficient voxel rendering. I've tried meshing and raytracing, and I'm pretty sure the finished game will use some combination of the two. Here are some of my rendering stress-tests. The first two uses meshing with ~100K blocks, and the last uses ray-tracing with ~300K blocks.

Here are some tests of self-replication using a block called a helix.

Here are some rendering tests for reflections, and a slight bevel on voxel edges.

The game has kind of an interesting cursor that smoothly snaps and rounds to objects.

Here's the game running on Steam Deck. I've also tested the game (and developed it!) on Windows, MacOS, and Linux.

This was the first video I ever took of the game, when it was just blocks in a void.