Learning to Make a Game

Choosing Godot was only the beginning. Before I could start building Axirune properly, I needed to understand how the engine worked and, more importantly, how to turn an idea into something interactive.

April became a month of learning, experimenting and making small mistakes on purpose.

Learning How Godot Thinks

One of the first things I had to understand was that Godot is built around nodes and scenes.

Instead of thinking about a game as one large program, Godot encourages you to break it into smaller reusable pieces. A scene might represent a menu, a game board, an interface element or an individual object, while nodes handle specific responsibilities inside those scenes.At first, this way of working required a change in mindset.

Once it started to make sense, however, I could see why the structure was so useful. Breaking systems into smaller pieces made the project easier to understand and would later make Axirune much easier to expand and maintain.

Starting With GDScript

The next major challenge was learning GDScript, Godot's scripting language.

I began with the fundamentals:

• Variables

• Functions

• Conditions

• Loops

• Arrays

• Dictionaries

• Signals

• Input handling

• Scene references

Knowing what these concepts meant was one thing. Using them together to create actual game behaviour was another.Small experiments became extremely important.Instead of immediately attempting to build the full game, I tested individual ideas: making something respond to a click, changing a value, updating an interface element or triggering an action when a condition was met.Each small test helped turn programming concepts into practical knowledge.

Understanding Signals and Communication

Signals became one of the most useful concepts to learn.

A game contains many systems that need to communicate with one another. A button may need to tell another part of the game that it has been pressed. Completing an action may need to update the interface. A puzzle system may need to notify another system that something has changed.

Signals allow those parts of the project to communicate without everything becoming tightly connected.That concept would become particularly valuable later as Axirune developed into a game with multiple interacting systems.

Learning Through Debugging

A large part of learning game development turned out to be debugging.

Code would sometimes run but produce the wrong result. Other times a reference would point to the wrong node, a condition would behave differently from what I expected, or something simple would stop working because of one small mistake.Learning to read errors and trace problems became just as important as learning to write code.Instead of treating every error as a failure, I gradually began treating it as information.

What happened?

What did I expect to happen?

Which value changed?

Which function ran?

Where did the logic break?

That process became a normal part of development rather than something to avoid.

Building Small Prototypes

I deliberately kept the early experiments simple.The goal was not to create polished artwork or complete levels. The goal was to prove that the basic ideas could work.

I experimented with:

• Grid-based layouts

• Click and touch input

• Moving information between nodes

• Basic user-interface elements

• Reusable scenes

• Simple game-state logic

• Visual feedback

• Resetting and restarting systems

These prototypes were rough, but they answered important technical questions before I committed to a larger design.That was especially useful for a puzzle game, where the underlying logic matters far more than how attractive the first prototype looks.

From Tutorials to Problem Solving

Tutorials were useful for learning individual concepts, but I quickly realised that following instructions was different from building my own game.At some point, there is no tutorial telling you exactly what the next line of code should be.I had to start breaking problems down myself.

Instead of asking:

"How do I build this entire system?"

I learned to ask smaller questions:

What information does the system need?

Where should that information be stored?

What should trigger the next action?

Which node should be responsible for it?

Breaking larger problems into smaller pieces became one of the most useful skills I learned during this stage.

Keeping the First Game Manageable

Learning the engine also reinforced an important design decision: my first completed game needed to stay within a realistic scope.It was tempting to think about more levels, more mechanics and more features, but every new feature also meant more code, more testing and more opportunities for systems to interact in unexpected ways.I wanted the project to be ambitious enough to teach me something, but focused enough that I could actually finish it.That thinking would strongly influence the design of Axirune.

Rather than building a large game with many unrelated systems, I wanted to create a focused puzzle game around a small number of mechanics that could interact in interesting ways.

Preparing to Build Axirune

By the end of April, I was no longer simply experimenting with Godot.I understood enough of the engine, GDScript and basic game architecture to begin thinking about how Axirune itself should be structured.There were still many things I would learn while building the game, but I now had enough knowledge to move from isolated tests toward an actual production plan.The next step was to define what Axirune was going to be: its rules, puzzle systems, progression, visual direction and overall scope.

That meant moving away from general learning and starting the game's design document.

Next Development Journal: Designing Axirune.