Game Play Design

Concept

Tank! is based on the tank parts of the game Combat for the Atari 2600. The look and play of the game should be similar. In addition to what Combat offered, Tank! also offers larger and different play fields (loaded from a text file), capture the flag style play (maybe in the future), and networked play that supports more than four players (hopefully at least 16).

Battle Field

The field can be larger than the viewable area and includes rectangluar obstacles, spawn areas, and goal areas. The obstacles are normally impassable, but the collision resolution can be exploited to go through them. Spawn and goal areas are owned by a team and used only by that team. The spawn areas define where players start the game and where they start again after being shot. Goal areas define where the opposing team's flag must be taken to score in CTF games.

The field is defined by a text file parsed by the program at run-time. It is specified on the Battle Field File Format page.

Scoring

So far, only a deathmatch type game has been implemented, although the design allows for a capture-the-flag type game to be added later.

Deathmatch

All players have their own personal score, and each team has a score. When a player kills a tank of the opposing team, their score increments by one and if it is positive, their team's score also increments by one. If a player kills a teammate who has a non-negative score, that player's score is decreased by four. If the teammate has a negative socre, no scores are changed.

Capture-The-Flag

All players have a personal score that works the same as a deathmatch type game except the scores have no effect on the team scores. Capturing the opposing team's flag is the only way to incement a team's score.

Game Simulation Loop

Todo:

This section and the following ones do not describe game play so they need to be relocated somewhere more appropriate.

Stuff happens. Tanks die.

• Process local input
• Process network input
• Update all locally held player data
• Clients: If changed, send current local player data to the server
• Server: Send data requiring an update to all clients
• Render frame
• Wait to maintain fixed framerate

Timing

Client

The game loop will start when the Common Game Time is a multiple of 16.

Server

The game loop will start when the Common Game Time plus 6ms is a multiple of 16, but all operations dealing with the update times of the players will use Common Game Time minus 6ms. Thus the server will update its game state 6ms after the clients have updated theirs, giving the server a chance to respond to the current state of the clients before the clients perform another update. This will allow the game state to be updated for all systems with a latency under 16ms (one frame) on a wired LAN.

---