Chapter 13: Artificial Intelligence (AI)

Overview

Artificial intelligence is a scientific term that gives nonhuman entities algorithmic and mathematical solutions for problem solving and simulating human thought and decision making. In films, this is often depicted as a mechanical robot trying to act human. In computer or videogames, it is the heart and soul of the nonplayer characters (NPCs) controlling our enemies and allies.

Typically, we think of games such as chess, checkers, and backgammon as intellectual and sophisticated games, therefore a machine that can simulate being an adversary (especially a masterful one) has been a way for researchers to validate their AI techniques. Since computers can process mathematical instructions and perform iterations (repetitive processes) very fast, researchers in AI use these skills to simulate human thought.

As game designers, we must not only plan our vision but try to conceptualize each idea and how it can be expressed through a mathematical expression or logically arrived at through a database search or script. You will discover that simple, everyday activities are in fact very complicated and complex concepts.

In a baseball game, the pitcher throws the ball at the catcher as the batter from the opposing team tries to hit the ball and safely get to a base. Most of us have seen this scenario many times on television or at the ballpark. There are many complex issues being processed in this simple example of a sports game. The batter’s box is empty so the team at bat sends out their next batter (based on the roster and batting order) to the plate. The pitcher holding the ball may first check the runner on first base based on the following conditions: (1) There is a runner at first base, and (2) the first base runner is leading or positioned off the base by a few feet or more. The pitcher, who still has the ball even after the ball has been thrown to the first baseman, knows that a batter is “in” the batter’s box ready to receive a pitch. The ball is thrown based on a preset speed, type of pitch (curve ball, fast ball, slider, and so on), target position “in the strike zone,” and factors based on real-world factors like typical pitches and number of strikes, balls, and wild pitches this pitcher throws. The batter responds by swinging at the ball or not.

A pitch will be judged as a strike or a ball (if the batter doesn’t swing) based on the pitcher’s real-world factors previously mentioned. A swung-at pitch will use the batter’s real-world factors like number of strikeouts, singles, doubles, triples, home runs, type of preset hit (bunt, grounder, short hit in the air in the outfield just outside the infield), power hit (deep outfield or a possible “over the wall” home run), and point of contact with the ball (late swing, early swing, or perfectly timed swing).

The batter’s real-world factors and player factors, such as options selected and timing triggers, are combined, and a logical result should be determined. For example, a selected option to bunt would not result in an “over the wall” home run nor would a batting pitcher typically hit a home run or even a triple. The algorithm should include for a batting pitcher an extremely small (one in 10,000) chance of hitting a home run, a little better chance (one in 5,000) of hitting a triple even if the real-world factors indicate this is unlikely to occur. As the batter hits the ball into “fair” territory, the players in the field must follow the hit ball and respond if they are currently the closest field player to the ball. A ball hit to left field may have the shortstop initially moving, but as it passes by or over his head, he stops moving and the already moving left fielder continues moving until he acquires the ball. There are certain logical (predetermined) movements, such as the pitcher backing up the catcher on certain plays or the shortstop backing up the third baseman or second baseman, especially if they are the players moving after the ball.

Let’s look at a situation where the center fielder has just acquired the ball after it has hit the ground (so a caught fly out is not possible). There are runners at second base and first base, and the batter who just hit the ball is advancing to first base. The center fielder can throw the ball to the third baseman—outing the runner from second base, throw the ball to the second baseman—outing the runner from first base, or throw the ball to the first baseman—outing the batter advancing to first base.

What decisions does the experienced center fielder make in the real world? If the situation occurred when the team at bat had two outs, it would be vastly different than if the team at bat had no outs. (Remember, three outs retires the side, and the inning is over.)

I handled this situation in my baseball endeavor by remembering that each base is 90 feet from the other. The database had a factor for each player’s 100-yard dash speed (300 feet) and a factor for each player’s throwing speed and accuracy. Before acquiring the ball, the computer calculated the distance from the point of acquisition of the ball to each base (first base, second base, and third base) and factored in the center fielder’s throwing speed and accuracy to each of these bases against the runner’s speed and his distance to the next base or his current position (remember the runner could be leading off the base when the ball was hit) to the next base. The action that would result in a guaranteed out would be selected first. If no out situation was possible, then throwing the ball to the most advanced base or third base to stop further advancement would be the default selected.

Let’s assume that this scenario would have the center fielder throwing the ball to the second baseman. The second baseman would out the runner from first base. If this would be the third out, the action would terminate and the at-bat team would be finished; possibly the sides would exchange places (batting side taking the field and vice versa). If the outing at second base was not the third out, the second baseman would have to evaluate the current situation, just like the center fielder had done (second base runner is running to third base, is on third base, or is running home; batter is running to first base, is on first base, or is running to second base). These factors would result in another throw by the second baseman to the first baseman, to the third baseman, to the catcher, or possibly held until all action is halted and the runners are safe (stationary, not advancing) on first and third base. Then the second baseman would throw the ball to the pitcher. The batter’s box would again be empty and the cycle continues.

This seems like a lot of calculating and planning, but as designers, we must express our vision to the other team members, like the programmers who must translate our vision into concrete instructions, the artists who must provide models and artwork needed for each of these scenarios and actions, and the sound engineers who provide realistic sound effects to add life into this realistic and intelligent creation.

In our design, we must be consistent and fair. If a pitcher has no batting statistics (this is possible nowadays), then have some planned criteria such as minor league or college statistics followed by an average division, league, or professional statistics for pitchers.

When designing a game like chess or poker, design the best or championship skill level first and then lessen its strength. Lower strength levels can have threshold criteria placed on the player, shorter search path depths, or time limits to determine the best move found. In chess, you may exhaust all paths of analysis for the expert, set a limit to the depth of each path or a threshold value (such as “situation is valued at half a pawn or better” end analysis) for a club player, and select one of several random “non-losing” moves for a novice player.



Game Design Foundations
Game Design Foundations (Wordware Game and Graphics Library)
ISBN: 1556229739
EAN: 2147483647
Year: 2003
Pages: 179

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net