建立完整游戏AI实践之1

人工智能在很长时间因为某些原因在游戏开发里拖后腿，但游戏的特性将会越来越依赖更多地AI。如果一个游戏的AI没有达到玩家与其的水平，那么这个游戏将会感到很过时并因人们的感受而尴尬。

Game AI is not just neural networks and learning systems and complex mathematical structures, although it can be, but primarily game AI is about creating an environment and the appearance of thought from units. Game AI is behavioral, not scientific.

游戏AI不只是自然网络和学习系统，以及复杂的数据结构，尽管它包含这些，但主要的AI是创造一个环境并从单位来展现。游戏AI是基于行为的，不是科学性的。

The key to understanding how to create game AI is understanding what you want your final results to be and then building the system to provide those results. It all comes down to what the player can see; if they can't tell it's happening, then it might as well not be.

理解如果创建游戏AI的关键在于你想要什么样的最终结果，并要如果构建系统来提供这些结果。AI的全部结果是玩家看得到的，如果没看到，那就是没管用。

The examples and discussion will be given based on the format of Real-Time Strategy (RTS) games, however some of these concepts can be translated into being appropriate for other genres as well. All data examples are done in standard C format.

这里给出的例子和讨论是基于实时策略游戏，然而这里的一些内容可以转化为其他适合的游戏。所以数据结构都是以标准C写成。

状态机

有限状态机

A finite state machine (FSM) is a system that has a limited number of states of operation. A real world example could be a light switch which is either on or off, or an alarm clock that is either idling by telling time, ringing an alarm or having its time or alarm set. Any system that has a limited number of possibilities where something can be defined by one state (even combinations) can be represented as a finite state machine.

一个有限状态机（FSM）是一个有有限状态操作的系统。一个实际的例子是一盏灯可以被打开或者关闭，或者一个闹钟可以闲着报时间，也可以响铃如果设置了响铃时间。任何有限数目的可能性都可以被一个状态或者一个组合来表示。

Finite state machines are natural for any type of computer program and understanding how to use them effectively to create game AI is only as hard as understanding the system you are trying to represent, which is as detailed or simple as you make it.

FSM对于任何类型的计算机程序都是自然的并且写代码的难度与你理解你所代表的东西难度一致。

Using Finite State Machines

用FSM

There are many purposes for using FSMs in games but one of the more intricate ones you have to deal with is trying to model unit behavior since trying to simulate human beings is the toughest simulation there is. As guaranteed hard as it is to simulate human behavior there have been many stories of detailed game AI's that were mistaken for human players and vice versa by other players and spectators of the games, especially some detailed FSMs systems.

用FSM有很多目的，但一个其中一个复杂的原因是你必须处理尝试对以模拟人类行为为最难模拟部分的单元行为进行建模。有很多在这方面采坑的FSMS。

While some other systems are designed to more accurately model the way humans think and learn, sometimes you can just never beat the simplicity of having a choice, weighing the factors and deciding, as a human, which one you would make given that choice. When learning more about AI decision and learning systems always keep this in mind as often the best system for the job is the simplest and not the most scientifically accurate.

当一个其他系统被设计为精确模仿人类思想和学习的系统时，你将没有容易的选择，因为要像人类一样权衡因子的大小。当学习更多AI决策和学习系统后把这个记载心中：越简单越有效。

Don’t misunderstand this as opposition to Neural Network, Genetic Algorithms or any other artificial intelligence systems, just don’t mistake clever routines and interesting algorithms as being a better solution if they wont give better results. Weigh your choices based off what you need to get your end result, not the latest trends.

不要将AI与神经网络，遗传算法和其他人工智能系统混为一谈。以你需要得到的最终结果来权衡你的选择而不是最终的趋势。

游戏状态机

Creating a believable environment for your game means that you need to consider as many detailed elements that the player might possibly focus their attention on as you can. The more of these you anticipate by planning and testing, the more immersive the environment will be for the player when they are discovering your creation.

为你的游戏创建可信的环境意味着你需要与玩家可能在游戏里注意到的一样考虑哪些细节元素。你参与指定和测试的越多，为玩家提供给的环境就越引人入胜。

In your total game state there will be at least two division of state machines that you will need to keep your game going. The first state machine will deal with the game interface, which includes whether the game is paused, if there are different modes the player can be looking at the world in, then which one, what things the player can and can't see and any other flags you might use for your particular interface.

