Architecture of a Dispersed Gamification System for Tourist Attractions

The paper addresses the issues of implementing e-guide-based gamification systems for tourist attractions by proposing a dispersed gamification system architecture in which its respective functional aspects are handled by multiple web services with various scopes of responsibility. The features provided by the proposed architecture are successfully matched to tourist attraction requirements identified during development of an e-guide gamification system for an international consortium of tourist attractions. The key contributions of the paper are: the new definition of gamification system extending beyond the concept of a set of game-based rules and including the information technology components necessary to implement it; mapping the abstract gamification system model into the domain of tourist attraction gamification and the analysis of advantages and disadvantages of various organizations of e-guide gamification systems; the introduction of a new, dispersed architecture of e-guide gamification system that addresses the identified needs of tourist attractions.


Introduction
Over ten years has passed since the confluence of web technologies, digital business models, as well as online and location-based gaming gave rise to gamification [1].This phenomenon, defined as "the use of game-design and game psychology in non-game settings to engage the target audience and motivate specific behaviours" [2] spread to as remote areas as education [3], marketing [4], industrial production [5], medical therapy [6] or scientific research [7].It has found its way into tourism as well [8].
There are various goals for implementing gamification in tourism: economic, social and environmental and it could be aimed not only at tourists but also at employees and community [9].The expected benefits include raising brand awareness, enhancing tourist experiences, increasing their engagement, improving their loyalty, introducing entertainment and supporting employee management [10].
In this paper, we take a different point of view and rather than focusing on a specific goal of tourism gamification, we focus on a particular medium of its implementation, that is on multimedia visitor guidance systems, better known as e-guides, which substitute human guides with portable electronic devices running software capable of communicating information about visited places and watched objects to visitors.
Such devices can be rented at tourism premises (with the necessary software and data pre-installed) or owned and brought by visitors themselves (with the necessary software and data downloaded from the Internet).
There is number of scientific reports on implementation of gamification to e-guides, including such cases as:

•
"Grand Master Challenge", which provides an entertaining experience (in a form of solving a mystery of a medieval-themed crime story) to the visitors of Rhodes, Greece [11]; • "PhotoTrip", in which gamification is used to improve the quality of recommendations of cultural heritage locations along travel itineraries [12]; • "SUMMIT", which gamifies the experience of walkers and hikers for the benefit of local communities through the area of which they wander [13]; • "The Ocean Game", which is a treasure-hunt-based mobile educational game for children visiting Natural History Museum of Funchal, Portugal [14]; • "The Secret Diary of Philippe Perrin" and "Support a Reporter from the Year 5000 AD", which are two interactive stories engaging visitors of a "space city" in Toulouse, France, to perform certain real-world activities [15]; • "Trip 4 All", a gamified virtual assistant to traveling elderly people [16].
Unfortunately, there has been little effort in the existing literature to generalize the published case studies and identify the specific traits of e-guide gamification systems that ought to be addressed in a dedicated way.While there are publications that deal with gamification in tourism on a more general level (e.g., [8]), the solutions they provide focus rather on the "soft" aspect of implementing gamification (that is what more or less abstract types of gamification techniques there are and how they match to intended effects) rather than on the "technical" one, that is what functional components one needs to apply gamification rules to practice.This research gap has become apparent to this author during his work on an e-guide gamification system for an international consortium of tourist attractions [17].A sophisticated requirements elicitation process employed there, involving subject-area experts, tourist attraction employees and visitors-see [18] (pp.621-623) for its description-resulted in the exposure of a number of domain-specific issues that have not been treated with due attention so far.Consequently, a generic framework for gamification of tourist attraction has been proposed, specifying implementation principles addressing these issues, including: separation of gamification layer, considering gamification rules to be a kind of e-guide content separate from the rule engine and standardized description of e-guide events and gamification rules [18].
This paper contributes to the proposed framework and at the same time addresses the identified research gap by, first, providing a practical, wide definition of gamification system and listing its components, then, describing the specific needs of tourist attractions with regard to applying gamification to e-guides and analyzing the advantages and disadvantages of possible alternatives for the placement of vital gamification system components and finally, proposing a dispersed architecture of gamification system that addresses a number of identified needs.
The structure of the paper reflects the above-mentioned aims.In the following section, we start with a discussion on the notion of gamification system leading to its new definition and the list of its components.In Section 3, we narrow down the discussion to e-guide gamification, describing its specifics and its special needs.We also investigate the possible implementation models for e-guide gamification systems differing in the placement of its respective components.In Section 4, we analyze the applicability of dispersion to respective gamification system components, then introduce and explain the concept of dispersed gamification system architecture.Section 5 closes with the conclusion and suggestion for future research.

