Team ThinkTank

Specifications

Ad Hoc networking game. Similar to the Atari Combat! Players control their tank and shoot enemy

tanks. Each player gets a point per tank

destroyed.

Specifications

Tanks can move around the map. All players will be on the same map. The map will be in the form of a top down

view. The edges of the map will be treated like

walls.

Requirements

Transmissions will be encrypted. Communication between users will be

synchronized. Built on top of the M2MI architecture. Game will be fault tolerant to people

leaving and entering.

Limitations

Limited number of users. Can only join one game at a time. Cheating control is limited. Synchronization prevents the game from

updating events in real-time.

Optional Ideas

Different game modes. Multiple games on the same network.

Papers for Selection

A Counter-Based Reliable Broadcast Protocol by Chang and Hwang

A Distributed Architecture for Multiplayer Interactive Applications on the Internet by Diot and Gauthier

A Reliable Transfer Protocol for Ad-Hoc Networks by Sundaresan, Anantharaman, Hsieh and Sivakumar

Counter-Based Reliable Protocol Guarantees two properties:

1. All receivers in group receive broadcast message.

2. Each of the receivers order the messages in the same sequence.

Counter-Based Reliable Protocol Paper details how messages work in “normal”

circumstances. Abnormal circumstances (nodes leaving,

joining), left out in paper. We will improve upon their ideas to make it work with this occurring.

Basis is nodes arranged in a ring, token passed around via broadcast message. Token contains ordered message descriptors from each node.

Multiplayer Interactive Apps

Describes implementation of maze game, similar to Combat!

Gives some measurements regarding broadcast delays.

We will measure our broadcast delays and compare.

Multiplayer Interactive Apps

Our broadcast will be based on Model-View-Controller architecture

Time interval between Controller sending a tank movement/shoot message, to when View receives that all parties have heard message.

A Reliable Transfer Protocol

Describes a proposed transfer protocol for Ad-Hoc Networks (ATP).

ATP has many similarities to TCP. The goal of ATP is to provide similar

services to the ones provided by TCP:Congestion Control and Reliability.

A Reliable Transfer Protocol

TCP uses sender and receiver windows.ATP uses rate based transmissions.

Reliability with ATP is highly dependent on the receiver feedback and the selective use of ACKs.

Measurement Description

Measure delay between controls to move tank, and reliable broadcast layer acknowledging all nodes have received broadcast.

Test with distributed as well as same machine hosted game sessions, with varying numbers of players

Integration Plans

Implement interfaces for various components within architecture, then implement interfaces with minimal functionality

Fill in functionality for interfaces with “real code” later

Test Studies

Front end tank simulation integrated in single player mode with no communications

Reliable broadcast/encryption layer implemented with simple counter application (each application simply broadcasts increasing numbers to ensure reliable reception)

Risk Analysis

Big risk is the reliable broadcast layerMitigate by starting that among first to be

implementedDesign in such a way such that

implementations may easily be swapped out

Version Control

Use CVS version controlEverybody can update same file

simultaneouslyEverybody has their own sandbox to work in In RCS, only one person can have file

checked out at a time.

Tentative Schedule

Interface Placeholders: Jan 7th

GUI: Jan 14th

Reliability/Security/Encryption: Jan 21st

Reliability/Synchronization: Jan 28-Feb 4th

Test/Debug: Feb 11th

Options, etc. Feb 18th