在你的所有状态里，至少有你需要保证游戏进行下去的两个状态。第一类状态机是处理游戏接口，包含游戏暂停。如果玩家可以在世界里看到不同的模式，这时玩家可以和不可以看到的和其他表示必须在你的接口里。

The second state machine will deal with what is actually going on in the game, the current state of the environment, objects in the level, objectives completed or failed in the mission and all other variables that you use to guide and challenge the player.

第二类状态机要处理游戏要继续下去，也就是环境的当前环境，每层的对象，目标完成或者失败和你用来指导和挑战玩家的其他变量。

You may have an alert system where the enemies will be actively patrolling if the player has been spotted or has fired shots, or flags for whether certain critical pieces have been destroyed or not. All of these items can be contained inside of a structure such as the example one below.

你可能有一个警报系统：如果玩家射击后会有敌人巡逻，或者某个重要地点被摧毁的标志。所以的这些可以被包含在下面的数据结构里。

struct GameLevelState {
  int alert;        	// Alert status of enemies //
  struct Positionshot;  // Position of last shot fired //
  int shotTime;     	// Game cycle last shot was fired //
  int hostage;      	// Hostage rescued //
  int explosives;   	// Explosives set or not //
  int tank;         	// Tank destroyed //
  int dialogue;     	// Dialogue variable //
  int complete;     	// Mission completed //
 };

灵活性

保持AI灵活是极端重要的。做的越是模块化，将来越容易扩展。理解AI是一个非常迭代的过程是重要的，你需要尝试并且构建之。

构建优秀AI的目标是单元在一个看起来真实的环境里很好的交互。
单元行动

在游戏AI里玩家控制单元，这对他们是很有意义的。没有这些，单元适应玩家将是困难的。如果一个玩家没有感到他在控制单元并从他们身上得到恰当信息，他就不会继续玩。

剖析101

你可以提供玩家一个简单的数据结构

struct Character {
  struct Positionpos;           	// Map position //
  int screenX, screenY;         	// Screen position //
  int animDir, animAction, animNum; // Animation information, action and animation frame number //
  int rank;                     	// Rank //
  int health;                   	// Health //
  int num;                      	// Number of unit //
  int group;                    	// Group number //
  int style;                    	// Style of unit (elf, human) //
  struct AnimationObject animObj;   // Animation object for complex animations //
};

Now some definitions of the variables:

The  pos  variable determines the unit's position in the game world and the  screenX, screenY  variables are useful for easily adding information around the unit on the screen such as health or selection information.

The  animDir, animAction and animNum  all refer to the units current animated state that will be drawn to the screen.

The  rank  and  health  variables are both fairly obvious and are extremely simplified for what information they could hold.

The  num  variable is the number that the unit is in the main unit array. Later, when calling the unit information from its group it is sometimes useful to pass off which unit it is, without giving the actual structure address.

The  group  variable determines which group the unit belongs to as a unit should belong to a group at almost all times. The only time a unit should not be in a group is if the unit is dead.

The  style  and  animObj  variables are both more information about how the unit's graphics will be drawn.

Building Past Basics

Once you have your initial routines working based on a simple version of your units, such as the above, its time to start building more information into them to really bring them to life.

You will need to think about what kind of actions and reactions you want the units to have. Do you want them to be controlled by emotions? Do you want them to be able to freeze up? Run away? Charge like a madman?

If you do then adding variables to determining emotional states could be a next step. The best way to try to understand what components your units can have is to try and understand yourself and what you would be dealing with in a situation that they are. In order to create human like reactions, you need to base it off of how a human would react.

There is another side to this, almost an opposite of human reaction, which is providing a synthetic experience that is not based on reality, but instead based on challenging the player. Instead of making your units based on your instincts, you will need to think in whatever manner you want your units to react in. The point is that you have to make the decisions about every facet you can or you will end up with flat, boring reactions that are too easy to predict, or even seemingly random. Either of these traits could ruin an otherwise good game, so put a lot of thought into it, and most importantly, play it to death to make sure it works!


Grouping

To group or not to group?

If you are creating a First Person Shooter game then it comes as no big surprise that grouping isn't for you. However, if you are creating a RTS or a game that has the player controlling more than one unit at a time then you have a question to ask yourself.

