Problem Set 12
Purpose This problem set concerns the design of a universe program. You will need to take notes during lecture, and you should carefully read the notes for Lab 9 Distributed Programming. In addition, you may also wish to read Chapter~14 of Realm of Racket as well as the documentation for universe programming.
The actual goal of this course is to design a distributed multi-player version of Hungry Henry.
Deadline The deadline for this problem set is Wednesday 4 December 2013 midnight. If anyone requests an extension, we will grant the entire class an extension of 48 hours. Jarred X. requested an extension of the deadline so the permissible deadline is Friday 6 December midnight.
Grading As announced, the problem set is worth 150 base points, which is approximately 3x the average weight of a problem set. The base point allocation follows the usual pattern, ensuring (1) that it is executable and tested and (2) that the code is based on a recognizable design recipe (data definitions, well-formed signatures, properly formulated purpose statements, illustrative examples/tests, a structurally organized function definition).
In addition, you may earn 150 bonus points. To obtain these base points, the code must live up to the published style guide for this course. You may also wish to consult the Racket Style Guide though if the two are in conflict, the former overrides the latter.
Finally, do keep in mind that we eliminate the worst problem set grade before we compute the final grade. So in principle, you do not need to tackle this final set.
a Hungry Henry server program
a Hungry Henry client program
you apply the server’s main function to the number of players,
you inform players when the server is running, and
players then run the client’s main function on a name and your IP address.
Playing distributed Hungry Henry proceeds very much along the lines of the random-walk version from Problem Set 8 and Problem Set 9. Some number of cupcakes are distributed over a canvas. Each player is assigned a named avatar that is also visible on the canvas. The goal is to navigate the avatars across the canvas so that they get close enough to the cupcakes to eat them. The winner is the player whose avatar eats the most cupcakes.
A human player navigates his/her avatar by setting waypoints. To set a waypoint, a player clicks the mouse on the canvas. Naturally a player may set as many waypoints as desired, but the avatars must visit the waypoints in the order specified.
The Hungry Henry Server To make the game fair, the server manages the entire state of the game and enforces all rules uniformly. Its main function accepts a natural number n and then waits for n client programs to connect. Assume that the worlds have unique names (iworld-name), which are used for the player’s avatars. Once n players have signed up, the server sends all clients a message to start the game.
The Hungry Henry Client It follows that clients merely serve as devices to control avatars. To this end, the clients receive and display the following information every time the state changes: (1) the positions of the remaining cupcakes, the positions of the (still) participating avatars (players), and the positions of the waypoints for the client’s player. Conversely, the client sends a message to the server every time the player clicks on a position in the canvas.
Design The design of a universe program proceeds in three
stages. First, you need to decide which component—
Second, from these decisions you can infer (1) the data definition for these messages, (2) the state of the universe and the state of the participating worlds, and (3) the handler functions that you must use in the main functions and their signatures.
Third, the rest of the process follows the world design recipe and the function design recipes that you have practiced for the entire semester.
Schedule We would like you to bring the results of the first two steps to the labs on 25/26 November 2013. The TAs and the tutors will work with you (in pairs) to get these pieces correct before you go off and work on your wish lists.
Which information must reside in/is created in the server?
Which information must reside in/is created in the clients?
Which information must flow from a (player’s) client to the server?
Which information must flow from the server to a specific player? Which information may not flow from the server to a specific player if we want a fair game?
When does information flow from the server to the clients and vice versa?
What is a good data representation for the information (messages) that flows from clients to server?
What is a good data representation for the information (messages) that flow from the server to the client?
Which events should the server react to? Which events should the client(s) react to? (Other than message exchanges.)
Which parts of the server’s state of information changes over time and needs to be tracked in its state? What is a good data representation?
Which parts of each client’s state of information changes over time and how does it change? What is a good data representation?