FSM: Difference between revisions
PhilippRauch (talk | contribs) |
m (fixed wiki links) |
||
Line 18: | Line 18: | ||
==File Format== | ==File Format== | ||
Bohemia Interactive's FSM file format is similar in syntax to other "class" containing files such as the [[Description.ext]] file or the [[ | Bohemia Interactive's FSM file format is similar in syntax to other "class" containing files such as the [[Description.ext]] file or the [[Config.cpp]] file. | ||
Class FSM | Class FSM | ||
Line 56: | Line 56: | ||
*'''name''': This property takes a string argument and defines the name of the state. | *'''name''': This property takes a string argument and defines the name of the state. | ||
*'''init''': This property takes a string argument and represents the code executed upon an objects entering of the state. The code follows standard coding guidelines for [[ | *'''init''': This property takes a string argument and represents the code executed upon an objects entering of the state. The code follows standard coding guidelines for [[Function]] or the [[Code]] type. | ||
===Link Class=== | ===Link Class=== | ||
Line 70: | Line 70: | ||
*'''condition''': This property takes a string argument and is a code statement which must evaluate to '''true''' or '''false''' | *'''condition''': This property takes a string argument and is a code statement which must evaluate to '''true''' or '''false''' | ||
'''Example''': (side player == West) | '''Example''': (side player == West) | ||
*'''action''': This property also takes a string argument and defines code to execute during the transition (prior to state change). The code follows standard coding guidelines for [[ | *'''action''': This property also takes a string argument and defines code to execute during the transition (prior to state change). The code follows standard coding guidelines for [[Function]] or the [[Code]] type. | ||
Line 79: | Line 79: | ||
In the above example, we can see a more complex definition of an FSM. The States represent what a unit might encounter during a fictional battle. We can see things like the Reload State and Fire Single Shot state which represent actions a unit will perform | In the above example, we can see a more complex definition of an FSM. The States represent what a unit might encounter during a fictional battle. We can see things like the Reload State and Fire Single Shot state which represent actions a unit will perform at least once. Once a state has executed once, there are Links (or transitions) which determine the next state to traverse to. In some cases, there are transitions which loop to the same state. These transitions explain behavior that is carried out repeatedly until another condition occurs. None of the above Links themselves contain any actions (none were needed for this example), but they do display their conditions and priority. | ||
When we examine a state change from the state '''Target Acquired''' in the above example we get three optional transitions. | When we examine a state change from the state '''Target Acquired''' in the above example we get three optional transitions. | ||
Line 87: | Line 87: | ||
Each transition has a condition which is different from each other and a priority to sort the list when checking the conditions. If we take the highest priority transition (Weapon Out of Ammo), we find it this check only applies if the unit has fully run out of ammo in his weapon. If this evaluates true, the state changes to '''Reload'''. If the unit has ammo in his weapon, the engine then checks the next transition which is to see if the units magazine count is above 2 AND if they can enable bursts. This is a crude way of identifying that the unit might be more liberal with their shooting if they knew they had more magazines available. If this evaluates true, the '''Fire 3rd Bursts''' becomes how the unit engages. If that also evaluates false, then the default transition is that the unit '''Fires Single Shots'''. This would always evaluate true and cover any condition in which the unit cannot burst fire or is running low on ammo. It is also a safety in that if there are any other conditions we have not checked for, this is the transition to always follow. | Each transition has a condition which is different from each other and a priority to sort the list when checking the conditions. If we take the highest priority transition (Weapon Out of Ammo), we find it this check only applies if the unit has fully run out of ammo in his weapon. If this evaluates true, the state changes to '''Reload'''. If the unit has ammo in his weapon, the engine then checks the next transition which is to see if the units magazine count is above 2 AND if they can enable bursts. This is a crude way of identifying that the unit might be more liberal with their shooting if they knew they had more magazines available. If this evaluates true, the '''Fire 3rd Bursts''' becomes how the unit engages. If that also evaluates false, then the default transition is that the unit '''Fires Single Shots'''. This would always evaluate true and cover any condition in which the unit cannot burst fire or is running low on ammo. It is also a safety in that if there are any other conditions we have not checked for, this is the transition to always follow. | ||
The above example is very simple and is missing | The above example is very simple and is missing a lot of elements to make it a working FSM that | ||
is both believable and efficient. I only use this example because it shows different approaches | is both believable and efficient. I only use this example because it shows different approaches | ||
one might commonly use in FSM design. --[[User:CrashDome|CrashDome]] | one might commonly use in FSM design. --[[User:CrashDome|CrashDome]] |
Revision as of 18:04, 6 December 2006
FSM file structure and Concepts
Introduction
The FSM file is a new edition to Bohemia Interactive products starting with the Armed Assault and VBS2 product lines. FSM stands for Finite State Machine and is the primary method of coordinating Artificial Intelligence within these products.
What is the purpose of a Finite State Machine?
A Finite State Machine (as defined on Wikipedia) "is a model of behavior composed of states, transitions and actions."
By allowing an object to change states, we can give the appearance of dynamics. By allowing an object to change states conditionally, we can give the appearance of not only dynamics, but also intelligence.
As an object changes states, we perform actions which emit the desired behavior of that state. As in the above example, an object might start in State 1 and perform Action A. After the action is performed, the state machine looks at the next possible transitions and tries to find the transition in which a condition is satisfied. Perhaps in the above example, our object finds Condition Y is satisfied. In this case, the object would enter State 3 and perform Action C. In this crude example, the state machine would exit and our example would be complete. In more elaborate examples there might exist a transition which would take our object from State 3 to some other state such as back to State 1 - or even back to itself to perform the Action C again.
File Format
Bohemia Interactive's FSM file format is similar in syntax to other "class" containing files such as the Description.ext file or the Config.cpp file.
Class FSM { fsmName = “”; Class States { class SampleState { name=””; init=””; class Links { class SampleLink { priority=0.000000; to=””; condition=””; action=””; }; }; }; }; initState = “”; finalStates[] = {}; };
FSM Class
The FSM class contains three properties and a collection of States.
- fsmName: This property takes a string argument and defines the name of the FSM.
- initState: This property takes a string argument and refers the engine to begin at a predefined state in the state collection.
- finalStates: This property takes an array of string arguments. Current purpose unkown.
State Class
The State Class is the definition of a single state and the actions it performs. This class contains two properties and a collection of Links.
- name: This property takes a string argument and defines the name of the state.
- init: This property takes a string argument and represents the code executed upon an objects entering of the state. The code follows standard coding guidelines for Function or the Code type.
Link Class
The Link Class contains 4 properties.
- priority: This property is a floating point number which defines in what order the engine is to check conditions. A high value indicates higher priority.
Example: A link with the priority value of 1 exists along with another link which has a priority of 0. Even though both might contain different conditions, both could have satisfied conditions when the machine is looking for a state change (both conditions evaluate true). In this case, the priority of 1 will become the transition chosen.
- to: This property takes a string argument and defines the destination of the Link. The string should match the string of the destination State's name definition.
- condition: This property takes a string argument and is a code statement which must evaluate to true or false
Example: (side player == West)
- action: This property also takes a string argument and defines code to execute during the transition (prior to state change). The code follows standard coding guidelines for Function or the Code type.
Concepts and Examples
Example
In the above example, we can see a more complex definition of an FSM. The States represent what a unit might encounter during a fictional battle. We can see things like the Reload State and Fire Single Shot state which represent actions a unit will perform at least once. Once a state has executed once, there are Links (or transitions) which determine the next state to traverse to. In some cases, there are transitions which loop to the same state. These transitions explain behavior that is carried out repeatedly until another condition occurs. None of the above Links themselves contain any actions (none were needed for this example), but they do display their conditions and priority.
When we examine a state change from the state Target Acquired in the above example we get three optional transitions.
- To Fire 3rd Burst
- To Fire Single Shot
- To Reload Magazine
Each transition has a condition which is different from each other and a priority to sort the list when checking the conditions. If we take the highest priority transition (Weapon Out of Ammo), we find it this check only applies if the unit has fully run out of ammo in his weapon. If this evaluates true, the state changes to Reload. If the unit has ammo in his weapon, the engine then checks the next transition which is to see if the units magazine count is above 2 AND if they can enable bursts. This is a crude way of identifying that the unit might be more liberal with their shooting if they knew they had more magazines available. If this evaluates true, the Fire 3rd Bursts becomes how the unit engages. If that also evaluates false, then the default transition is that the unit Fires Single Shots. This would always evaluate true and cover any condition in which the unit cannot burst fire or is running low on ammo. It is also a safety in that if there are any other conditions we have not checked for, this is the transition to always follow.
The above example is very simple and is missing a lot of elements to make it a working FSM that is both believable and efficient. I only use this example because it shows different approaches one might commonly use in FSM design. --CrashDome