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 layer  Mitigate by starting that among first to be implemented  Design in such a way such that implementations may easily be swapped out

Version Control Use CVS version control  Everybody can update same file simultaneously  Everybody 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 7 th GUI: Jan 14 th Reliability/Security/Encryption: Jan 21 st Reliability/Synchronization: Jan 28-Feb 4 th Test/Debug: Feb 11 th Options, etc. Feb 18 th