06/07 08 Game Programming Contest Manual

Document Status: Draft

Please note that this document is still very much a rough draft. As such, it is subject to change. Please plan accordingly.

Preface

Welcome to the 08 Game AI Programming Contest Framework. The roots of this project stretch all the way back to a pilgrimage to UIUC's Reflections/Projections conference, which hosts the infamous MechMania programming contest. After several years of competing at MechMania, I began to foster dreams of holding a similarly spirited event at NDSU. I'm very pleased to finally let these ambitions see the light of day.

This project is by now means a one person endeavor. As such I'd like to acknowledge those who helped me transition from theory to practice.

Meisha - the pivotal genius behind many a MechMania framework, for fabricating enough free time to field my earliest questions
PhilHassey - the Ludum Dare dynmo, for answered some of my architecture questions
Foresth - the antagonist, for spurning me with cons of his own & providing invaluable feedback
My friends - the circle of mad genius, for making giving up a non-option
My parents - the source of it all, for springing for that first programming class back in elementary school
My son - the next generation, for reminding me why I love this stuff
Steph - the supportive partner, for her endless love & encouragement

Overview

The objective is to score more points than your opponent before the match ends. Points are gained by collecting resources (ether) from the environment. The team with the highest remaining ether reserves at the end of the match wins. Game play is divided into two distinct phases: setup and primary.

Setup Phase

Personally, I've never been a huge fan of symmetric maps as, once you've seen half (or less) of the map, you've seen it all. On the other hand, asymmetrical maps run the risk of giving one team a geographic advantage. My solution tries to combine the advantages of both while adding something new to the strategy of the game.

All maps will initially start out as being symmetric. Before the primary phase of game play begins, each team will be given a portion of the map, along with a number of discretionary terrain tiles. Each team will then have an opportunity to place their discretionary tiles on their portion of the map. Any tiles that are not used by the end of the setup phase are discarded (thus, you don't have to use all the tiles if you don't want to).

The result will be maps that have a low probability of being completely symmetric, while avoiding any sort of unfair bias. It also gives teams a chance to explore AI concepts like base planning, defense layouts, choke points, etc.

Primary Phase

The primary phase involves the exploration of the map, acquisition of resources, as well as offensive and defensive maneuvers. The primary phase is turn based. The turn for a player is announced by the game server. The player may then make an action for any given unit. The server will process the result of the request, update the game state and return the appropriate results to the player. This single cycle of request-update-respond is referred to as a round. At the end of a round, the player may attempt to make a new action request, thus initiating a new round. This process repeats until either the total amount of time allotted for the player's turn has expired or the player preemptively ends their turn. Note that some actions take effect at the end of a round, while others only take effect at the end of a turn.

Event resolution

The following actions take place immediately at the end of a round:

  • spawning a unit
  • moving a unit
  • attack results (including damage and destruction)
  • reconfiguring a router
  • router cycle detection and destruction
The following actions take place at the end of a turn:
  • collecting ether

Units

There are 3 different types of units available:

  • tanks
  • routers
  • bases

Tanks

Tanks are the main stay of your forces. They are the only units capable of movement or attacks. Tanks are also responsible for spawning and reconfiguring routers. A tank can attempt to spawn a new router in the cell that it currently occupies, provided that the cell does not already have a router and the player has enough resources to afford the router. To reconfigure a given router, a tank must enter the router's tile & issue a reconfiguration command. If the player has sufficient resources, the router's port configuration will be updated. Note that a tank cannot reconfigure an opponent's routers.

movement & combat

A tank can only perform a finite number of actions per turn. Moving a tank reduces the number of attacks it can make. Conversely, attacking with a tank reduces the distance it can move. The exact relation between moving and attacking is specified in the formula below. To avoid confusion, the server will provide the exact number of remaining movement points & attack points whenever a tank performs an action.

Moving horizontally or vertically one cell costs a single movement point. Moving diagonally costs (2^0.5) movement points. A tank can attempt to make as many moves as its movement points allow. Tanks can move into an adjacent traversable tile that is not already occupied by a tank or a base with the following exception: tanks cannot 'squeeze' through diagonal gaps between untraversable tiles (see diagram below).

Tanks can occupy the same tile as a router (even if it's an opponent's router). Requesting an action point that results in a failure (i.e. moving into a rock) does not use up any action points, but still counts against a player's total allotted time per turn.

