Creating the Look and Sound of Axirune

Creating the Look and Sound of Axirune

Building the Vector Art, Interface, Music and Sound Effects

By June 2026, Axirune had already moved beyond being a collection of experiments. The core puzzle systems were taking shape, the directional-arrow mechanics were established, and the overall structure of the game was becoming much clearer.

The next challenge was presentation.

A puzzle game can function perfectly well with placeholder graphics, temporary buttons and basic sound cues during development, but those elements are not enough for a finished game. If Axirune was going to feel like a complete product rather than a prototype, the visual and audio design needed to support the gameplay just as carefully as the underlying code.Because I was developing Axirune independently, this stage involved handling the artwork, interface design, music, sound effects and implementation myself. That made consistency especially important. Every visual element and every sound needed to feel as though it belonged to the same game.

Moving Beyond Prototype Visuals

During the earlier stages of development, visual polish was deliberately kept secondary to functionality. The important question was whether the puzzle mechanics worked.Once those systems were stable enough, I could begin replacing temporary assets with graphics that reflected the identity I wanted Axirune to have.The objective was not to make the screen as visually busy as possible. In a puzzle game, clarity is more valuable than decoration.

Players need to understand the board quickly. They should be able to distinguish directions, obstacles, targets and interactive elements without having to study the interface.That meant the visual design had to communicate information first and create atmosphere second.This became one of the main principles behind Axirune's final presentation:

the artwork should support the puzzle rather than compete with it.

Creating the Artwork Myself

Axirune's visual assets were created as part of the same solo-development process as the game itself.Working this way gave me direct control over how every element related to the mechanics.If an arrow was difficult to read, I could redesign it.If a tile was too visually dominant, I could simplify it.If an interface element drew too much attention away from the puzzle board, I could change its proportions or styling.There was no hand-off between a programmer, artist and interface designer. The artwork could evolve alongside the game because the same person was responsible for both.

That flexibility was useful, but it also meant I needed a disciplined workflow. Without clear visual rules, it would have been easy for the game to become inconsistent as new assets were added.

Building a Vector-Based Art Workflow

I chose a largely vector-based approach for Axirune's artwork.Vector graphics were well suited to the project because many of the game's visual components are based on strong shapes, symbols, arrows, tiles and interface elements.They also made it easier to maintain clean edges and consistent proportions across different asset sizes.Instead of painting highly detailed textures for every object, I could focus on shape language, colour relationships and readability.The general workflow was straightforward:

create the basic design, refine the shape, produce a clean vector version, export the asset and then bring it into Godot for testing.

The important part was testing the artwork inside the game rather than judging it only as a standalone image.An icon that looks attractive in isolation may become difficult to understand when placed on a puzzle board beside several other symbols.That meant many visual decisions could only be finalised after seeing the assets in context.

Designing Axirune's Visual Language

One of the key goals during this stage was establishing a visual language that remained consistent across the entire game.The directional arrows were especially important because they are closely connected to how the player reads and understands the puzzles.Each direction needed to be immediately recognisable.The shapes, colours and orientation of the arrows had to remain clear even when several appeared on the board at the same time.The same principle applied to tiles, targets and other puzzle elements.Instead of treating every graphic as an independent illustration, I tried to think about how the complete set of assets behaved together.

This included questions such as:

• Which elements need the strongest contrast?

• Which objects should remain visually neutral?

• How much detail can a tile contain before it becomes distracting?

• Are interactive elements clearly different from decorative ones?

• Can the player understand the board quickly without relying on text?

These questions helped shape the final presentation much more than simply choosing a particular visual style.

Designing Arrows, Tiles and Supporting Graphics

The arrow graphics became one of the most recognisable parts of Axirune.Because direction is fundamental to the gameplay, the arrows needed to work both as visual assets and as gameplay information.I experimented with their proportions, thickness, colour and placement until they remained readable without overwhelming the rest of the board.The surrounding tile graphics were designed to give the arrows a stable visual environment.If every tile had been highly detailed, the board would have become difficult to scan. Instead, the supporting graphics needed enough personality to make the game visually distinctive while still allowing the important puzzle information to stand out.Targets and other special elements required the same balance.The player should notice them immediately, but they should still feel like part of the same visual system.This process reinforced an important lesson: visual hierarchy matters just as much in game design as it does in graphic design.

The player needs to know where to look.

Building the Interface

The user interface required a slightly different approach from the puzzle board.Menus, level information, buttons and navigation elements need to communicate their purpose instantly.A puzzle interface should not create additional puzzles.I wanted Axirune's controls to feel simple and deliberate.Buttons needed clear states, readable labels and consistent dimensions. Navigation needed to remain predictable. Information shown around the puzzle board needed to be useful without creating unnecessary clutter.The challenge was to make the interface feel like part of Axirune's visual identity without making it overly decorative.This was particularly important because interface elements are seen repeatedly throughout the game. A visual effect that seems impressive the first time can become distracting after dozens of levels.