The Scope of the Gamification System Concept
While game can be defined as "a system of rules in which agents compete by making ambiguous, endogenously meaningful decisions" [19] (p.19), gamification, similarly, employs a system of rules linking users' actions to game-inspired consequences, such as rewards, storyline progress or, at least, a specific feedback.This may explain why the widespread notion of gamification system is this system of rules-see for example, [20] (p.13) or [21] (p.236).In this paper, however, we shall refer to this notion as gamification system in a narrow sense or system of gamification rules, because our focus is on the technological solutions that make it feasible to implement such a system of rules in practice.For this reason, from now on, we understand gamification system in its wide sense, that is also including the environment that gamification is applied to and the technological components necessary to make the gamification rules actually work.Before we proceed to discussing these components, one more assumption has to be stated: that our work deals with an online or computer-supported gamification, that is one in which the gamification rules are automatically processed by dedicated software.While it is possible to implement gamification with just a pen-and-paper-based approach (known as offline gamification [22] (p.136)), usually the complexity of both the environment gamification is applied to and the gamification rules themselves strongly advocates the use of information technology (IT) to handle the maintenance of the game state and processing of gamification rules.

The Gamification System Components
There are several components required in order to implement online gamification.Interestingly, an analysis of existing literature reveals no prior effort in distinguishing the full gamut of these components.The closest attempts we identified were: 1.
Maha Khemaja and Félix Buendia in their paper introducing a framework aiming to help developers to build context-aware gamified apps and making use of ontologies and micro-services, identified such components as "Game element manager" (which "defines and adapts game elements") and "Game logic manager" (which "defines and adapts game logic") [23]; 2.
Philipp Herzig who conceived and developed a cloud-based platform for enterprise gamification identified its following components: "Business Entity Provider" (which "manages and maintains the state of domain entities", such as "badges, points or levels") and "Event Processing Agent" (that "holds a set of gamification rules which reason over incoming events" to "calculate feedback such as point or badge instances for the respective users and update the entities' states" maintained by the Business Entity Provider) [24] (pp.83-84).

3.
A prior work of this author devoted to the architecture of gamified learning management system (LMS) distinguishes 20 functional modules, yet considered from a perspective of an LMS, not a gamification system (i.e., the modules perform tasks typical for an LMS and additional gamification-related tasks, for example, the module list includes "Server-side scripting environment" used both to test programming exercise solutions and process gamification rules) [25].
As can thus be observed from the above-described examples, the descriptions provided in the existing literature are not sufficient for the aims of this paper, as they describe the architecture of particular implementations of gamification systems (all the three examples); consequently: the components are defined according to the structure of the implementation (i.e., if a single module of an implemented system handles two tasks, the system includes this module as a single component rather than two; while such a combination may make perfect sense for a given implementation, it may not in a different context); include those components that they consider relevant to their own work (i.e., omit components subjectively considered obvious and/or out-of-scope, such as rule management system in examples 1 and 2 or include components which are irrelevant for gamification, though relevant for the gamified system, such as course management in example 3).
In order to properly address the gap described above, this paper introduces a list of gamification system components which was developed adhering to the following rules:

•
identify one component per one type of data or function of a gamification system; • consider only types of data or functions that are relevant for every online gamification system, regardless from the context and aim of gamification and the implementation architecture; • include only the necessary gamification-related components (e.g., some form of user authorization exists in most gamification systems, yet it is neither always necessary nor specific to gamification systems).
Eventually, after a careful examination of a number of gamification system implementation examples and relevant literature (including [23][24][25]), a list containing the following components has been assembled:

