1 / 19

Team ThinkTank

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.

patch
Download Presentation

Team ThinkTank

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Team ThinkTank

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. Optional Ideas • Different game modes. • Multiple games on the same network.

  7. 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

  8. Counter-Based Reliable Protocol • Guarantees two properties: • All receivers in group receive broadcast message. • Each of the receivers order the messages in the same sequence.

  9. 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.

  10. 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.

  11. 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.

  12. 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.

  13. 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.

  14. 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

  15. Integration Plans • Implement interfaces for various components within architecture, then implement interfaces with minimal functionality • Fill in functionality for interfaces with “real code” later

  16. 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)

  17. 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

  18. 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.

  19. 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

More Related