DevBlog — Refactor, Feedback, Improve!

Apprentice Codex

7 min read

·

Apr 18, 2026

--

Listen

Share

In this blog post, I will finish writing about the structure elements I created for this prototype and try to highlight the importance of “small, incremental steps” as one moves forward in any project (more so in development ones).

Previously, I implemented the base elements necessary to make the simulation “work” : the Board and the Cell.

But, to “complete” the game, I said I needed:

• Level
• Level Selector
• Main

Let’s tackle this step by step. I can start with a simple “Main” scene and set the entry point in Godot to it. Then it’s just a matter of adding one instance of the Board scene like so …

… and this gives us more or less the same “result” as before. But now, I have a place where I can add more stuff without impacting the Board logic. I can, for example, create a “Main Hud” — a place to have UI elements that I want present everywhere in the game, like a “settings” button. (won’t actually implement settings in this prototype, but its for demonstration purposes).

So, if I create a new basic scene with the “settings” button like this …

… and then instantiate it in the Main scene, just like the Board …

… I am able to add this new layer to the game (albeit it does “nothing”) very quickly.

Quick Tip : When creating HUD elements, give a quick glance over to the Mouse > Filter property. Depending on how you want your element to behave (as in, if you want it to “block” the other elements of the game behind it, or not), you may want to change this setting.

I still need to tackle two more elements, with the next one being the “Level” scene. I can repeat the same steps as before and replace the Board instance in the Main scene with a Level instance. Nothing new here, just a tad bit of structure added with a very quick refactor.

Now, what will I use this Level scene for, exactly ? I want for it to be the “bridge” between the Board (and, by extension, the game logic) and user interactions. I want to be able to interact with the Simulation, pause and restart if I need to and make it possible to “load” different configurations unto the Board logic.

Assuming I create all the buttons I need, I will need to connect them to different methods in the Board scene. But I don’t want to couple this too much, in case I want to add more ways of performing the same actions. Nor do I want to duplicate my code if I can avoid it. Also need to be careful with the Board logic. I don’t want to keep on adding nested if statements to handle every possible state combination imaginable.

It got a bit too much, too fast. Let’s break this down and solve this as we go.

For all the UI elements I may or may not need ? a separate “Level HUD” scene that I will instantiate in the “Level” scene. The end result its something like this …

Press enter or click to view image in full size

I might have gotten ahead of myself, but it should have everything I want.

• 3 buttons on the bottom right to interact with the Board simulation logic
• a button that will, eventually, allow me to exit the “Level” and go to the “Level Selector”
• a basic “congrats” level to reward the player when the level is completed.

Notice that I didn’t add any “Board” here. That is the Level’s responsibility. So, to solve this, I will be using events (in Godot’s terms, signals) to let the Level scene know when the player wants to interact with the board. This allows me to:

• test the HUD independently of the Board
• keep the logic self-contained, in case I want to expand or reorder things around later

All this, from the Level Hud’s point of view, translates into something like this:

I defined two new custom signals that will be listened to by “something” to react to the player’s input. I took the liberty to “collapse” the 3 main buttons events into one signal, with a “action” string to tell which is which later on. I will explain why in just a sec.

With this, I can go back to the Level scene and “connect” to this signals and do what I need to. Now, I need to have some way of performing different “actions” in the Board. I could just create one method for each and do a switch case for each possible option, but … That ain’t pretty. And we are trying to learn here, right ? So, I resorted to an old concept that I like and have used in the past : State Machines

I won’t go into too much detail here (gonna save it for it’s own dedicated post), but here’s the gist of it:

• Instead of adding all the logic into one place, we separate it into dedicated “states” (classes, in this case)
• The entity that will use this (our Board) can be in one state at a time
• We throw in a dedicated helper to switch between states
• We expose one method to tell the Board “hey, I want to switch states”
• and …

Done! One State Machine created.

How does one look, in Godot ? Using the native elements as best I can, it looks something like this:

Press enter or click to view image in full size

Now, all I have to do is go into my Level scene and wire everything together!

Again, I might be getting ahead of myself (went ahead and prepared the “level selector” bit too), but this is it!

I have the Level listening (connected) to the HUD’s events (signals) and passing the info along to the Board. And you can see why, earlier in this post, I “collapsed” the 3 main button events into “one”, with an input variable named “action”. It plugs straight into the logic I created in the State Machine where I have mapped the “rules” to change State. For example, if the Board is in the “Interactive” state (in which the player can “interact” with the Board) and presses the “play” button, it switches to the “Simulation” state (where we can see the Board move and do it’s thing)

With this in place, all I need to do is create the Level Selector, where I applied the same principles. A scene, some buttons, custom events and wire everything in the Main scene, which will act as a “bridge” between the Level and the Level selector itself. Which, in the end, looks like this:

I added a new empty Node to the Main scene named “Inner”, which acts as a “anchor” for me. I prepare the two scenes I want (Level and Level Selector) and created two functions that allow me to instantiate them when needed. Then I wired two events that let me know when the player wants to “switch scenes”, throw in an auxiliar variable or two and it works like a charm!

Press enter or click to view image in full size

There is a thing or two I haven’t explained (how to have different ‘level’ configurations, for one), but that can be explained later on (or just ask me, that also works fine).

It seemed there would be a lot more stuff to do in the beginning of this post, but by focusing on one goal at a time, and improving what I already had as I went it made it easier. Good to see this strategy works in game dev too.

Hope this DevBlog helped in some way or another. The next one will be focused on the State Machine implementation that I just glossed over in this one and there may be one or two more after that one. Enjoy!