•
Gamified system (GS), that is the environment to which gamification is applied to enriched with: Event processing layer (EPL) responsible for identifying those events (typically resulting from users' activities) happening in GS that are relevant to gamification and passing their description to GRPS (see below); Gamification presentation layer (GaPL) responsible for presenting the gamification-related feedback to users, using either an adapted original user interface of GS (so called in-band gamification) or through a separate user interface dedicated to gamification (so called out-of-band gamification); • System of gamification rules (GRS), that is the rules defining game-inspired consequences of users' actions (i.e., gamification system in its narrow sense); • Game state (GSt), that is the description of the current state of gamification-related indicators (e.g., points, badges and items collected by specific users); • Game state maintenance subsystem (GSMS), that is the software that provides access to GSt and updates it ensuring its consistency (it may also trigger gamification rules which are state-dependent); • Gamification rule processing system (GRPS), that is the software interpreting gamification rules of GRS in the context of GSt (accessed via GSMS) using data received from EPL of GS as input and passing the results of applied rules to GSMS and GaPL of GS (see below); • Gamification management system (GMS), which is the software allowing for setting and updating GRS, resetting GSt as well as gathering and providing usage statistics that may be of use to the management of an organization implementing the gamification.
Figure 1 illustrates how the components described above are inter-connected.Detailed information about the character of the interactions performed over these connections is provided in Table 1.
Information 2018, 9, x FOR PEER REVIEW 4 of 13

•
Gamified system (GS), that is the environment to which gamification is applied to enriched with: o Event processing layer (EPL) responsible for identifying those events (typically resulting from users' activities) happening in GS that are relevant to gamification and passing their description to GRPS (see below); o Gamification presentation layer (GaPL) responsible for presenting the gamification-related feedback to users, using either an adapted original user interface of GS (so called in-band gamification) or through a separate user interface dedicated to gamification (so called outof-band gamification); • System of gamification rules (GRS), that is the rules defining game-inspired consequences of users' actions (i.e., gamification system in its narrow sense); • Game state (GSt), that is the description of the current state of gamification-related indicators (e.g., points, badges and items collected by specific users); • Game state maintenance subsystem (GSMS), that is the software that provides access to GSt and updates it ensuring its consistency (it may also trigger gamification rules which are statedependent); • Gamification rule processing system (GRPS), that is the software interpreting gamification rules of GRS in the context of GSt (accessed via GSMS) using data received from EPL of GS as input and passing the results of applied rules to GSMS and GaPL of GS (see below); • Gamification management system (GMS), which is the software allowing for setting and updating GRS, resetting GSt as well as gathering and providing usage statistics that may be of use to the management of an organization implementing the gamification.
Figure 1 illustrates how the components described above are inter-connected.Detailed information about the character of the interactions performed over these connections is provided in Table 1.

Specific Traits of Gamification of Tourist Attraction E-Guides
The research conducted as part of a work on an e-guide gamification system for an international consortium of tourist attractions [17] resulted in the following key observations regarding the expected usage conditions of such a system:

•
tourist attractions usually have staff that is competent in designing tourist routes but not in IT; such staff can therefore be expected to become involved in designing game-based rules but rather not in the development of e-guide apps; hence the need for independence of GRS and the remaining, more IT-oriented systems and the availability of GMS providing an easy way of viewing and editing the rules; • routes are updated depending on the change of exhibits, whereas e-guide apps are updated depending on the change of mobile technology standards; the life cycles of the two are therefore not synchronized: a tourist attraction may want to replace an app while keeping the route description and related gamification data or to update the route description without changing an app; • the tourist attraction may want to use different sets of gamification rules, for example, one for the tourist attraction as a whole and another for distinct tourist routes; it should be therefore possible to change one without affecting the other ones; • on the other hand, several tourist attractions may collaborate to develop a shared set of game-based rules which will be adapted by all of them; again, it should be possible to change it without affecting the other ones; • the tourist attraction management may be interested in keeping a registry of tourists' activity within the gamified system for the sake of securing against frauds (especially if real-world rewards are envisaged) or just statistical analysis of tourists' behaviour as a source of inspiration for possible future improvements of tourist routes or gamification rules; this can only be done with transmission of data from an e-guide app to the server; • the tourist attractions may include locations of limited connectivity, hence the access to web-services and online databases cannot be guaranteed for all the time; • the number of visitors coming every year to a single tourist attraction may be in the scale of several hundred thousand; while obviously not all of them will use the e-guides, the system should be highly scalable to remain operational in the high season.
Comparing the rented-device model to the bring-your-own-device model (with downloadable apps and content), the following advantages of the gamification of the latter were found, stemming from the fact that the device stays with the visitor after the visit:

•
the contact with the visitor is sustained after the visit, allowing to refresh the tourist's memories from the visit, invite him or her for another visit, especially after changes to exhibitions, or tease him or her with notifications about records they made being broken, • the visitors themselves can refresh the experiences of their visit any time later, by checking their achievements with their own device, • the returning visitor can be automatically recognized, so his or her experience may continue to the next visit, with challenges open from one visit completed in another and points and badges being accumulated across various attractions possibly for years.
As for the disadvantages, an Internet connection is needed to install (only in the case of native mobile apps) and use (especially in the case of web apps) e-guides on the visitor's mobile device.These can be somewhat reduced by providing free Internet access in the tourist attraction premises, still it is sometimes technically infeasible to ensure the wireless network is accessible from every location on the covered tourist route and some visitors may be reluctant to connect to such a free Internet network due to their security concerns.

Mapping Gamification System Components to E-Guide Gamification Domain
As an e-guide gamification system is a specialization of a gamification system, it features all its components.Table 2 maps the gamification system components as defined in Section 2 to the components of an e-guide gamification system, giving also a hint for their placement (on the mobile device used by a visitor or on a remote server that the device has to be connected to).

Possible Alternatives for the Location of Certain E-Guide Gamification System Components
As presented in Table 2, there are four e-guide gamification system components that can be placed on both client (the mobile device used by a visitor) and server side (e.g., provided as a web service): GRPS, GRS, GSt and GSMS. Figure 2 presents four basic e-guide gamification system organizations depending on the placement of these components.Note that the organizations presented in Figure 2 are the basic ones and more sophisticated solutions are also possible, such as: • separation of GRS and GRPS (i.e., the rules are stored on a server but processed on a client or vice versa), • separation of GSt and GSMS (i.e., the game state is stored on a server but its control code is on a client or vice versa), • mirroring of GRS/GRPS and GSt/GSMS (i.e., two game states are maintained: local and global and synchronized when connection is available), • distribution of GRS/GRPS and/or GSt/GSMS (i.e., some of the rules are stored and processed client-side and the remaining ones server-side and/or part of the game state is stored and updated client-side and the other server-side).
Although such more sophisticated solutions may be useful in certain environments (in which constraints on computing power, storage volume or network bandwidth become an issue), one of the primary organizations presented in Figure 2 should be sufficient for most cases in practice.
In Table 3, we compare the advantages and disadvantages of the four primary organizations of e-guide gamification system.Note that the organizations presented in Figure 2 are the basic ones and more sophisticated solutions are also possible, such as:

•
separation of GRS and GRPS (i.e., the rules are stored on a server but processed on a client or vice versa), • separation of GSt and GSMS (i.e., the game state is stored on a server but its control code is on a client or vice versa), • mirroring of GRS/GRPS and GSt/GSMS (i.e., two game states are maintained: local and global and synchronized when connection is available), • distribution of GRS/GRPS and/or GSt/GSMS (i.e., some of the rules are stored and processed client-side and the remaining ones server-side and/or part of the game state is stored and updated client-side and the other server-side).
Although such more sophisticated solutions may be useful in certain environments (in which constraints on computing power, storage volume or network bandwidth become an issue), one of the primary organizations presented in Figure 2 should be sufficient for most cases in practice.
In Table 3, we compare the advantages and disadvantages of the four primary organizations of e-guide gamification system.

Dispersed E-Guide Gamification System
Dispersion is not a novel idea in the area of gamification systems for mobile devices: the most notable examples of its application are the dispersion of rule execution in the client-side rule processing model (each user's device processes only the gamification rules applicable to that user) and the dispersion of game state in the client-side state maintenance model (each user's device maintains only that user's game state).
In this section, however, we want to show how to apply it in a novel way, based on server-side state and rule processing model and cloud computing, to address the needs specific for tourist attraction gamification.

Basic Properties of the Dispersed E-Guide Gamification System Architecture
There are three basic ideas behind the proposed gamification system architecture.The first one is that every system component except GS is implemented as a web service available in the cloud.Note, though, the special cases of GSt and GRS.Both can be considered to be data sets: a list of attributes that define the game state in the case of GSt and a list of rule definitions specified in a general-purpose or domain-specific language (see [26] for an example of such a specialized language) in the case of GRS.As such, they could be made available in whole as web resources, however a much more convenient and secure solution is to provide an access to their respective elements via a web service offering four basic types of operation (create/read/update/delete).For instance, the cloud-based service for gamification of e-guides developed for the purposes of the BalticMuseums: Love IT! Project [17] implements a RESTful web service [27] (sections III.C, III.E and IV) for these purposes.
The second idea is that there can be (and usually there will be) more than one web service of each type, each handling a different scope of gamification (hence the dispersion).In order to understand why it brings an important advantage to e-guide gamification systems, we have to reconsider two of the needs of tourist attractions presented in Section 3.1, that is: • a single tourist attraction may want to use different sets of gamification rules, for example, one for the tourist attraction as a whole and another for distinct tourist routes; • several collaborating tourist attractions may want to use a shared set of gamification rules in addition to those defined at the level of respective attractions.
It therefore makes sense to connect a single instance of GS to multiple web services of which a dispersed GRS is composed, each of them defining a different scope of gamification rules (e.g., those defined at a level of a specific route, a visitor type, an attraction or a chain of attractions).Extending this example, a specific instance of GRS web service could be matched with a specific instance of GSt (maintaining the state of game with regard to the specific scope of gamification rules).
There are other reasons for making the remaining gamification system components dispersed.As for GRPS and GSMS, the goal is to ensure high responsiveness of e-guides by providing these web services on servers of adequate performance and with high-speed connection to the specific tourist attractions' networks.It is therefore reasonable for tourist attractions in a certain area to use a specific service provider that meets such criteria.Finally, GMS can be dispersed not only for both the reasons given above (it could make sense both to manage a specific scope of gamification separately from the others and to use a provider ensuring its high-speed connection to GSt and GRS) but also for other reason (e.g., different GMS instances may have different user interfaces).
The third idea is that the web services are cross-compatible and independent of each other.Therefore, any GS can be connected to any GRPS or GSMS, any GRPS can process rules of any GRS, any GSMS can maintain any GSt and any GMS can be used to manage any GRS or GSt.In practice, it means that, for example, a single GMS service instance can be used to edit rules of several GRS instances and each of these could be executed on several GRPS instances.For an example of such inter-connections, see Figure 3, in which two GMS are used to manage four GRS employing two GRPS and applied to six GS.

Validation of the Architecture Meeting Needs Specific to E-Guide Gamification Systems
In this section, the proposed architecture is checked with regard to meeting the needs specific to e-guide gamification systems as presented in Section 3.1.
As can be seen from Table 4, three of the needs (GMS available for easy editing of rules by non-IT professionals, GRS separated from technical components, server-side processing of rules and maintaining of game state as a protection against frauds) are principles of the proposed architecture, that is, any system adhering to it has to meet them as well.Permitted by the architecture As described in the previous section, the proposed architecture allows for using various gamification rulesets in a single tourist attraction as well as using a single ruleset by more than one tourist attraction.The proposed architecture also allows for highly scalable systems, both in terms of scaling-up (replacing a specific web service provider with another one, offering better performance) and scaling-out (dividing a specific job among several web service providers).
The only need that is not addressed is the processing of rules and maintaining game state without network connection.In fact, the approach based on web services makes it difficult to fulfil such a requirement.However, there are at least two possible workarounds.In the case of short offline periods, event buffering (handled by EPL of GS) can be a sufficient solution as its only drawback is delayed feedback, because the user-generated events are only processed when the connection is restored.For longer off-line periods, additional client-side mirroring of GRS/GRPS and GSt/GSMS is an appropriate solution.Its main drawback is the desynchronization of the global game state and the local one, which can only be resynchronized after the connection is restored and the buffered events can be processed by a relevant web service.If the period of desynchronization is very long, the remote GRS can be meanwhile modified, making the new global game state different to the local one.

Practical Verification of the Architecture
The proof of concept for the architecture is provided by the cloud-based service for gamification of e-guides [27], which uses the event and rule definition scheme described in work [26].While the developed system has successfully passed various types of tests in different simulated environments, the real-world verification will start after the e-guides which are currently being developed within

Validation of the Architecture Meeting Needs Specific to E-Guide Gamification Systems
In this section, the proposed architecture is checked with regard to meeting the needs specific to e-guide gamification systems as presented in Section 3.1.
As can be seen from Table 4, three of the needs (GMS available for easy editing of rules by non-IT professionals, GRS separated from technical components, server-side processing of rules and maintaining of game state as a protection against frauds) are principles of the proposed architecture, that is, any system adhering to it has to meet them as well.

Requirement Fulfilment
As described in the previous section, the proposed architecture allows for using various gamification rulesets in a single tourist attraction as well as using a single ruleset by more than one tourist attraction.The proposed architecture also allows for highly scalable systems, both in terms of scaling-up (replacing a specific web service provider with another one, offering better performance) and scaling-out (dividing a specific job among several web service providers).
The only need that is not addressed is the processing of rules and maintaining game state without network connection.In fact, the approach based on web services makes it difficult to fulfil such a requirement.However, there are at least two possible workarounds.In the case of short off-line periods, event buffering (handled by EPL of GS) can be a sufficient solution as its only drawback is delayed feedback, because the user-generated events are only processed when the connection is restored.For longer off-line periods, additional client-side mirroring of GRS/GRPS and GSt/GSMS is an appropriate solution.Its main drawback is the desynchronization of the global game state and the local one, which can only be resynchronized after the connection is restored and the buffered events can be processed by a relevant web service.If the period of desynchronization is very long, the remote GRS can be meanwhile modified, making the new global game state different to the local one.

Practical Verification of the Architecture
The proof of concept for the architecture is provided by the cloud-based service for gamification of e-guides [27], which uses the event and rule definition scheme described in work [26].While the developed system has successfully passed various types of tests in different simulated environments, the real-world verification will start after the e-guides which are currently being developed within the framework of the BalticMuseums: Love IT! Project [17] become published and accessible for the general public.

Discussion and Conclusions
Gamification is a useful tool for tourist attraction management for a number of purposes including enhancing tourist experiences and increasing their engagement [10].A convenient form of its practical implementation in tourist attractions is through the use of e-guides, which provide software and content for mobile devices to assist the visitors in their visiting process.The gamification of e-guides requires technological support meeting the requirements specific to this area (e.g., the need for gamification rules to be easily-editable and separated from the software as the tourist attraction personnel skilled in engaging visitors is not usually skilled in software development or the need for scalability, as the number of visitors is changing vastly across the seasons) including some peculiar ones (e.g., the need to concurrently use several gamification schemes defined for different scopes: route, attraction or a chain of attractions).
In this paper, we proposed an architecture aiming at addressing these needs.Our approach is based on identifying gamification system components responsible for the respective aspects of its functionality, each of which could be implemented as a separate web service, and, in turn, dispersed, depending on various practically-inspired criteria.
Due to insufficiency of the prior literature on this topic, we had to start with defining gamification system in its wide sense (extending beyond the set of game-based rules) and identifying its components.We described typical organizations of such systems, pointing to their advantages and disadvantages.Eventually, we defined the properties of the proposed new architecture and verified that it is capable of meeting the identified needs of tourist attractions.
The architecture has been proven to be implementable as a cloud-based e-guide gamification system [27] has been developed for the consortium of tourist attractions participating in the BalticMuseums: Love IT! Project [17].The limitations of the conducted research stem from the fact that, so far, the e-guides to be connected to the system are still at most at their prototype stage and were not presented to the general public, therefore, there is no data yet how the proposed solution fares in real-world conditions.Analysing such data is, however, an interesting research topic of its own and as such is intended as our future work.

Figure 1 .
Figure 1.Inter-connections between gamification system components and users.

Figure 1 .
Figure 1.Inter-connections between gamification system components and users.

Table 1 .
The character of interactions between gamification system components and users.

Table 2 .
The implementation of gamification system components in e-guide gamification system.

Table 3 .
Advantages and disadvantages of the primary e-guide gamification system organizations.

Table 4 .
Fulfilment of tourist attraction needs by the proposed architecture.

Table 4 .
Fulfilment of tourist attraction needs by the proposed architecture.