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.

Problem 1 The Hungry Henry program must implement two communicating components:

a Hungry Henryserver program

a Hungry Henryclient program

To run a distributed Hungry Henry game, you distribute your client program to all
players that wish to participate. You also share your computer’s IP address
(in symbolic or numeric form) with the players. Once everyone is ready,

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—the server, the
client—keeps track of which knowledge/information and the messages that
the server and the clients exchange in order to share knowledge, in what
order these messages are sent, and when they are sent.

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.

In order to get help, you need to have answers to the following questions
when you show up for lab:

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?

Until you have made a reasonable attempt to answer these questions, the
TAs cannot and may not help you.