FANDOM


Icon TFT
"You are accessing the classified database of the Task Force Talon"
This section of the Act of War wiki is archived, containing information from defunct fansites and wikis.
Do NOT edit any information in the archives unless it is fixing up spelling mistakes.
The finite state machine describing a game entity behaviour

The state machinesEdit

The behaviour of a unit is described by one or several state machines.

Each TypeWarrior can therefore contain a tree of state machines which root is specified by the property UnitStateMachineDescriptor.

During the cycle of life of a unit, it might sometimes happen that preventing the machine state to take decisions is required (for example, when a unit enters a Warp of a transporter). In this case, the unit is said to be lobotomised. In the other case, a unit that takes decision is said to be unlobotomised.

Machine stateEdit

<ndf>
TUnitStateMachineDescriptor
(
   MyName                            = //String
   MainUnitStateDescriptor           = //TUnitStateDescriptor
   SubUnitStateMachineDescriptorList = //TNewList { of TUnitStateMachineDescripor }
)
</ndf>

The TUnitStateMachineDescriptors are organised like trees by using the SubUnitStateMachineDescriptor property that contains a list of sub-state machine. Even if they are organised like trees, each state machines working on a unit is independant from the others. However it is possible to re-use an entire subtree of a given TypeWarrior in an other one, by allowing each state machines to navigate in the hierarchy in a predictable way.

Each TUniStateMachineDescriptor contains a tree of TUnitStateMachineDescriptor which root is specified by the MainUnitStateDescriptor. They represent the different states (terminal if they are leaves, non-terminal in the other cases) that the machine can take. They are also instanced seperately for each units at the creation.

Each state machine can have to reconsider the state in which it is (it would be senseless to have a state machine that can naot change its state)

The decision is taken:

  • regularly if a TEffetUnitStateMachine_LaunchDecisionRegulierement is looping in the current state.
  • When the unit receives a new order in the case the flag LaunchScannerEtDecisionOnNewClick of the current state is true.
  • When an effect forcing to take a decision is used (TEffetUnitStateMachine_ChangeFatherUnitDecision, ...)

If the decision takes the machine in a new state (or the decision was taken after a TEffetUnitStateMachine_LaunchDecision), the following effects are executed:

1. for each TUnitStateDescriptor that we leave, by going up in the tree:

  • The EffetDescriptor is killed
  • The EffetDescriptor_OnEndNormal is executed

2. for each TUnitStateDescriptor in which we enter, by goinf down in the tree:

  • The EffetDescriptor_OnStartNormal is executed
  • The EffetDescriptor is launched in background (it is an effect that lasts)
  MUSD
  +- USD1
  |    +- USD11
  |    +- USD12
  +- USD2
       +- USD21
       +- USD22

Therefore, a decision that brings the machine from the state MUSD/USD1/USD11 to the state MUSD/USD2/USD22, will execute the following sequence :

  1. We kill the EffetDescriptor of MUSD/USD1/USD11 ;
  2. We launch the EffetDescriptor_OnEndNormal of MUSD/USD1/USD11 ;
  3. We kill the EffetDescriptor of MUSD/USD1 ;
  4. We launch the EffetDescriptor_OnEndNormal of MUSD/USD1 ;
  5. We launch the EffetDescriptor_OnStartNormal of MUSD/USD2 ;
  6. We launch the EffetDescriptor of MUSD/USD2 in background ;
  7. We launch the EffetDescriptor_OnStartNormal of MUSD/USD2/USD22 ;
  8. We launch the EffetDescriptor of MUSD/USD2/USD22 in background.

State and decisionEdit

<ndf>
TUnitStateDescriptor
(
   MyName                            = //String
   Precondition                      = //TAccesseurBoolean
 
   EffetStack                        = //TNewStringList
   EffetDescriptor                   = //TSuperEffetDescriptor
   EffetDescriptor_OnStartNormal     = //TSuperEffetDescriptor
   EffetDescriptor_OnEndNormal       = //TSuperEffetDescriptor
 
   { Non-terminal states }
   UnitDecision                      = //TUnitDecision
   SubUnitStateDescriptorList        = //TNewList  { of TUnitStateDescriptor }
 
   { Terminal states }
   EffetDescriptorBeforeEnd          = //TSuperEffetDescriptor
   SauveEffetDescriptor              = //Boolean
   LaunchScannerEtDecisionOnNewClick = //Boolean
)
</ndf>

The TUnitStateDescriptor allows to define terminal and non-terminal states.

The terminal states are characterized by the absence of UnitDecision and SubUnitStateDescriptorList. Reciprocally, a non-terminal state must have thos two properties defined.

For some matter of optimisation, a TUnitStateDescriptor belongs to a unique tree (but the state machine it belongs to can be of course shared by many TypeWarrior).

It comes from the fact that each TUnitStateDescriptor should be identified in an unique way within a state machine.

Terminal statesEdit

A state is terminal only if it is a leaf in the state machine tree.

We have the following constraints for the effects (if they are defined, which is not obligatory) :

  • EffetDescriptor_OnStartNormal : must be atomical, can be functional and must force a decision;
  • EffetDescriptor_OnEndNormal : must be atomical, can be functional and must not force a decision;
  • EffetDescriptorBeforeEnd : must be atomical, can be functional and must force a decision;
  • EffetDescriptor : must not be atomical, or infinite if EffetDescriptorBeforeEnd is not defined

Non-terminal statesEdit

A non-terminal state is a node in the tree. We have the following constraints for the effects (if they are defined, which is not obligatory) :

  • EffetDescriptor_OnStartNormal : must be atomical, can be functional and must not force a decision;
  • EffetDescriptor_OnEndNormal : must be atomical, can be functional and must not force a decision;
  • EffetDescriptorBeforeEnd : must be defined;
  • EffetDescriptor : must be infinite.

Taking decisionsEdit

There are 3 types of TunitDecision:

  1. The constant decision: TUnitDecisionConstante
  2. The choice: TUnitDecisionIfThenElse
  3. The multiple choice: TUnitDecisionPriorite (allows to construct something equivalent to the switch...case)

The only decision that is difficult to predict is the TUnitDecisionPriorite. It has a list of subdecision. Each of those subdecision can:

  1. bring to a finale decision (TUnitDecisionConstante)
  2. inform the incapacity to decide (it is possible when the TUnitDecision is incomplete with the flag BreakAllowed at true), in this case, the next decision is tested

The main TUnitDesicion of a non-terminal TUnitStateDescriptor must always bring to a decision. It must always be able to decide.

Ad blocker interference detected!


Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.