FUNDAMENTALS OF GAME DESIGN, SECOND EDITION
Athlete AI Design
In action games and first-person shooters, the player's AI-driven opponents typically exhibit a small number of behaviors each triggered by a specific event (appearance of the player on the scene, being shot at, and so on). When together in a group, the AI seldom assigns special roles to particular individuals or instructs them to help each other. It's every monster for itself.
These kinds of actions aren't acceptable in a sports game. People don't mind if a monster in a first-person shooter wanders aimlessly around, but the athletes in a sports game must behave like humans, and that means deliberate, intelligent action. Particularly in team games, each athlete works with the others on the team to accomplish particular goals. The position the athlete plays dictates behavior to some extent, but within those boundaries, the athlete still must respond intelligently to a number of possible events. In a relatively simple simulation such as tennis, there might not be many of these events, but a highly complex simulation such as American football, with 22 players on the field at a time, presents hundreds of them.
The play in a sports match can be broken down into states that are defined primarily by the rules and secondarily by the tactics and strategy of the game. For example, the period of time before a tennis player serves the ball is one state, and the rules dictate where she may stand and what actions she may take (and likewise for her opponent). The moment she serves the ball, the game enters a new state. The moment the ball passes over the net, it enters another one, and so on. The best way to design a sports-game AI is to map out a game's states as a giant flowchart. There could be far more states than you realize at first. Corner kick in soccer is not just one state but several: the period before the ball is kicked, after the kick but before the ball touches another athlete, after it has been touched by another athlete, and so on. See Figure 16.3 (next page) for a partial example.
Consult the official rules of the sport as you construct the flowchart; they often describe states in detail, with special rules applying to each. However, the rules alone are not enough—rules describe game states for the purposes of listing legal and illegal actions, but not for purposes of tactics or strategy. Whenever something changes that requires the athletes to adopt a different tactic, the game has moved into a different state.
SETTING COLLECTIVE AND INDIVIDUAL GOALS
After you define the game states, you can start thinking about what the team should do in each state—where each athlete should be trying to go and what he should be trying to do to support the team's collective goal at that moment. In some cases, these activities are defined with reference to a specific individual on the opposing team, for example, trying to prevent an opposing player from doing his job. The software must have a way of matching up athletes with their opponents, just as the real athletes do.
After you define what the team should be trying to accomplish in a particular state and have assigned each athlete a role, you then must define exactly how the athlete is to perform that role: what direction he moves, what other movements he makes, which animations should be displayed, and so on.
An athlete with nothing to do shouldn't just stand still. Most sports games include fidgets, short animations in which the athlete shifts his weight, stretches his arms, or makes some other neutral action every few seconds. If play is under way, an athlete not closely involved—the third baseman on a fly ball to right field, for instance— should turn and watch the action.
Like war games, team sports games are good candidates for using hierarchical finite state machines to produce the artificially intelligent behavior required. Two-player sports can use simple finite state machines, one for each player. See the discussion on finite state machines at the end of Chapter 14, "Strategy Games."
I wouldn't ever set out to hurt anybody deliberately unless it was, you know, important— like a league game or something.
—Dick Butkus, NFL linebacker
Injuries are a sad but common side effect of sports, and serious simulations take them into account. Because injuries occur somewhat randomly, they're outside the player's control and can be frustrating. Most sports games allow the players to turn off injuries if they don't like the effect that injuries have on the game.
Although it's possible for an athlete to injure herself simply by running or jumping, this doesn't provide the player with any visible explanation for why the injury occurred. A lot of sports games therefore limit injuries to cases of some kind of collision, ordinarily between two athletes. To determine whether an injury occurs, you should include such factors as the relative speed of the two athletes, their weights, their respective susceptibilities to injury, and a random probability just to introduce some uncertainty into the situation. The heavier an athlete is, the more force she imparts in a collision, and it is the force that does the damage to the other athlete.
The stress of playing some positions, such as pitching in baseball, can injure an athlete without a collision, with injuries becoming more likely the longer the pitcher stays in the game. You can compute the probability of an injury on every pitch and raise the probability slightly with each ball thrown.
You can also decide which part of the body sustains the injury and the length of time for which it will disable the athlete. Study reports of injuries and recovery times for the sport you are simulating. if your game tracks athletes over a period of time, you should consider the cumulative effect of injury and recovery time on their careers.
