Thoughts on finite state machines and roles and complex objects in games

The definition of finite state machine is not mentioned here. For details, refer:

Http://baike.baidu.com/view/1270724.htm

I want to focus on the benefits that FSM may bring as the core of game management.

 

Introduction

It is well known that using scripts in event-driven scenarios is the most appropriate extension method, such as RPG and RTS games. However, in Act and ftg games, if you want to describe a role with many types of actions, a simple scripting language is a little inadequate.

Here, FSM can take advantage of its advantages. The State set can accommodate a group of homogeneous complex data, and the conversion rules can define the response of an object to the game world, that is, the state change. From the earliest initial state to the last several possible ending states, as long as this object exists, it must be in a certain state. The status conversion function can be stored in a file or database in the form of a role table, which provides great convenience for the development role editor.

If you have enough time, you can even use the GUI to develop intuitive drag-and-drop statuses in the window, link conversion instructions and conditions, and intuitively complete the role design. Commands (such as a mandatory trick command) and external events (such as the moment of landing from the air) are actually state machine conversion conditions (triggers), there is no difference between the two for FSM, the source is different.

 

A typical instance m.u. g.e. engine N is designed based on the FSM idea from the provided interface. All objects are in a group of States, including physical properties of objects. Of course, there are still a lot of such ancient things that do not look so reasonable and elegant. For example, the absence of a name for only numbers makes it very inconvenient to read when creating roles, it is often necessary to search for the meaning of the serial number. However, its overall design philosophy is very clear: Physical rules first determine the movement of objects. The state machine acts on a role or object by changing the physical attributes when entering or exiting the state, it eventually forms a seemingly consistent and controlled world system. For example, if a hits B and B is hit by trigger, the trigger changes to the flying state. Based on the strike strength and angle of A, you can give B a initial speed. When B is in the flying status, the controlled mark is off. (can B stop when B is in the flying status? That's too false.) after landing, the role jumps to the controlled state under the impact of the time-to-date trigger. The FSM does not move during the process of flying out and landing. It is completely effective by physical rules, which further confirms that FSM is based on physical rules, the operating mode that influences a role by changing its physical attributes.

This article is just an example of how to sort out your ideas and make it easy to use.

Above.