Microsoft Baseball 3D

This page is part of the History Of Game AI project curated by the AI Game Programmers Guild. Game Index -- AI Architecture Index -- Game AI Eras

Microsoft Baseball 3D
Developer:	WizBang! Software Productions
Publisher:	Microsoft Game Studios
Year:	1998
Platforms:	PC
Genre:	Sports
AI Era:	Strategic

Microsoft Baseball 3D (PC, 1998) was the first PC baseball game published by Microsoft Game Studios and was developed by WizBang! Software Productions.

The AI was primarily controlled by the AdLib scripting language engine (created in-house by Rob Duisberg). Steve Rabin was responsible for the baseball player AI, Vikki Zarkovich programmed the pitcher AI, Rob Duisberg wrote the announcer play-by-play AI, and Norm Sohl wrote the season simulator. From start to finish, the game took 2 years to complete (1996 to 1998) and was based off of WizBang's HyperBlade engine, which included AdLib.

Description of AI Behavior

The AI was intended to replicate realistic baseball player behavior, avoiding anything that would be uncharacteristic of real baseball players. Decision making during plays was designed to be optimal, however AI player performance was guided by actual player statistics (accuracy of throws, running speed, etc). The player look and feel was designed to be highly realistic with several key players on each team sporting texture-mapped photo likenesses. In the quest for realism, some of it fell into the uncanny valley as motion captured animations/transitions were sometimes clunky or jarring and player locomotion was somewhat odd looking due to the foot planting locomotion engine (see below).

Notable Behaviors

The key notable behavior was how the baseball players could adapt and cooperate regardless of the situation, due to a central manager that enforced good cooperation. For example, the human player could have the AI play out of position to the extreme right or left and the system would cope and still work reasonably well. This is described in more detail in the AI Player Coordination section.

Architectures

AdLib Scripting Engine

This section is based on first-hand knowledge by AIGPG member, Steve Rabin.

Many of the systems in Microsoft Baseball 3D, including the AI and camera, were controlled through an in-house custom scripting language called AdLib. AdLib was based on a Finite-State Machine architecture that included formalized message passing in addition to support for spawning background processes. AdLib primarily handled high-level control, calling to C++ functions for most work. The AdLib state machine structure had several unique constructs, such the ability to capture events regardless of the current state (called Global Responses) if they failed to be handled/consumed by the current state. AdLib was the inspiration for the State Machine Language (SML) later designed by Steve Rabin.

The individual player behaviors were basically state machines with about 20-30 states each. Originally each position had it's own state machine, but since any player could theoretically play any position, the final design had only 4 state machines: Outfielder, Baseman, Pitcher, and Catcher. In retrospect, there was still too much duplicated code and it would have been better to have broken up each state machine into specific tasks like Cover Base, Intercept Ball, or Rundown Chase (and then switch between state machines as needed).

AI Player Coordination

This section is based on first-hand knowledge by AIGPG member, Steve Rabin.

Microsoft Baseball 3D used centralized coordination, in the form of an invisible manager, to give job tasks to each AI baseball player (AI players would then be responsible for autonomously accomplishing their assigned job). The cooperation algorithm can be described as Task-Based Assignment, whereas tasks were the primary consideration.

First, a prioritized list of tasks were composed based on the current game world conditions (location/trajectory of the ball and base position of runners). For example, if the hit was a line drive between 1st and 2nd with no base runners, then the list of prioritized tasks would be: Catch the ball, Backup the catch, Cover 1st, Cover 2nd, Cover 3rd, and Cover home. The next step is to assign each prioritized task to the best candidate for the job (based on their ability to quickly accomplish the task). The highest priority task "Catch the ball" might be assigned to the First Baseman if he could get to the ball first. The second highest priority task "Backup the catch" might be assigned to the Second Baseman in this case. The third highest priority task "Cover 1st" might be assigned to the Pitcher. The fourth highest priority task "Cover 2nd" would likely be assigned to the Short Stop. The fifth highest priority task "Cover 3rd" would be assigned to the Third Baseman. Finally, the last task "Cover Home" would be assigned to the Catcher.

