-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy path7-conclusions.tex
68 lines (45 loc) · 7.5 KB
/
7-conclusions.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
\chapter{Conclusions}
\label{chap:conclusions}
\begin{chapterintro}
In this chapter we will describe the conclusions extracted from this master thesis and detail the achieved goals. Also, the thinkings about future work will be detailed.
\end{chapterintro}
\cleardoublepage
\section{Conclusions}
By using Unity3D as the base to build the application we have been able to create a cross-platform mobile game without the effort requires to manage separate developments for each platform.
We have built an application from scratch following a typical mobile application development lifecycle defined the in the following four different phases: discovery, design, development, testing and deployment.~\cite{vithani2014mod}
Firstly, we covered the requirement analysis phase, determining the needs for our application, taking account of the possibly conflicting requirements of our client, analyzing, documenting, validating and managing software or system requirements.~\cite{kotonya1998requirements}
Secondly, we obtained the use cases, which covers all the functional requirements obtained in the first stage of our development.
Then, we design the game architecture, where we decided to use Unity3D as our game base engine. Moreover, four asset plugins placed in Unity3D (2D Toolkit, HOTween, iOs native and Android native) where included in the architecture in order to improve performance and make the development easier. Also we need to design physical pieces to let the gamer interact with the software application. This pieces have a unique base pads distribution to let our algorithm identify each piece. In order to detect what physical figure has been placed on the application recognition zones we build the instrument recognition algorithm.
Finally, we design three game modes to cover the use cases presented. In this document we have presented two of them.
Following this path we have been able to build a multi-platform mobile musical training software for children using the framework Unity3D engine.
This multi-platform game application have reached being a commercial product. Physical instrument pieces are sold in a renowned toy shop which have stores in more than 20 countries. Also, both iOs and Android applications have been are available in App Store and Google Play respectively.
\section{Achieved goals}
In this section we will detail our application's achieved goals checking if we have covered all the use cases presented in section \ref{subsec:gamemodes}
\begin{description}
\item[Play an instrument]
This goal has been achieved successfully. This use case is described in \ref{subsec:playinstrument}. The gamer is able to play five different instruments, one of each musical instrument family. In order to select the instrument to play with, the gamer is able to place the physical miniature, which represents the instrument family, on a recognition zone in the screen. Also, the gamer can watch a demo or change the melody to be played. We can see this achievement in figures \ref{fig:playing_xylo_start_screen}, \ref{fig:playing_piano_screen}, \ref{fig:playing_harp_screen}, \ref{fig:playing_panpipes_screen} and \ref{fig:playing_trombone_screen}
\item[Conduct the orchestra]
This goal has been achieved successfully. This use case is described in \ref{subsec:conductorchestra}. The gamer is able to conduct the orchestra that is playing the selected melody. The gamer can conduct the melody by enabling or disabling the instruments that are playing this melody. In order to select the instrument family whose instruments will be able to be enabled or disabled, the gamer is able to place the physical miniature, which represents the instrument family, on a recognition zone in the screen. Also, the gamer can watch stop or change the melody to be conducted. We can see this achievement in figures \ref{fig:conducting_all_stop_screen} and \ref{fig:conducting_some_screen}.
\item[Discover an instrument]
This goal has been achieved successfully. This use case is described in \ref{subsec:discoverinstrument}. The gamer is able to read information of instruments of the five different musical families. In order to select the instruments to discover, the gamer is able to place the physical miniature, which represents the instrument family, on a recognition zone in the screen. Also the gamer can reproduce the instrument selected sound. We can see this achievement in figures shown in section \ref{sec:discoveringscreens}
\item[Watch a melody play demo]
This goal has been achieved successfully. This use case is described in \ref{subsec:watchdemo}. Gamer is able to watch a demo of all available melodies in the \textit{Play instrument} game mode with each of the five instruments the gamer is able to play with.
\item[Select a melody]
This goal has been achieved successfully. This use case is described in \ref{subsec:selectmelody}. Gamer is able to select a melody within both \textit{Play instrument} and \textit{Conduct orchestra} game modes. We can see this achievement in figures \ref{fig:melodies_playing_screen} and \ref{fig:conducting_melodies_screen}.
\item[Select an instrument]
This goal has been achieved successfully. This use case is described in \ref{subsec:selectinstrument}. As we have said in the previous achievements, the gamer is able to choose an instrument within all game modes. In order to select the instrument, the gamer is able to place the physical miniature, which represents the instrument family, on a recognition zone in the screen.
\item[Build the instrument recognition algorithm]
This goal has been achieved successfully. This actor is described in \ref{tab:actores}. The instrument recognition algorithm detects what physical figure has been placed on the application recognition zones. This algorithm is used within the three game modes included in our application when the user place the physical miniature, which represents the instrument family, on a recognition zone in the screen.
\end{description}
\section{Future work}
There are several lines than can be followed to continue and extend features of this work.
In the following points we present some improvements that we can add to our application to continue the development.
\begin{itemize}
\item Add new instruments to the \textit{Play instrument game mode}. This new feature imply the development of new screens for each new instruments and the manage of new musical sounds.
\item Add new instrument families to the game. This feature imply the design of new pieces as long as modifying the recognition algorithm to support them. Also, the three game modes should be adapted to represent the new instrument families.
\item Update game project to Unity 5. This involves some work related with all Unity components. While many areas are upgraded automatically, there are certain parts of the project where we will need to manually adjust or refactor.
\item Reduce artifacts size. While Android and iOs markets allow us to upload huge sized applications, this suppose that user should only install the application when they are connected through WiFi. This would suppose a barrier to attract new gamers, so artifact size should be reduced from 300 MB, its actual size.
\item Add notifications management system in order to allow the client to interact with the gamer. This would let the client to promote their other applications and the new game features
\item Reduce resources requirements. This would permit lower resources devices to run the application and decrease the battery use.
\item Automate the deployment phase. This feature would allow us to decrease times when applying bug fixes to our application.
\end{itemize}