Fix following prof. suggestions

report/res/sections/00-Title.tex

@@ -5,24 +5,24 @@
 % not capitalized unless they are the first or last word of the title.
 % Linebreaks \\ can be used within to get better formatting as desired.
 % Do not put math or special symbols in the title.
-\title{GameBank: a distributed pervasive game}
+\title{GameBank: a distributed pervasive application}
 
 
 % author names and affiliations
 % use a multiple column layout for up to three different
 % affiliations
 \author{\IEEEauthorblockN{Davide Polonio}
-\IEEEauthorblockA{Computer Science Master Degree\\Department of Mathematics\\
-University of Padua\\
+\IEEEauthorblockA{University of Padua\\
 Padua, Italy \\
+Computer Science Master Degree\\Department of Mathematics\\
 [email protected]}
 
 \and
 
 \IEEEauthorblockN{Eduard Bicego}
-\IEEEauthorblockA{Computer Science Master Degree\\Department of Mathematics\\
-University of Padua\\
+\IEEEauthorblockA{University of Padua\\
 Padua, Italy \\
+Computer Science Master Degree\\Department of Mathematics\\
 [email protected]}}
 
 % make the title area

report/res/sections/01-Abstract.tex

@@ -7,8 +7,9 @@
 the gameplay, making it more interactive and engaging. Furthermore, device 
 ubiquity in everyone's life enables gamers to interact between each other in 
 multiplayer matches more than ever. In this paper, we present GameBank, a 
-pervasive game that distribute the burden of managing money in board games to 
-the players, through a well defined and established wireless link: Bluetooth.
+pervasive application that distributes the burden of managing money in board 
+games to the players, through a well defined and established wireless link: 
+Bluetooth.
 \end{abstract}
 
 % keywords

report/res/sections/02-Introduction.tex

@@ -2,7 +2,8 @@ \section{Introduction}
 \label{introduction}
 % no \IEEEPARstart
 
-Playing games can be a social activity, especially when playing board ones. 
+Playing games are an appreciated social activity, especially when considering 
+board ones. 
 Sometimes, though, the engagement can be reduced by the burden of managing the 
 game itself by a master, a player that has to take in consideration the actions 
 of everyone and act accordingly to the game mechanics. Recently a new concept 
@@ -25,9 +26,9 @@ \section{Introduction}
 Most of the time, players are located in the same room when playing board 
 games. This particular scenario makes an already established technology in 
 the market, Bluetooth, an optimal solution to implement pervasive applications. 
-In our report, we will talk about GameBank, an example of pervasive game that, 
-thanks to this wireless link, allow players to distribute the role of a Bank in 
-monopoly-like games with a piconet.
+In our report, we will talk about GameBank, an example of pervasive application 
+that, thanks to this wireless link, allow players to distribute the role of a 
+Bank in monopoly-like games with a piconet.
 Bluetooth, a technology developed initially by Ericsson, Nokia, IBM, Toshiba, 
 Intel and many others~\cite{haartsen00}, has become today a widely used
 standard especially in PAN (Personal Area Network) communications. This
@@ -41,12 +42,12 @@ \section{Introduction}
 
 Finally, establishing the connection via Bluetooth
 allows other wireless link to be used for other purposes, thus enabling the
-user to perform other actions while playing our game, e.g. browsing the
-internet via WiFi.\\
+user to perform other actions while playing our game, e.g, browsing the
+internet via WiFi.
 
 This paper is organised as follows: Section~\ref{introduction} describes how 
-pervasive games and distribution of mastering duties can improve the overall 
-gameplay, while Section~\ref{related_works} provides related works. 
+pervasive games and the distribution of master duties can improve the 
+overall gameplay, while Section~\ref{related_works} provides related works. 
 Section~\ref{game_bank} describes how the application is designed and 
 implemented, listing the problems we faced while developing it. At the end, in 
 Section~\ref{results} we analyse some metric results about Bluetooth and in 

report/res/sections/03-RelatedWorks.tex

@@ -4,9 +4,9 @@ \section{Related works}
 Games are an instrument for entertainment and socialisation. As described 
 in~\cite{gee03}, a game in order to keep its user amused needs to:
 \begin{enumerate*}[label=\roman*)]
- \item have a learning curve not too steep
- \item continuously give information and hints
- \item remain challenging during the gameplay without being too much difficult
+ \item have a learning curve not too steep;
+ \item continuously give information and hints;
+ \item remain challenging during the gameplay without being too much difficult;
  \item engage the player as a ``producer'' and not only as a ``consumer''.
 \end{enumerate*}
 In this context, board games can result sometimes in long and mechanical 

report/res/sections/04-GameBank.tex

@@ -8,10 +8,9 @@ \section{GameBank}
 
 \subsection{How it works}
 
-GameBank, as already described in Section~\ref{introduction}, is an application 
-complementary to a board game. It helps players removing some burden related to 
-manage possible in-game transaction, distributing the task to the members and 
-eliminating the need of a game master.
+GameBank, is an application complementary to a board game. It helps players 
+to remove some burden related to manage possible in-game transaction, 
+distributing the task to the members and eliminating the need of a game master.
 
 Since the social nature of board games, the application is designed to work 
 in multiplayer-only mode. Indeed, because a single player match is a particular 
@@ -24,22 +23,22 @@ \subsection{How it works}
 device in order to recognise players in a match uses a Universally Unique 
 Identifier (UUID), so different players can have the same username.
 
-There are two ways to start a match: loading the game from a save and starting 
-a new one. In any case, the smartphone performing one of these actions becomes 
-the Bluetooth master, and it starts waiting for other players to join the 
-lobby. When a player joins, she has the possibility to ``poke'' the master, 
-that sees a toast message on her screen (this actions sends a \texttt{POKE} 
-event). Additionally, the player that join the match has to set herself as 
+There are two ways to start a match: loading the game from a saved one and 
+starting a new one. In any case, the smartphone performing one of these actions 
+becomes the Bluetooth master, and it waits for other players to join 
+the lobby. When a player joins, she has the possibility to ``poke'' the master, 
+that sees a toast message on her screen (this action sends a \texttt{POKE} 
+event). Additionally, the player that joins the match has to set herself as 
 ready: a match can start only if all the players in the lobby are ready. 
 The connections created is an ad-hoc one, but as a matter of fact the master 
-forwards the packets it receives to everyone after the match starts, simulating 
+forwards the packets received to everyone after the match starts, simulating 
 a P2P (Peer-to-Peer) networking. We saw this as an opportunity to simplify 
 transaction communications.
 When all the conditions to start the match are met, the host has the 
 possibility to start it, making every connected device to display the dashboard 
 activity.
 
-The dashboard activity is subdivided in two tabs: one for transfer money and 
+The dashboard activity is subdivided in two tabs: one to transfer money and 
 the other one to see the transaction log. In the first tab, users can send 
 money to each other or to themselves (impersonating the bank). In the second 
 tab, there is the transaction log, that is updated every time someone creates a 
@@ -57,15 +56,16 @@ \subsection{How it works}
     ~ 
     \begin{subfigure}
         \centering
-        \includegraphics[scale=0.056]{gamebank}
+        \includegraphics[scale=0.056]{photogb}
         \label{fig:gamebank}
     \end{subfigure}
+    \label{fig:matchmaking}
     \caption{Respectively a GameBank match and matchmaking}
 \end{figure}
 
 \subsection{Architecture}
 
-GameBank architecture is composed of two layers (as 
+The GameBank architecture is composed of two layers (as 
 explained in Figure~\ref{fig:gbArchitecture}): one for the 
 communications/networking and the other one dedicated to the game logic. 
 
@@ -98,14 +98,15 @@ \subsection{Architecture}
 The game layer simply takes the events coming from the network transmissions, 
 and it stores the data in a Realm database\footnote{\url{https://realm.io/}} 
 through the logic layer, that is based on events too. Finally, the views, that 
-are what the user sees and interact with, subscribe to events coming from logic 
-and Bluetooth parts, allowing them to be updated by the \texttt{onChange} 
+are what the user sees and interacts with, subscribe to events coming from 
+logic and Bluetooth parts, allowing them to be updated by the \texttt{onChange} 
 callbacks.
 
 \subsection{Game creation}
 
 In this part we are going to describe in the details the procedure we have 
-designed to connect the Bluetooth devices and to start a match.
+designed to connect the Bluetooth devices and to start a match (the result can 
+be seen in Figure~\hyperref[fig:matchmaking]{1}).
 
 When a user opens a match, in the network layer a Bluetooth socket is opened 
 and set up for incoming connections. When a client connects to the host, 
@@ -162,26 +163,26 @@ \subsection{Data transmission}
 \texttt{MEMBER\_CONNECTED} and \texttt{CURRENT\_STATE} events happen, that 
 means that other events can not be processed meanwhile.
 
-The way the data get sent changes when a user's device is a client or a 
-host: in the first case the client updates its logic and then it sends the 
-events to the host which will broadcast it to the other clients, instead in the 
-second case, the host updates its logic first and then it sends them via 
-a broadcast message. In this way there is no way for a client to check if the 
-event it sent was received successfully and it does not guarantee the same event 
-processing for every member, but it saves data transfer and it makes the 
-backend logic simpler.
+The way the data get sent changes depending on whether the user's device is a 
+client or a host: in the first case the client updates its logic and then it 
+sends the events to the host which will broadcast it to the other clients. 
+Instead in the second case, the host updates its logic first and then it sends 
+them via a broadcast message. In this way there is no possibility for a client 
+to check if the event was received successfully and it does not guarantee the 
+same event processing for every member, but it saves data transfer and it makes 
+the backend logic simpler.
 
 \subsection{Known issues}
 
 During the app development we have faced some issues that we were able to 
 partially solve.
 
-\subsubsection{Image dimensions}
+\subsubsection{Image size}
 
 As already said, images too large cause long transmission times with Bluetooth, 
 an since we transfer data  in the main thread, this results in the application 
 hanging while transferring it, providing bad usability. In order to partially 
-solve this problem, we have reduced images dimension, scaling them to a default 
+solve this problem, we have reduced images size, scaling them to a default 
 one, converting them to the JPEG format and reducing their overall quality. A 
 definitive solution would be using a thread different from the one running the 
 user interface, displaying to the user a loading message during Bluetooth 

report/res/sections/50-Metrics.tex

@@ -58,19 +58,6 @@ \subsection{Test settings}
 transmitted.
 
 \subsection{Data analysis}
-\begin{figure}[t]
- \centering
- \includegraphics[scale=0.7]{client_data_utilization}
- \caption{Graph illustrating the input/output for a client}
- \label{fig:res:cdu}
-\end{figure}
-
-\begin{figure}[t]
- \centering
- \includegraphics[scale=0.7]{host_data_utilization}
- \caption{Graph illustrating the input/output for a host}
- \label{fig:res:hdu}
-\end{figure}
 
 Analysing the graphs we obtained in Figure~\ref{fig:res:cdu} and 
 Figure~\ref{fig:res:hdu}, we discovered that it follows a particular growth 
@@ -91,3 +78,17 @@ \subsection{Data analysis}
 The only thing that surprised us was that Android is not able to support over 
 seven simultaneous Bluetooth connection. When we tried to connect eight devices 
 we incurred in an Android Bluetooth API crash.
+
+\begin{figure}[h]
+ \centering
+ \includegraphics[scale=0.7]{client_data_utilization}
+ \caption{Graph illustrating the input/output for a client}
+ \label{fig:res:cdu}
+\end{figure}
+
+\begin{figure}[h]
+ \centering
+ \includegraphics[scale=0.7]{host_data_utilization}
+ \caption{Graph illustrating the input/output for a host}
+ \label{fig:res:hdu}
+\end{figure}