Robot Arena, an AI Video Game

Written by Luis Cruz on Thursday, 18 August 2011. Posted in Academic Portfolio

Game AI | CS4731

Robot Arena, an AI Video Game

The ultimate goal for Robot Arena is to achieve a fine balance between AI components and equipment power, as well as between the difference equipment components themselves, so as to create a deep strategic game in which it is not immediately obvious what the optimal designs are.

Documents

Overview

The premise behind Robot Arena is that of a 1 vs. 1 fighting game, but unlike most such games, the player's role in Robot Arena is more strategic than tactical. The inspiration for Robot Arena was the Robot Wars T.V. series, which involved teams of amateur and professional "roboteers" who built real life robots that then fought against each other in televised matches. By bringing this type of gameplay to the digital medium, the hope is that more variation can be realized, by a larger number of people, and at a cheaper cost.

While games involving the player as the designer of his own battle avatar are plentiful, games where the player is also in charge of designing the AI of this battle avatar are less common. Most games place the battle directly under the player's control, and Robot Arena is unique in that it both avoids this temptation and also utilizes a sophisticated system by which customized AIs are not only designed by the player, but are integrated into the game play itself. This integration is achieved by a resource system, in which the player is charged for both AI components and equipment for the robot, leading to a design trade-off between complex AI and raw equipment power - "brains" vs. "brawn."

The ultimate goal for Robot Arena is to achieve a fine balance between AI components and equipment power, as well as between the difference equipment components themselves, so as to create a deep strategic game in which it is not immediately obvious what the optimal designs are. Indeed, the ideal is for there to be no globally optimal design, so that players have to tweak their robots specifically for their opponents, the map selections, and the game modes, leading to back-and-forth interactions of evolving complexity.

Scripting

We chose C# as our language due to the similarity to Java and C++. In Unity a C# script derives from MonoBehaviour, that means a script can be attached at authoring time to objects in the scene, but we can also have pure C# classes which can be instantiated at runtime. The MonoBehaviour scripts have some system methods which are very useful, such as Start, Awake and Update. Awake and Start are for initialization and and executed only once, while Update is executed at every tick.

Pathfinding

Given the continuous space of the game and the extra dimension of 3D, we decided to interface with an available API for pathfinding based in NavMesh. First we chose what object will be used to scan the environment, in our case we chose a Capsule because our Robots are based in a Capsule Collider, the capsule's radius was very important and it solved one of our previous issues of the Robot hitting/tripping with the wall's corners; so setting a capsules radius much larger than the Robot's fixed that problem. Then we choose the nodes size for the grid (NavMesh) and the number of them, this will give the final density of our grid (NavMesh).

We have now the NavMesh for navigation, but how to use it? The main function for the Robot to move around the terrain is the "MoveTo(Vector3 destination)", that is, the Controller script will provide a new destination to the Robot, and then MoveTo will make a call to create a new path from its current position to the destination, this search process is based on the A* algorithm, when the path is computed, the Robot will have a callback function that will receive an array of Vector3 positions, and here is the part that gets complicated, for performance and functionality issues you do not want to just move to the 1st point and create another path at every frame, but also is not possible to navigate all these points, otherwise you will move to the destination extremely fast. Other two functions will play an important role in solving this caching and selection of where to move to; then there is the FindPoint( ) function which is called at every 0.2 seconds, what this function does is to calculate how much the Robot has moved and select a new destination (WayPoint) from the cached path, then a state machine for the robot will be in charged in calling a MoveTowards() function to move to the selected waypoint.

Project by: Luis Cruz, Peng Zhou and Abhijeet Dani at GeorgiaTech

Social Bookmarks

About the Author

Luis Cruz

I am pursuing my MS in Computer Science at Georgia Institute of Technology (GaTech) with emphasis in Computer Graphics. I received by BS in Computer Science at GaTech in 2009 with specialization in Software Engineering and Computer Graphics.

Leave a comment

You are commenting as guest.