Hey Today's devlog will be about something a bit more specific regarding game development.
Every game is, in essence, a huge collection of variables and data. We all know this, but very few people have actually tried developing a game themselves. No matter how you look at it, game development is not just visuals and sounds — it's also about internal calculations and data flow.
For those unfamiliar with these concepts, let me explain:
Variables are named values that can change. For example, here's a simple health variable:
And here's the same variable, but with a bit more logic behind it:
Both examples are variables. The first is a simple variable with no logic attached to it beyond its name. The second, however, is a variable specifically responsible for health: it never exceeds its defined limits, and when it reaches 0, it triggers the character's death method.
Data is all the information that describes a game's content, rules, logic, and resources, while not being program code itself. In most cases, this includes all the assets and scenes you see in the game, as well as all tracked player and world states. For example:
Here we can see NPC scene data, sprites, animations — all of these are data. And so is this:
This is a game save file. Data is also something that gets passed between objects and scripts within the game. For example, when you pick up an item in almost any game, you're manipulating data by updating your inventory with a new item.
Of course, this is only a brief explanation. Going into every detail would quickly turn this devlog into a dictionary reading session.
So why am I even making a devlog about this topic?
Because every aspect of game development is deeply connected to data, and surprisingly few people ever talk about it.
Every system, every mechanic, even something as simple as pressing a button is tied to variables and data. While adding something like a health value may seem straightforward, properly using even a single stat requires a clear understanding of how it functions within your game.
And even if you've created a health variable and are saving it in a save file, you'll immediately encounter another challenge: data transfer.
Passing data — such as dealing damage to a character's health — is something present in countless games, but there are endless ways to implement it. You could directly modify a variable in an object upon collision to deal damage. But if your attack hits an object that doesn't have a health variable, you'll get an error. You could use a global signal that only affects the player's health, but that works only until you want enemies to take damage too.
You can keep solving these issues one by one for a long time, either patching every possible edge case or eventually finding an architectural solution that fits your specific project.
Developers have invented countless approaches to solving these kinds of problems, and it's always worth learning from them. However, even the best architecture can't solve every development challenge. Sometimes your game may not need a complex architecture at all because the underlying concept is much simpler.
This devlog may seem a bit chaotic, but even a single health variable can be handled in countless ways depending on the type of game you're making.
For example, in my game Life with the Tribe, I had a health system. However, conceptually it only mattered during battles. There is no active gameplay outside of those encounters, and the battles themselves aren't particularly complex.
In a sense, I could remove health entirely from the game and only keep a battle-specific life system. It wouldn't even really be health anymore — just a number of lives. Every hit would remove one life, and when all lives are gone, the battle is lost. At the start of every new battle, the player's lives would simply reset.
That approach would actually be much simpler.
And surprisingly, this is still all about variables and data — because I effectively removed data transfer from the equation altogether.
This small shift in how I viewed the game's design changed many things behind the scenes. Suddenly, I no longer care how much health the player has. I don't need to save that information. I don't need to display it in the UI. I don't need to create loss conditions based on save-file data or variables stored in other objects.
It seems like a tiny conceptual change — simply asking whether a variable is needed in the first place — but the results can be significant.
This idea applies to any variable or piece of data in a game.
Some things may seem standard and necessary. You can create variables, save them, manage them, and build systems around them. But eventually you may end up with so many variables and interconnected pieces of data that maintaining them becomes difficult.
That's why it's sometimes important to step back and ask whether your game actually needs them in the first place.
That's the main point of this devlog.
Understanding the purpose of variables and data is incredibly important. Just like with the health example, something that seems insignificant at first can become much simpler once you rethink it and remove unnecessary data from the equation.