Glad to hear and see that the channel is growing at such a rate. The quality of the videos and the scripts are incredible! Thank you for all the content.
Thanks Dean. I put a *lot* of effort into the script and editing for this one in particular. I really wanted to cover the basics of SMs but do in a way that could also be entertaining. Turns out that's hard xD
Man, I have just done an exam at uni about state machines. I did not fin any “useful” application outside of theory, but after this video I understood a lot more of what I have done. Thansk
Remember that computers are big Turing machines, so computers and their programs are composed of many, many states in practice... State machines are everywhere... no matter if you implement them as sequences of if-else, switch-case or with a shift register or some variable just changing its internal value, states are in every program you create...
I just came across your content, and wow! What an incredible channel! Not only is the content extremely interesting, but the presentation, depth, and delivery are all perfect. As a bonus, the audience has the opportunity to learn a few things. Thank you very much for the effort you invest in this. Keep up the outstanding work. Subbed!
I was twisting my brain into a knot trying to program without atate machines, and then i finally bit the bullet and learned how to implement them. Completely changed my world and actually made me love programming
Heck yeah! Thank you so much. Not sure why it performs so poorly... probably the thumbnail and title. Should have entitled it "Computers hate this one weird trick..."
@@NesHacker Haha, indeed! Never really tried to exploit thumbs myself but it is the "cover of books". Good luck with your channel, mate! Something really unique and cool you decided to cover.
Hey man, I saw your message about being burned out. Really appreciate the videos you made. They helped me get my basic of NES coding in ASM down. Thank you.
My Hallowe'en Arduino games work in the same way using state machines. It truly is the only way to keep track of things in the main program loop. I typically determine the main things I want to do, list them and use a byte variable initialized at 0 to be the "waiting for some player input" state of my (relatively) simple games, then either increment the byte or jump between 0-n states and end the game by resetting back to 0. Understanding what, why and how to implement state machines (it's quite simple, really) is truly like a cheat code if you are trying to learn programming.
Love these videos! From a design perspective, my guess on elimnating state from the 8th row rather than the 9th is that most ui (points, health, time, etc) will need to display in that top row and that needs to account for state to update the values. Again, this channel is awesome, can't wait for more art and design related breakdowns.
Thanks for this episode. Im learning programming now and like watching videos on programming for retro hardware. Seeing how the programming language is translated into bits/bytes makes a lot of the basic concepts more understandable.
The waterfall on Zelda 1's title screen is animated using a group of 16 8x16 sprites. Related fun fact: The middle part of the sword's blade is made out of sprites in order to work around the 4 color limit for BG tiles. Same for some of the leaves on the title screen.
No offence but this is not an explanation of HOW it works... 😉 The animation of the waterfall is made with 5 metasprites of 4 tiles each (4 times 8x16). The top of the waterfall(the splashings) is made of 2 metasprites that simply alternate between each other. The waterfall in itself is made by 3 metasprites BUT only the white part of it not the blue one... The blue part is made with background tiles. Now, everything is moving according a pattern of 5 cycles of 3 steps and there is a shift on the y position for each metatiles. It's difficult to explain by words but the effect is made by updating the metatiles AND by shifting downward them on a 5 cycles of 3 steps... Really smart ! 😎
@@Xplouding The usual scheme is that if you have M things that can cause state transition ("inputs" in automata theory), you assign each a unique ID between 0 and M-1. Likewise, if you have N states, you also assign each a unique ID between 0 and N-1, where the starting state is assigned ID 0. Each state is then an array of M next-state IDs (indexed by current input), and the state machine is either an array of N states or an array of N addresses that point to states (indexed by current state), depending on whatever is most convenient for the underlying hardware's addressing modes.
Automata and SMs are basically the same thing. Usually the term "Automata" is used when formally defining them mathematically (as in Deterministic Finite Automata, etc.).
I'm working on my own game in Godot, and seeing how older devs did things sometimes has modern world implementations. Game Maker for example is almost entirely state machine based.
Very good video as a playful yet technically sound introduction to general game design by showing the central primitive algorithm behind a game's logic. Well done.
Cool! It's always the creativity and usage of simple and not-so-simple concepts in video games! The compressed images in many rpgs for example. The animated backgrounds of course. Getting to create "impossible graphics" by mixing sprites and background tiles or precise timing while editing the graphics memory :D
As someone learning assembly language as a hobby (z80 for Master System, but same concepts) and living in Japan, I have to say I love your videos, especially the little Japanese messages thrown in. あなたも日本語を勉強している？
I doubt very much that the doors in Metroid which take 5 missiles are "5 states". Likewise enemies don't have as many states as they have health, states are about behavior. It's more likely that the state only changes once 5 missile hits have been registered.
State machines are abstractions ultimately and just like how there are many ways to implement a system, there are also many ways to model a system. That being said, I do take issue with the anti-pattern idea of "if you aren't doing it *this* way, then you are doing it wrong". We may have learned to use state machines as a formal way to describe and model systems, but that doesn't mean it HAS to be the only way. Had history been a little different we may have wound up using some other modeling methodology (whether for better or for worse is a separate issue).
I only use an actual state machine class for stuff if the logic has branching paths. for stuff like animations or level completion i just use a number or boolean.
Yeah, it's subtle but even if you're using a number of a boolean the animation can technically still be modeled as a machine. How you go about implementing the animation or logic is independent of the computational abstraction involved.
I feel like i have to fundamentally disagree on your perspective of what a state machine is. in my experience and terminology, you'd use a state machine for a single object (you can have multiple objects with different state machines, or one object with many state machines, or any mix). for instance, a player character idle, running, jumping (up and falling down, or even just "in air" and allow variables just as the vertical speed to dictate which part of that state you're in. And to me that's the big difference. and idle waterfall doesn't have a state, it's an object or series of objects stitched together and alternates color pallette with a variable that changes over time. the variable is not in itself a state machine, but the variable can tell the object(s) when to change states. Edit: i guess what i'm trying to say is there's no good reason to need to segment off portions of code on an animated waterfall by using a state machine. maybe a normal animation function and then a different state for the fade, but to me i don't think the video came across in that sense.
I chose the words “modeled by” carefully. State machines are a way to model computation, and are not in and of themselves programs. Thanks for watching.
Having actually done game development, the importance of this concept cannot be overstated. The overall structure even on a modern PC of how we *do* games is init, repeat game loop until done, shutdown. Game loop is draw, get input, think. Draw before think is a side-effect of modern GPU hardware and the driver stacks that feed geometry and shaders to them. From there everything is, as you say, either updating a state or making a decision based on a state. Even enemy AI is comprised of of states. Am I where I want to be? If not, move there. Is it time to update where I want to be? If so, choose a new destination. Can I attack? If so am I close enough to attack any heroes? If so choose the best target and attack them. A lot of programming works this way too, but _all_ games do it.
Yep. Even though I kinda thought it wouldn't do well as a video, the concept was so important I figured I needed to take a crack at teaching it for those who follow the channel earnestly trying to learn game programming. Maybe I should have entitled it "The dark secret behind ALL games..."
State machine is a higher-level concept/abstraction (that may be implemented in many different ways under the hood), state variable is just implementation detail.
Did you remove a video? I'm trying to find this video you did on Movement in Super Mario Bros 3, but I can't seem to find it anymore. Was it taken down by youtube? Did it even exist in the first place? Or am I having a false memory? Please help! I've been looking for at least an hour now.
The water looks like a set of pixels that move based on a lookup table of sines? maybe? differing speeds? doesnt sound very fast.... maybe alookup into already genned lumps of water? sounds faster
Thanks you sooo much for your videos!!!! I can`t wait for the next one, i am curious on how to code the graphics. I wanna make my own game, but it looks so difficult. I am not sure if i will succeed, but it never hurts trying!
Before learning graphics, use text to represent stuff. For example, I had a checkers game with weapons. Instead of going straight to graphics, I made the game logic first by using X for player 1, O for player 2. Then I print out a screen that looks like. [X...] [X...] [....] [....] [O....] [O....] Then I made holes in the stage be like [----] And so on. If I added weapons to a unit, I wrote a number next to it to show what they have (5 might be a bomb for example). I also made it at some point to where the [X...] changed to To show player O that the enemy is on that square. Basically... Point is you can convey a lot with text.
I'm writing a 2D sidescroller and am quite surprised how many levels of state machines I need to encode behavioral changes in the player character, enemies, scenery objects like elevators, and the game itself. The engine contains special code constructs to manage all these states and make it easier to add or change them, because let's face it -- I'm lazy and scatterbrained and managing all this stuff on my own is hard!
For real, I am working on a simple movement demo for an upcoming video now and it's nuts how many state machines are involved even for something so basic.
State machines are what I use instead of coroutines and/or events in .NET, C# and Unity. They're also more translatable to other languages, say you wanted to translate your C# codebase into C. You would want to use a procedural programming approach, making all public static classes and public static 'methods' first.
@@NesHacker I’d focus on branching code that depends on some value for where to branch. A visual example mimicking a switch statement from C, eventually ending with an ASM example where the branch instruction uses an address that is modified to effectively change the behaviour that is chosen. For non-code, I’d take the sample of gravity on a player falling off a cliff. Walking on ground, the state machine uses behaviour for player walking and checking if on ground. Then if ground isn’t there, change to a behaviour of falling, where it applies player falling and checking if on ground. This simple 2 state machine means it either has a player control routine or a player falling routine, with the only shared functions being checking for ground and setting the state. I’d then go into a what happens if it was in the walking state, but the ground was never detected from a bug (or missing instruction) just to show how the player would keep walking over the air like some Looney Tunes cartoon. This clarifies that there is a different behaviour that needs to be switched to be state machine control. For a real example, I think of the elevators in Metroid. If the player happens to press down while standing on the elevator, their normal behaviour switches to the behaviour state of freezing the character in place while the camera scrolls up. Animation state machines are too simple, imo. They don’t show the true power of state machine design.
Yeah as for the specific tools they used I am not too sure. The definitely coded the games using 6502 assembly, and probably used either 16-bit or 32-bit (absolute state of the art in 1985) 8086 or x86 systems. I'll look for more information about how it was done back then and if I find some good stuff I'll turn it into a video :)
@@NesHacker thank you sir. I've been looking into what devices if any they used but come up empty most times. I find it odd u don't see NES dev kits for sale. I hear ya state of the art, technology premiere might be just graph paper and coding on a PET lol...I had a girlfriend who worked in the Kyoto offices in the 2000s but she never knew what the NES utilized. She did manage to get me a disk writer kiosk that says property of G. Yokoi dept 2 on a sticker in the back and it appears to have all the wiring still intact but I believe it was to diagnose system trouble not create games. I was shopping auction houses to see which would give me the best take, but they aren't sure if the name tag is all the value or the writer it's a $500 or $50000 coin flip. I can't confirm if it's for programming. You interested in taking a peak at some photos to make an educated guess? Let me know and thanks for the reply and not treating me as a moron lol
Hi, wow, your videos are pure quality!! Thanks about that... but, (allways apears a but haa) can you expose an example of “how to code” a simple state machine in asm, I think I’ve an idea, but... thanks anyway
Can you use OOP or ECS when programming retro systems (or show pseudo code that could be the implemented using OOP, ECS etc)? I know that you kind of must do the most performant code and such, and OOP is kind of in a bit of conflict but I feel that to be really usefull to game devs, the content I watch has to have some best practices to work with modern game development languajes and engines or APIs, becose, now days, the code has to be readable by other devs and manteinable. I have the same feeling for something like Pico-8, its nice and all, but such constraints I think its not good for beginners or rookie game devs like myself, trying to learn the best way to develop games. I feels this much constraints are good and exiting for experienced game developers that know the best practices and when to break them and hack away to get the best performance and save memory etc, and no so much for beginners that should learn the best practices for readability and manteinability for further expansion of the codebase and to posibly work with other devs without needing a manual for an advanced hack made for performance and such. This is only my opinion, of course you channel is about NES assembly programming, but I think you knowledge and way to explain things are great and could also be used for modern game dev too!. This video on the state machines is great, becose like you said it can be applied to any game, old and modern. More like this one! Chears!
It all depends on what you're trying to accomplish. If you just wanna make a game and do it quickly then going about it this way is a bad call. But if you specifically want to make an NES game, then you kinda have to do it this way... If you use engines or "maker" programs for the NES you'll be constrained because they don't implement everything that is possible.
If we want to be pedantic, wouldn't Super Mario Bros. 3 levels have more than 2 states because they can be cleared by either Mario or Luigi, which makes a difference in what gets uncleared by a Game Over?
State machines are amazing, but one of the most annoying things about trying to learn about them is that the overwhelming majority of material about them is only about software implementations. Hardware only gets mentioned in passing, and rarely mentions anything that would be useful if you wanted to actually try building one.
A state machine is a coding pattern though. Each instance in a system has data for that "state" and the conditions to look out for to pass to a different state. you then have a handler that looks at the active state and looks for the the conditions to move to a different one that is defined in the active state. the hardware doesnt matter as much other than that it determines the memory/processing available needed to consider how much data and what methods should be used to hold the data within each state. State machine are a great way to organize the systems of any program running on tomagachis to cars, to anything using bluetooth, and more
@@Wuddigot It's not just a coding pattern. It's extensively used in hardware as well. Things like DC balancing in communications links, error detection and correction, and as part of the control circuitry of a CPU. Hell, I think there are even devices out there with programmable state machines for use with I/O. You can find heaps of state-transition diagrams for state machines used in hardware, but very little about translating those into actual circuits.
@@NesHacker I peeked at the asm. I should have predicted another state machine… (a loop that moves the sprites down, and cycles them based on next state).
I feel like you're giving the wrong impression here. NES games aren't fundamentally programmed as state machines, state machines are just a natural way to think about games and their systems.
I'm pretty sure I say "can be modeled using state machines" or something to that effect a lot in the video. I guess folks might not understand the difference between interpreting solutions by way of models and actual programming though if they are novices.
my dude, a state machine is a high level formalisation, they don't exist in low level code. You are just talking about state. A number being incremented is not a state machine. You say "you can think of this like a state machine" to anything. Yea any state change can be thought of state machine. You could do math with a state machine. Just have every single number ever be a state, and then create your infinite transitions to all the other numbers. Being able to imagine something as a state machine doesn't mean it is one. Again, a state machine is a code formalisation. It's existence is fickle and trying to define things as state machines is pointless.
I'm a CS student in my third year right now, and games are my passion, and someday maybe even my career. As someone who's always thought of the NES hardware as brilliantly concise and who's limits allowed for excellent lessons in video-game design, I've always wanted to show off to friends, family, and employers "hey, look at this thing I made! it's a full-fledged game and it costs less computer storage than a screenshot!" NES games (and all video-games in general) always inspire me to continue learning, and now that I have the resources to actually start making the games that continue to inspire me... I feel more determined than ever Thank you so much for these absolutley amazing videos! They've given me excellent motivation and passion to continue working on games. Even if this channel doesn't survive for the next decade, just know that your work has inspired people like me to continue their second quest. For that, I thank you!
I'm unlikely to ever make practical use of any of the content in your videos, and as a result I'm frequently coasting through them without fully internalizing the details, but the manner in which you present these esoteric and technical topics is simply addictive to watch. I'm definitely on a binge! Thanks so much!
Buy an Arduino and start state machining your home. The lights, an aquarium, heck, anything. It's a very powerful concept that as the video says, takes programming from something that will drive you mad trying to keep everything straight in your head, into a network of simple functions that may or may not involve one another - your choice.
