crystal  committed d499026

Added sections (Board, BoardClient, BoardHost, Input) to the LaTeX file.

  • Participants
  • Parent commits 7026699
  • Branches master

Comments (0)

Files changed (1)

File bouncers_final_report.tex

-The inspiration for Bouncers came from a similar video game named Zurroball
+The inspiration for Bouncers came from a similar video game named Zurroball 
 \cite{zurroball} on the popular website Neopets.  The basic game concepts
 of preventing a ball from falling onto the ground were taken from here.  We 
 expanded on this by adding multiple balls at the same time and also 
+The Board class is a base class that provides the fields and methods that all 
+boards have in common.  Since all Boards look the same and have the same 
+things, the constructor loads up the graphics and creates a list of toys 
+(myToys).  Another thing Boards have in common is the paintComponent() method, 
+which paints the background and all the toys.  Board also defines the operations 
+that are essential for game play: newLevel(), plusPoints(), getPoints(), and 
+The two classes that extend from Board are BoardHost and BoardClient.  In the 
+case of a single-player game, only BoardHost is used; in the case of 
+multi-player game, both are used.  On the surface, BoardHost does all 
+computation for toy movement and sends the updated list of myToys to 
+BoardClient, while BoardClient receives myToys and simply displays them in the 
+aforementioned paintComponent() method.  This provides the desired effect of 
+replicating the screen on all virtual machines.  More implementation details 
+BoardHost extends the Board class.  The board code contains a startup process 
+to handle board start up (receiving remote references for allclientBoards), 
+waiting for allClientBoards to be initialized, and starting the boardManager.  
+boardManager is an overridden operation that controls all ball movement and
+collision, then repaints all balls to the screen.  An important thing to note
+is that after calculating the next positions of all balls, boardManager sends
+the list of myToys to allClientBoards, then waits to receive clientDone until
+it can proceed.  
+Another overridden operation is mymouseclick, which is triggered whenever 
+“this” board receives clicks, or when anyone in allclientBoards sends a click.
+Each click “punches” the ball up, so this part determines ball movement and 
+increases the game points.  If a ball has been clicked, mymouseclick sends a 
+message to allClientBoards’ plusPoints operation, telling them to update their 
+points.  Another important thing to note is that allClientBoards only has to 
+update points, and nothing else, because BoardHost will take care of the rest.
+Other overridden operations are gameOver, which stops the game when one balls 
+hits the bottom of the screen, and restartBoard, which starts up a new game 
+and resets all game values.  Similarly to the previous operations, these also 
+send messages to allClientBoards.  Also as before, allClientBoards need only 
+minimal information—for gameOver, allClientBoards flips their gameStatus bit; 
+for restartBoard, allClientBoards sets resets initial game values and sends a 
+message to BoardHost.  
+Another important thing to note is that whenever BoardHost needs to iterate 
+through myToys, it uses the Java synchronized statement to provide mutually 
+exclusive access to the myToys collection.  This ensures that other processes 
+do not change myToys while the iterator is going through the collection.  This 
+is important because, for example, we don’t want to get a toy’s position and 
+do collision detection based on that position, only to have that position be 
+changed somewhere else.
+BoardClient also extends the Board class.  This class is used if the game is 
+being played on multiple virtual machines.  In its startup process, the 
+receives a link to the hostBoard, sends a goahead to the hostBoard to notify 
+it that we are created, then starts up boardManager().  Unlike hostBoard’s 
+boardManager, this one merely has a loop that receives the list of myToys 
+(sent from hostBoard), sends back the clientDone capability to notify 
+hostBoard that we received myToys, then refreshes the screen to account for 
+the updated toys.  Similarly, the mymouseclick() operation, which gets called 
+when “this” board receives clicks, merely sends a message to boardHost’s 
+mymouseclick operation, which handles the calculations.  The restartBoard 
+operation is slightly different, because any Board can click “Start Game” to 
+start a new game.  If the player on a BoardClient starts a game, restartBoard 
+sends a message to boardHost’s  restartBoard operation, which takes care of 
+notifying all the other BoardClients.  
 Toy is the base class for clickable objects that appear on the screen, 
 providing the mutators and accessors for the class variables. In the
 \cite{ballcollisionsA}\cite{Chuan}.  All of these operations are used by the
 BoardHost class to simulate ball movements and collisions.
 \subsubsection{KeyInput / MouseInput}
+The MouseInput class takes a capability (mouseClick) for an operation in its 
+board to which the (x, y) coordinates are to be sent.  We use mousePressed 
+because it’s faster than mouseClicked, because mouseClicked coalesces the 
+clicks together.  The KeyInput class doesn’t need a capability, because we 
+only use the keyboard to handle exiting the game.
 Bouncers was an extremely fun and rewarding program to write.  We learned
 a lot about being able to read and understand every part of someone else's code
 (BnB).  This is an important lesson, as in the real world, you often face the
-task of mainting code that was not originally yours or having to integrate
+task of maintaining code that was not originally yours or having to integrate
 foreign code to your own.  We learned about Swing and had a real hands on 
 approach to creating a large application using JR.