#programming principles

Visual scripting tools like Blueprints and DOTS built into off-the-shelf engines like Unreal and Unity are definitely helpful in lowering the bar for non-programmers to start developing games. However, there’s a lot more to programming than just learning the syntax of how to do what you want to do. Beyond the basic rules of how things work, programmers also need a strong understanding of how to organize and utilize data efficiently. The best way I can try to explain this is by using an analogy. 

Let’s say that you wanted to craft a great story, but you don’t know the language you want to tell the story in. Instead of writing the story in that language, suppose you’re given a pretty broad library of images that you can use to tell the story instead. You can begin putting things together with that image library and it will certainly be something. However, bypassing the need for vocabulary and grammar aren’t all that’s needed to tell the story. Writing a good story also requires understanding of story structure, character development, pacing, and a variety of other invisible skills that typically require careful study and experience. None of these skills are inherently granted by the image library, no matter how extensive it is. The library just lets you bypass the language barrier.

Similarly, the visual scripting tools allow developers to bypass the programming language syntax barrier. This removes one barrier from the path but not all. There are other conceptual challenges that trained programmers are usually taught to circumvent that cannot be automatically bypassed or granted with a visual scripting language. They still need to learn those rules and best practices, be it with a visual scripting system or writing code. The initial barrier to entry is lowered but the general requirements of being a programmer (even one who only uses visual scripting tools) will remain. Those skills are not inherent to the act of coding but earned through the process of learning how to code.

[Join us on Discord] and/or [Support us on Patreon]

The FANTa Project is being rebooted. [What is the FANTa project?]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

I suspect it’s because of how a lot of gameplay is defined as a “state machine”. A state machine basically means that the player is always in some pre-defined state, with specific transitions out of and into those states based on input and factors. For example, in a really basic version of Super Mario Bros, you might have defined states like standing, walking, jumping, falling, and dying. Depending on the inputs, Mario transitions from one state to another. Here’s an example:

In this simple state machine, Mario cannot land from a jump in the walking state. He can only land, stand for a moment, then begin walking. Mario cannot directly transition from walk to neutral jump, Mario must stop walking and transition to the stand state before he can neutral jump. Similarly, Mario cannot go from standing to forward jump, Mario can only jump forward while walking. This enforces certain limitations, like Mario not being able to jump again until he lands on the ground.

Here’s the thing about these state transitions - they often require playing some sort of animation and require at least one frame of processing before they can change state again, because the system is handling the transition to this state on this frame. I suspect this is why, in Super Mario Bros, you can jump off of certain things on the first frame you land on them - you’ve stopped falling for one frame and are in the “standing” state, which allows for jumps. The second frame in, the terrain Mario was standing on is no longer there so Mario transitions from the standing state back to falling and can no longer jump. But it was for that one frame, so a player with good timing can 1-frame jump off of it.

State machines are a super common tool used for controlling gameplay because we naturally want to limit what the player can do in each state. One-frame state transitions tend to be fine for most players thanks to the difficult timing windows involved. Speed runners push those limits far beyond what we normally expect players to do, but they are also generally not the target audience for our games so it doesn’t make a huge difference to the developers if they can take advantage of them, as long as it doesn’t cause other players grief when players do so. Sometimes frame-perfect tricks are even supported by the game in order to reward better play, like fighting games.

[Join us on Discord] and/or [Support us on Patreon]

The FANTa Project is being rebooted. [What is the FANTa project?]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

It’s not really technical resources so much as trying to keep track of (and verify) a whole bunch of game data at once. Checkpoint saves simplify things a lot for the programmer tasked with writing the save system, the designers choosing checkpoints, and can be helpful in guarding against broken game states. In order to understand why they’re helpful, it’s important to understand how restoring a saved game actually works.

