Choosing a Game Engine

Choosing a Game Engine

Why Godot Became the Foundation for Axirune

After deciding what kind of game I wanted to create, the next major decision was choosing the engine that would actually allow me to build it.At this stage, Axirune was still only a concept. I knew I wanted to create a focused 2D puzzle game with grid-based mechanics, strong replayability and the possibility of releasing it across more than one platform.Because I was developing the project alone, the engine also needed to be something I could realistically learn and work with without spending months fighting the tools themselves.

Choosing a game engine therefore became one of the most important early technical decisions in the project.

What I Needed From a Game Engine

I was not looking for the engine with the largest feature list.I was looking for the engine that best matched the type of game I wanted to make.My requirements were fairly specific.

The engine needed to handle 2D development well, provide a scripting language that was approachable for someone still developing their programming skills, support a clean way of organising game systems and allow me to build without unnecessary complexity.It also needed to make sense for an independent developer.That meant development costs, licensing, workflow and export options all mattered.There is little value in selecting an extremely powerful engine if most of that power is irrelevant to the project.Axirune did not need a huge 3D rendering pipeline or a complicated production environment. It needed reliable 2D tools, logical scene organisation and a programming workflow that I could understand and gradually improve.

Comparing the Available Options

I spent time looking at the major game engines and trying to understand how each approached development.There are several excellent engines available, and each one has its strengths.Some are particularly strong for large 3D games. Others have enormous ecosystems, large asset libraries or extensive commercial support.

But the question I kept returning to was simple:

Which engine makes the most sense for this particular game and for the way I need to work?

For a solo developer, development speed matters enormously.Every additional layer of complexity affects how quickly a problem can be understood, tested and fixed.I wanted an engine where I could experiment with a mechanic, run the game, see what happened and make another change without turning each small idea into a complicated process.That gradually pushed Godot to the top of my list.

Why Godot Stood Out

Godot immediately felt well suited to a small 2D game.Its scene and node structure provided a way of breaking the project into manageable pieces instead of treating the entire game as one enormous system.

A menu could be treated as its own scene.A gameplay board could have its own responsibilities.Interface elements, visual effects, audio systems and game logic could be organised separately and then connected together.That approach made sense to me because it reflected the way I wanted to build Axirune: one understandable system at a time.Godot also has strong dedicated 2D functionality rather than treating 2D as a secondary use of a 3D engine.

For a grid-based puzzle game, that was a significant advantage.

I needed control over sprites, interface elements, positioning, input and movement far more than I needed advanced 3D features.

Learning GDScript

Another major factor was GDScript.At the beginning of the project, programming was one of the areas I knew I would have to learn properly.GDScript appeared considerably less intimidating than some alternatives.Its syntax is relatively clean and readable, which made it easier for me to understand what a piece of code was doing.That mattered because I did not simply want to copy code until something worked.

I wanted to gradually understand the systems I was building.

For Axirune, that meant learning how to represent things such as:

• player input

• directional movement

• board states

• puzzle rules

• user-interface behaviour

• signals between different systems

• level loading

• progression

• generated puzzle logic

Starting with a scripting language that I could read and reason through made that learning process much more practical.

Scenes and Nodes Matched the Way I Wanted to Work

One of the concepts that initially attracted me to Godot was the relationship between scenes and nodes.Instead of thinking about the game as a single large program, I could break it into smaller components.

A node could perform a specific job.

Several nodes could form a scene.

Scenes could then be reused or combined into larger parts of the game.

This structure would later become very important to Axirune.A puzzle game contains many systems that appear simple individually but interact constantly.The board needs to communicate with the game rules.The rules need to communicate with the interface.The interface needs to react to input and game state.Progress needs to be stored.Audio and visual feedback need to respond to actions.Breaking those responsibilities into smaller systems made the project easier to reason about.

At this stage I did not yet know exactly how every Axirune system would eventually be structured, but Godot gave me a framework in which I could learn those ideas progressively.

Fast Experimentation Was Important

Puzzle mechanics benefit enormously from experimentation.Something that sounds interesting on paper may feel completely different once it becomes interactive.That meant I needed to be able to test ideas quickly.Could an arrow move across the grid in the way I expected?

Could the game detect a particular board condition?

Could input be restricted correctly?

Could a puzzle state be reset?

Could a mechanic interact with another mechanic without breaking the board?

Being able to make a small change and immediately test the result became a major part of the development process.

Godot's workflow suited that style of iteration.Instead of trying to design every system perfectly before writing code, I could build small experiments and gradually turn the successful ones into reusable game systems.

Open Source Also Mattered

Godot being open source was another positive factor.For an independent project, I liked the idea of using an engine that did not require me to build the business model of the game around engine royalties or changing commercial licence structures.

It allowed me to focus on the project itself.

That did not automatically make Godot the correct engine, but combined with its 2D workflow, scripting system and scene architecture, it strengthened the case considerably.

Choosing the Right Tool Instead of the Biggest Tool

One of the things I learned during the research process was that choosing technology is not about selecting whichever product appears most powerful.A tool is useful when it matches the problem.Axirune was intended to be a focused 2D logic game created by one developer.That meant clarity, iteration speed and manageable systems were more valuable to me than features designed for much larger productions.

Godot seemed capable of giving me everything the game actually required without forcing unnecessary complexity into the development process.That was ultimately what made the decision easier.

Opening the First Real Axirune Project

Once I had made the decision, the research stage ended and the real learning process began.Opening the Axirune project inside Godot for the first time was very different from comparing engines on paper.Now I had to understand how scenes were structured, how nodes interacted, how scripts were attached and how game logic actually moved from an idea into something interactive.The screenshot from this stage shows the real Axirune project running inside Godot.It represents the point where the engine stopped being something I was researching and became the actual development environment for the game.From there, the challenge was no longer choosing the technology.

It was learning how to use it.