CSP301: Assignment 1 on Multi-player Game

Background reading

1. Read Kernighan & Ritchie to learn the C language. Also, refer to the readings on the main course webpage on C Macros.
2. Read latex documentation (see main course webpage)
3. Read OpenGL documentation (see main course webpage)
4. Read GIT and Reviewboard documentation (see main course webpage)
5. Carefully read the man page of select() system call

The Game

Software Engineering

• Collaborative Programming: Install a GIT repository for you and your partner. Install Reviewboard and integrate it with the GIT repository. Share and develop your design document and the code using both these tools. Your repository and reviewboard installation should be accessible from the campus network, mention the URL of the repository and reviewboard in your design document. We will examine your repository and reviewboard history during evaluation.
• Design Document: You should write your design document in LaTeX. The design document should detail the high-level design of your intended implementation. It should also have the high-level implementation architecture: for example, what are the different components your implementation, what is their interface (API functions), etc. Identify the design decisions you made and why you made them. For each group of two students, we need three design documents:
  1. One design document for each student's implementation
  2. One common design document which details the common design decisions (e.g., state definition and communication)
  While designing your solution, consider the following things:
  • What is the state abstraction? What is the state that is communicated? What happens if a host goes down? What happens if a host is temporarily unavailable? (This will be a part of your common design document)
  • How do you represent the different entities in the game? For example, do you use a thread for each entity? Or do you use one process which updates the state of each entity?
  • How do you communicate over the network? For example, you could have many threads listening on different sockets, or you could choose to use the "select()" system call.
  • What features of the OpenGL library do you use to make your GUI fast and user-friendly?
  • Other interesting design decisions
• Implementation: Implement the project. Implement the tests. Write a report on whether some of your design decisions changed (from the design document). You must use a Makefile. Here are some targets you must implement:
  • 'make all': Compile your project
  • 'make run': Run your game
  • 'make test1', 'make test2', 'make test3', ...: Run the tests. You could use 'ssh' to run the tests requiring multiple computers.

Tests

• Test by playing a computer against another computer. Test in the following scenarios:
  1. Both players are on the same computer and use your implementation
  2. Both players are on different computers and use your implementation
  3. Both players are on the same computer and one player uses your implementation and the other player uses your partner's implementation
  4. Both players are on different computers and one player uses your implementation and the other player uses your partner's implementation
• Play with one ball, two balls, and three balls.
• Use tools like xdotool to automate input to your application
• Use network simulation tools to test your implementation on high-latency, low-bandwidth networks. Write automated tests for this setup
• Test your application when the network is dropping packets at X rate. Vary the value of X and report till what point does your application perform acceptably. Automate this test

Note:

1. To be done individually, except where group work is explicitly authorized (e.g., common design document)
2. The last date of submission of the design documents is Sep 19. The last date for the implementation is Oct 19.