Hi! Today I want to talk about code architecture, and about why it matters.

To make the topic clear, let me first explain what code architecture is. Code architecture is the conceptual plan and internal structure of a program, which defines its key components, their responsibilities, and the ways they interact with each other.

Why does it matter, and what's the point of it at all? Because if you write code only to implement whatever tasks are put in front of you (making minigames, or adding new mechanics), you can turn your code into "spaghetti code" very quickly. Yes, "spaghetti code" is a real term.

And why does "spaghetti code" even exist, and why do so many games suffer from it? Why not just write the code "the right way"?

Heh-heh… there is no right way to write code. Forget it, that doesn't exist in nature.

As strange as it may sound, every developer decides for themselves whether their code is "right", and that depends directly on what that code is supposed to do.

Here, let me show you why this topic came to my mind in the first place:

What you see is the scene in the editor for the fight with the training dummy. For those not in the know, there's a lot of stuff here, so I won't go too deep into the details, but let me explain this much. The base game's fights will have 5 enemies in total: the training dummy, the slime, the goose, the plant girl, the goblin girl (coming in the update). And for the DLC I'm planning to expand the combat and add roughly 2~3 times more enemies, with unique bosses. And the core idea is that after the base version's update, the skeleton of the combat code won't change anymore — I'll only be adding new enemies and their special attacks on top of that skeleton.

Sounds right, and so I started writing the new mechanics and attacks. I quickly made the first build that you tested, as a prototype, and after that I started refactoring the combat code so it wouldn't turn into "spaghetti code". But the spaghetti was already here.

So even though I was trying to do everything right, during development I realised that some things would have to be changed and extended in order to improve the gameplay. The basic example is the monsters themselves and how they get spawned:

At first I set it up so that every monster is a separate scene with its own attacks and patterns. But once I started working on the special attacks, I realised that it creates a whole lot of dependencies and conditions that overcomplicate the code. What do I mean by that?

Here's a simple example: for the fight with the dummy I want to make a battle that teaches the player all the basic mechanics. That's attacks, defence, special attacks, changing the enemy's HP, and changing the enemy's states (yes, there are a lot of conditions here, but more on that later). So I need to track the whole fight somehow (the change in the player's HP, the change in the enemy's HP, its current state, and so on). And although this tracking might seem easy, the monster itself — being a separate scene — doesn't know anything about what's around it. Which means that to hook it up to the global combat system that spawns the monster, you have to write an endless number of signal connectors:

This doesn't have much effect on performance, or on how the monster acts and how the fight plays out. But there are problems with adding new special attacks for the monsters. How should the fight scene and the fight manager react to the enemy's and the player's special attacks? Which types of special attacks exactly are planned? Will the monsters have special combat conditions such as: parries, guards, invulnerability?

The more I thought through the conditions, the more I understood the potential of this combat system, and in order to unlock it fully I spent quite a long time thinking specifically about the code architecture. My spaghetti code for the prototype works, and it will keep working right up until I start creating new unique monsters, and although my code is already almost ready for the base update, I had to rework how the code actually works right now.

Architecturally, what I realised is that keeping the monsters as separate scenes is fine, but their special attacks and their reactions to the player's special attack need to be separated from the enemy entirely. I also realised that although the combat manager that manages the whole fight system does need to know about the player's and the enemy's HP, it doesn't necessarily have to store that inside itself (that is, to have variables and signals for it). There are a lot of other small things that will be changed depending on how exactly the code architecture works, because once all the systems are thought through in detail, there will be far more room to create unique special attacks for both the enemy and the player.

Right now I'm stuck in exactly that process — creating the code architecture for the combat system. I want to make fights with monsters where you'll be able to grab a goose by the neck and start squeezing it, or make a monster girl start running away from you so that you have to catch up to her! There are countless ideas that will be both funny and erotic, but to fully implement them you always have to think everything through in advance.