Imagine you have a bunch of boxes of Lego bricks and a clean play space. Inspiration strikes and you decide to build a castle out of Lego bricks. You spend some time, carefully choosing which piece goes where and assemble your castle. However, you run out of time before you finish the castle - the west tower isn’t done yet and you have plans to build out the dungeon and courtyard, but you’ve got an appointment or something. After you leave, the automated Lego-cleaner robot takes the castle apart and puts all of the used Lego pieces back into their respective storage boxes for future use.

At this point, your in-progress castle is physically gone, completely disassembled into its component parts. You’ve got a clean slate if you wish to start building something new. But if you want to continue working on the same castle from before, you need to remember where each piece of the castle was before it was disassembled and place that same piece there. How difficult can this be to keep track of? Well, that depends on the number of pieces. The more pieces you have to remember to reconstruct the castle state, the more complicated the restoration process has to be.

This is basically how it works for saving game state. We have to figure out what pieces have been moved where, write them down, and then (later) completely reconstruct the entire game state from the bits of information we’ve written down.

If we’re allowing manual saves, it depends on the scope of what we’re saving. Do the location of enemy corpses matter? If so, we have to remember them. Do the visual variations of the enemy corpses matter? If so, we have to remember them. Do the items you’ve picked up matter? Do the items the enemies have dropped matter? What about enemy AI state - if you’ve broken stealth and the enemy knows where you are, does that get saved? And if so, do we save the AI state of all of the enemies? This also makes testing these save restorations potentially very difficult because we have to test that everything the players care about is the same as when they saved. The more data there is, the more complicated the testing process becomes. Imagine saving everything’s state in Breath of the Wild. How much would you have to keep track of?

As you might have guessed, this can be a real rabbit hole of potential edge cases. The worst case scenario is saving a state that is actually broken - imagine saving a fraction of a second before you get killed by a rocket or something. If we save the rocket information, restoring the save would get you killed 100% of the time, rendering the save data effectively useless to the player. 

“What does this have to do with checkpoints?” you might ask.

Checkpoints present a lot of known quantities. We can guarantee you’re at a certain location. We can guarantee you’re in good health. We might even require you not to be in combat to save, so that we avoid the inescapable death scenario above. Since we choose the location, we can guarantee that it’s safe. And, since we can lock off past areas as the player finishes them, we can discard any and all of the old data from those areas. A checkpoint save is basically a way to simplify and standardize a large number of game variables leading up to that point. When we mark a checkpoint, we need to keep track of significantly fewer elements. That makes it easier for designers to figure out what must be saved and what can be inferred, for programmers to write the code needed to save the relevant stuff, and for testers to make sure that everything comes back after restoration the way a player would expect. 

Checkpoints are a lot like using pre-built standardized sections for the Lego castle. It might not be exactly what you built before, but it’s close enough that the differences are functionally moot and makes things a lot simpler to keep track of. With checkpoint saves, we’re trading complexity and granularity for reliability and simplicity. Sometimes we prefer to keep that complexity and granularity of details (e.g. a game like Civilization), but other times the little details really don’t matter so much (e.g. a game like Uncharted or Spider-Man).

Related reading:

[How does a save file get corrupted?]

The FANTa Project is currently on hiatus while I am crunching at work too busy.

[What is the FANTa project?] [Git the FANTa Project]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

In my experience, I’ve found it easiest to break the big feature down into individual components that I feel confident building and estimating. For example, let’s say that we wanted to add a new feature to our game - item set bonuses for equipment. Let’s assume that we already have a system for what equipment items are (e.g. stats, 3D model, type, equipment slot, etc.), what individual bonuses are (from items, effects, character abilities, etc.), and for players to equip those items already in place (e.g. tracking total stats from items, tracking which item is in which slot, etc.). What would creating an item set bonus feature actually entail? Let’s start breaking it down.

What exactly makes up an item set? For purposes of our game, let’s say an item set is a collection of bonuses defined somewhere in data that are assigned to specific numbers that represent the number of items in that set currently equipped. This means each individual item set object needs to know how many items from the set are currently equipped and which bonuses to activate. The item set bonus object should probably have some externally accessible functions that get called whenever an item from that set is (un)equipped so it knows when to modify the bonuses it is applying to the player.

