next »

[Falmil]

I'm trying to think of a good structure to use for holding a state for a game entity. Obviously, finite state machines come to mind, but I guess I don't quite understand them completely. Mostly, I'm confused as to how only having one state at a time is good enough for a game entity. If you had a character running, jumping, and shooting all at once, I don't get how you would accurately store all those states at once, unless you had single hybrid states like "RunJumpShoot" or something.
My original non-FSM idea consisted of each game entity having a hash of different time values. The key would be a "state" string or attribute of that entity, while the time would be when the entity started in that state (assuming the game system has a clock of some kind). A bomb might have an "air" and "ticking" state so that when the "air" state attribute was gone (it hit something) or the "ticking" state attribute was 5 seconds old, the bomb would explode. (Obviously, you could use event timers and collision resolution methods for that example though.) The "state machine" would work by checking which attributes it had that it knew how to deal with, using the time since the "state" started and now for things like animations and time based transitions. Obviously, its going to be a lot messier than having one state at a time and naturally flowing from one state to the next based on the entity's own variables. I haven't really thought out how the multi-state thing completely. Obviously, some states would void others(can't be on the ground and in the air), and some states would be more important than others, so it would take more work to manage all the states.
Still, it seems like most people simply use FSMs. So, I figured that I would try to figure out what I was missing and not understanding that made them good for storing game entity state.

[BlueSweatshirt]

FSM's are generally most effective with AI. They have scripted behaviour, and it makes it much easier to control the desired actions.

FSM's are not for dynamic actions like run/jump/shoot all at once, but for when only one action or set of actions will need to happen at a time.
With that said, using a FSM type of structure certainly in possible in a run/jump/shoot kind of case, but it's certainly not as efficient as if you weren't worrying about states.

There are several ways to manipulate a state machine, and it boils down to either:
A variable that determines what to do within a class/object/entity
Separate class/object/entities that switch from one to the other

Imho, FSM's are not an answer for everything. I only use them for more complex AI, usually-- Most simple AI I make I don't even bother. They're also good for things like doors and switches, of course, but that's a trivial case.

For instance, an enemy that only needs to shoot bullets across the screen, and change direction randomly every 3 seconds does not need a state machine, even thought it basically has different states. In this case, it's so simple states would only make a mess of things.

But if you want an AI that reacts to input-- Say you want an enemy to back away after it's hp goes below 50%, states start to shine. You just create two different states for the two different circumstances, and switch to the defensive, back-off state after it's hp goes below the mark.

I hope I understood what you were asking, and that I clarified a bit.
Cheers! 

[TobiasW]

Furthermore, your overall game state (main menu, options, playing, highscore table, ...) make a good FSM.

A use with entities: An enemy which has different phases it goes through.
You can find an example in one of my unfinished games here. Click on "Start", press Ctrl+N two times to get to level 3, and observe these blue little arrows. They load, they push and swim till they stop, they choose a new direction - and begin again.

Still, it seems like most people simply use FSMs. So, I figured that I would try to figure out what I was missing and not understanding that made them good for storing game entity state.

Well, where did you read/hear that people use them for storing game entity state? These sources should be the best to explain why they think it is good

[Overkill]

Finite state machines can be good for simple cases of artificial intelligence and input parsing/recognizing.

Finite state machines based on their current state and input, decide which state to go to next (using a transition function), with a set of final states. Deterministic FSMs can typically be encoded as simple lookup tables or switch statements in code. But actually, FSMs themselves aren't that useful outside of input recognization, since by their formal definition they can only accept or reject input.

Finite state tranducers factor in an action to be performed with the state machine. Moore machines perform an action depending only on current state. Mealy machines perform an action depending on transition taken. These are more useful but are still limited in what can be done with them.

I think a lot of people blur many different stated-based things into finite state machines, but FSMs are only a small subset of state-based things you can do.

Anyways, I think that using finite state machines and tranducers are not useful for everything. In fact, for game entities it is probably rubbish, since these events (jump, run, shoot) are happening simultaneously, continuously over several frames, and with a few exceptions, independently of one another in terms of player control. Only states that are related but are mutually exclusive should be really grouped, for instance, land/jumping/falling state, or running vs walking, or possible player-facing directions (usually just left or right in side-scrollers, udlr (with diagonals possibly) in RPGs/topdown). You will actually want plenty of lower-level variables for each exclusive state (for example, determining exactly how far into a jump you are, the vertical speed, animation related timings, and the list goes on, blah blah every state could have some unique variables unshared by other states). None of these should actually be states in the finite state machine sense. I know I personally don't use finite state machines to encode real-time platformer scenarios.

However, controllers that influence a non-player entity's action could use a state-based system of sorts, probably along the lines of a Mealy Machine could be good for artificial intelligence. (Where the agent controls actions that affect their state, but does not directly affect their state) But typically with real-timed games, you need to put variable timing between each transition, and allow for interruption and other things. By this point, these are strictly not finite state machines, while still relying on state. But here this is useful.

Game menus can sometimes be close to FSMs, but usually aren't.

I tried to keep this quick, hopefully it's of some use to someone and I haven't skimmed on anything too vital. It's possible there are plenty of counterexamples to what I've stated, I've just went with some policies on how I generally approach this whole game-state thing.

Really, it entirely depends on what sort of game you're making. Games with a more static environment or fixed time steps (ex. turn-based RPGs) can get away with the simpler state-based systems. The more real-time, the more crap you need to accommodate for -- it will involve states to a degree, but there are now plenty of underlying variables.

[raigan]

This is a great topic; we've struggled with how to best organize behaviour logic when there seem to be two conflicting "state machines" at work simultaneously -- for instance a game where you can run and jump, but also grab onto and use things (which changes how running and jumping controls work).

Trying to enumerate all possibly combinations seemed like way too much work, but otherwise it was very tricky since in some situations the "movement" state machine should have priority over the "action" state machine, and in other cases the opposite is true.

[Falmil]

Hmmm, I guess all that does make sense. I'm not sure where I got the idea that state machines should be used for game entity state. I guess that means my original idea was better than I thought.

[Glaiel-Gamer]

i usually have some sort of state machine in my games (sometimes get lazy and use animation state as game state), just done as a lot of if statements (you have way more control that way for cases like shooting / jumping / blah)

[Kadoba]

 I don't view running, jumping, and shooting as states, they are flags to be handled by the state. In the player entity in my projects all of these would happen under one state, which is the free state. The vast majority of the time this is what state the player is in. This state holds all of the entity's control code meaning if it were any other state then the entity couldn't even walk. However, this gives us a ton of control. For example whenever the player entity is hurt and we want it to flinch for a few seconds all we have to do is change the "free" state to the "flinch" state and then have that state give back control to the free state after a moment. It is the flinch state's responsibility to change the sprite and handle anything unique about being smacked in the face. Now the only thing we have to do when the entity gets hit is change the state to flinching and the rest is automatically handled.

The same would happen if the player swung a really big sword. He shouldn't be able to walk or do anything else while swinging. Just change the "free" state to the "bigswordswing" state and have that state handle everything and then put the state back to free. If the player gets hit during the attack then switch the state to "flinching" and the attack immediately stops and the player flinches. If the player is in a cutscene then the state is in the "cutscene" state. The player does not have direct control and if anything special needs to happen to the player entity during the cutscene you have a place to put the code.

The idea is the same for AI except it might not spend quite as much time in the free state and instead free state acts like an intermittent state, giving the state to other "mental" states such as chasing and wandering. For example an ogre starts in the free state but since it doesn't see anything interesting it switches to the wandering state. Eventually the ogre spots the player and switches to the chasing state. The player throws a rock which bonks the ogre on the head, putting him into the flinching state, after a brief moment the ogre recovers and enters the free state by default. The free state realizes this time that the ogre sees the player so it puts it back into the chasing state. The player runs away out of sight and after a while the ogre gives up and reverts back into the wandering state.

This is just the way I handle it, which is probably pretty messy but I hope you get the idea.

[Zaknafein]

Not related to A.I., but there's been talk about states in that thread...