A couple of years ago gamedev channel NesHacker did a video on how everything in your typical NES game is really a pile of state machines, concurrent ones, nested ones, bunches and bunches of them. If you have any interest in NES coding at all, it’s worth a look. (8½ minutes)
The chief difference between normal, sequential programming and game programming is that most video games have to make a framerate target, and have to split their processes between frames. Lots of little things are usually happening concurrently, and you can’t rely on normal program flow to keep track of things. Instead, each of those little processes has to remember what it’s doing between frames, and that memory takes the form of state machines, reminders of what each routine is in the middle of doing.
Drawing it out with circles like in this video I think makes it seem a bit more complicated than it actually is, but it does require a different way of thinking about your code than you may be used to in other programming disciplines.
