There is no consensus about how to name the set of components and features from vid- eo games that can be used in non-game contexts. It is common to find terms like “game mechanics“, “game dynamics“, “game techniques“, “game attributes“ or “game meta- phors“ [Sim 12b]. For the purpose of this paper the term “game elements“ was chosen. It includes the common designation, widely used, of “game mechanics”.
Among these game elements, some are used to inform players about their perfor- mance and progress in the game, other elements are to reward players; some elements have to do with the dynamics of the game and the progression of the players (gameplay mechanics). In our proposal, game elements are associated with the core concepts identified in the previous section (Table 1). Feedback can be materialized through rewards; hence the core concept of feedback and rewards uses game elements like points, badges or progress bars.
Table 1: Core Concepts vs. Game Elements
CORE CONCEPTs GamE ELEmENTs
Flow & Fun Feedback & Rewards Points, progress bars, badges, trophies,
leader boards
Friends Sharing, inviting friends, give/trade/ask for
virtual goods, leader boards (social graph)
Gameplay Levels, intermediate goals, clear objectives, fun
failure, rules, virtual economy, reward schedule
The concept of friends can be implemented by using features to engage with other players, make new friends or share and give virtual goods. A leader board, common- ly associated with competition, can be used to foster the power of socialisation to change behaviour [Zic 11]. Like in many social games, leader boards can also be used to visualise the players’ social graph.
The gameplay concept includes the game dynamics that represent the players’ pro- gress. Elements like clear objectives, intermediate goals, levels, a reward schedule
JorgeSimões,RebecaRedondo,AnaVilas,AdemarAguiar
is included in this core concept. The reward schedule defines the frequency and the conditions for their assignment. The virtual economy sets the rules for the transaction of virtual goods in the systems’ context. Fun failure is the possibility of repetition after failure without this being regarded as negative but rather making it fun, inducing in the player a sense of control.
The transversal components of flow and fun are achieved through the way that gam- ified activities are set in the system. [Zic 13] points out that mastery and progress are what makes gamified experiences fun. The sense of mastery and progress can be im- plemented through elements in the gameplay, friends and feedback and reward con- cepts. The same goes for flow. The player can be kept in a flow channel when or he or she is optimally challenged by tasks that are neither too easy nor too hard [Csi 00]. This could be achieved by providing immediate feedback, intermediate goals and different levels of progression. In this way the challenge is balanced with the players’ skills.
architecture
Some existing proposals address the issue of defining the structure of gamified appli- cations. The SAP Gamification Platform [Her 13], expected to be released in the second half of 2013, is a platform for enterprise software that highlights building blocks for any gamified application. It includes modules like “Player Management”, “Achievements”, “Analytics”, “Rules of Game” and “Rule Optimizer”. The platform can be integrated with an application in a non-game context, adding game elements. Events in the non-game application are sent to the platform and through the “Analytics” and “Rules of Game” modules, the achievements are sent back to the application. [Kol n.d.], calls what is considered in this paper as a gamified system a “gamification platform” and describes the building blocks for this kind of application: “Connectors”, “Tracking Engine”, “Re- wards Engine”, “Gaming Engine”, “Reputation Engine” and “Analytics Engine”.
Both proposals highlight the components necessary for a gamified system, but a more formal description of an architecture, from a software engineering perspective, is needed. This paper proposes an architecture based on six main building blocks (Fig- ure 1), represented as UML packages.
Figure 1: Architecture for a Gamified Application: Main Components
This architecture is a typical three-tier model for a software architecture (Figure 2) with a presentation tier (users’ interface), a logic tier (system’s logic) and a data tier (data interface). In the data tier, the block identified as “Activity Manager” gets data from a source outside of the system or from the players’ activities while the “Connections Manager” manages the links with external applications, for example, by publishing the players’ achievements in a social network.
Figure 2: A Three-tier Architectural Model for a Gamified Application
JorgeSimões,RebecaRedondo,AnaVilas,AdemarAguiar
analytics Engine
The way players get feedback for their action is crucial. By tracking certain variables related to players’ actions, a gamified system can find patterns, trends and correla- tions and be able to provide immediate and accurate feedback in a fun and engaging way. Data analytics play an important part in gamified systems, therefore an analytics engine must be part of these systems. Analytics are the algorithms and data used to measure key performance indicators [Wer 12].
activity Manager
To feed the analytics engine, the system must also include an activity manager, a com- ponent able to monitor and read the data generated by users’ activities. The activ- ity manager can obtain data from a mediator, a human user or an external device if the non-game context is in the real world or directly from the players’ activities if the context is digital. To manage players’ activities, the gamified system can use one or more of the following four approaches to monitor and collect the data for the activity manager:
■ Automatically, by the system itself: the actions of the players on a website or web application are monitored by the system. The gamified system is the website or web application powered by generic gamification platforms. Examples include PunchTab or CaptainUp.
■ Using an external device: a smartphone or another device or gadget is used to keep track of what the player is doing in a non-digital context. The device syn- chronizes with a website to upload the data. The players take an active part in the process since they can control whether to use the system or not, what to track, what to share or what to achieve. The best known example is Nike+. Zamzee is a similar application targeting children in lower socio economic environments. ■ Relying on the players: In these systems, the players have full control over the
data collected. Data can only be uploaded by the players using an app in a smart- phone or logging into a website. The players are active players. Examples are EpicWin, an app for smartphones, and HabitRPG.
■ Relying on a special user: a human user monitors the players’ activities and is responsible for uploading the data. This user can also be a player with special privileges. Players are passive players because they cannot act upon what is being monitored. ClassDojo is an example of this approach where students are the players and teachers act as mediators. Other examples, targeting younger audiences are Chore Wars and HighScore House (motivating children and teens to do chores with parents as mediators).
Gamification Engine
A gamification engine should provide the game elements and the rules to establish the gameplay for the target activities. The gamification engine is closely related to
the activity manager and to the analytics engine. This engine establish the “Rules of Game” as in Herger’s proposal [Her 13] and is also related to the block called “Rule Optimizer”. It should include a toolbox for game elements, a virtual economy manager and a reward scheduler.
Player Profile
The “Player Profile” is a component for players to define their profile within the gam- ified system. It is the place to store the player’s achievements, using game elements (badges, points, trophies), to report feedback and where the player can set which out- side applications or social networks can be used to publish their personal gamification data.
dashboard
The “Dashboard” is designed to allow non-player users access the system. These users can be mediators between the software system and a non-digital context or can be some kind of system administrators. Other system stakeholders can also access the system through this interface. The dashboard is a component to evaluate the results and the behaviour change that the gamified activities are producing. It allows the gam- ification administrators to tune the system by changing and improving the rules and it displays the results according to Key Performance Indicators (KPI) defined for the activities.
Connections Manager
The “Connections Manager” is designed to establish links with the non-game context and to publish the players’ achievements, e. g. badges or trophies, in a social network or other similar applications. Gamified systems relying on external devices to keep track of what the player is doing need a connection with those devices. These devices must be synchronized, through some kind of physical connection, with a website to up- load the data. The data collection process may involve connections to external devices, and any gamified system outputting the players’ social graphs must have connections to social networks and other social applications.
Guide
This guide is intended to help a designer of a gamification scenario in a digital or non-digital context. It assumes that the designer has a gamified system built on the proposed architecture. The designer can then use the system as a tool. The gamifica- tion framework is therefore completed with this guide.
The designer should first be aware of what is to be gamified and what are the bene- fits in motivating people, the players, to change their behaviours.
What behaviours need to be changed and what are the appropriate activities that can make these change happen should be the first concern of the designer. The designer
JorgeSimões,RebecaRedondo,AnaVilas,AdemarAguiar
must also be aware of the context and the profile of the players. The decision to design a more competitive or more cooperative system must take into account who the players are (Table 2 – Non-game context characterization).
Table 2: Reference Guide to Apply Gamification
1. Non-game context
characterization 1.1. Context’s nature: digital or non-digital1.2. Identify target activities 1.3. Identify target behaviours
1.4. Players’ profiles characterization 2. Set the system’s
objectives 2.1. Define the goals in relation to the target behaviours2.2. Quantify the goals (KPIs)
3. Select game elements 3.1. Feedback and rewards
3.2. Social interaction (friends) 3.3. Gameplay
3.4. Flow and fun
4. Select meaningful data 4.1. Define the process to monitor and collect data
4.2. Define the actions to be monitored 4.3. Define the rules
4.4. Data analysis regarding systems’ objectives (2.2) 4.5. Select game elements for feedback
5. Evaluate results 5.1. Compare results with the objectives
5.2. Optimize rules if needed
The goals for the gamified system should then be set according to the target behaviour. These goals must be quantified with appropriate metrics (Table 2 – Set the system objectives). Game elements (Table 2 – Select game elements) should be chosen ac- cording to the core concepts of feedback and friends. How and when players should be rewarded is addressed at this stage. Players receive immediate feedback through rewards and other game elements. Then, they can adjust their actions in order to get closer to the goals. The gameplay set in the gamified context should implement these feedback loops. Feedback loops push users toward the target behaviours [Wer 12]. These loops have a central role in any gamified system: players perform actions and then they receive feedback. Feedback increases motivation and leads the players to further actions. The progression of the players through the activities should keep them in a flow channel (the activity should not be neither too easy nor too challenging), allow for repetition after failure and allow multiple courses of action. When players start their target activities, the system monitors their actions and collects relevant data according to the objectives that were set (Table 2 – Select meaningful data). Data is analysed and the actions of the players are evaluated against the goals (Table 2 – Evaluate results).