Tomorrow it'll be exactly a month since I started streaming the development of Hexahedra. In total I've put 58 issues, 9 bugs, and 3 milestones onto the Issue Spike — one reason for streaming was to get me to focus more while working, and it certainly seems to have helped. I'm half-seriously considering streaming other parts of my life to help progress, I've got a lot of Warhammer 40,000 Necrons that need painting.

#Progress. Yes, I'm entirely happy with my handwriting, thanks for asking.

The Unity client is starting to feel like an actual game, even if there's not much to look at by way of assets. We can drag and drop Devices and Commands, and even add new Command Tracks, and logic branching with lasers is working. Right now the Unity client can only cope with one Workstation (that's the next milestone), but within that one Workstation we can visually program, and the lasers have given us while loops.

Basic branching with a laser and two Command Tracks

So, where are we after a month?

Milestone 1: JSON

The core HexSim DLL needs to be supplied with a puzzle setup and a solution somehow. The initial state of the Factory is loaded up from a puzzle definition JSON file. When we come to verify solutions on a backend server, the solution will also be provided via JSON, and this is working (which is handy, it powers some of the unit tests), when we're using the Unity client changes to the Factory made by the player get passed through to HexSim as they happen.

Being able to work with JSON lets me verify that the simulation is working, which gives me confidence to build the client on top of it.

Open source software is a wonderful thing. Like most C# developers, I'm grateful to James Newton-King for Json.NET.

Milestone 2: solve puzzles via Unity

This was the next obvious step — build the very basics of a working client so I could drag-and-drop Devices and Commands in order to set up a solution, and pass this through to HexSim to test the wiring for that process. I also then needed to get Unity to understand the list of events that HexSim passes back so that it can properly display what's happening in the Factory. This step would have taken me a lot longer, but I was able to grab a lot of the necessary code (particularly the drag-and-drop Unity EventSystem stuff) from the prototype I made last year. I also stole the (oh-so-attractive) placeholder icons I made for the prototype. Bask in their brilliance:

Developer art is best art. Don't worry, I'll be hiring a professional to sort these out at some point.

Milestone 3: LAZORS!!

Yes, that really was the name of the milestone. What's your point?

Silly names aside, the reason to add lasers early on was because they're the main way of adding branching to the logic flow of a Workstation. Lasers work by colour matching — a green laser will branch based on whether or not it hits a green surface (usually a cube, but there is a Device which is a simple coloured Panel that can be used to intercept a beam). This opens up a lot of interesting possibilities, not just because we can create loops, but because the laser will keep travelling until it hits something, allowing the state of one Workstation to affect another. Players will also face the challenge that the supply of hexahedra might not be uniform — the supply might contain an assortment of different source cubes, arriving in a random order, and laser matching will allow players to sort the cubes and deal with them appropriately.

I also had a lovely "ooh, this is cool" moment when coding the lasers, because I realized that although two blue lasers pointing at each other wouldn't reflect each other's beams, they should of course both see each other's beam as a "return" signal. It's obvious in hindsight, but it wasn't until I was working out how to pass back to Unity the position where a beam had either been reflected or absorbed (in order to draw the beam correctly) that I spotted that the situation could arise. It's not exactly "emergent" behaviour, I had to code a special case for it (HexSim isn't modelling the beams travelling directly, it's just looking at what's in their path), but it was a nice unexpected feature.

There will be another way of doing branching, with a weighing Device, but that will only work on the cube in its own Workstation.

What's next?

Milestone 4, as I mentioned, is adding support for multiple Workstations to the Unity client. HexSim already supports this, but there's no way to add or remove Workstations from a level Unity-side. This is going to require a few other things, such as being able to move the camera, which hasn't come up until now. Zoom is already in, moving it comes next.

Milestone 5 is showing the player what the source and target cubes actually look like. These are set in the JSON puzzle definition, but there's currently no way in the Unity client to see what cubes you'll get and what you need to make them look like to complete the level. I've already shot myself in the foot a couple of times because I changed the JSON definition and then forgot, and shipped the wrong cube to an angry customer.

The other exciting news is that I've signed a contract with a freelance artist to start designing the Devices this week. These will be sketches I can then pass to a 3D modeller who will then make the final game assets. That means the sketches themselves won't be highly polished, because they don't need to be, but I'm planning on using them as placeholders on flat quads once they're done, which should make the game feel much more like a game.

I've been delighted by the progress over the last four weeks, and happily it feels like a sustainable pace, so I'm looking forward to seeing where I am in another four weeks' time.