State Machines
Today the Unity course started diving into state machines, a concept that I had to learn back when I started with GML. I'm very thankful for that past experience because these crazy Aussies move at such a quick clip that I 'd have to rewatch these lessons several times just to grasp them. Did I mention that this course is being given by two chummy Australian guys? It's amazing.
State machines are interesting to me because they are one of the first concepts of game design programming that don't immediately translate to something in real life. You could argue that variables are the first big item to wrap your head around. However, it's easy enough to describe a variable (just a way of storing some piece of information that can change, like a box). Also, variables have been used for decades in the front end of consumer business products such as word, so it's more likely that someone can understand them.
But state machines... even compared to programming for other types of software, they are a concept that is handled pretty uniquely by game design. Using context, of course, even a layperson could probably figure out what a "state" is. It's a very human concept. If you have a headache and a fever, you could say that your state is "being sick."
What I like about them is that, at its core, a videogame is very much just one big state machine, with many more states than someone would probably imagine. There is the core coding, which is flexible and basically only "reads" the current state and awaits the next state. That's the MACHINE. But underneath the machine, you've got all of the individual states, each with their own rules and functionality and thought that has to be put into them.
For example, let's look at a game like Super Mario brothers. Your state machine would start with the state of "game menu". The game menu state would be designed to allow the player to select an option on how they would like to proceed. Is it a 1 player game or 2 player game? Based on the decision, we'd store that data in a variable (1p or 2p), and then after loading the first world, we'd change our state to "Mario stand."
The "Mario Stand" state would display Mario standing still. It would default to looking right. However, a variable that would be switched based on player input of the left direction would cause this state to render him facing left. Then there would be several "exits" from this state.
It's complicated and I can imagine a little mind-boggling... how much thought and programming goes into just getting little Mario to run back and forth. But if done correctly, the state machine is manageable and compartmentalized. In a way, it's all just a big puzzle to figure out.
And then, of course, once you figured out the puzzle of making him do the thing, you get into the actual nuts and bolts of game design, which is making adjustments to all of those things so that they just sing.
Anyways, thanks for reading, as always!
State machines are interesting to me because they are one of the first concepts of game design programming that don't immediately translate to something in real life. You could argue that variables are the first big item to wrap your head around. However, it's easy enough to describe a variable (just a way of storing some piece of information that can change, like a box). Also, variables have been used for decades in the front end of consumer business products such as word, so it's more likely that someone can understand them.
But state machines... even compared to programming for other types of software, they are a concept that is handled pretty uniquely by game design. Using context, of course, even a layperson could probably figure out what a "state" is. It's a very human concept. If you have a headache and a fever, you could say that your state is "being sick."
What I like about them is that, at its core, a videogame is very much just one big state machine, with many more states than someone would probably imagine. There is the core coding, which is flexible and basically only "reads" the current state and awaits the next state. That's the MACHINE. But underneath the machine, you've got all of the individual states, each with their own rules and functionality and thought that has to be put into them.
For example, let's look at a game like Super Mario brothers. Your state machine would start with the state of "game menu". The game menu state would be designed to allow the player to select an option on how they would like to proceed. Is it a 1 player game or 2 player game? Based on the decision, we'd store that data in a variable (1p or 2p), and then after loading the first world, we'd change our state to "Mario stand."
The "Mario Stand" state would display Mario standing still. It would default to looking right. However, a variable that would be switched based on player input of the left direction would cause this state to render him facing left. Then there would be several "exits" from this state.
- Pressing the jump button
- Go to "Jump State"
- Pressing a direction
- Go to "Walk State"
- Pressing a direction while holding 'b'
- Go to "Run State"
- Pressing the start button
- Go to "Pause State"
It's complicated and I can imagine a little mind-boggling... how much thought and programming goes into just getting little Mario to run back and forth. But if done correctly, the state machine is manageable and compartmentalized. In a way, it's all just a big puzzle to figure out.
And then, of course, once you figured out the puzzle of making him do the thing, you get into the actual nuts and bolts of game design, which is making adjustments to all of those things so that they just sing.
- How FAST does he walk? How Fast does he run?
- How much further does he move if he jumps from a running start?
- How much is the player allowed to adjust his momentum in mid-air
- Some games choose to be realistic and not allow you to change your movement mid-air
- Others give the player a super-hero like ability to adjust their positioning in midair, breaking the rules of physics and all game logic
- How high does he jump?
- How forgiving will we be with his hitbox while moving?
- Consider problems such as jumping VERY close to an enemy. One pixel closer and you kill the enemy, one pixel further and you land right next to him and likely get killed yourself.
- etc etc etc
Anyways, thanks for reading, as always!
Comments
Post a Comment