Do you need your units to act in a coordinated way?

If the answer is yes, then there is a good chance that grouping is for you. If the answer is no there still may be advantages to grouping but you will have to sort those out on your own as they will no doubt be totally dependent on exactly the kind of actions you want your units to perform.

Benefits of Grouping

• Units can move in a formation only accessing one master list of movement information. The advantage here is that you do not have to propagate information to every unit in the group when a destination or target changes as they all get their movement information off of the group source.
• Multi-unit coordinated actions, such as surrounding a building, can be controlled at a central location instead of each unit trying to work out where it is in relation to other units and bumping back and forth until they are in the correct position.
• Groups can maintain their structure so that issuing new orders only takes the same amount of time and data as issuing an order to a single unit. Most important you will create something that can be easily understood and read. Changing around 25 units or so and having them try to pass information to each other can be quite a chore if they don’t have any common ground.
• Depending on the formation of the group, obstacle avoidance and detection can be simplified and time to find paths can be reduced, which can be a serious concern when dealing with a large amount of units.

The Big Picture

Organizing your group, just like everything else in creating a game AI, is about understand the final affect you want to gain with control of the units. The idea is to create a place where there is a central repository of information which can be found quickly and shared between units. The idea is also not to duplicate any data, you want data to be found at one source and one source only, and that source needs to be the most logical position for the information so that when you are later working with it and building off of it, other logical extensions will equally seem to be in the correct places.

From my experience I decided that this separation in my work should be split where anything that has to do with the unit as an enclosed entity will be placed in the unit's data structure, while anything that had to do with movement, or actions, since those are what we are trying to organize and share, will be placed in the group data structures.

This means that the units alone will not have any information on where they are going, or what they are doing beyond the physical position they are in, like their animation frame and position in the world. To do this it means that a unit must ALWAYS be in a group as long as they are capable of moving or their actions changing. If they are alone, then they are just a group of one.

One of many

While we are ultimately looking for a group to act as a coordinated system, the system is definitely made up of individual pieces and it's important to keep track of what each unit is doing individually so that when we need the group to break formation and move about as separate entities with common or individual purposes we can. For this goal I created a structure similar to the one below.

struct GroupUnit {
  int unitNum;              	// Character Number //
  struct Unit *unit;        	// Unit character data //
  struct Positionwaypoint[50];  // Path in waypoints for units //
  int action[50];           	// Actions by waypoints //
  int stepX, stepY;         	// Step for individual units, when in cover mode // 
  int run, walk, sneak, fire, hurt, sprint, crawl;      	// Actions //
  int target;               	// Targets for units //
  struct Position targetPos;	// Target Position //
};

Explanations of the variables:

The  unitNum  is the number of the unit in the group. If there is a maximum of 10 units in a group, then there will be 10 possible slots that could have units. The first unit would be unitNum 0, following to unitNum 9.

The  unit  is a pointer to the unit's character data, which holds information like the characters current position, health and every other piece of information on the individual. Its important that a unit's vital signs and other information can be monitored from the group so that you can easily check to see if a group member has been wounded and communicate this to the other members, along with a myriad of other possibilities.

The  waypoint  array contains all the places that the unit has to move in a queue. All actions and waypoints are only specified in the GroupUnit structure if the group is not in a formation and units need to move about on their own.

The  action  array contains actions that are associated with the movements to waypoints. This allows you to create more detailed command chains, as telling units to sneak across one area and then sprint across another adds a lot of possibilities to making more strategic and thought out movements by the player.

The  stepX, stepY  information can be used for simple velocity; every frame move this unit this many world-position-units in any direction on the map. Used properly this can be just as applicable for all situations as doing real physics modeling, only with a simpler system and usually reduced processing time (not to mention ease of implementing the first time or quickly).

The  run, walk, sneak… variables all deal with different states the unit are in. These are not animations, but action states that can be toggled easily and even have multiple states that effect each other differently when more than one are turned on.

The  target  and  targetPos  variables are used to hold the unit number of the enemy being targeted and his current position. The enemies position, as well as health and other attributes, could just be referenced each time by looking up the enemies unit number, but for readability I decided it would be easier to keep a local copy of the enemies position.

Mob mentality

