CS680
Fall 2008
hw7 - Multiuser Pong 

hw7a: Due Monday, Dec. 1 , by midnight: #1, 2, 3

hw7b: Due Sunday,  Dec 7, by midnight: rest of parts

In this assignment you'll start from the supplied Pong3 project, and the hibernate_chat project. Recall that Pong3 has all GUI sources in package game.presentation, and all model sources in package game.model.  Although we could make it pure MVC, with a separate controller, we won't bother because that is not essential to proper layering (since it's impossible to layer controller over view in general anyway.) The basic architecture for this project has been covered in class.
  1. We now need domain classes PongMove and PongMatch that hold the needed persistent state for moves and matches. Make the PongMove include explicit "missed the ball" information. as well as the y-coordinate at the bounce-surface (bounce-surface is defined in Extrapolator of Pong3). We can use the older PongGame for the memory-only state. Draw a new class diagram for PongGUI, PongGame, PongMatch, PongMove, Ball, and Paddles. Note added 11/30: you can show additional classes if you need them to connect to PongMatch/PongMove, for example, the FutureTask classes.
  2. We need to be able to send and receive match-setup and move messages and store the state in tables pong_match and pong_move. Design a service layer and Hibernate DAO (PongService, PongDAO) for PongMoves and PongMatches by converting hibernate_chat and adding on two more domain classes for PongMove and PongMatch, with an association connecting PongMatch with its PongMoves, corresponding to a foreign key in pong_move.  This is a bidirectional N-1 association. For a working example of this kind of association, see the Conference and TechSession domain objects in techconf2 (zip) from CS636. Don't loop over reads in a transaction: that makes an overly-long transaction. Just let a read transaction method return null if nothing of interest is there yet. Let the service-layer caller (not the service layer itself) loop over read requests if needed, possibly with delays between attempts.
  3. For testing of the DB service, write a simple Java program CommTest.java that puts the protocol through its paces, that is, sends the initial setup message as end A, gets it back as B, joins the match (by updating the pong_match row) as B, gets the joined-up match as A, starts the match as A, sends in a move as B, and get the move as A.  All this is done in one single-threaded program that uses the service layer API. "ant commTest" should run this program. Leave "ant sysTest" there for the Message test.

    -------------------------------------hw7b--------------------------------------
  1. The model needs some minor teminology adjustments. The user paddle (locally controlled paddle) can be on either side now and there is no computer paddle, so rename the paddles to remove this assumption. Similarly examine other names for obsoleteness. 
  2. We need to execute all the DB service calls in a separate thread from the Swing UI thread. Note that we did the Pong3 extrapolation in another thread using futures, and there is a simple example on futures linked on the class web page under Oct. 7. Design Callable<T> classes for T objects that need to be gotten from the DB and Callable<Status> classes (with constructors having type T arguments) for things of type T we need to send to the DB, or design some other way if you want. As with the extrapolation, we can resolve the futures in the tick handler with complete thread safety because the tick handler (of javax.swing.Timer) runs in the UI thread. Make sure there's only one DB thread running at a time. In memo.txt, explain your design for threading.
  3. The UI needs a little work. Start the ball when the second player is attached, possibly after a delay of a few seconds if that helps with testing. Show a message like "waiting for second player" when the first player has no second player. 
  4. In memo.txt, explain any changes to the model API you needed for this project. Report on any delays you can observe due to the database accesses. 
  5. Implement multiuser Pong. Just run one game and exit. Disallow window-resizing, but keep the window size data in the database. The remotely-controlled paddle can just jump to the final position determined by the other user. Slow the ball down if necessary to get the game to work. Look at "and sysTest2" in hibernate_chat to see how to run two instances of Pong together, one a little after the first, for the "ant run" of your final build.xml. Make sure "ant tests" still works to run the unit tests from Pong3.
Deliverables

We will collect your work electronically from a hw7 subdirectory of your cs680 directory. Do not modify the permissions for that directory.

hw7a: in this version, the old Pong classes are just the Pong3 ones, waiting for enhancements in hw7b.

hw7b: Now the old Pong classes work the new way to implement multiuser Pong. Make sure "ant run" runs two instances of Pong concurrently, one a little later that the other, and terminates within 2 minutes with no user input (the ball starts, but noone returns it, so the program exits).

Things we would like to add, but ran out of time: think about how to do them.