A tank performs an attack by indicating a target square. Attacks are line of sight (LOS) based; obstacles in between the attacking tank and the target can block the attack (and receive) the attack. The exact code for determining the LOS path across the map is provided in (fill_in_blank). Note that unlike tank movement, it is possible to 'squeeze' shots through diagonal gaps between obstacles, at least under certain circumstances (i.e. shooting along an exact 45 degree angle). If an attack is blocked by an intermediate obstacle, it is blocked completely - there is no partial damage. When an attack takes occurs, it affects only a single tile - there is no area of effect damage. Finally, note that everything on a tile that gets struck takes full damage.

Routers

Routers are deployed by tanks to divert ether flows to the home base. Each routers has 4 ports (north, south, east, west) each of which can be set to one of 2 values (receive, send). The initial configuration of a router is specified at deployment, but can be reconfigured later. It is not possible to reconfigure an opponent's routers. Routers can receive ether two ways: 1) the router is built directly over an active ether source, 2) the router receives a beam of ether from another router. Routers built on an active ether source will automatically receive ether from it. In order to receive a beam of ether from a given direction, a router must have the corresponding port set to receive. The flow present in a router at a given time is the sum of all its inbound ether. Any port set to send will direct ether out from the router in the corresponding direction. The amount of ether set in a given direction is equal to the total flow into the router divided by the total number of outbound ports. Routers report the current flow they are receiving each turn.

Bases

Each team starts with one or more base stations. Base stations serve two critical functions: spawning new tanks and collecting ether. In order to collect ether, every base has a built-in router. Base routers have all ports set to receive and cannot be reconfigured. Base stations are capable of spawning new tanks in any adjacent traversable tile, provide the tile is open (meaning a tank could move into it) and the player has sufficient resources. Destroying a base does not result in a loss of previously accumulated supplies.

Ether

Ether is the essential commodity of the game. Ether is required to spawn new tanks and routers as well as reconfiguring routers. The player with the largest ether reserve at the end of the match is the winner. Note that it is possible to have completely eliminated your opponent's forces and still lose the match! While achieving combat superiority can lead to victory, it can just as easily lead to defeat! Ether originates from ether sources scattered about the world. Each ether source has two associated statistics: size and flow rate. Size refers to the total remaining amount of ether that can be harvested from the source. Flow rate refers to the amount of ether that can be harvested per turn.

Detecting Ether

Tanks can detect both the size and flow rate of ether sources. In addition, tanks can also detect the outbound ether flows of routers. Both the direction and approximate quantity of ether (rounded up and capped at a maximum of 255) can be sensed.

Harvesting Ether

To harvest ether from a source tile, you must first deploy a router on its tile. The router will automatically begin harvesting ether from the source based on its flow rate. In order to receive credit for ether, it needs to be routed to a base station. Note: ether that is not routed to a base station is simply lost!

Routing ether to a base station is relatively straightforward. Ether is beamed along horizontal and vertical paths from one router to another. Based on the port configuration of a router, beams of ether may be split or merged. An entire connected collection of ether sources and routers is referred to as an ether network. It is critical that ether flows through a network in an acyclic fashion. Introducing a directed cycle into a network results in phase harmonic feedback that overloads all affected routers. This results in the immediate explosion of all routers in the directed cycle!

One final note regarding ether harvesting: while it is not possible to reconfigure an opponent's routers, it is possible to redirect their flow.

Terrain

There are three types of terrain: open, water and rock. These different terrain tiles are differentiated by two characteristics: traversablity and conductivity. Traversablity indicates that a tile can be moved upon. Only open terrain is traversable. Conductivity indicates whether or not a tile blocks ether flows and attacks. Both open tiles and water tiles are conductive. Note that it is not possible to 'squeeze' tanks through diagonal gaps in the terrain, but it is possible to 'squeeze' attacks through. Since ether can only travel in vertical and horizontal lines, it obviously cannot be squeezed through diagonal gaps.

API

General Comments

All commands and most responses are passed as ASCII text. The reasoning behind this decision is to aid debugging - most anything pulled off the TCP buffer can get dumped directly as output & be understood by a human. It also helps server side (and if done correctly client side) error checking somewhat easier. Obviously, this also adds a couple layers of indirection for things like converting numbers. Hopefully since this contest is turn based & people oriented this design choice will prove to have more benefits than draw backs.

Conventions

In the documentation API commands appear in Courier New, with arguments indicated by italics.
Content Revised: 01/07/2008
Layout Revised: 10/16/2006