The Big Refactoring - Chapter 1

Anthuulos — Wed, 30 Oct 2024 16:41:36 +0000

Hello everyone!

Welcome back to The Big Refactoring, where I explain the significant changes we’ve made in Town Alight since we published its first version. Feel free to ask any questions regarding the development process in the comments! Today, I’m going to talk about one of the biggest reasons that led us to make the choice of refactoring the game: Godot’s tilemap system.

Chapter 1: Living in a tile world

Tiles… most of you might have an idea of what these little guys are, but for those of you who don’t: a tile is a small rectangle (or hexagon, or other funky shape, but let’s not get ahead of ourselves) which, when placed together with other tiles, creates a tileset. Using tilesets is how worlds are created in many 2D games, and when used wisely, they can make your life easier as a game developer. Guess who didn’t use them wisely initially? That’s right, yours truly.

And how could I mess up such a basic concept? Well… let me explain. In the original version of Town Alight that you can play in the browser, almost everything in the game is a tile. The trunk of that tree? A tile. That fire that is threatening our birb’s way of life? A tile. That piece of roof from where our beloved mayor bravely commands his troops? You guessed it, a tile.

This doesn’t seem that bad, right? Wrong. In Godot, and other game engines, tiles are not their own objects like the villagers or the birb. Instead, they are part of the tileset object, which is in charge of telling each tile where it goes and which layer it belongs to. And, hey, it’s great that it works this way because otherwise tile-based games would be very resource-intensive. However, the stuff you can do with tiles is very limited. Each tile only knows about itself and is completely unaware of its surroundings; it doesn’t even know if it belongs to a house or a tree! This leads to weird scenarios…

Now… I confess I’m not an expert on burning trees, but this doesn’t look like how a tree would burn in real life. The issue is that, not only does it look weird, but we also didn’t have control of what happened when a tree or a building was scorched, because the game didn’t even know that there was a building there in the first place! For this reason, we decided to change how the tileset interacted with the rest of the game, which, at the moment, was our core mechanic.

Changing this behavior wasn’t going to be easy, because the fires only wanted to spread throughout the tileset without acknowledging there were other objects in the scene. This meant that the first step was changing the fires from being tiles to being their own separate object, which allowed them to have individual colliders and to check their neighbors. So… here you go, our new, independent fire, with upgraded graphics thanks to Doops!

Now, we just needed to make our building and nature tiles understand that they were part of a group, and the obvious step was simply to take them out of the tileset and make them their own objects, similar to how the fire became its own object. This allowed us to give each structure its own identity, so no more half-scorched, half-healthy trees for us. Not only that, but this also allowed us to give each structure more complex features, such as defined fire resistance and a value, among other properties. The result (besides many features which I will not discuss yet) was structures that burned in a more natural way, like this guy:

As a bonus, now that structures aren’t part of the tileset system, we are able to place them wherever we want, without the placement constraints imposed by the tileset system.

Finally, with these two major changes, we now can improve the interaction between fires and structures. Since fires only knew how to spread throughout their grid and now have more complex behaviors, we can make them detect their neighbors and tell them that these neighbors could come in the form of other fires, bushes, trees, buildings, and more! The structures, on their end, now understand that having an active fire as a neighbor means trouble. In summary, the world is much more interconnected now than it once was, and you’ll be able to experience that yourself in the future.

There’s so much more I could discuss about the new changes to the tileset system, but I don’t want to overwhelm you with a mega-long entry. For now, we’ve covered the most significant changes. If you have any questions or want me to dive deeper into any of these topics, feel free to let me know—I'll be happy to explore them in future entries!

That’s all from me for now. Thank you for reading, and I look forward to sharing more exciting updates with you soon. Stay tuned!

– Anthuulos

The Big Refactoring - Chapter 0

Anthuulos — Tue, 15 Oct 2024 19:44:43 +0000

Hello everyone!

Welcome to this first chapter of my adventures as Town Alight’s main coder. This is the first of many diary entries in which I’ll explain the significant changes we’ve made in Town Alight since we published its first version. After publishing each entry, I’ll answer any questions you have about Town Alight’s development; remember, we’re always open to feedback.

Chapter 0: But why, tho?

The first diary in this series is called “The Big Refactoring.” While we have big plans to expand Town Alight, we encountered many issues with how the Game Jam version of the game was working behind the scenes. We wanted to improve its performance and readability, so this became our first priority before even beginning to implement new features. You may ask: “Why didn’t you develop it well in the first place?!” First of all, how dare you?! Second of all… you’re completely right; but there were a few reasons:

Godot newbies
As some of you might know, Town Alight is being developed in Godot. What you might not know is that both Doops (the artist) and I, Anthuulos (the coder), are relatively new to Godot! Before starting the project, Doops had begun his game dev journey a few months ago. For my part, I had developed games in Unity for about 7 years before only starting to learn Godot a month ago. This led to learning concepts on the go while developing the game, using non-optimal techniques to get where we wanted to go.
Deadlines
Town Alight was developed for PirateSoftware’s 2023 game jam, which required us to create a functional game in just 2 weeks! This forced us to make decisions that resulted in a horribly disorganized game but ultimately made it work. I remember saying to myself, “This is awful code; shame on me,” while coding at 2 AM. But hey… the game did what it had to do for the moment, so I regret nothing!
Design Experience
This is still an issue, at least for me. I confess that I have no sense of aesthetics whatsoever. Many times, I want to show the player all the data I’m using to make the game work, but the reality is that most players don’t care about this; they just want a simple HUD that allows them to make decisions without having to look at a million numbers on the screen. With your help and feedback, I’m sure I’ll be able to overcome this personal obstacle.

So, here we are—many months later—looking in horror at my old code and wanting to erase everything and start from scratch. But I won’t! Instead, I’m going to show you what changes were made to the game to optimize many of its processes. In the first chapter, I’m going to discuss something both Doops and I ended up hating: making the whole game based on tiles without room for more complex behaviors.

I hope you like this series, and I’ll see you soon in the first chapter of The Big Refactoring!

-Anthuulos

DEV Community: Anthuulos

The Big Refactoring - Chapter 1

Chapter 1: Living in a tile world

The Big Refactoring - Chapter 0

Chapter 0: But why, tho?