One of the biggest joys of building a puzzle game is learning how to play your own game. You add a mechanic, give it a go, and start to see all the ways it interacts with other parts of the game. This often happens in ways that seem obvious once you spot them, but you didn't see coming.

I briefly touched on this idea in an earlier post, when I first added branching logic to the game. Being able to have multiple Command Tracks for a single Workstation, and being able to switch tracks, causes the Workstations to get out of sync. Normally it takes 10 steps to travel to the far end of a track and loop back to the start. Switching tracks takes a step, so every time you switch you add one step onto the time it takes to loop, and the Workstation will take longer to get back to the start than one without branching.

Watch the Workstations get more out of sync every time the left one switches track.

On one level, I'd anticipated this — tracks can execute forwards or backwards, and it'll even be possible to switch a track's direction on the fly, or reset back to the start of the first track early, or tell a Workstation to pause until a cube arrives or another Workstation triggers a release command. But while I was considering all these more complex mechanics, the idea that a simple track switch would cause Workstations to desync over time hadn't occurred to me. It was great to be a player discovering this for the first time after lots of effort being a developer.

That's an instance where I hadn't fully appreciated all the aspects of a mechanic until I tried it. But there have been cases where I've realized that some mechanics are missing entirely that, conceptually, fall naturally out of the rest of the gameplay. So far they've mostly involved paint.

There are two ways to paint cube faces in Hexahedra. The "normal" one is the Spray Painter, which can be placed anywhere around a Workstation and spray the side of the cube it's facing. The other is the Squirt Painter, which can only go at the top of a Workstation pointing down, and which fires a blob of paint straight down to hit the top of a cube. But if there's no cube there, the paint keeps going until it hits something — a cube in a lower Workstation, the floor, whatever.

I hadn't given much thought to the "whatever" part of that sentence until I was discussing things with Ana, the concept artist I've been working with. There aren't actually many other things that a paint blob can hit, because the paint gets fired right at the end of a step, so that if the paint falls out of the Workstation it starts in and hits a cube lower down, we can be sure that that cube isn't in the middle of doing something else (being painted another colour, rotating, and so on). The only devices that are active at this point are other Drop Painters, Lasers, and the Coloured Panels that can reflect laser beams.

Let's face it, a device this cool deserves some interesting interactions.
(Concept art: Ana Steiner)

Suddenly, it hit me. If a paint blob hits a Coloured Panel that's at the bottom of a Workstation pointing up, it'll paint the panel a new colour. From then on, Lasers interacting with it will start seeing different results. Here's another way to alter the behaviour of your factory over time.

Not only that, but what about the Lasers themselves? If a paint blob falls through a beam, and is the correct colour to reflect it, the firing Laser should register a return signal even if it wasn't already hitting something the correct colour.

Currently I don't have those mechanics programmed into Hexahedra, so these things don't happen, but it's clear that they should, they follow naturally from the mechanics already designed. So, I've added the jobs to my issue tracker, and at some point they'll start to happen.

There's still a long way to go with Hexahedra's development, and I'm adding new devices regularly (the Cleaner went in recently, and the Hitter is close to being finished). I'm sure it's only a matter of time until another unforeseen mechanic takes me by surprise :)