Final Project
Distributed Tetris
Due dates may be found on the schedule.

The topic winning the vote in class on March 27th was a distributed tetris game, likely in teams with one team’s wins causing setbacks for the other team. Additional details will be placed here as the project is further defined.

1 Final project logistics

  1. In-class selection of a final project concept (March 27, 12:30pm)
  2. Staff turn that concept into two assignments:
    1. MP10 (released on April 22, due May 6) can be done by each student in isolation and is autograded.
    2. Project (released by May 6) is a distributed app and is graded as an in-person check-off
  3. In-class checkoff of MP9 shows how the project grading will work (April 24, 12:30pm)
  4. Final project is checked off in person (May 12, 1:30pm)

Both MP9 and Project check-off have some points for your code working properly and some for you interacting with other students’ code as a user to produce the user input that lets us test the distributed app.

2 Initial notes (subject to change)

Tetris is played on a 10-by-20 grid. Each cell of the grid has one of 8 states: empty, or the color/image of a piece of one of the seven tetrominos. Events occur when the player provides and action1 There are traditionally six actions: move left, move right, rotate left, rotate right, descend, drop. or on a predictable time scale (via some kind if ticking clock). The front-end could be as simple as the following:

This simple design would leave all game state to the server.

Then MP10 could be a standard tetris game. The project would add the interaction between boards and possibly some kind of validation of other server’s decisions to prevent cheating.

Is each server multiplayer?

Should there be:

  1. One board per server, which multiple users can view simultaneously?
  2. One board per server, and only one user can view it with subsequent users rejected?
  3. Multiple boards per sever, with each user seeing their own?

Option 1 is easy to code (no sessions to track), but means clock ticks should happen on the server side so that multiple users don’t make the clock tick faster. If clocks are on the server, the clients needs a way to know when a tick happened; maybe a WebSocket?

Options 2 and 3 presume some form of user session tracking. Perhaps a login client-to-server message to create a session ID, or having the server put such an ID into the HTML page it serves?