Commits

Anonymous committed b339628 Merge

Merge branch 'master' of ssh://bitbucket.org/eyan/bouncers

  • Participants
  • Parent commits 897ff1d, 5d3438b

Comments (0)

Files changed (4)

bouncers_final_report.tex

 
 \usepackage{hyperref}
 \usepackage{setspace}
-
+\usepackage[pdftex]{graphicx}
 % these \setlength etc. lines concern page layout, amount of paragraph
 % indentation etc.; beginners should ignore them (but include them)
 \setlength{\oddsidemargin}{0.0in}
 apply the parallel programming constructs learned throughout the quarter to
 a creative JR application with visuals from Java's Swing/AWT.  We created an
 interactive video game named Bouncers where multiple people (or one person)
-work together to prevent soccer balls from falling into a pit of fire.
+click on soccer balls to prevent them from falling into a pit of fire.
 \end{abstract}
 
 \section{Introduction}
 \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 
-introducing a multiplayer aspect, where players from different machines can
+introducing a multiplayer aspect, where players from different computers can
 work together toward the goal.  By using JR, we were able to easily 
 parallelize the basic game functionality such as moving balls and testing 
 for collisions.  Additionally, the multiplayer portion was very simple as JR 
 uses transparent communication between its virtual machines - meaning at the 
 programmer level, send and receive statements from remote operations have 
-the same syntax as from the same virtual machine.
+the same syntax as if they were for an operation that existed on the same 
+virtual machine.
 
 \section{Project Design}
 
-INSERT PICTURE HERE.  Describe overall design in laymen terms
-C
+\begin{figure}
+	\begin{center}
+		\includegraphics[viewport = 68 287 692 557, width=\textwidth]{fig1.pdf}
+	\end{center}
+	\caption{How BoardHost moves Ball objects}
+	\label{fig1}
+\end{figure}
+
+\begin{figure}
+	\begin{center}
+		\includegraphics[viewport = 26 274 730 493, width=\textwidth]{fig2a.pdf}
+	\end{center}
+	\caption{How the multi-VMs are connected}
+	\label{fig2a}
+\end{figure}
+
+\begin{figure}
+	\begin{center}
+		\includegraphics[viewport = 17 242 720 515, width=\textwidth]{fig2b.pdf}
+	\end{center}
+	\caption{How the multi-VMs communicate}
+	\label{fig2b}
+\end{figure}
+
+
+
 
 \section{Class Structure Overview}
 
 from disk, the Image variable is stored once in memory and only read from
 disc the first time a Ball object is created.
 
-\subsubsection{Ball::Physics}
+\subsubsection{Physics}
 All of the physics and movement mechanics of the game are defined within the 
 operations of the Ball class.  The physics and algorithms for 2D ball 
 collisions have been implemented many times before, and we drew a lot of our
 \subsubsection{KeyInput / MouseInput}
 C
 
-\section{Conclusion}
-E
+
 \subsection{Improvements}
-E
+Pete Doctor, the director of Pixar's UP, once said that "Pixar films don't get 
+finished, they just get released".  While we are extremely satisfied with the 
+current state of Bouncers, we would have loved the opportunity to spend more 
+time with the game and improve it.  Here are some things we would have loved 
+to implement if we had more time:
+
+\subsubsection{Game Mechanics}
+There are lots of cool things that we could add to make the "game" aspect more 
+fun.  For one, the Toy class was created to allow us to easily create different
+types of Toys.  Currently, there is only a single Ball class, but we would 
+have loved to expand this. Some interesting ideas tossed around were:
+\begin{itemize}
+\item "Bombs" that look similar to Balls but would end the game immediately 
+			if a player tried to punch it.
+\item Balls with different sizes and speed.
+\item Power-Ups that when punched, altered the game state (adding more points, 
+			slowing down the game, etc.).
+\end{itemize}
+\subsubsection{Multi-VM Speed Optimizations}
+
+The current host and client VM structure made the program very easy
+to convert from a single player game to a multi-player game (the main reason
+we chose this path).  However, the performance of the game dips dramatically 
+with this method.  The reason is that every time step, the host must send to
+each client a full copy of the \texttt{myToys} list.  The client receives the
+list and simply does a \texttt{repaint()} method call.  Here, the processing 
+power of the client is not used at all.  A possible solution  is to have the 
+host send \texttt{myToys} every T time steps to each client.  The times where 
+no data is sent, the clients will simulate their own physics.  This would cut
+down the number of synchronization steps by a linear factor of T.
+
+As the number of balls gets larger, the time to compute one time step for all
+of the balls becomes very long and the slowdown is noticable to the user.  An
+obvious fix would be to divide the work (collisions and movement) into chunks
+so that other PCs are able to compute and simply send back the result to the 
+host.
+
+
+\section{Conclusion}
+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
+foreign code to your own.  We learned about Swing and had a real hands on 
+approach to creating a large application using JR.
+
 
 
 The design of Bouncers was based off of the game BnB \cite{JRBook}.  We used

fig1.pdf

Binary file added.

fig2a.pdf

Binary file added.

fig2b.pdf

Binary file added.