The essence of a game system is input and output. We divide the game system into multiple different states, with different States producing different outputs under different inputs. According to this idea, we can divide complicated subsystems in the game, such as the combat system into multiple States. What we need to do is to input different combat operations, convert the corresponding status and execute the Action output in the corresponding status.
So what is a finite state machine? The input and output of the state machine are discrete and limited. On this basis, the finite state machine we call describes this problem:
In a finite input, the ing relationship of a finite Output Combination is generated due to different input sequences. To describe this ing relationship, there are two expressions: Status migration table and status migration diagram.
Since it is a ing relationship, is it possible to implement a general finite state machine?
The answer is yes. In this sense, the general finite state machine is the engine used to parse the state chart and generate the required output.
A general state machine in this sense must meet the following two conditions:
1. The status of the state machine can be configured.
2. You can configure the conditions that meet the State migration requirements of the state machine.
The status migration diagram can be configured.
The finite state machine has several types of output triggering actions:
1. Entry action)
2. Leave action)
3. Transfer action)
4. When the system is in a certain state and receives a specific event, the triggered event is short for the input action)
5. Timeout action)
The above basic concepts have been clarified, so we can start our FSM trip.
First, we should use new hands to guide task robots as the first FSM application, and all FSM applications must do the first thing,
1. Draw a status migration Diagram
This status migration diagram describes the ing between receiving server input events and outputting events to the server as a client novice task robot.
That is to say, we need to draw a State migration diagram. First, we need to figure out the interaction model between the client and the server, and then divide the State based on the interaction model. What needs to be stated first is that the state chart can be nested!
Why do we need to divide the status into smaller ones?
The finer the state, the smaller the granularity of the action to be executed, the smoother the state machine operation and the less prone to performance problems.
How to divide the status?
First, the status is visible to the external environment. that is to say, there must be input and output. If there is no input or output, this state is not observed, that is, there is no need to define it.
On this basis, we can describe a different state based on different inputs and outputs. If there is the same input and output, we think it is the same state. That is to say, the real state division is to judge a State from observed, input and output.
How to drag the FSM?
We can take a specific example: in the input and output streams of a newbie task, the input and output streams about combat may be repeated in many places, for example, when receiving a combat task, in addition, the input and output streams of the task of collecting strange items in the wild may be the same, so we can use a sub-FSM to represent the data, and we can reuse this part of code.
The conclusion is that the sub-FSM is used to solve the problem of Repeated input and output streams in a large state machine.
2. Implement a FSM engine for parsing status migration Graphs
3. Similarities and Differences between our FSM framework and traditional FSM programming: FSM is essentially a control strategy. Traditional FSM programming integrates control policies and States. Our FSM framework, the control policy and status are separated.
The above is the theoretical knowledge of FSM. The next article FSM: Finite State Machine in Game Development (practice) will explain the practical application of FSM in games based on specific examples.
Http://blog.csdn.net/peter_teng/article/details/9151111