Restraint therefore became part of the design process.

Balancing Style With Readability

One of the recurring decisions during June was how much visual character to add without sacrificing clarity.Puzzle games are especially sensitive to this problem.If the artwork becomes too detailed, the player may struggle to separate functional information from background decoration.If the artwork is too minimal, the game can feel unfinished or generic.The solution was not to choose one extreme.Instead, I tried to make the important gameplay elements visually strong while allowing supporting elements to remain quieter.This created a hierarchy where the puzzle remained the focus.Colour, shape and contrast all became functional tools rather than purely aesthetic choices.The strongest visual elements were reserved for the information the player needed to recognise quickly.

Creating the Music

Audio became the second major part of Axirune's identity.Music in a puzzle game has a difficult role.It needs to create atmosphere without becoming distracting.The player may spend a long time considering a move, retrying a level or experimenting with different solutions. Music that is too intense or repetitive can make that process tiring.The goal was therefore to support concentration rather than dominate it.The music needed to sit behind the gameplay and contribute to the overall mood without constantly demanding attention.I approached it as part of the complete experience rather than something added after the game was finished.That meant testing the music while actually playing.A track that sounds suitable on its own can feel completely different when combined with repeated movement sounds, menu actions and puzzle feedback.

Designing Sound Effects as Gameplay Feedback

Sound effects were treated as functional feedback.When the player performs an action, the game should communicate clearly that something has happened.Movement, interaction, errors, successful actions and puzzle completion all benefit from distinct audio cues.The purpose of these sounds is not simply to make the game louder.They help reinforce cause and effect.A successful move should sound different from an invalid action.Completing a puzzle should feel more significant than pressing an ordinary interface button.These differences help the player understand the state of the game without relying entirely on visual information.The best sound effects are often small, but they can have a major effect on how responsive the game feels.

Keeping the Audio Consistent

Just like the artwork, the audio needed a consistent character.If every sound effect came from a completely different style, the game would feel fragmented.I therefore paid attention to the relationship between the different cues rather than judging each sound independently.Volume was also important.Interface sounds should not overpower gameplay sounds. Gameplay sounds should not compete with the music. Completion cues need enough presence to feel rewarding without becoming harsh.Balancing those levels was part of turning separate audio files into a coherent soundscape.

Integrating Art and Audio Into Godot

Creating assets was only part of the work.Every graphic and sound had to be integrated into the actual Godot project.That meant importing assets, assigning them to the correct scenes and nodes, checking their scale, testing them at different points in the game and making adjustments when necessary.

This stage often exposed problems that were not obvious during asset creation.

A graphic might need additional contrast.

A button might require different spacing.

A sound effect might be too long for a frequently repeated action.

The implementation process therefore became another design pass.

Rather than thinking of artwork and audio as finished before they entered the engine, I treated the game itself as the final testing environment.

Maintaining Consistency as a Solo Developer

Working alone has advantages during this stage because decisions can be made quickly.There is no need to coordinate between multiple departments or wait for changes to move between different people.At the same time, solo development creates its own challenge.When one person is responsible for programming, game design, artwork, interface and audio, it becomes easy to lose consistency if each area is approached separately.The solution was to treat Axirune as one complete system.The code determines how the puzzle behaves.The artwork determines how that behaviour is communicated visually.The audio reinforces the player's actions.

The interface connects the player to everything else.None of these elements exists completely independently.

Thinking about them together made the final game feel more coherent.

Refining the Presentation Without Losing the Puzzle

By the end of this stage, Axirune had moved much closer to its finished identity.The prototype mechanics were now surrounded by a visual and audio presentation created specifically for the game.The most important outcome was not simply that the graphics looked better or that the game now had music.The important outcome was that the presentation supported the puzzle systems.

The arrows were easier to read.

The board had clearer visual structure.

The interface became more deliberate.

Sound effects reinforced player actions.

Music gave the game atmosphere without interfering with concentration.

The result was a stronger connection between the way Axirune worked and the way it looked and sounded.

Development Decision

The main development decision during June was to keep Axirune's presentation clear, consistent and functional rather than overly decorative.The visual and audio identity would support the puzzle mechanics instead of competing with them.Vector-based graphics provided a practical way to create consistent assets, while carefully designed sound effects and restrained music helped make the game feel more responsive and complete.For a solo-developed puzzle game, this approach also helped keep the production scope realistic while still giving Axirune its own recognisable identity.

Development Takeaway

Creating the look and sound of Axirune reinforced something I had already learned while designing the gameplay:

a strong game is built from systems that work together.

Artwork is not separate from gameplay when the artwork communicates the rules.Sound is not separate from gameplay when it confirms the player's actions.Interface design is not separate from gameplay when it determines how easily the player understands and controls the game.By treating the visual design, interface and audio as extensions of the puzzle systems, I was able to move Axirune from a functional prototype toward a finished game with a consistent identity.

The next stage would focus on something less visible but equally important: testing, balancing, fixing edge cases and preparing Axirune for its final release build.