ARES - Hierarchical AI

ARES is a project by Yee-Cheng Chin, John Shields, Mike Shim, and Andrew Bragdon for the Spring 2006 CS196-2 class "Innovative Game Development" at Brown University. ARES was successfully presented on May 12th, 2006 as the final project for the course.

Today's hottest video games boast photo-realistic graphics, humanlike movement, facial expressions, and accurate physics models to boot. Many of these games also claim to have "intelligent AI"—meaning that the in-game agents emulate human decision processes. The reality is that although graphics, physics, and sound have made remarkable strides towards realism, AI remains glaringly stupid. A primary cause of this stupidity is that the all-powerful AI gives orders to every non-player agent in the game. When "bosses" and "underlings" exist in a game, the AI controls them on an equal contextual level. This monolithic AI model fails to consider real commands in military or social organizations are passed down through a chain of command. Ideally, a non-player agent's choices are not only dependent the game state, but also on the goals of his commanding officer or social superior. A second problem with the existing monolithic AI model is that of global information: when one enemy grunt discovers the player's location, then all other enemies are also instantly made aware of this information. Real social and military structures exhibit information lag, that is, that any information detected at a low level in the organization will take time to propagate upwards to the commanding ranks and then downwards to all concerned parties in the hierarchy.

ARES presents a solutionto this problem: a hierarchal AI model where units receive orders and information through a chain of command, then use that information to make decisions for themselves and their inferiors. The ARES AI System will provide real time strategy games with an enhanced sense of realism and enable new levels of engagement for players. Our game ARES is not a "game" in the conventional sense of continual player involvement, but rather a showcase of the ARES AI System: the user constructs a scenario using the ARES Studio editor program, then runs the app and watches the action unfold as troop movements are coordinated in an AI hierarchy. As the game was conceived and implemented by a team of four people in one semester, we chose to focus our efforts on a never-been-done-before AI model instead of implementing gameplay elements found in other action and strategy games; this choice was inline with the CS196-2 course goals. Any number of popular games—from Warcraft to Doom to The Sims—could implement our AI System to enhance the player experience. Our ultimate goal is to hear the player exclaim: "I can't believe the A.I. just did that!"—a reaction we've had a few times ourselves when testing our engine.

