User:CrashDome/Sandbox - Revision history

Erentar: Erentar moved page CrashDome's Sandbox to User:CrashDome/Sandbox: Bot: Moved page

2018-12-03T01:48:46Z

Erentar moved page CrashDome's Sandbox to User:CrashDome/Sandbox: Bot: Moved page

← Older revision	Revision as of 03:48, 3 December 2018
(No difference)

CrashDome at 16:51, 19 December 2006

2006-12-19T16:51:35Z

← Older revision		Revision as of 18:51, 19 December 2006
Line 1:		Line 1:
	[[Category:Sandbox]]		[[Category:Sandbox]]

	~~{{ArmA-disclaimer}}~~

	~~<big><big>FSM file structure and Concepts</big></big>~~

	~~==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 [http://en.wikipedia.org/wiki/Finite_state_machine 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.

	~~[[Image:SimpleFSM.jpg]]~~

	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 C 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 C to some other state such as back to State A - 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 [[Functions]] 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 [[Functions]] or the [[code]] type.


	~~==Concepts and Examples==~~

	~~===Example===~~
	~~[[Image:ExampleFSMDiagram.jpg]]~~


	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 atleast 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 alot 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. --[[User:CrashDome\|CrashDome]]~~

	~~==External Resources==~~
	*[http://en.wikipedia.org/wiki/Finite_state_machine Wikipedia Entry for FSM]
	*[http://www.nist.gov/dads/HTML/finiteStateMachine.html Nat'l Institute for Standards and Technology Definition of Finite State Machine]

CrashDome at 15:41, 1 December 2006

2006-12-01T15:41:35Z

← Older revision		Revision as of 17:41, 1 December 2006
Line 9:		Line 9:

	===What is the purpose of a Finite State Machine?===		===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."		A [http://en.wikipedia.org/wiki/Finite_state_machine 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.		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.
Line 85:		Line 85:
	*To Fire Single Shot		*To Fire Single Shot
	*To Reload Magazine		*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. ~~The first~~ transition to check ~~would be~~ if the unit has run out of ammo in his weapon. If this evaluates true, the state changes to '''Reload'''. If the ~~units~~ has ammo in his weapon, the engine then checks to see if the units magazine count is above 2. This is a crude way of identifying that the unit might be more liberal with their shooting if they knew they had more magazines. If this evaluates true, the '''Fire 3rd Bursts''' ~~become~~ how the unit engages. ~~The~~ default transition ~~if none of the above are true~~ 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 alot 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. --[[User:CrashDome\|CrashDome]]

			==External Resources==
			*[http://en.wikipedia.org/wiki/Finite_state_machine Wikipedia Entry for FSM]
			*[http://www.nist.gov/dads/HTML/finiteStateMachine.html Nat'l Institute for Standards and Technology Definition of Finite State Machine]

CrashDome at 07:53, 1 December 2006

2006-12-01T07:53:23Z

← Older revision		Revision as of 09:53, 1 December 2006
Line 1:		Line 1:
	[[Category:Sandbox]]		[[Category:Sandbox]]

	{{~~unsupported~~-~~doc~~}}		{{ArmA-disclaimer}}

	<big><big>FSM file structure and Concepts</big></big>		<big><big>FSM file structure and Concepts</big></big>
Line 23:		Line 23:
	{		{
	fsmName = “”;		fsmName = “”;
	~~initState = “”;~~
	~~finalStates[] = {};~~
	Class States		Class States
	{		{
Line 43:		Line 41:
	};		};
	};		};
			initState = “”;
			finalStates[] = {};
	};		};

CrashDome at 22:44, 30 November 2006

2006-11-30T22:44:00Z

← Older revision		Revision as of 00:44, 1 December 2006
Line 75:		Line 75:
	==Concepts and Examples==		==Concepts and Examples==

	===~~Generic~~ Example===		===Example===
	[[Image:ExampleFSMDiagram.jpg]]		[[Image:ExampleFSMDiagram.jpg]]


	~~==Bibliography==~~		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 atleast 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.

	~~crashdome:~~		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. The first transition to check would be if the unit has run out of ammo in his weapon. If this evaluates true, the state changes to '''Reload'''. If the units has ammo in his weapon, the engine then checks to see if the units magazine count is above 2. This is a crude way of identifying that the unit might be more liberal with their shooting if they knew they had more magazines. If this evaluates true, the '''Fire 3rd Bursts''' become how the unit engages. The default transition if none of the above are true 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.

CrashDome at 22:19, 30 November 2006

2006-11-30T22:19:56Z

← Older revision		Revision as of 00:19, 1 December 2006
Line 12:		Line 12:

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

			[[Image:SimpleFSM.jpg]]

	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 C 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 C to some other state such as back to State A - or even back to itself to perform the Action C again.		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 C 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 C to some other state such as back to State A - or even back to itself to perform the Action C again.
Line 60:		Line 62:

	*'''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.		*'''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.		'''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 ~~class~~' '''name''' definition.		*'''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'''		*'''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 [[Functions]] or the [[code]] type.		*'''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 [[Functions]] or the [[code]] type.

Line 71:		Line 76:

	===Generic Example===		===Generic Example===
			[[Image:ExampleFSMDiagram.jpg]]


	==Bibliography==		==Bibliography==

	crashdome:		crashdome:

CrashDome at 21:50, 30 November 2006

2006-11-30T21:50:28Z

@@ Line 6: / Line 6: @@
 ==Introduction==
 ==File Format==
 ===FSM Class===
 ===State Class===
 ===Link Class===
 ==Concepts and Examples==

CrashDome at 19:55, 30 November 2006

2006-11-30T19:55:07Z

← Older revision		Revision as of 21:55, 30 November 2006
Line 1:		Line 1:
	[[Category:Sandbox]]		[[Category:Sandbox]]

			{{unsupported-doc}}

	~~This is a test of the Footnote system.~~<~~ref~~>~~Footnote should appear here~~</~~ref~~>		<big><big>FSM file structure and Concepts</big></big>

	~~Footnote List:~~		==Introduction==

	~~<references/>~~		==File Format==

			===FSM Class===

			===State Class===

			===Link Class===

			==Concepts and Examples==

			===Generic Example===

			==Bibliography==

			crashdome:

CrashDome at 18:59, 3 August 2006

2006-08-03T18:59:44Z

← Older revision		Revision as of 20:59, 3 August 2006
Line 2:		Line 2:


	This is ~~atest~~ of the ~~reference~~ system. <ref>~~tets~~</ref>		This is a test of the Footnote system.<ref>Footnote should appear here</ref>

			Footnote List:

			<references/>

CrashDome at 18:38, 3 August 2006

2006-08-03T18:38:04Z

← Older revision		Revision as of 20:38, 3 August 2006
Line 1:		Line 1:
	[[Category:Sandbox]]		[[Category:Sandbox]]


			This is atest of the reference system. <ref>tets</ref>