So how do we break these components down into tasks?

Let’s start with how the data gets into the game. We need some way for the item designers to designate an item set. They need to be able to specify in design data what the item set is. Each item set needs a unique ID, a name (that may need to be localized), a maximum number of equipped items, and individual bonus effects that are mapped to specific equipped item counts. Let’s say we use some spreadsheet stuff for this. We parse the design data from the spreadsheet and save it off. That’s the first task - the code needs the information from the design data.

Now that we have this information, what do we do with it? Well, we need set up our game variables within the object to track relevant data in the game. We need to know the maximum number of equipped items (from design data), what the bonuses are (from design data), the current count of equipped items (from the player’s current loadout), and any currently applied bonuses from the item set. Once we have this, we can add the code needed to handle normal use cases like what to do when a set item is equipped or removed.

What do we expect to happen when the player makes an equipment adjustment? The set bonus should change the number of equipped items, then adjust the currently applied bonuses appropriately - applying new bonuses or removing old ones as needed to the player. Naturally, we would need to make sure that we don’t accidentally leave bonuses on the player if they remove an equipped item, otherwise it  could lead to degenerate player behavior like equipping all of these items to get the set bonuses, then swapping them out for other items while retaining the bonuses from the set.

Obviously, there would be additional tasks that would need to be done as well. They would need to be identified, scoped, and get estimates too. However, Each of these tasks shouldn’t be seemingly-overwhelming in scope. If it is too big, it means you haven’t broken it down into small enough components and need to do that. Once you’ve gotten all of the tasks broken down such that you are confident you can do each one, you can add up the estimates for each task (and some additional cushion time for each just in case) and present that as your total estimate. Write it down. Then, provided you have a green light to go ahead, you do it and see how accurate your estimates were. Maybe this task took longer than you thought. Maybe that task was a lot easier than expected. You can then internalize how things worked out and try for more accuracy next time. 

Further reading:

How do I even approach building a system in code?

The FANTa Project is currently on hiatus while I am crunching at work too busy.

[What is the FANTa project?] [Git the FANTa Project]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Let’s take a higher level look at this. First off, what exactly is a save file? When you’re playing a game, you’re making decisions, you’re finding items, you’re getting new abilities, and so on and so forth. It’s like building a castle out of legos - this piece went here, that piece went there. Then, when you finish playing the game and exit, it’s like taking apart your castle and putting all of the lego blocks back into lego storage. There’s no castle there anymore. If we wanted to be able to restore that castle later, we have to know where all of the pieces you used were so that we can put everything back to where you last left it.

So let’s imagine that we’re building some kind of RPG and there’s a character that we want to save. Well, what data do we care about?

Character’s name, probably 

Character level, probably a number from 1-99

Character class, probably a number to represent which class it is (e.g. 1 = warrior, 2 = rogue, 3 = wizard, etc.)

Character’s total experience points, let’s say a number from 1-9,999,999

So, this would be an example of our theoretical save file in data - a chunk of information:

When the game reads the file, it would read the name - AAGD, then the level - 15, then the class - 3 (Wizard), then the next seven digits for experience points. Then we can reconstruct this character - a Wizard named AAGD that’s level 15 and has 90,801 experience points.

But imagine that the game accidentally write the wrong number into there someplace. Let’s say that we kill a monster and earn 200 experience points, so now we want to save this new data to the save file. But… something goes wrong and the memory address we’re writing to is off when we save it. So, instead of writing 0,091,001 experience to the right place in the save file, we accidentally write it 3 spaces too early, like so:

