From ae84ad1281ba208485e3873d9c29c40a0c22f84b Mon Sep 17 00:00:00 2001 From: Davide Polonio Date: Wed, 20 Jun 2018 14:44:14 +0200 Subject: [PATCH] Fix following prof. suggestions --- report/res/img/{gamebank.jpg => photogb.jpg} | Bin report/res/sections/00-Title.tex | 10 ++-- report/res/sections/01-Abstract.tex | 5 +- report/res/sections/02-Introduction.tex | 17 +++--- report/res/sections/03-RelatedWorks.tex | 6 +- report/res/sections/04-GameBank.tex | 55 ++++++++++--------- report/res/sections/50-Metrics.tex | 27 ++++----- 7 files changed, 62 insertions(+), 58 deletions(-) rename report/res/img/{gamebank.jpg => photogb.jpg} (100%) diff --git a/report/res/img/gamebank.jpg b/report/res/img/photogb.jpg similarity index 100% rename from report/res/img/gamebank.jpg rename to report/res/img/photogb.jpg diff --git a/report/res/sections/00-Title.tex b/report/res/sections/00-Title.tex index 3df016e..df533ec 100644 --- a/report/res/sections/00-Title.tex +++ b/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\\ davide.polonio@studenti.unipd.it} \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\\ eduard.bicego@studenti.unipd.it}} % make the title area diff --git a/report/res/sections/01-Abstract.tex b/report/res/sections/01-Abstract.tex index aa0f8d3..b2609dc 100644 --- a/report/res/sections/01-Abstract.tex +++ b/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 diff --git a/report/res/sections/02-Introduction.tex b/report/res/sections/02-Introduction.tex index f6c8e83..840495e 100644 --- a/report/res/sections/02-Introduction.tex +++ b/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 diff --git a/report/res/sections/03-RelatedWorks.tex b/report/res/sections/03-RelatedWorks.tex index 317358a..6e3caec 100644 --- a/report/res/sections/03-RelatedWorks.tex +++ b/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 diff --git a/report/res/sections/04-GameBank.tex b/report/res/sections/04-GameBank.tex index 2ca0a44..7cfb3d6 100644 --- a/report/res/sections/04-GameBank.tex +++ b/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 diff --git a/report/res/sections/50-Metrics.tex b/report/res/sections/50-Metrics.tex index d7e70b5..57b573b 100644 --- a/report/res/sections/50-Metrics.tex +++ b/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}