Designing Axirune

Designing Axirune

Turning an Idea Into a Complete Game Design

By May 2026, I had moved beyond simply learning how Godot worked. I understood the basics of scenes, nodes, GDScript, signals and input well enough to start thinking less about individual coding exercises and more about the game I actually wanted to build.That was the point where Axirune started changing from an idea into a structured game design.I knew I wanted to make a 2D puzzle game, but that description alone was far too broad. A puzzle game needs clear rules, understandable feedback and enough depth to remain interesting after the player understands the basic mechanic. As a solo developer, I also needed a design that was realistic for one person to build, test and maintain.The challenge during this stage was therefore not simply coming up with features. It was deciding which ideas actually belonged in the game.

Starting With the Core Idea

The earliest concept behind Axirune was deliberately simple: directional arrows moving across a grid.The appeal of the idea was that direction could become both the visual language of the game and the basis of its logic. An arrow immediately communicates movement. The player should be able to look at the board and begin forming an idea of what might happen without needing a large amount of explanation.That simplicity was important to me.I wanted the rules to be easy to understand while allowing the puzzles themselves to become increasingly difficult. That is a common challenge in puzzle game design: complexity should come from the interaction between simple systems rather than from constantly adding new rules.Instead of designing dozens of unrelated mechanics, I began thinking about how a small number of reusable systems could interact with one another.

The grid became the foundation.

Once movement is constrained to a grid, each cell can have a defined purpose. It can contain an arrow, an obstacle, a directional modifier, a goal or another gameplay element. That gave me a predictable structure for both programming and puzzle design.

Defining the Rules Before Building Content

One of the most useful lessons from the earlier prototyping stage was that content should not come before the underlying rules.It would have been easy to start creating levels immediately, but doing that too early would have meant constantly rebuilding them whenever the mechanics changed.

Instead, I started defining how the game should behave.

Questions included:

• How should an arrow move?

• What should stop its movement?

• What happens when its direction changes?

• How should different board elements interact?

• What information should be immediately visible to the player?

• What makes a solution valid?

• How can the game communicate failure without feeling unfair?

These questions gradually became part of the Axirune game design document.The document did not need to be a huge formal production manual. For a solo game developer, its main purpose was to prevent the design from drifting.Whenever I considered adding a mechanic, I could ask whether it strengthened the central puzzle system or simply added unnecessary complexity.That distinction became increasingly important as the project grew.

Designing the Grid and Arrow Mechanics

The grid gave Axirune a consistent environment in which every gameplay system could operate.Rather than treating each puzzle as a completely separate piece of logic, I wanted the board to function according to reusable rules.Directional arrows could move through cells, interact with board elements and respond to mechanics that altered their path. Later mechanics could therefore increase puzzle complexity without requiring the player to relearn the entire game.This became one of the central design principles behind Axirune:

Introduce complexity through combinations of familiar systems.

A player might understand an individual arrow, obstacle or directional element almost immediately. The challenge comes from predicting what happens when several of those systems interact on the same board.That approach also suited the technical structure I had started building in Godot. Small gameplay systems could be developed independently and then connected together.

The design and the code were beginning to support the same philosophy.

Designing for Replayability

Replayability was something I wanted to consider from the beginning rather than add after the game was finished.A traditional puzzle campaign can provide carefully designed challenges, but once every puzzle has been solved, much of the discovery is gone.I wanted Axirune to offer more than a single linear sequence of levels.That led me to think about two different types of puzzle experience.The first was a structured campaign containing deliberately designed levels. Campaign puzzles could introduce mechanics gradually, control the difficulty curve and teach the player how different systems interact.The second was generated puzzle content.

Procedural puzzle generation offered a completely different advantage: variation.Instead of every board being permanently fixed, a generator could create new configurations using the same underlying mechanics. The important challenge was ensuring that procedural generation produced meaningful puzzles rather than simply random arrangements of objects.Randomness by itself does not create good puzzle design.The generated board still needs rules, constraints and validation. A puzzle should feel intentional even when it was produced by a system rather than manually constructed.This idea eventually became a major part of Axirune's identity and its emphasis on replayability.

