How I Found Direction

After DIV was finished, I kept thinking about games built around recording.

The first idea was simple: record a path, then replay it. That naturally suggested a few possibilities — connecting map pieces, drawing routes, rotating terrain. But the further I followed them, the more I found they already had well-developed forms: pipe-connection puzzles, route planning, or spatial assembly like Blue Prince.

So I simplified the idea one step further. If you break a path apart, isn’t the most basic unit of information a direction?

And that’s where the real question began: how do I represent direction?

1.0 — The Resource Loop

I came across a game on Twitter: black and white dots spawning randomly on a board, which had to be connected according to certain rules before they could be cleared.

That gave Direction its first concrete form — obstacles spawn randomly on the board; when the player moves into an empty cell, that movement’s direction is kept, and the stored direction can then be spent to clear an obstacle.

From there it grew into a 2048-style turn-based movement game. Obstacles became enemies, taking up the player’s space. The fuller the board, the fewer positions remained to move through and generate new directions.

The loop closed:

space → movement → vector → enemies → space

The player’s goal was to keep moving to produce vectors, then spend those vectors to destroy enemies and win the space back.

The system worked. But a more fundamental problem surfaced: I had answers, but the enemy types and level formats weren’t producing problems that needed them.

I first tried adding enemies with directional shields and double health bars, then introduced separate characters with directional skills, hoping to create more gameplay possibilities. It wasn’t until I began experimenting with fixed-board puzzles — complete information and planning ahead — that the design actually turned. The survival loop fell away, and what survived was the character system’s directional skills, which became the foundation of the next version’s puzzle system.

2.0 — The Skill System

The second version was a puzzle game closer to a turn-based tactics game. Here direction represented a spatial relationship, which came from movement and attacks. The player combined acquired directions into skills, then ordered those skills to clear the board of enemies.

I built a skill table based on combinations of direction and movement/attack, and designed a progression of levels around it, so players would gradually learn skill execution, vector resource management, and board reading.

But this structure produced a new problem. The levels were designed backwards from the skill table, so every ability I added required a new batch of situations for it to matter in.

I ended up building problems that needed my answers, so that the answers I’d already designed could be answers. Each level worked on its own — but remove the corresponding skill and the problem had no reason to exist.

I started to wonder: is this really a puzzle game?

3.0 — The World Rules

The problems with 2.0 made me doubt the whole approach to level design. Rather than keep adding skills and adjusting levels, I set the system aside and went back to the definition of direction itself.

Force, momentum, path — from physics I got the idea that direction could be something left behind by an action in the world. It has a source, and it can be stored, transferred, and released.

So I made blocks the carriers of direction, and pushing its source.

From these starting points, more advanced mechanics — combination, redirection, collision — followed naturally.

But I had no interest in turning DIR into a physics simulator, so I simplified the rules.

What remained were three actions: push, install, trigger.

Looking back, DIR’s three versions were three ways of understanding direction. The first treated it as a resource. The second treated it as a set of skills. Only in the third did I treat it as a state in the world.

For two versions I designed answers the player could use, then went looking for problems that could use them. The third reversed it: build a set of rules that work on their own, then look between those rules for problems worth solving.

Direction was finally founded.