Suddenly, when the game reads our save file, it now thinks that our character is level 0, has an unknown class (9), and has 1,001,801 experience points. This save file has been corrupted, because the data in doesn’t make any sense anymore. If this save file is all we have to look at, there is no way for us to figure out what is correct because we have no record of what came before it. It’s important to note that some of this data is still usable - the name is still correct, for example. But because not all of it is usable, we can’t reconstruct the save file.

Some of you might be canny enough to realize that we can also use this information to cheat. If you know the format for this save file, for example, we can do something like this:

Instantly, this save file now represents a “legitimate” level 99 character with maximum experience.

This is basically what happens when a save file gets corrupted - the data that was in it no longer makes any sense, and there’s no way to figure out what should be there because we have no record of what came before. Some sort of bad data got inserted into it in such a way that one or more elements of the save file don’t work anymore, so you have to throw the entire thing out.

This week we continue the Design Phase of the FANTa Project!

[What is the FANTa project?] [Git the FANTa Project]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

This is a follow-up to [the last post I wrote about developing AI]. This post will cover the basics of game entities actually handling decision making, and what that actually means. In future posts, we can go over some of the more specific stuff, like how AI forms the backbone of many animation systems or how pathfinding actually works. But for today, we’ll talk about the basics in evaluating a choice and deciding a course of action.

Generally, AI is a looping routine that checks a list of conditions every time step, then makes a decision and does something for that time step until the next time it has to ask itself what to do next. A time step is a unit of time where the AI has to make a decision and carry it out. It could be a matter of seconds or milliseconds, but it is the individual block of time an AI has to make a decision and act on it. Here’s a simplified example of the Centipede AI from the arcade game of the same name:

If I have been shot, delete myself and add points to the player score. Spawn a blocker at my current position.

If I am touching the player, kill the player.

If I am moving right, and the space to my right is traversible, move right.

If I am moving right and the space to my right is not traversible, move down and set myself to moving left

If I am moving left and the space to my left is traversible, move left

If I am moving left and the space to my left is not traversible, move down and set myself to moving right

If I have reached the bottom row of the screen, the game ends and the player loses

All centipede units start off moving right, and follow this basic algorithm until they are either completely destroyed and the player advances a level, or they reach the bottom of the screen and the player loses the game. This is the basic concept of most programming - looping through a bunch of conditional statements and doing specific things depending on when those conditions change.

However, this condition list can make it hard to model more complex behavior. Conditions tend to demand more granularity and logic in order to make things behave better. For example, maybe you want to check if more than one condition is met. Look at the basic condition for killing the player:

If I am touching the player, kill the player

What if the player has the ability to gain a temporary invincibility shield via a power up or something? Then you need to check TWO conditions

If I am touching the player AND the player is not invincible, kill the player

If you add in a health system, you need to start checking more even conditions than that - how much health does the player have, is the player shielded, is the AI actually attacking, etc. Each of these differences in conditions being met can have a different result. But note here that we want to test multiple combinations of conditions and have different results depending on the set of results. One common way to handle this is to start grouping things together into what’s called a State Machine. Most of the time, we call them Finite State Machines, because there is a finite number of states that will be represented. Here’s an example for Centipede. In this, we have two states: moving left and moving right. We then identify the way to transition between these states on specific inputs. Here, the only input we care about is whether we’ve collided with something. If there is no collision with a block, the Centipede’s state does not change. However, if there is a collision with a block, the Centipede’s state changes from moving left to moving right, or vice versa.

There are really only two possible inputs here - if the centipede moves and there is a collision or there isn’t a collision. No collision results in remaining in the same state. Colliding with an object forces a state change - the centipede must change direction and start moving that way. It will then remain in that new state until another collision happens. 

We can also nest these state machines inside each other. For example, the moving behavior is encompassed inside another state machine that handles whether the centipede is alive or dead. Like so:

Only living centipedes will move left or move right. Dead ones don’t do either of those, and thus don’t care whether they have collided with blocks or not. This representation is logically equivalent to checking “If Alive AND Moving Right AND Collides with block” but makes more intuitive sense than trying to keep track of all of the different conditions strung together.