Campaign Design and Progression

The campaign had a different purpose.Here I could control exactly what the player encountered and when they encountered it.Early levels needed to establish the basic visual language of Axirune without overwhelming the player. Once those ideas became familiar, later puzzles could introduce additional mechanics and more complicated board states.The goal was a progression curve rather than a simple sequence of increasingly crowded levels.A good difficulty curve should make the player feel that their understanding is improving.That meant thinking about the order in which mechanics appeared, how long players had to become comfortable with them and when combinations of mechanics should start appearing.

This also influenced the tutorial philosophy.Where possible, I wanted the game itself to demonstrate how systems behaved instead of relying on large amounts of explanatory text.For a logic puzzle game, understanding through interaction is usually more valuable than reading a long instruction screen.

Keeping the Scope Realistic

Axirune was being developed as a solo project, so scope was always part of the design process.There is a difference between an interesting feature and a feature that improves the finished game enough to justify the development time.Every additional mechanic creates more than programming work. It also creates testing requirements, user-interface considerations, interactions with existing systems and potential edge cases.That meant I had to become comfortable with rejecting ideas.Some concepts were interesting but did not belong in the core game. Others could potentially become future additions rather than expanding the initial scope.This was one of the most important parts of designing Axirune.The objective was not to make the game contain as many systems as possible. It was to build a focused set of systems that worked well together.

For an indie game design project, particularly one being created by a single developer, that discipline can be more valuable than feature count.

Writing the Game Design Document

As the mechanics became clearer, I began documenting the structure of the game more formally.The game design document became a reference for the major systems rather than a fixed document that could never change.

It covered areas such as:

• the core gameplay loop

• grid behaviour

• directional movement

• board interactions

• level progression

• puzzle-generation concepts

• interface requirements

• player feedback

• replayability

• visual direction

• audio requirements

Writing these ideas down exposed problems that were easy to overlook while simply thinking about them.If I could not clearly explain how a mechanic worked, it probably was not defined well enough to implement.The document also helped separate essential features from ideas that could wait.For a solo development workflow, that became extremely useful. It gave me something concrete to return to whenever the project started expanding in too many directions.

Prototype Before Polish

Another decision made during this period was to avoid polishing systems before I knew they were worth keeping.It is tempting to make an early prototype look like a finished game. Artwork, animation and sound immediately make a project feel more impressive.But polished presentation cannot rescue a weak puzzle mechanic.So the priority remained functionality.

Could the board communicate its state clearly?

Could the player predict movement?

Could the mechanics create interesting decisions?

Could the systems support many different puzzles?

Only after those questions were being answered did it make sense to invest heavily in presentation.

This approach also made experimentation less expensive. Throwing away a rough prototype is much easier than throwing away a system that already has finished artwork, animation and audio attached to it.

Designing Systems Instead of Individual Levels

Probably the most important change in my thinking during this stage was moving away from designing individual puzzles first.I began designing the systems that could create puzzles.That distinction changed the direction of Axirune.If the mechanics were flexible enough, the same underlying rules could support handcrafted campaign levels, generated challenges and future variations without rebuilding the game from scratch.This also aligned with one of my main goals for the project: long-term replayability.Rather than treating every level as an isolated piece of content, I wanted Axirune to behave like a puzzle framework capable of producing many different situations from a consistent set of rules.That became the foundation for much of the development that followed.

Development Decision

Build Axirune around small, reusable puzzle systems rather than designing the entire game as a collection of isolated levels.

The grid, directional movement and board interactions would form a common foundation that could support both handcrafted puzzles and generated gameplay.

Development Takeaway

The biggest lesson from this stage was that game design is as much about removing ideas as adding them.Once I stopped asking, "What else can I put into the game?" and started asking, "What does this system contribute to the core puzzle?", the project became much easier to define.

Axirune was no longer just a collection of experiments.It had rules, structure, progression goals and a clear direction.The next stage would be turning that design into the visual and audio identity of the finished game.