This Task-Based Assignment algorithm was used for every play including odd situations such as rundowns. The manager would revisit job roles whenever the situation changed significantly (such as the ball was caught, the ball changed owners, or the base runner situation changed).

Animation

This section is based on first-hand knowledge by AIGPG member, Steve Rabin.

Virtually all of the 500 animations were motion captured, with the exception of the running animations (due to difficulty in capturing a smooth cycle with the tethered equipment). One level of indirection was used to cut and composite raw animation files on disc into final playable animations at runtime, while also adding additional information for blending times when entering a composite animation. This compositing was authored in a unique scripting language specifically built for this purpose. Animations were played by embedding the specific composite names inside of AdLib scripts. For AI purposes, the composite scripting language offered a quick way to adjust animations during development to better suit the needs of the AI (thus eliminating the need to enlist the help of an animator). Typical adjustments involved making the animations "snappier" (cutting frames out or speeding up the animation) and creating new animations out of existing raw animations.

Locomotion

This section is based on first-hand knowledge by AIGPG member, Steve Rabin.

A peculiarity of the system was that most player translation was directly controlled by the placement of the feet in the animation. Heel and toe contact points were used which caused a sort of jarring walk as each came into contact with the ground (since each foot was static and didn't bend). The foot planting avoided the problem of foot sliding with the aim of providing realism, but it came at the cost of adding complexity in controlling player motion. To make an AI player move, a speed was chosen in which case a particular walk/jog/run animation would play and be scaled to that speed. The feet of the animation would drive the player forward in world space and the AI controller would pivot the player to guide the direction. When the destination was reached, the AI would switch to a stand animation (causing a quick 1-2 frame blend) simultaneously popping the position to the final desired spot. This was of particular concern since the foot placement of the basemen was very important.

Post-Mortem

What Worked

AI Player Cooperation

This section is based on first-hand knowledge by AIGPG member, Steve Rabin.

The Task-Based Assignment algorithm worked better than expected since it figured out how baseball players can optimally cooperate from first principles (determining what is important to accomplish and which player can best accomplish that task). Initially a playbook cooperation algorithm was considered where job assignments would be looked up in the playbook based on the situation, but this appeared to be a flawed approach since many plays fell between different precomputed playbook plays (even though the playbook include over 100 plays). However, other baseball games have successfully used a playbook cooperation mechanism (CITATION NEEDED).

Prototyping Behavior

This section is based on first-hand knowledge by AIGPG member, Steve Rabin.

During initial development of the player AI, an overhead 2D visualization was used to program against, since the full 3D engine with models/animations was not ready during the first 6 months of development. On the whole this worked out well for getting the large-scale cooperation worked out, but completely failed to anticipate the complexity of moving 3D players in a realistic and accurate manner when the time came to integrate with the 3D game.

AdLib Scripting Engine

This section is based on first-hand knowledge by AIGPG member, Steve Rabin.

The engine had the ability to track and log the state/messages of every game object over time, proving critical for finding bugs when multiple AI agents were involved.

What Didn't Work

AdLib Scripting Engine

This section is based on first-hand knowledge by AIGPG member, Steve Rabin.

While the structure of AdLib was powerful and advanced for its time, the inability to easily debug a script at runtime made the language frustrating for the developers to work with. While the scripting language offered reloading during runtime, this didn't help when faced with bugs, since a broken script usually caused the game state to become corrupt.

Lessons Learned

This section is based on first-hand knowledge by AIGPG member, Steve Rabin.

Sports games are extremely difficult to program with respect to AI since they must emulate the realistic expected behavior of the actual sport, down to the smallest detail or rule. A large amount of development time was dedicated to perfectly emulating the high expectations of players and finding/fixing all of the corner cases.

Reception by Public

The game came out to mixed reviews, however most consumers of the game received the game for free bundled with a 3D graphics card, resulting in over a million copies of the game produced.

References

1. Making the Play: Team Cooperation in Microsoft Baseball 3D, Steve Rabin, Computer Game Developers Conference (CGDC), 1998

External Links

(ADD LATER)