Notice that the state transition for this state machine is only one way. Once you’re dead, you don’t get to go back to being alive anymore. But suppose we wanted to make it so that the centipede can resurrect parts of itself... for example, if there are berries spawned in the map that, when touched by the Centipede, restore any dead portions. If that were the case, then there’s a potential new transition from dead back to alive again.

Each of these transitions happens on some kind of input. That input could be time-based (X seconds have passed), reaction based (the player attacked me), environment based (I have moved into an area that damages me), or one of many other possible inputs. This kind of logic is the core of AI. When a Dark Souls boss is deciding what to do next, it is generally in some kind of state machine. Maybe you did this, so it will do that. Maybe it will follow X attack with Y. These inputs don’t necessarily have to be deterministic either - we could give choose a new state based on a random roll. We could even make the state transition triggered by random chance in addition to other specific criteria (e.g. this thing will happen with a 20% chance to occur only if the player didn’t use fire spells during this battle). These decision-making state machines can be super simple, or incredibly complex depending on the number of inputs and the number of layers you have built up.

Next time, we’ll go a little bit into how AI state machines interact with animations in order to make characters move smoothly.

PS. Those of you with good memories may remember [a post that I wrote about distilling down programming problems into terms of input and output]. State Machines are a natural extension of that basic principle being applied.

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Whenever I think about building a new system, I think of it like a box with a specific set of inputs on one side and outputs on the other. If you open the box, you will see that it contains a bunch of internal logic that takes the inputs and calculates the outputs from them. A large box might even contain several smaller boxes inside that are invisible from the outside. However, you can also close the outer box and still trust it to do what you want it to do. When I have a code task that needs doing, the first thing I do is establish what inputs I have and what outputs I need from it.

Let’s try an example. Say I’m outlining a very basic experience level system. This system will keep track of experience points earned, then increase the player’s level when certain thresholds are reached. It won’t do anything else (yet), because we can have a separate character stat system and a character ability system and such that can behave based on the character’s level. So let’s break this down - a very basic experience level system.

What goes into it? 

Any time the player gains experience points, the experience level system must know how much experience it has obtained.

It needs to specify a specific asset to read from (like an experience table spreadsheet) so it knows how many experience points are necessary to reach which level. 

It needs to be able to field requests for information about what level the player is from other systems, how much experience the player has earned, and how much is needed for the next level

It will probably need a way to bypass the regular experience gain method for debugging purposes… a special debug-only input that will generate enough experience points to set the player at a specific level to test level-gated parts of the game.

What comes out of it?

The player’s current experience level

Maybe the total number of experience points earned so far

Maybe the number of experience points needed to reach the next level

Maybe it will send an event out to notify other game systems whenever the player has gained a new level

These inputs and outputs can be organized into a programming interface - a set of functions that can be called from other parts of the game that will pass in the data the experience system needs and provide the information that the other parts of the game want (e.g. the UI will want to know what the character’s level is so it can display it).

You don’t need to actually make it do these things yet - you’re just establishing the parameters and limits of the system’s box. You can put in some placeholder functions first just so you have some code to test, for example. You can then assume that it will (eventually) do these promised things once you’ve finished the planning and implemented the system. Then you can look at how your different system boxes connect to each other in the bigger overall picture. When you actually finish the planning for your system you can start making it do what you promised it would. It should take the given the inputs that you’ve established that it needs, and present the outputs that you promised it would give. 

Why should I care?

Think about it. By establishing the inputs and outputs of your system, you’ve effectively figured out its limits. You know exactly what it needs to function, and how other systems will interact with it. Once you’ve established the limits, you can write the necessary code to fill in the gaps. Nailing down those limits and parameters is the fastest way to get a system ready to work. It also provides a good mentality to break down complex hard-to-solve problems into simpler, easily solvable components.

First figure out where your starting point and finish line are. Then figure out how to get from one to the other.

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr