Linköping University | Department of Computer and Information Science
Master’s thesis, 30 ECTS | Computer Science
2020 | LIU-IDA/LITH-EX-A--20/077--SE
Analysis of a Distributed User
In-terface Framework
–
through development of a map based multiplayer game
Analys av ett ramverk för distibuerade användargränsnitt
-genom utveckling av ett kartbaserat multiplayer-spel
Ermin Pitarevic
Supervisor : Anders Fröberg Examiner : Erik Berglund
Upphovsrätt
Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publicer-ingsdatum under förutsättning att inga extraordinära omständigheter uppstår.
Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka ko-pior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervis-ning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säker-heten och tillgängligsäker-heten finns lösningar av teknisk och administrativ art.
Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsman-nens litterära eller konstnärliga anseende eller egenart.
För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.
Copyright
The publishers will keep this document online on the Internet - or its possible replacement - for a period of 25 years starting from the date of publication barring exceptional circumstances.
The online availability of the document implies permanent permission for anyone to read, to down-load, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility.
According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement.
For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.
Abstract
A variety of user interfaces have provided different solutions and possibilities, highlight-ing the importance of them in our interaction with computers. As our interaction with computers have been reaching different levels, the importance of the designing and devel-opment of user interfaces have become more obvious.
The aim is to focus on the relatively new field within Human Computer Interaction, Distributed User Interfaces. Moreover, the work should focus on the provided Distributed User Interface framework, Marve, and further analyze and evaluate it through the imple-mentation of a larger web application, a map based multiplayer game. Given the result, shortcomings and related requirements were introduced, which are not only applicable for Marve, but for web focused Distributed User Interface frameworks in general.
The work has brought up the importance of understanding the contribution of a framework as Marve, and how this can be used to facilitate the development of a web application. Ad-ditionally, the work demonstrates where Marve contributes to facilitated development of the map based multiplayer game. Furthermore, it highlights important issues, which have to be managed by Marve in order to being a complete Distributed User Interface frame-work for web development. Several shortcomings have been brought up and discussed, setting up additional requirements for further development and improvements.
Acknowledgments
All the years here at Linköping University have been tough but memorable, an experienced journey to say the least. There have been a lot of challenges, which have been putting me to the test. A great experience which has helped me develop a lot!
I would like to thank Erik Berglund and Anders Fröberg for patiently helping me throughout this work with constant availability. Great guidance, useful advices and encouraging words that I appreciate.
Another thank you to others that have been part of this journey. And last but definitely not least, a special thank you to the ones who have supported me and continuously do. You know who you are.
Contents
Abstract iii
Acknowledgments iv
Contents v
List of Figures vii
List of Tables viii
1 Introduction 1 1.1 Motivation . . . 1 1.2 Aim . . . 3 1.3 Research questions . . . 3 1.4 Delimitations . . . 3 2 Theory 4 2.1 Human Computer Interaction . . . 4
2.2 Intelligent User Interfaces . . . 5
2.3 Human Computer Interaction and Usability . . . 5
2.4 Distributed User Interfaces . . . 6
2.5 Challenges with Distributed User Interfaces . . . 6
2.6 The Marve Framework . . . 7
2.7 Related Work . . . 9
3 Method 10 3.1 Description of the Game . . . 10
3.2 Technical Description of the Platform . . . 11
3.3 OpenStreetMap . . . 11
3.4 Leaflet . . . 11
3.5 Turf.js . . . 12
3.6 Flask . . . 12
3.7 The Marve Framework and its Contribution . . . 13
3.8 Development of the Game . . . 16
5.2 Method . . . 33 5.3 Source Criticism . . . 35 5.4 The work in a wider context . . . 35
6 Conclusion 36
6.1 Future Work . . . 37
List of Figures
3.1 Initial sketch of the layout/structure of the game. . . 11 3.2 Simple device and room handling example, where device 1 and 2 requested to join
and joined room 1, while device 3 did the same for room 2. . . 14 3.3 The reference to a node element is set for the receiving device, and the distributed
object will be placed there. . . 16 3.4 The two classes included for the database. . . 21 4.1 The game lobby, with options to enter room number and the team to join. . . 22 4.2 Request to start the game was made by one of the leaders, and both
team-leaders have to confirm the start. . . 23 4.3 The game panel in different phases, with relevant information and actions to be
made. . . 23 4.4 The action section, with actions for a soldier to the left and healer to the right. . . . 24 4.5 The path calculated to a destination for a selected character. . . 24 4.6 The path time difference between two different surfaces, asphalt and grass. . . 25 4.7 The shooting action, the sight line is shown and then the bullet is fired. . . 25
List of Tables
2.1 Component presentation . . . 8 4.1 Requirements for the Marve Framework based on the presented shortcomings . . 28
1
Introduction
In the last decades, our interaction with computers has fundamentally changed. With the technology continuously evolving, we now have access to powerful machines with enor-mous functionalities and capabilities. [16, 5] The shift from having big computers in secure rooms used by professionals, to smaller personal computers in homes and offices, was the factor that created the need for the Human Computer Interaction field [16]. With a vari-ety of platforms, the restriction of performing tasks on a specific device is no longer a concern. Likewise, as the Web is rapidly evolving, many challenges and issues are remaining, while new ones are arriving. This has an impact on the development and designing of the User Interfaces, related systems and applications, while also affecting the functionality of the Web. [16, 5]
Designing the systems is very dependent on the Human Computer Interaction field, which is the area that establishes the actual communication platform between the users and the computers. The challenge that arises is to achieve the perfect interaction, which in turn creates the ideal coherence. Additionally, the focus also lies on how this can be applicable in today’s digital world. [5]
1.1
Motivation
The development within the Human Computer Interaction field involves the understanding of the user needs, in order to contribute innovatively and meaningfully. More intelligent, interactive, and beneficial designs have become applicable, providing many new challenges
1.1. Motivation
Initially, this modern interaction between computers and users was done using a Command Line Interface (CLI), which is still popular today. Another well-known User Interface which got introduced after the CLI is the Graphical User Interface (GUI), which have been used for a long time, and still is. The shift from the CLI to the GUI opened up for many possibilities and emphasized the importance and relevance of the User Interfaces. Several other User Interfaces were introduced with different contribution to the field, with more focus on the social and natural interaction, as well as the body movement. However, none of them really reached the groundbreaking level as the GUI.
Ubiquitous computing, with several devices being connected and interacting, changes the availability of devices, and eliminates the direct dependency to a specific device. This requires innovative and different interface models which could facilitate the development of dynamic applications, as well as support these new capabilities and modifications.
Having devices working together, several separate GUIs are required to support every new configuration, mainly due to the complex interaction structures and mechanisms. This is not always optimal as programmers have to put significant time and effort to develop these, which can result in big costs for software projects. [2]
A comparatively new field within Human Computer Interface is Distributed User Inter-faces (DUIs). It introduces a new way of working with interactive systems, and removes the strict dependency between single end user, computing platform and environment. It sup-ports a new way of developing distributed applications, with the possibility of re-organizing User Interface components at run-time. A DUI can in that way share the User Interface components dynamically among connected devices, creating a functional User Interface. Moreover, DUIs have been proposed as a solution to the newly demanding issues within the User Interface interaction. This area establishes an effective way of performing tasks in various contexts, either by facilitating the implementation or by introducing new possibilities and options.
There are challenges which have to be considered designing DUIs, related applications and frameworks. Developing these and achieving a working design for multiple dimensions are complex. This is partly due to the combination of dynamic applications and the User Interface development, but also as a new field will require a lot of work in general. As DUIs open up for new interactions and a different run-time infrastructure, this has to be properly considered to achieve a manageable and impeccable distribution.
Marve is a proposed framework which is of interest in this thesis. It provides function-ality for working with distributed applications over the web, such as high-level support for transferring User Interface components between device at run-time, as well as managing connected devices and available sessions. It is of interest to test and analyze the capabilities of such a framework, in order to see how it could contribute, especially in collaborative situa-tions such as in a strategical multiplayer game. Moreover, it is interesting to understand how this framework could potentially facilitate the development of an larger web application.
1.2. Aim
1.2
Aim
It has been shown that Human Computer Interaction are becoming more relevant, with more fields contributing to the area. Distributed User Interfaces provide a new solution which could be applicable in many situations and could potentially facilitate the development of distributed applications. It represents an essential opportunity working with User Interface designs, especially with the ability to support reorganization of User Interface components during run-time. This could lead to a new way of designing and implementing web applica-tions.
This work should first investigate this area and the provided framework, Marve, in order to understand the functionality and objective. With this knowledge, a web-based multiplayer game will be implemented in order to test, analyze and evaluate the framework and its con-tribution. The aim is to implement a larger web application, which covers more challenging cases where possible shortcomings of the framework can be discovered. Moreover, the aim is to also understand how Marve could facilitate web-based multiplayer game development in different scenarios. Any shortcomings will be documented for a setup of requirements which are either necessary or advantageous for the framework, and in general for a DUI framework. Lastly, a discussion and conclusion based on the applied method and the given results should be presented.
1.3
Research questions
The following research questions will be processed in this thesis:
1. What is required from a distributed User Interface framework to support web-based multiplayer game development?
2. To what extent can the Marve framework facilitate the web-based multiplayer game development?
1.4
Delimitations
As the field of Distribution User Interfaces is still relatively new, there might be parts not being considered as part of the evaluation and analysis in this work.
The implementation was done using OpenStreet Map together with Leaflet, which does not provide the freedom and control of the implemented components. Additionally, it is not initially made for games but rather for map related applications, such as a route planner. This leads to a challenging task when developing the map-based multiplayer game in this case, and not give a fully elaborated and reflective answer.
Due to the time-span for this work, some parts or details might not be completely cov-ered and elaborated, or not included at all.
2
Theory
This chapter begins by presenting a more detailed description of some theoretical and rele-vant areas, in order to give the reader a better understanding of the method and the topic in general, as well as the evolution of it. Related works are then presented directly after.
2.1
Human Computer Interaction
The area of Human Computer Interaction (HCI) focuses on the relationship between the hu-man and the machine, more specifically the interaction between these two. This interaction is the process of the two-way information exchange, where the input of one part is the output of the other. There are multiple ways for a user to communicate with the computer, such as different interfaces and virtual reality. [6] The general process is that the user is interacting with the integrated interface, leading to the processing of information by the computer which later performs operations and presents the result through the interface.
Methods for communication have been, and still are, increasing as new technology is contin-uously developed and computers are capable of doing computations in milliseconds. [5] As this development continues, the interaction with our devices are becoming more common and HCI is becoming even more relevant.
At the very beginning, programmers interacted with computers using switches and reading light-emitting diodes. Together with the technological evolution this interaction was later done through Command Line Interfaces (CLIs), which is still used as of today. Later, and during the last couple of decades, the focus has been on Graphical User Interfaces (GUIs), where the interaction is completed by typing, clicking, and pointing. At early stages of the GUIs, the interaction was performed using simpler panels and displays, moving to the more evolved abilities. These provide the users a clear view, understandable controls of commands and actions, allowing users to feel responsible for the interaction with the computer. [22, 23, 24]
2.2. Intelligent User Interfaces
The Perceptual User Interfaces (PUIs), were introduced in the field as a contribution to the lack of social and natural interaction, similar to the interactions made between humans. The goal was to support the naturally, easy to use and understandable interactions, such as head gestures, hand gestures and speech. [22, 23] Appearances of Natural User Interfaces (NUIs) have also been present, with devices corresponding to body movement, such as Kinect. [24] HCI development and the frameworks involved rely on the evaluations of the users’ needs of the relevant HCI parts of the system. This facilitates the understanding of how the in-teraction can ensure a specific and properly developed interface, in order to improve the understandability and effectiveness of the interactions. [5, 15, 24]
The growing development of HCI in the different technological areas allow more intelli-gent and interactive designs to become applicable with many benefits, resulting in new challenges for the designers and developers. [5]
2.2
Intelligent User Interfaces
Another sub-field of HCI is Intelligent User Interfaces (IUI), with the aim to improve the in-teraction between the human and computer, as new technologies and devices are available today. Some of the problems these interfaces try to solve are related to the personalization of the system for each user. As each user might have different preferences and tasks, personal-ized interaction methods are implemented. Moreover, IUIs try to improve the complication and understandability of a system by filtering or clarifying the information required. Some topics strongly related to Artificial Intelligence (AI) are adaption and problem solving, lead-ing to the natural orientation of IUIs towards AI techniques. This does not have to be the case for every IUI. However, a central problem with IUIs is that it violates some of the principles of direct manipulation User Interface development. [1]
2.3
Human Computer Interaction and Usability
HCI want to accomplish and achieve usability for the users interacting with computers. Moreover, as most of the users are interacting with the interface, the importance of communi-cation by the system is at least as high as the computation. Organizations want to minimize costs and errors, while increasing the productivity and satisfaction of the employees, which are factors benefiting having high usability. [15]
Focusing on the user interaction design, as well as the development process, is required to achieve higher usability. Moreover, the interaction design component, which is a pro-grammed implementation, requires attention during the whole process and should provide requirements for the interface software component. This will not only ensure good usability or usefulness, but lead to beneficial results and contribute to the field of HCI. [15, 24]
2.4. Distributed User Interfaces
2.4
Distributed User Interfaces
Distributed Programming, the interest in studying the distribution of computer-based appli-cations describes distributed systems as “systems consisting of multiple autonomous computers communicating through a computer network”. However, using this to directly define Distributed User Interface (DUI) would not give a correctly representative definition as several character-istics are not considered. [25] There is no formal definition for DUIs, even though many of the proposed ones are leaning towards the same definition. However, a well defined definition, similar to the one in Elmqvist’s work [8], proposed by Vanderdonckt [25] is:
User interface distribution concerns the repartition of one or many elements from one or many user interfaces in order to support one or many users to carry out one or many tasks on one or many domains in one or many contexts of use, each context of use consisting of itself in one or many combination of users, platforms, and environments.
DUIs is a relatively new field within HCI, which have introduced a new way of working with interactive systems. It lifted the restrictions of the dependency between the single end user, computing platform and environment. Additionally, it enables the distribution of User Interface element between multiple users, without the dependency between the computing platform and physical environment. [7]
2.5
Challenges with Distributed User Interfaces
As the possibility of having a range of networked devices connected within environments became a reality with DUIs, there are challenges and characteristics to be considered. Future applications and frameworks are, together with their (distributed) interfaces, required to support the freedom of having the cross-interaction between multiple entities or dimensions. [4]
As DUIs introduces a new kind of interaction with a dynamic system, it could poten-tially be hard for users to interpret and understand parts of it, leading to the importance of considering the usability and intelligibility of the DUIs. Furthermore, the distribution of User Interfaces should be in full control by users with the option of adaption to their needs. Feedback is another important part, where the status and process of the distribution should be transparent, facilitating the users’ understanding. Another important challenge brought up is the runtime infrastructure. As DUIs allow for the interaction between multiple applications, handling different non-dependent dimensions, the runtime infrastructure is important in order to have a manageable and impeccable distribution. [4]
Designing DUIs, related applications and frameworks is another main challenge, as well as achieving a working design for multiple dimensions (such as devices, users, environments and platforms), especially considering the sensitivity of the context and the addition of the dynamic distribution. The specifications of the capabilities and borders of DUIs with its characteristics is an additional task to focus on. [4]
2.6. The Marve Framework
2.6
The Marve Framework
Fröberg et. al [13] proposed a DUI framework called Marve, which has been developed based on the experience of their earlier projects within DUIs, and is still under development as of today. Marve focuses on extending the existing GUI-toolkits, without a dependency to a specific GUI-toolkit, but rather being generally applicable to any. It should further create a mechanism, providing programmers distribution control, in order to reduce the complexity of the designing and management of the distribution of the User Interface components. Likewise, the target is to allow a smooth transition from GUI to DUI development.
The framework provides high-level support for transferring User Interface (UI) components between devices at runtime. An abstraction layer is created, by hiding network programming details correlated to the transfer of UI components and events between them. This allows the movability between the devices at runtime.
Furthermore, a model is presented by the framework, which describes the distribution of components for various settings related to the multi-device settings, as well as how the distribution can be performed at runtime. Moreover, Marve allows the freedom to control the transferred functionality, which lets the developer decide if functionality should be trans-ferred with the component or not.
Traditional GUIs use constraint mechanisms, such as layout managers, to control the place-ment and behavior of the UI components. This includes the initial positioning, resizing, and repositioning. DUI developers have to, additionally, be able to control the relation between components and devices. Using Marve, this is managed by a distribution manager which is controllable by the developers. UI components can be distributed among multiple devices, creating a UI dynamically adapted to different setups, at runtime. This is achieved by wrap-ping components for distribution by certain DUI containers, which are handling the control of the distribution among the connected devices. The distribution of components can either be controlled through code, by the users or as a mix of both.
As of today, Marve is updated and developed in JavaScript. The functionality is contin-uously updated and extended in order to provide a fully working framework for Web development. Concepts are the same, with operations being identical for the distribution and transfer of UI components.
2.6. The Marve Framework
Considerations when working with Distribution of User Interface Components
The authors [13] presented core issues related to this distribution of UI components, which developers should take into consideration.The visibility of a component in distributed environments can either be transmitted to one device or to multiple devices. Developers should define when the transfer of compo-nents should occur. This relation associated with the positioning, between the devices and the components is described by the mechanism called Component singularity. The relevant component presentation can be seen in Table 2.1.
Table 2.1: Component presentation Atomic
presentation
Related to the visibility of a component being restricted to a single device at time. Correlated to the move operator.
Mirrored presentation
Related to the visibility of a component being placed on at least two devices anytime. Correlated to the copy operator.
Cloned presentation
An extension of Mirrored presentation, with each component being unique and therefore not connected with the source component. As the users interact with graphical components, these components could have a piece of code executed when interacting with them. This action or routine is referred as a callback function for the respective component which has such a function attached to it. These call-back functions could be coupled or decoupled with the components, meaning they would either be transferred with the component or not. A coupled callback function is referred as server callback and a decoupled as client callback. Using Marve, the developers are able to control the coupling of the callback function, with the help of different type listeners.
Components should be able to be received and interpreted by every involved device within the distribution. Representing these components is not a simple task. Three general cate-gories for the component representation are presented as Component based-, Intermediate- and Image-representation.
2.7. Related Work
2.7
Related Work
Even though the DUI field is relatively new to researchers and still an emerging research field, Bharat and Cardelli [3] introduced a User Interface application with the ability of migrating from a machine to another over the network. This would also include the User Interface, as well as the application contexts and be applicable to mobile computing. However, these so called Migratory applications do not provide any support for both partial and full migration of the User Interface, which is what DUIs provide.
Badam et. al [9], presented three case studies related to their development of Distributed User Interface applications over peer-to-peer (P2P) network. This included a distributed media player, a real-time multiplayer game, and a collaborative search system. Running multiple DUI applications on several devices requires the maintenance of consistency of the states between these, as this affects every kind of application. Another core concern related to the consistency is the synchronization of the actions between different hosts. The robustness of joining or leaving the shared environment is another challenge with DUI applications, as there should not be any dependency on the functionality of each device. As objects such as media, images or documents are to be distributed, the DUI applications have to support this. Some of the proposed solutions are involving the use of common network infrastructure to meet the consistency challenge. Furthermore, system architectures, a synchronization mechanism and management of asymmetric functionality are few other solutions provided related to DUI development. The recommendations, based on their work, was focusing on the network protocol. They preferred P2P as the advantages of using it overcomes the complexity. However, other network architectures have been successful within DUI de-velopment, meaning this is not a requirement but should be considered as this affects the consistency and synchronization. Other requirements lifted are the independency of input and output, allowing DUIs to support input and output on multiple surfaces and devices. Out-of-band communication mechanism should also be provided to support the distributed transfer between peers. Lastly, rendering performance, platform- and format independency and robustness are mentioned, which usually are mentioned within the DUI area.
Villanueva et.al [26] developed a system allowing the distribution of UI components of web applications among a set of devices. The Web page components have a set of distri-bution operations attached to them during runtime, which the user can control and interact with. Proxywork is implemented as a proxy, with the concept of transforming a traditional Web page into a DUI Web page during runtime. To support most of the platforms and avoid some dependencies, the development was restricted to XHTML, CSS and JavaScript. The proposed system can handle different operations for interacting with the Web page. Accord-ing to the case study and the evaluation made, the users were more efficiently performAccord-ing tasks using the presented DUI system.
Fröberg et. al [13] have been using the earlier version of the Marve framework together with the development of a DUI based operator control station. Their application consisted of several GUI component. Additionally, their application handled device connections and
3
Method
This chapter will describe the details of the approach chosen to answer the research ques-tions. Initially, a qualitative literature study was done in order to get a good understanding about the focused area, which is covered in the theory chapter. Furthermore, the develop-ment process will be described focusing on the impledevelop-mentation and the relevant theory. A map-based game was developed, in order to use a bigger and more realistic applica-tion to properly test and analyze the distributed user interface framework.
3.1
Description of the Game
The game will further on be referred as DUIHammer. A map is used to represent the battle-field, where two troops represent each team. Each team is placed on their respective side of the battlefield and can consist of multiple members, where each team has a team-leader. A team consists of different characters, with different characteristics and options. During the respective round for each team, any movements or actions can be made during that round. The aim for a team is to win territory battles and eliminate the opponent’s team. DUIHam-mer is most interesting as a cooperative game, where responsibility for characters and actions are divided across the team, both as gameplay and for this work.
3.2. Technical Description of the Platform
Figure 3.1: Initial sketch of the layout/structure of the game.
3.2
Technical Description of the Platform
As the Marve framework is written in JavaScript and focuses on Web development, the natu-ral choice is to focus on JavaScript within the implementation. Other than that, the developer is not restricted. For this work, DUIHammer has been developed in vanilla JavaScript with some required libraries being included, which will further be described in the following sub-sections. Working with vanilla JavaScript and only using necessary third-party libraries are enough for achieving the aim of this work. Moreover, the result becomes more relevant, as any potential complications or distractions related to unnecessary additions of libraries or frameworks, are reduced. With the time limit of this work, this allows for more concrete and informative result. Marve is still under development, and the focus lies on analyzing and evaluating where possible improvements can be made, as well as finding other issues con-cerning the DUI related parts. Moreover, this creates requirements based on shortcomings, which can be used in future development of Marve, and DUI frameworks in general.
3.3
OpenStreetMap
OpenStreetMap (OSM) is the map used for the game in this work, which allows the creation of an editable map and extraction of geographical information. [18] The geographical infor-mation is extracted as GeoJSON, which is a format based on JSON and used for encoding the geographical data structures. [14]
3.5. Turf.js
3.5
Turf.js
Turf.js (Turf) is a JavaScript library used for geospatial analysis. It has a variety of methods and helper functions, allowing operations and calculations on GeoJSON data. [21] In this work Turf was mainly used for working with the GeoJSON data in order to calculate such as shortest routes for the characters, as well as for other checks for the geometrical calculations.
3.6
Flask
The Marve framework uses Flask [10] for its backend, which is a lightweight Web application framework. It works perfectly for smaller applications, as well as more complex ones, pro-viding an easy developing approach. Projects using Flask are not dependent nor restricted to any tools or libraries, but have a large selection if necessary. Naturally, this project’s backend was written using Flask, as it provides a concept called blueprints [11], allowing the connec-tion to Marve in a simplified manner. This is done by extending the Flask applicaconnec-tion from Marve.
SQLAlchemy
SQLAlchemy was used together with Flask, as there is an extension for Flask providing this relationship for simplified use. It is a suitable extension, giving the developer full power and flexibility of SQL. Moreover, it is designed for efficient, high-performing, and simple database access. [12, 20] As there are parts of the implementation that requires a database, which Marve currently cannot manage, a database is used. In this work, SQLAlchemy is a natural choice as it works perfectly with Flask and is enough for this work.
3.7. The Marve Framework and its Contribution
3.7
The Marve Framework and its Contribution
The Marve framework provides different methods for the distribution, as well as other func-tionality related to the users and rooms. It has the capability of working with multiple node layers, meaning it can iterate through node children and handle them accordingly. The fol-lowing subsections include relevant and used parts of Marve’s functionality in this work.
Session and User Handling
Marve has the capability to handle multiple sessions simultaneously, meaning multiple users (devices) can join and be processed accordingly. A user (device) can join a room and the connection is handled by Marve. If a room exist and a device requests to join it, it will directly join, otherwise it will create a room and the device will thereafter join it. Every device is granted a unique identifier (ID). With the usage the distribution manager (dm), a global JavaScript function object, each device is also added to the DUI network.
The following available methods for device management were used: • setDeviceListener()
Listens to any device connecting. Takes a listener as a parameter, which manages any new device joining the session. The developer will have to implement a listener specific to the application created, and the behavior the developer strives for.
• setConnectionListener()
Handles the current device connecting. As for setDeviceListener, the parameter is a lis-tener which manages the current joining device. The developer will have to implement a listener specific to the application created, and the behavior the developer strives for. • connected()
Connects the device to the session, which is fully managed by Marve. • setJoinRoom() and joinRoomRequest()
These functions are triggered when a device joins a room. A listener is taken as a pa-rameter, where the developer implements the event for when a user joins a requested room. The joinRoomRequest() function will update the server with the joining device and the room, and the server will then add the device to the room.
• setLeaveRoom() and leaveRoomRequest()
The setLeaveRoom() function is triggered when a device leaves a room. A listener is taken as a parameter, which is used by the developer to decide what should happen when a user leaves the room. The leaveRoomRequest() function will update the server with the leaving device and the room, and the device will then be removed from the room by the server.
3.7. The Marve Framework and its Contribution
Figure 3.2: Simple device and room handling example, where device 1 and 2 requested to join and joined room 1, while device 3 did the same for room 2.
Disconnecting, Reconnecting and Refreshing
In some cases, there might occur unexpected or intentional disconnection from the browser and the page. Sometimes a refresh of a page might be required due to some issue with the browser or the page. This can result into issues with saved states or different kind of issues with the application being used. Marve has functionality to manage this in order to avoid disconnections from rooms with associated consequences.
Every device has a unique id which is saved in the browser cookies after a device joins a room. A cookie is basically data stored on a user’s computer by the browser during the user’s session. In case of a refresh, initially a control is made to verify if an id is obtainable from the cookies. If that is the case, that is the same device, as the cookies are device specific, and the connected device will be assigned the same id as before the refresh.
Each of the components a device has been distributed are saved in the page specific lo-cal storage, including the component information and the relevant states. Following a reconnect, the components are re-distributed to the device.
If a device is manually leaving a room, the listener for the setLeaveRoom() function will be called, and Marve will handle the clearing of the cookies and the local storage with the specific information for that device.
However, in case of a unintentional disconnection, Marve tries to re-establish the con-nection with the device for a set time-interval. Passing the time-interval without success, the device will be removed.
3.7. The Marve Framework and its Contribution
Distribution Handling
Every user interface component, has to be a distributed object in order to be managed by Marve. A function named dm() (short for distribution manager) is provided by Marve, which takes the target Node or string as parameter, allowing the distribution to be done at DOM (document object model) element levels. The function attaches to the window object of the page. Assuming we have a DOM-node n to be converted to a distributed object, you simply wrap the node and use the distributed object directly:
dm(n)
Now the distributed object can be used together with the provided DUI functionality. Ini-tially, the distributed objects will be present as atomic, see Table 2.1. The central functions of the distribution are mirror and transfer (clone).
Mirroring
Mirroring an object is accomplished by using the provided function mirror(). The mirror func-tion has an opfunc-tions parameter, which in this work is used to specify the receiving devices of the mirrored object. An object obj being distributed by Marve, using the distribution manager dm, is mirrored to the receiving device with a unique id deviceId as following:
dm(obj).mirror({ device: deviceId });
The information is sent over the DUI network, and the receiver can handle any updates to its DOM-tree using the setReceiveListener, which takes a listener as parameter where the developer can react on receiving objects.
A mirrored component will be, as the name suggests, an exact representation of the ori-gin object. Meaning, any changes to the mirrored object by any device will be reflected on all devices sharing that mirrored object, as the state is shared.
Cloning
Cloning or transferring an object is accomplished by using the provided function transfer(). The transfer function has an options parameter which, similarly as for the mirror function, is used to specify the receiving devices of the cloned object. An object obj being distributed by Marve, using the distribution manager dm, is cloned to the receiving device with a unique id deviceId as following:
dm(obj).transfer({ device: deviceId });
As with the mirroring, the information is sent over the DUI network, and the receiver can handle any updates to its DOM-tree using the setReceiveListener, which takes a listener as parameter where the developer can react on receiving objects.
3.8. Development of the Game
Positioning of Mirrored or Cloned Objects
Initially during the distribution, a mirrored or cloned object is unchanged on the device it originated from, except from when it is fully transferred, where it is transferred to a new device and removed from the originated. During mirroring or cloning of an object, managed by Marve, these objects are added to the DOM at a specified position on the receiving device. This is done by a function setWidgetListRef(), which takes a reference to a node in the DOM as parameter. The node is an individual part of the document, such as an HTML element, where the developer wants the distributed objects positioned.
Figure 3.3: The reference to a node element is set for the receiving device, and the distributed object will be placed there.
3.8
Development of the Game
The understanding of which functionality and solution Marve provides, as well as how this could be used in the project, led to the following structure of the of the game development:
1. Implementation of the base of the game
2. Addition of enough features and components to have a big and complete enough ap-plication for Marve to handle
3. Creation of a lobby for players to request team and room to join 4. Addition of Marve
With the base implemented, the focus is then to include enough of components with their respective features, in order to achieve a complete game which would cover most of the testing of Marve. Additionally, a game lobby is created for distribution of players and games (devices and rooms), as well as for analyzing Marve’s functionality of handling devices and rooms. The integration of Marve is then the final part of the development.
3.8. Development of the Game
Base of the Game
The game map is structured by image tiles, which requires a tile layer URL (uniform resource locator) to load these tiles and have a visible map. This is a standard for how OSM provides the map usage. Moreover, it gives a good opportunity to test Marve’s capability of distribut-ing this to other players as it should be able to handle image objects. By usdistribut-ing Leaflet, the map is created with suitable properties, bounds and event listeners. This allows the players to move around, zoom and click on the map.
Relevant information was then added to the control and information panel, see Figure 3.1. This includes the game timer, which represent the time each player has to finish their turn. Other information, such as path time, character information, team information and action controls, were also added
Game Features and Functionality
With the base implemented, characters and the relevant features and functionality were added. As the characters are a central part of the game, many of the features were related to them.
Initially, as the game map does not provide any interaction on low-level, such as for the buildings and surfaces, this required the use of GeoJSON. Desired parts of the map were acquired by available services online, which allows the user choose an area and then provides a GeoJSON file with the relevant geographical information of that area. The main functional-ities and features were implemented using the provided methods and help functions by Turf, where calculations and filtering where using the properties building, surface and geometry represented as in Listing 3.1. This includes path and movement calculations with regards to obstacles and different surfaces, shooting sight and bound checks.
3.8. Development of the Game
Listing 3.1: Example of the GeoJSON structure. { " type " : " F e a t u r e " , " id " : "way/ 9 3 6 4 5 7 8 1 " , " p r o p e r t i e s " : { " timestamp " : "2019´09´06T16 : 5 2 : 4 6 Z " , " v e r s i o n " : " 5 " , " c h a n g e s e t " : " 7 4 1 8 5 8 1 6 " , " u s e r " : " d´vogel " , " uid " : " 2 0 0 3 4 5 6 " , " alt_name " : " Medicinska f a k u l t e t e n " , " amenity " : " u n i v e r s i t y " , " b u i l d i n g " : " u n i v e r s i t y " ,
" name " : " Linkopings u n i v e r s i t e t , Campus US " , " old_name " : " H a l s o u n i v e r s i t e t e t " , " short_name " : "HU" , " s o u r c e " : " Bing " , " id " : "way/93645781" } , " geometry " : { " type " : " Polygon " , " c o o r d i n a t e s " : [ [ [ 1 5 . 6 2 3 0 8 1 8 , 5 8 . 4 0 3 3 8 0 8 ] , . . . ] } }
3.8. Development of the Game
Characters and bullets were implemented as markers provided by Leaflet. This was the best way of working with the map, as it provides functionality working naturally with a map-based application. The markers were created using Leaflet and extended moving markers, with customized properties and functionality required for each character described bellow:
• Character type and category
Each character can be of a different category and different type within that category, such as a big soldier and small soldier within the category soldier
• Team
Describes which team a character belongs to. • Life and life handling
Defines how many lives a character has and related events for how a life is decreased/increased. • Character specific abilities
This includes ranges for different actions, such as shooting, melee and healing, as well as the relevant events for how these actions are made.
• Movement range and controls for these during interaction
Defines the range each character can move, as well as the movement functionality. • Movement speed on different surfaces
Defines the different speed value for different surfaces, such as grass or asphalt.
These properties and the related functionality for the interaction were implemented using the available events for the Leaflet markers together with the events provided for the map. There are multiple relations between the described properties, actions and events. The properties were easily acquired and used in calculations for the features and functionalities.
The movement of each character is performed by the player selecting a character, and selecting a position within range, resulting in a provided path to the position. This move can then be confirmed by the player and the character will start moving, if it can complete the move within the time left for that turn. Similarly, when an action is to be made, a character is selected and then confirmed using the control panel.
With working interactions, controls and calculations, the connection to the panels (con-trol and information) and the corresponding parts was made. An almost fully working game was achieved, following the presented description. However, the connection between devices and rooms was yet to be implemented.
Game Lobby
In order to properly handle room requests, a lobby was implemented, where devices can enter the room to join, as well as which team they want to join. The functionality for the
3.8. Development of the Game
Addition of Marve Functionality
There are several sections where the Marve functionality was added, and every used object had to be a distributed object as explained in Section 3.7:
• Positioning of the distributed objects
A reference to the node in the DOM, where each distributed object should be placed during the distribution, was added using setWidgetListRef().
• Game lobby
Each device connecting to the lobby was assigned a unique id, using the connected() method. This id represents the device in-game and over the DUI network. setConnec-tionListener is used to handle the connected device, in this case displaying the id. When pressing the join room button in the lobby, setJoinRoom() is called, and the device will be added to the selected room.
• Team information
When a device joins a room and a team, setDeviceListener() will trigger and the listener will be called. In DUIHammer, every connected device to the current room will be up-dated, and the team-members in the panel will be updated with relevant information. • Game start request
Team-leaders have the option to request the start of a game in their current room. This part is mirrored to all the connected devices using mirror(), meaning every device will be updated regarding the request of the start.
• Game map
As the team-leaders initially have the access to the game map, it was distributed to the respective team-members. This was done using the transfer() method, which clones a copy of the map to the devices at its current state.
• Game timer
Immediately at the start of the game, each player is mirrored the game timer using the mirror() method. As this should be identical for every player, this is not changed. To-gether with the game timer, an indicator and respective functionality was implemented, showing and managing whose turn it is, restricting a team to play during the opponents turn.
• Characters
Initially, each team-leader owns all the characters and decides which character to dis-tribute to the other team-members. The only method used for this was the mirror() function, as this should be reflected across the team. During the game map distribu-tion, each team has their opponent’s characters mirrored, letting them be updated of the opponent’s characters. In order for a leader to mirror a character to a team-member, each character was made draggable. Dragging a character and dropping it over a device in the team list mirrors it to that device. This could have be done by using right clicks or other designs, and is a design preference. Any changes to the characters are mirrored to every device in a team.
3.9. Shortcomings and Requirements
Backend
As Marve cannot handle application specific information, such as room information or relations between different classes, a Flask backend together with SQLAlchemy (Flask-SQLAlchemy) was used to handle this kind of data. This includes device (player) information, room (game) information for each started game, and the relation between these two classes. Other functionality for managing rooms and devices was also included in the backend.
Figure 3.4: The two classes included for the database.
Implementation, Analysis and Evaluation
During this phase, every section where Marve should be able to contribute was designed for this purpose. With different solutions of the implementation where Marve’s functionality was present, Marve’s functionality could be tested more extensively. and then evaluated and analyzed in order to see how useful a solution with Marve is in a specific scenario.
3.9
Shortcomings and Requirements
Together with the implementation, analysis and evaluation, any shortcomings were docu-mented and setup as requirements for the Marve framework. These will be further presented in the Chapter Results and more extensively discussed in the Chapter Discussion.
4
Results
4.1
DUIHammer
The resulting game, DUIHammer, will be presented in subsections of each relevant part de-scribed.
Game Lobby
The game lobby can be seen in Figure 4.1. For each room, the first two devices joining respec-tive team are automatically assigned team-leaders in their team. When the two team-leaders of respective team are present, they can request to start the game. Initially, only the team-leaders have access to all component, as they are the ones who should be able to have access to them in the beginning and thereafter distribute these to their team-members. Distribution of team-leader roles is accomplished on the application side, meaning Marve does not handle this.
Other team-members, who join after the team-leader in their respective team, will only have the frame and standard components available. The rest will, initially, have to be distributed by the team-leaders using Marve.
4.1. DUIHammer
Game Base with Features and Functionality
As described in Figure 4.1, both the team-leaders have to confirm the start of the game. One of them request to start the game, which will result in a request box appearing for all the players by mirroring using Marve. Both team-leaders have their respective checkbox to check, and then any of them can start the game by pressing the start button, provided both checkboxes are checked. Marve manages the mirroring of the request box, while the rest is application specific and managed there.
Figure 4.2: Request to start the game was made by one of the leaders, and both team-leaders have to confirm the start.
The panel was divided into two sections, information panel and control panel. Actions related to movement, shooting and healing were added there, as well as character information. The information panel includes general information such as number of players connected to the room, team-members, time left of the round and path time for a character. Different phases of the game panel can be seen in Figure 4.3 bellow.
Figure 4.3: The game panel in different phases, with relevant information and actions to be made.
4.1. DUIHammer
Depending on the character, different actions can be made, as seen in Figure 4.4. In this game, there are different kind of soldiers, represented as the type, which can shoot and have different advantages, such as movement speed, shooting range and life amount. Healers are there to work as a supporter and heal injured soldiers.
Figure 4.4: The action section, with actions for a soldier to the left and healer to the right.
During a team’s round, selecting a character belonging to the team, will allow the player to choose actions to be made. A player can either move the character, which is accomplished by selecting a character and then pressing on the destination on the map. The destination has to be within the movement range for the specific character and its type. With this requirement passed, a path with collision avoidance will be shown with the corresponding path time. This path can be confirmed by pressing CONFIRM MOVE button in the action sub-panel seen in Figure 4.4 and the character will start moving to the destination only if it passes the second requirement, the path time has to be within the time left of the team’s round-time.
4.1. DUIHammer
The path time could differ depending on the surface, resulting in a strategical choice to be made by the player. A comparison is shown in Figure 4.6, where the approximately same distance have two different path times on two different surfaces.
Figure 4.6: The path time difference between two different surfaces, asphalt and grass.
Other actions which could be made are shooting an enemy character and healing own char-acters. Selecting a healer and pressing the HEAL button in the action section seen in Figure 4.4, will heal all characters within the healers healing range. Furthermore, if a character of type soldier is selected, and has the opponent’s character within shooting range and without any obstacles in the way, it will have the option to shoot. This is accomplished by selecting the soldier to shoot, and then selecting a character of the opponent. If shooting is possible, a sight line will be visible and pressing SHOOT in the action section seen in Figure 4.4, will fire a bullet, reducing the life of the hit target. If the characters are close enough, the melee option is available, which will perform a melee hit and reduce the life of the target.
4.2. Distribution with Marve and Shortcomings
4.2
Distribution with Marve and Shortcomings
• Positioning of the distributed objectsDepending on the device whom an user interface element is distributed to, a different node reference was used, as seen in Figure 3.3. The device could either be the team-leader or a team-member. Marve managed the positioning correctly without any issues or difficulties. However, this was statically preset and could not be changed with any logic from the developer, meaning the implementation of the game had to be adjusted accordingly.
• Mirroring and cloning
The central mirroring and cloning for this game requires at least two players within the same team. A drag and drop listener was used for this, which allows a player to simply drag the distributed component over the team-member’s id in the team list, and then drop it to mirror the component. As seen in Figure 4.3 and the middle phase, the team-member’s id is highlighted in white, indicating that the distributed component can be dropped and mirrored to that team-member.
• Game lobby
The players joining the game lobby were correctly assigned a unique id, the connection was easy to setup and the setConnectionListener() managed connections correctly. The setJoinRoom() accurately managed the room connection for each player.
• Team information
As Marve handles the device listener, the only part to implement on the application side was the callback function for updating the respective team list. The same process would work for other information sharing functionality, which does not require mirroring, and can simply be used by acting upon newly joined devices. However, as Marve does not keep any information about the room-device relation and has no functionality for it, this had to be done in the application using the database.
• Game timer
The game timer was implemented using some basic JavaScript functions and callbacks, which got updated on the application side, while Marve was used to mirror the timer to all the connected players. This part worked correctly without any issues.
• Game start request
Mirroring the start request seen in Figure 4.2, worked to some extent. It got properly displayed for all the connected players. However, there were two issues. The first is-sue noticed was that every player could interact with the component, meaning that the restriction of team-leaders being allowed to interact with it was unsuccessful. Using different quick solutions on the application side did not work. The second, major short-coming noticed, was that pressing the "Start the game!" button removed the request correctly, but only triggered the event listener for that specific device pressing, meaning the corresponding event listeners did not transfer to the receiving devices.
4.2. Distribution with Marve and Shortcomings
• Disconnection and re-connection
Unexpected disconnects, intentional disconnection or refreshing were the possibilities of disconnecting from the game. These were all situations that Marve should handle, both managing the disconnection and re-connection on the client and server side. The setLeaveRoom() function was used together with a listener which should handle the leaving room event. Another function provided by Marve was the leaveRoomRe-quest() which would request a disconnection and update the server with the leaving device and the room.
All of the disconnection situations were tested, with only the intentional discon-nection working. Using the leaveRoomRequest() to make an intentional discondiscon-nection worked and the player got properly disconnected. Closing the browser, and waiting for the time period which should automatically disconnect the player worked as well. However, the re-connection handling did not work when refreshing the page, nor when unexpectedly disconnecting and re-connecting. This lead to the device being returned to the lobby and managed as a different device, meaning it started from the beginning again as a completely new device.
• Game map
As the players should individually interact with the game map, the cloning was per-formed by Marve to distribute the same game map to all the connected devices. The cloning worked properly with the map transferring to the devices. However, the in-teraction with the game map was not possible for any device who got the map cloned, leading to the same issue as for the start request for the game, where the corresponding event listeners did not transfer.
This was also confirmed using the mirroring functionality. It was mirroring cor-rectly from the originated destination, but the devices who got it mirrored could not interact with it at all, only see the map being moved by the origin source. Furthermore, as the map is based on image objects, these get updated as the player move the map and new image objects appear. Marve did, on the server side, correctly update these, but could not perform the mirroring correctly for these. This led to the mirroring of the map working for very slow movements of the map, as only a few images are added to the map. However, with larger and quicker movements of the map, it could not catch up and mirror it to the other device.
• Characters
The characters could be mirrored to other devices in the same way as with the other components. Likewise, the interaction with the character was not possible on the desti-nation device, meaning the event listeners were not distributed. Moreover, the position-ing of the character was different than on the origin device, even though the coordinates were identical. The movements were correctly mirrored with some performance issues, even if the positioning was different.
4.3. Requirements Based on the Shortcomings
4.3
Requirements Based on the Shortcomings
The issues and shortcomings that arose during the implementation and testing, resulted in requirements for the Marve framework covered by this work. These requirements are not a full representation of the requirements for the Marve framework or any DUI framework in general, but rather a sub-representation of the requirements which Marve failed to pass based during this work. Moreover, these requirements are necessary to pass in order to have a working DUI framework for development of web applications, especially for the web ap-plication presented in this work.
Table 4.1: Requirements for the Marve Framework based on the presented shortcomings
Requirement Shortcoming
Dynamic positioning of
distributed components
The placement of the distributed components in the DOM-tree are statically preset and cannot be changed dynamically.
Re-connection handling
Re-connecting with same id and at a correct state is not working after accidental/unexpected disconnect or refresh.
Event listeners transfer
Distribution of components does not transfer the event listeners and therefore not mirroring/cloning these components correctly. Performance Mirroring not working fully and is lagging when many newly loaded
images appear in the situation of quickly moving around the map during the mirroring. Same issue appears with the movement and
actions of characters being mirrored. Device-Room
relation
Checks dependent on the relation between a device and a room has to be done in the implementation of the game.
Mirroring options
Game start request allow every player to interact with it, even if restrictions are desired.
5
Discussion
5.1
Results
DUIHammer
The aim with DUIHammer was not achieving a complete game with the perfect design, but rather creating a well-covering game which would include every possible interaction a user would have with a web application. Moreover, the purpose with DUIHammer was to con-tribute to the DUI field by improving the Marve framework. Another purpose with DUI-Hammer was to open up the possibilites for a new way of developing a co-operative games, as well as a new way of playing it, through the distribution of the components.
Shortcomings and Requirements
As the Marve framework is still under development, some shortcomings were expected. However, as described in the Chapter Theory, some of the functionality had previously been working with other applications. A larger web application, such as DUIHammer, opens up for more testing and evaluation of the framework, leading to more shortcomings being discovered and being covered in a wider context.
As the DUI field is becoming more relevant with its advantages and contributions to the web development, requirements are necessary in order to achieve a complete framework, and provides a good overview for to follow and evaluate during development and im-plementation. The field could potentially be a solution and option for future applications within the web, and replace some of the current solutions used and facilitate parts of the
5.1. Results
Dynamic Positioning of Distributed Components
When a distributed user interface component is being mirrored or cloned, it has to be placed somewhere on the target destination. In web development, this is the DOM-tree, which holds a structure of all nodes. Depending on the design of the application, the destination position either has to be identical as on the source, or at a chosen place in the DOM-tree. In either of these cases, having static pre-defined references for each component would result in mas-sive work and non-maintainable code. Moreover, the reference of the position in the targeted DOM will naturally have to vary, as objects are usually not placed in the same position. There-fore, having a solution to dynamically reference to the destination is a must.
Listing 5.1: Usage of the positioning reference. // Updates Marve with t h e r e f e r e n c e t o d e s t i n a t i o n dm. s e t W i d g e t L i s t R e f ( w i d g e t L i s t R e f ) ;
// Returning t h e node element as r e f e r e n c e f u n c t i o n w i d g e t L i s t R e f ( ) {
i f ( getTeamLeaders ( ) . i n c l u d e s (dm. g e t D e v i c e I d ( ) ) ) r e t u r n document . getElementById ( " gameLayout " ) ; r e t u r n document . getElementById ( " duiWidgets " ) ; }
The code example in Listing 5.1 above, shows how the referencing to the destination is per-formed. Imagine if the application was even larger or more complex, with more cases where different destination positions would be required. This would result in a complex logic and require a lot more planning and design challenges.
Listing 5.2: Example of a currently non-working but necessary functionality. // Updates t h e widget l i s t r e f e r e n c e ( with newRef ) when c a l l e d
f u n c t i o n setNewWidgetListRef ( newRef ) { dm. s e t W i d g e t L i s t R e f ( newRef ) ;
}
In case of the need of updating the reference dynamically, by using the function showed in the code example in Listing 5.2, that would currently not work with Marve. However, this would facilitate for the developers and result in more flexibility and maintainability. Therefore, a useful and advantageous solution would be supporting dynamic positioning referencing.
Re-connection Handling
Accidental or unexpected disconnections are possibilities, either connection related or mis-take related. As presented in the result and Section 4.2, intentional disconnecting worked well with Marve updating the server and also the client afterwards. However, refreshing or unintentionally disconnecting and then re-connecting to the game or lobby did not work. The device got a new device id, and everything was reset for that device. Something noticeable was that there were attempts where Marve did actually save the state and the re-connect did occur, but very rarely and not with all correct states for the components.
5.1. Results
The framework, and more specifically the re-connection was tested and implemented based on simpler applications based on "standard" components such as forms with simpler struc-tures. Compared to a larger application as DUIHammer, having a more complex structure and different components with the addition Leaflet, which could possibly be an issue for Marve to handle as these cases were not considered in the initial phase of the implementation of Marve.
There are many applications where progress and current states are relevant and impor-tant. It can result into consequential issues if applications cannot manage these cases, if unintentional disconnections or refreshes occur. Therefore, this is an important requirement to pass in order to achieve a complete DUI framework of this kind.
Transfer of Event Listeners
Events are a very common part in web development, and a central part in humans interaction with the web. These are usually combined with functions, where the function awaits the occurrence of the event before triggering. The event listeners are providing the interaction between the application and the user, in this case the game and the players.
Listing 5.3: Example of event listeners added to the in-game characters.
// Event l i s t e n e r which f i r e s when a c h a r a c t e r i s c l i c k e d on c h a r a c t e r . on ( ’ c l i c k ’ , o n C h a r a c t e r C l i c k ) ;
// Event l i s t e n e r which f i r e s when a c h a r a c t e r i s moving c h a r a c t e r . on ( ’ move ’ , onCharacterrMove ) ;
Different shortcomings during different tests of distribution led to the finding of Marve not handling the event listener transfer during the mirroring or cloning phase. With the game start request, the start button has an event listener which fires when pressed and will further call functions related to starting the game for all players. The other case was the cloning of the map, where the map interaction was not present for the devices having the map distributed. This applied for the characters as well, where the mirroring of these did not transfer the event listeners connected to them.
A result of this was that devices receiving distributed objects could not interact with them, as event listeners plays a central role and are not transferred to these devices. This mainly affected the destination devices, meaning the players whom the components got mirrored or cloned to. However, this does not only affect them, but the whole game as it cannot be played without this functionality available.
Likewise, as web applications use these event listeners constantly, with buttons or any other components which a user can interact with, this is a major requirement for a framework within the field of DUI, and Marve in this case.
