Simultaneous game states

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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
-----|-------
Head | Shoot
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.

Answer 4

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.