article784.asp.htm

电脑游戏中的人工智能制作（含源代码）

  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 //
};
</PRE></BLOCKQUOTE>

<P>Now some definitions of the variables:</P>
<P>The <I>pos</I> variable determines the unit's position in the game world and the <I>screenX, screenY </I>variables are useful for easily adding information around the unit on the screen such as health or selection information.</P>
<P>The <I>animDir, animAction and animNum</I> all refer to the units current animated state that will be drawn to the screen.</P>
<P>The <I>rank</I> and <I>health </I>variables are both fairly obvious and are extremely simplified for what information they could hold.</P>
<P>The <I>num </I>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.</P>
<P>The <I>group</I> 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.</P>
<P>The <I>style </I>and <I>animObj</I> variables are both more information about how the unit's graphics will be drawn.</P>

<H2>Building Past Basics</H2>
<P>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.</P>
<P>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?</P>
<P>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.</P>
<P>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!</P>

<H1>Grouping</font></H1>
<H2>To group or not to group?</H2>
<P>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.</P>
<P>Do you need your units to act in a coordinated way?</P>
<P>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.</P>

<H2>Benefits of Grouping</H2>
<OL>
  <LI>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.</LI>
  <LI>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.</LI>
  <LI>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抰 have any common ground.</LI>
  <LI>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.</LI>
</OL>

<H2>The Big Picture</H2>
<P>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.</P>
<P>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.</P>
<P>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.</P>

<H2>One of many</H2>
<P>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.</P>

<BLOCKQUOTE><PRE CLASS="code">
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 //
};
</PRE></BLOCKQUOTE>

<P>Explanations of the variables:</P>
<P>The <I>unitNum</I> 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.</P>
<P>The <I>unit</I> 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.</P>
<P>The <I>waypoint</I> 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.</P>
<P>The <I>action</I> 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.</P>
<P>The <I>stepX, stepY</I> 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).</P>
<P>The <I>run, walk, sneak