The ultimate goal of course is to have a centralized location for as much of the data as possible to limit the amount of look ups and processing to a minimum and keep things simple. Lets take a look at a sample data structure for doing this.

struct Group {
  int numUnits;          	// Units in group //
  struct GroupUnit unit[4];  // Unit info //
  int formation;         	// Formation information for units and group //
  struct Position destPos;   // Destination (for dest. circle) //
  int destPX, destPY;    	// Destination Screen Coords //
  struct Position wayX[50];  // Path in waypoints for group //
  float formStepX, formStepY;  // Formation step values for group movements //
  int formed;            	// If true, then find cover and act as individuals, otherwise move in formation //
  int action, plan;      	// Group action and plans //
  int run, walk, sneak, sprint, crawl, sniper;   // Actions //
  struct Position spotPos;   // Sniper Coords //
  int strategyMode;      	// Group strategy mode //
  int orders[5];         	// Orders for group //
  int goals[5];          	// Goals for group //
  int leader;            	// Leader of the group //
  struct SentryInfo sentry;  // Sentry List //
  struct AIStateaiState; 	// AI State //
};

The  numUnits  variable refers to the number of units in the group and the  unit  array holds the GroupUnit information. For this particular group the maximum units has been hard coded to 4.

The  formation  flag determines what type of formation the group is in. They could be formed in a column, wedge or diamond shape easily by just changing this variable and letting the units reposition themselves appropriately.

The  destPos  and  destPX,destPY  are all information for keeping track of the final destination of the group and relaying that information quickly to the player. The waypoints and steps work the same manner as individuals except that when units are in a formation they will all have the same speed so they stay in formation. There is no need to update each unit by its own speed value, as the group's can be used.

The  formed  variable is one of the most important as it determines whether the units act in formation or as individuals. The concept is that if the group is formed then all the units will have the same operations performed on them each cycle. If there is a reason that they can't all move the same way, such as enemies attacking or a necessary break in formation to get past an obstacle, then the units need to move on their own.

The actions are the same as individual, and you'll notice that there is a variable for a sniper that is not in GroupUnit structure as there is no reason to have one unit in a group be a sniper while the rest are off running around. It is logical to split that unit into its own group and then control the sniper activities at the group level. This is the kind of planning you need to do to figure out what information is best served in what section of your structures.

The  strategyMode  is a quick variable that determines how the units respond to enemies. Is it aggressive, aggressive with cause, defensive, or run-on-sight? Having an easy to access overview variable that controls basic responses is a good way to cut out a lot of individual unit and group situation calculations. Beyond that it gives the control to the player, who can set different groups in different modes so they know how each group will react if they encounter any enemies.

The  orders  and  goals  arrays point to orders and goals described in an order and goal database so that when orders are given they can be assigned to multiple groups easily and each group feeds off the same information.

The  sentry  and  aiState  are fairly self explanatory as they contain sentry information and more detailed aiState information for doing detailed pattern matching.

Putting it together

Now that we have some structures for our groups, what's next? The next step is to figure out how you are going to use this information by routines in your game.

It's  crucial  that you carefully plan for your AI routines to be modular and flexible so that you can add on to them later and easily call different pieces. The concept here, as in data structure organization, is to only do something in one function, and to make that function limited so that it does a specific thing. Then if you need to do that thing again you can call the routine that is already tested and is a known single point of operation on that data. Later if you run into problems with your AI and need to debug it, you don’t have to go hunting all over the place for the offending routine, because there is only one routine that would operate on that data, or at least in that manner.


Tips

Walk before you run. Learn the basics, create the basics, add more advanced routines for your particular game as you need them. Never fall into the trap of using a routine because it is popular and everyone else seems to be using it. Often other people are using a routine because its' benefits fit their needs, but it may not fit yours. Furthermore, people often use routines just because they are the standard, even if they are actually not the best routines for their situation.

Your concern should always be on getting the best results, not having the current fashionable routines; if it works, use it. The game developer mantra used to be, and always should be, "If it looks right, it is right." Don’t let the people who are interested in designing real world total physics simulations make you feel bad for creating a simple positional system where you add X to the position each frame. If that is what works in your particular situation, then do it. Correct physics has its place in some games, but not all of them and there are other ways of achieving nearly the same results.

You can never build a perfect replica of reality. That is just a fact. So you need to draw your own line on where  good enough  is and then make your good enough reality.