There are many possibilities for AI improvement in games research, and it is appropriate to distinguish briefly between what ARES is and is not. The ARES AI model does not emulate a human video-game opponent but rather a real-world human army. For this reason, ARES has a primary application to Real-time Strategy games. Note also that it can be used both as an opponent AI and also a support AI; in the latter case, the player would be able to issue orders to groups of units which would be executed in a realistic military fashion. We do not seek to create an invincible AI which can beat a human player every time (e.g. IBM's Deep Blue Chess AI), or a scalable AI which can be adjusted in difficulty to provide the player with the optimum sense of challenge. There many excellent opportunities for AI improvement, some of which were explored in other CS196-2 projects including Q-Boltz Millenium Wars and Kung Fu Tamagotchi. In ARES, we kept our goal focused on the hierarchical AI model as a way to create an added degree of in-game realism.

The ARES AI System

The ARES AI System is structured around four military ranks as follows: 1 General, 5 Colonels, 10 Captains, and 130 Grunts. A standard game configuration can handle up to 300 units total on a 300x300 tile map; by comparison Blizzard Entertainment's StarCraft has a maximum map size of 256x256 tiles and roughly 125 total units in a game. The ARES AI operates in turns. Each turn, units perform basic actions such as moving, detecting enemy units, and firing. Additionally, decision-making units (Captains and above) think and give orders every couple of turns, with Captains thinking more frequently than either Colonels or Generals. Different ranks use different decision making algorithms as follows:

• The two Generals (one per side) are concerned with the whole map; they play "a game of chess" using a Minimax look-ahead search algorithm to make orders to move the Colonels. A General makes decisions based on the location of its troops and the known locations of the enemy troops. Much like a realistic general, however, ARES Generals take a broad view of the game state: they consider the map as a 10x10 grid and look at groups of units rather than individuals.
• Colonels receive an order from the General to move to a broad region on the map, then organize their subordinate Captains to best attack enemy units and capture the target area.
• The Captains focus on most zoomed-in extent of the game, coordinating the movements of Grunts to attack enemy forces. Unlike Generals, Colonels and Captain make decisions using utility functions as follows:
  1. Game state factors such as the number of combatants on each side are considered. Then the AI walks through limited set of possible tactics (predetermined attack routes) looking for chances to "flank" the enemy from the side or rear. Using this model, a chance of winning is evaluated for each tactic.
  2. The possible outcomes are then weighted by personality factors such as Aggressiveness which are unique to the unit.
  3. If the Utility Function evaluates below a certain threshold, the unit will order its subordinates to retreat. Otherwise, the attack will proceed with the tactic of greatest utility. The Captain generates routes for his troops by mapping the attack route to a list of tiles using A* pathfinding
• Grunts implement only the most basic level of AI agent actions, including detecting enemy units, moving, and firing. Like the real military, our model gives grunts almost no opportunity for independent thinking; they are merely cogs in the machine.

For further information, please see the links to the Project Proposal and Post Mortem on the lefthand sidebar.

Latest Screenshots

Thursday, May 04, 2006

We finally got ingame screenshots working so I've taken a few from the latest build. This will be shown in class on Friday. I'll let them speak for themselves:
 

ARES Studio

We've made a Win32 scenario editor/tool for Ares called "ARES Studio". This was demo'ed in class weeks back, but by now it's gotten pretty robust. We took the words of the BiG Games Tool Programmers to heart and made an application that can be used to position soldiers and change their use of formations. In the near future it may be used to tweak soldier parameters such as aggressiveness, etc.

Here's some screenshots:

This is the Scenario Editor which is used to place soldiers of all ranks and objects such as trees, buildings, burning cars, etc.

Here's another screenshot of the Scenario Editor. Note that the colored dots are soldiers, with circles being grunts. Black lines indicate hierarchy links

This is the Tactics Editor. It is used to create preplanned "attack routes" which armies choose from when attacking an enemy. Note that orientation is important in the game, and flanking can take enemies by surprise! In the above example, one "squad" (5 or 6 soldiers) will follow the blue route, while another squad follows the red route.

This is the Formation Editor. It is used to create offensive and defensive formations, that is locations and orienations of individual soldiers.

No screencaps

Thursday, April 27, 2006

No screencaps recently because for some reason I'm having trouble getting taking them with our graphics engine. For some reason that funcitonality broke a month ago and we haven't yet been able to fix it. We did implement a number of

We will however have a working build online mid next week, up until now we've only made a number of demos that weren't worth a public release.

Here's a summary of our work in the past two weeks:
Andy—Worked on a C# editor for in-game Tactics and Formations, also doing a variety of work related to pixel shaders
Johnny—Skinned and animated lots of in-game graphics including US and Iran soldiers, guns and accessories, muzzle flashes, 4 palm trees, and a mosque.
Yee-Ching and Mike -- Implemented enemy formation recognition and response for AI units. YCC is working on the Colonel AI and Mike also started work on the general's minimax algorithm

Graphics Work

Sunday, April 16, 2006

As just a sample of the good things to come, here's some renders of the soldiers from either side. These should be representative of in-game graphics. Here's an Iraqi soldier:

And a US soldier:

Took a long time to make these, but I did have some meshes and textures ripped from the game Battlefield 2 to get me started

 - Johnny

Good Things to Come!

Monday, April 10, 2006

Johnny here. After a month of heads-down coding we're finally getting some cool results. Our first demo will go online this week along with some new screenshots. At this point we have captains and grunts moving and coordinating formation. Stay tuned, frequent updates from here on out!

3DSMax Rendering

Friday, March 03, 2006

Johnny here. I have my 3D Studio Max 8 environment all set up and ready to crank out some awesome combat models and I wanted to just post a few screens of how that process looks:

In the screenshot above I am UVW-mapping the 3d soldier model, i.e. using a 2-D bitmap to create the "skin" of the 3-D model. The 2-D mesh on the right maps to the 3-D wireframe on the left.

In the second screenshot, I have made the skinned soldier lie in prone position using a skeleton to simulate human-like joint bending. This is actually a six-frame firing animation, I was a bit lazy and didn't bother rendering it for the site (come back next week) I only have to animate the few bones of the skeleton to make the entire soldier model appear to walk, run, jump, fire, die, etc.

Last note, there is a sweeeeeet WYSIWYG Ogre3D plugin for 3DSMax called oFusion, I haven't got a chance yet to thoroughly test it out but it looks like its going to make my life much easier this semester. If you are interested in Ogre def check it out BOYEEEEEEEEEEEE! (flava flav in the howwwwwwwzzz!)

Website Online

This website went online Friday, March 3rd at approx 0300. Lots more work to do, however!

First CS192-2 Demo

Friday, February 24, 2006

Here are two screenshots from our first demo shown in CS192 class. These screens show a height-map terrain engine that Andy and Yee Ching built running in Ogre3d. 100 FPS, wow!