Assignment 3 specification (DEADLINES: 24.11 + 29.12 + 30.01 + 16.2 + 17.2 + 27.2)

The 3rd assignment is a group work. You have to assemble groups of 3 or 4 persons and tell the lecturer at the lectures on 24.11.14 and inform the assistant by email the names & student numbers of each group member. In this assignment your group has to design and implement a networked game. The game does not have to be anything new, i.e. take an old (preferably simple) idea and make it to be your “own” (style). Or if you want to make a full “technology demo” with multiple new things without any full game implementation (a tech demo has to have something that can be played but not fully), select 5 instead of 4 advanced techniques.

Game has to support at least 4 players (-3 from basic points if game is only 2 player game). Select a game that you can implement in time. The game plan (rules and implementation) has to be documented.

Use client-server paradigm or, if you feel you're up to it, use peer- to-peer approach without any centralized server. A client can be also made to run the server (non-dedicated).

Feel free to select any protocol you desire (UDP/TCP/SCTP) or even combine them. What you implement on top of the selected protocol has to be still reliable.

Networking code must be made by you, preferrably in C but C++ is also accepted. Use any library you see fit for other tasks (e.g. http-page parsing, GUI, database access, etc., if you feel the need) but remember to document the usage of these. Also if you're using code/instructions from other sources, please document them and add references to code to avoid plagiarism charges. You are free to use the examples provided on this course, and the exercises/assignments you have done during the course in this project.

GUI WILL NOT BE SCORED. So keep the user interface simple. If you have the skills to make something advanced that does not take too much time you can create more fancy GUI but still, it will not produce more points.

Use some code repository (recommended, not required). The course SVN is at your use but some other (e.g., git) code repository can be selected if you prefer them. The course assistant has to be given at least reading access to the code repository if an external one is used.

You can also ask for help for your project from the lecturer/assistant personally or via email. See wiki main pages for reception hours.

Required basic features:

• Documentation (5 p), in PDF-format, must include:
  • Game description:
    • What kind of game you are trying to implement
    • What are the game rules and game mechanics
      • How the game is played (controls and movement/actions)
      • Views of different players (how actions are shown to others, how the players perceive the game world)
      • How the game will end
  • Game design
    • How to implement the game you described
    • The game features you are going to implement
  • Protocol
    • Diagrams (scored separately): Joining, game situations, error situations, ending of the game
    • Packets
  • Advanced techniques that are planned
    • The design of the technique in your game and a bit about the theory of the technique
    • How the technique is used in your game - what aspects it affects
  • Work schedule (here you can describe different features)
    • When each feature will be done
  • Division of work
    • Which persons were responsible of certain tasks (documentation, protocol design, server/client implementation, conducting testing, etc.)
  • Testing reports
    • From each tester + ideas how to fix the problems that did arise during testing (or actual fixes)
  • Additional libraries used
    • How/why/for what?
  • Situations that your implementation cannot handle
• Protocol design and implementation (6 p)
  • Design (3p)
  • Implementation (3p)

The game has to consist of server and client and it can be played over networked connections. The game has to have ending terms. (5p)

Your clients must be able to search for the server in some way (server announces, broadcast, multicast, IP-list on some http-server, …). (2p)

Chat has to be provided for the players. Both public and private chatting has to be implemented. (2p)

Latency and jitter measurements for clients on server. (2p)

Implementation testing and testing reports. Each game has to be tested by 3 non-group members. The testing reports are included in the final documentation. (2p)

You can select 4 different techniques you want to implement into your game. Each technique will give 4 points, 2 from design into your code (in documentation) and 2 from implementing the technique.

Different techniques and some reading material (feel free to introduce some others too!)

• Lag compensation (Lag compensation QIII unlagged Fight the lag
• Client side prediction (+ correction from server: Convergence) Algorithms and Networking for Computer Games chapters 9.3.1 + 9.3.2 Fight the lag On the suitability of dead reckoning schemes for games Networked Physics
• Partitioning of the game area to smaller pieces - based on possible views (e.g., BSP) Quake III Arena Game Structures BSP @ wikipedia - look the references!
• Fog of War [ Dealing with fog of war in a Real Time Strategy game environment Fog of war part 1 part2
• Real time game (your server has certain fixed update rate for game world - does not affect your rendering rates on client) - game is kept synchronized between all clients Fight the lag On the suitability of dead reckoning schemes for games
• Packet compression Algorithms and Networking for Computer Games chapter 9.2.1, ioquake3 sources, ]
• Area of Interest filtering Algorithms and Networking for Computer Games chapter 9.6
• Full Peer-to-Peer game without any authority (all clients negotiate the game state updates) Peer-to-peer support for massively multiplayer games Challenges in Peer-to-Peer Gaming
• Multi-server system where games are kept synchronized. When one of the servers crashes or is closed the others should keep the game running even with the clients that belonged to the crashed/closed server. Minimum amount of servers: 2.

* Negative effect

• Giving a presentation of the project at the end of the course: 1 p
  • A good presentation (discussion): 1 p
• Any additional feature that you want to promote: 1-2p (remember to document these!)

Late returns: (2,3,4 and 6 ) = - ½ points/day

Further info for each deadline return

1. Send a list of group members to course assistant by email at the end of lectures on 24.11.2014
2. Return the game idea design documents to the assistant via email (only one return/group)
   • Describe here at least:
     • what kind of game (type, mechanics, rules)
     • how the game is played (how to move, interact, is the game player vs. player(s) or co-operative, how the game will end) - illustrations are great way to demonstrate this
     • what networking protocols you are going to use and what kind of networking you plan to use (server & client / peer-to-peer)
     • List what basic features you are going to/plan to/not going to implement
     • advanced techniques - how they are utilized in your game and how they affect your game
     • group formation and division of labor
     • initial schedule (loose schedule)
3. Give details what repository you are using for the code/where the code resides and give at least read access for the assistant. Provide a list that shows what has been done - or mark the progression into your main project documentation (if not in the same repository, please send an updated version or a link to it).
4. Same as. 3rd return if repository changed + exact location where to find the document
5. Send slides to the assistant / put them into repository you're using and send only the exact location of the slides
6. Same as. 3rd return if repository changed + brief explanation what works and what does not (can be included in the updated document)

Each group has own group-accessible folder on the course SVN server, complete addresses are in following table.

If the SVN does not work for some of the members please report this ASAP to the assistant.