# Simultaneous game states

I think I understand the basic idea behind a Finite State Machine-based game loop. But I'm trying to write a little game in which the same object can simultaneously be in multiple, independent states. At least that's what I want to do.

To give you an idea: `Robot` may be in `FleeState` and `FireLaserState` at the same time, besides in each of them individually at any time.

Would something like this be possible using the FSM pattern? Or ought I to look elsewhere?

After all, does the whole idea make sense?

Pasted from my comment below: A little clarification of why I'd like states to be kept separate: I want the player to have the ability to program simple state changes before a game... say "if (health_is_way_too_low) flee". But then I want multiple such rules to be active simultaneously in order to keep the game interesting, and cannot know beforehand which other states may be active.

-
Makes sense in quantum physics. Otherwise, it's just one state: FleeWhileFiringState. – user15805 Apr 13 '13 at 15:50
Let me explain why I wanted to keep the states separate: I want the player to have the ability to program simple state changes before a game... say "if (health_is_way_too_low) flee". But then I want multiple such rules to be active simultaneously, and cannot know beforehand which other states may be active. – Kristian D'Amato Apr 13 '13 at 15:58
You could use super/substates - states could inherit each other and then you could use a custom scripting language to detect sub/super states – Polar Apr 13 '13 at 16:01
If the states are independent, you might use multiple FSMs to track them separately. – amitp Apr 13 '13 at 16:02
Thanks amitp; I was thinking like that too, but hoped there was something made for the job! – Kristian D'Amato Apr 13 '13 at 16:05

The main idea behind a FSM is that, at any moment, it can be found in a single state from a finite number of possible states. If you find yourself needing more than this, try to see if those multiple states can't actually be merged in one single state. If you feel like taking the dirt road is not that much of a bad idea, you can build a FSM base and some extra behavior on top of it, to allow for a lot more flexibility. As I said in my comment, this whole object-in-multiple-states makes sense in quantum physics and is a really funky subject to think of, if you ask me.

Similar situation of mine: I've recently tried to design a simple lamp with a smooth turn on/off effect as a FSM. When turned on, its intensity would gradually increase. The opposite when turned off. Keeping just the states: On, Off, Turning On, Turning Off was insufficient. When saving the game, for example, I also had to store the current light intensity when turning on or off, so that the process may be resumed. While, obviously, the number of possible states here was not equal to infinity (intensity goes between [min, max]), there were just too many to enumerate and merge. I had to (partially) break the FSM idea by storing the intensity step alongside the state. Perhaps you could apply something like this?

Regarding your latest edit, take a look at the gambits system in Final Fantasy XII:

The player is able to program the AI-controlled companions in a very nice way. Conditions are checked on each turn, one after the other. If a particular condition is met, the character performs the action and stops checking the rest, since he only has the ability to perform one action per turn. But in your case, you can make it not stop the checking process, and achieve the feeling of simultaneous actions.

Noticed how I made the word "actions" stand out? If I were you, I'd use a list-like structure, or perhaps a stack-like structure, to keep track of multiple actions that the robot has to take at any given time. If the robot has to flee and shoot at the same time, the actions would be: `[Flee, Shoot]`. Every time you think it is necessary, you can go through the main table of `{condition, action}` pairs and build the list or stack of actions that the robot has to perform.

You can build this behavior on top of a FSM base, like I did with my lamp. If the robot is in state `COMBAT`, it does the table of `{condition, action}` pairs check. Perhaps its health is below 50%? Add action "Flee" to the stack! But don't stop there. If there are some enemies still in range, also add "Shoot" to the stack.

-
Thanks Bogdan. Perhaps coming from a physics background, your comment re quantum physics made me chuckle :) Anyway, the thing is that contrary to the Q. physics counterpart, the states I'm trying to model are not complete states of the owner object... an object may be fleeing and shooting, but neither on its own describes the whole thing. Still, I think you're right; I'll give your basic idea a try. – Kristian D'Amato Apr 13 '13 at 16:33
Hah, I guess my comment may seem that way to people w/ background in physics. Just like chemistry, physics is a really intriguing science that I try to learn about from time to time, but mostly I get really puzzled. Ain't giving up though. – user15805 Apr 13 '13 at 16:40
+1 For remembering the gambits from FF XII – JCM Apr 14 '13 at 0:18

You have a couple choices here, you just haven't realized it yet from trying to shove round things into square holes =)

1) You haven't really defined all your states yet. Flee and Fire are independent states, adding a FleeAndFire state is the traditional way and well respected. By specializing states like this you get great control over what your actions will be and how they transition. The downside is that you need a good way to create your FSM and transitions and keep track, but there will be a finite number of states.

2) You've merged objects when they shouldn't be. Your robot is actually a RobotWheels that handles all the movement states, and probably all the other useful states for an entity in your world. On top of your RobotWheels is a RobotDefenseArray which is responsible for target acquisition decisions and firing when appropriate. The drawback is that your total entity may act "funny" unless they either use each other as inputs or react reasonably to the same trigger stimuli.

All the other options involve an AI and how it determines how your states transition; whether it is neural nets, pattern matching, procedural code, the list is endless.

-
As you point out, the states are not really completely independent, some of the time: say, if I'm fleeing and the retreating battle is turning in my favor, I would want to stop fleeing. So I need some centralized object that controls both motion and attack. Urgh.. my head hurts. – Kristian D'Amato Apr 13 '13 at 16:13
You are now talking about an AI that drives the states your Robot enters. Your AI sets goals and the underlying "make this goal work" code sequences out the states to get stuff done. Decisions like "am I winning right now" have nothing to do with states themselves. In this case the AI says "Oh, I'm now winning" and sets the goal of "defend" which then triggers states like "find cover" -> "acquire target" -> "fire" in sequence. Take a look here: web.media.mit.edu/~jorkin/goap.html – Patrick Hughes Apr 13 '13 at 16:19

I would break something like this up into slots and actions. For example, you would have a legs slot and an arms slot for your robot. Different actions take up different slots, so you can layer actions on top of each other. Here's a simple example:

``````Slot | Action
-----|-------
Arms | Shoot
Legs | Flee
``````

As you can see, the `Shoot` action takes up both the `Head` and `Arms` slots. The `Flee` action takes up only the `Legs` slot, so both can be performed at the same time. If there are two pending actions that use some of the same slots, you can sort them by priority, so a `Flee` action would be more important than a `Patrol` action when a powerful enemy is around.

-

To me, it seems like you're running up against a common problem that the Mixin or Decorator pattern could solve. From the Wikipedia article on the Decorator Pattern:

the decorator pattern is a design pattern that allows behavior to be added to an individual object, either statically or dynamically, without affecting the behavior of other objects from the same class.

This sounds like what you're trying to do, no? You can also find more information about Mixins in relation to game development here.

Depending on the language you are using implementation may or may not be an easy solution. For instance, in the JavaMonkey engine every spatial entity in the scene has a linked list of objects which all implement a "control" interface. These "control" objects each have an update method that gets called from their "owner" object (the spatial scene entity) at every iteration of the game logic. This allows you to add bundles of functionality dynamically to an object.

You could, for instance, create a control that establishes a fire weapon behavior that acts independently of another behavior that flees. This functionality is easy to implement in Java with interfaces and even easier in Javascript as Mixins can be directly implemented, other languages I'm not too sure about.

-