As the web-based user interface was designed to be used on any device, the interface had to be clean, easy to use and composed according to the rules of Responsive Design.
The interface consists of four elements: An area for the main content, a menu, a mood picture and a sidebar. On small screens the menu is displayed as a drop-down menu at the top of the site. If the screen-width extends, the menu will be placed on the left showing all entries at once. The mood picture is an image displayed at the top of the site, which is replaced dynamically depending on the content. Each site can specify its own picture to support the atmosphere of the narrative of the currently displayed content. If the screen size is big enough and the currently displayed page shows the content of a seminar, a sidebar will be displayed on the right to provide additional information about the character and its current progress.
The area of “seminars” is the entry point for a user after they got access to the platform. A seminar wraps up all following features, is completely independent from other courses and can provide any kind of learning content. Therefore it can be used to represent a wide range of courses e. g. a class at school, a course at a university or any other learning content. It is also possible to use a seminar repetitively by creating a copy and applying some changes.
To attend a seminar the users has to create a personal figure which is called “character”. This character will become their virtual representation and is bound to the context of the course. In terms of gamification the character accomplishes all actions, gets points, will be listed in rankings and so on. All information about a character is displayed on a profile page.
As explained later in this paper the user can choose between different character types which are defined by the seminar managers. Based on this type, an avatar will be created to visually represent the character.
To avoid interference with the virtual identity of the character, any personal information like the real name or the e-mail address are stripped from the character’s profile. This feature is important to give the users the possibility to identify themselves with their virtual representation inside the system.
Many game types also use groups of characters to add collaboration between group members and competition between different groups. Depending on the type of game these groups can be any kind of coalition. Common examples would be guilds or clans that stick together during the complete game, but also pick-up-groups or any kind of randomly joined groups can be found in gamified settings. This concept has been implemented in Questlab as well.
Character group quests
Furthermore, it is possible to create quests for character groups. They are meant to reflect quests that do not take place on the platform itself but in real-life classes. The character group quests therefore currently contain only static data: a description, some rules for the quest and a text for groups who have won the quest and those who have lost it.
It is also possible to add “stations” to a character group quest which is bound to a GPS-coordinate and can be accessed with a hidden URL. For this URL a QR-code can be created and scanned by people visiting the position at the defined coordinate.
Additionally a number of experience points (XP) can be specified as the maximum amount of points a group can obtain. If seminar moderators enter which groups have attended the quest, they can assign how many XP of the maximum possible value each group has earned. These XP are then added to the XP of each character that belongs to the group.
After creating a character, the user is able to accomplish quests of a seminar. Quests can be tasks like the ones that can be found in role-playing games or simple exercises like multiple choices items. They contain the learning content and are therefore the key element of a gamified system.
Each quest is assigned to a specific quest type and is part of a quest group. It is possible to create different branches by specifying multiple succeeding quests, which offers the possibility of decision points and parallel quest sequences for instance. An entry text is assigned to each quest that will be displayed as a label for these decision points. The branches are a great way to create non-linear narrative paths and give the user more control over the story. Regarding to Knautz, Göretz & Wintermeyer [21, p. 2] this is a key element of gamification.
Another very important aspect of games is storytelling. Plot and narrative create a context for a quest, connect them with one another and serve as an atmospheric element. For this purpose, every quest can have a prologue and an epilogue. The prologue can be viewed straight after entering the quest, guides the user towards the task and creates the appropriate context that is needed to understand and successfully solve the task. The epilogue will not be displayed until the task has been solved successfully.
The look and structure of a task is determined by the task type stated below. After the user has submitted a solution for a task, his submission is evaluated and feedback will be given. If the answer is wrong, the task has to be redone. If the user has given a right answer, positive feedback will be displayed along with the title and a link to the next quest or quest group, which provides a continuous game flow. If the task has been solved successfully, the (correct) answer will not be displayed when the user enters the quest again, unless a button is clicked. This ensures that the user can redo a task for learning purposes without immediately displaying the answer.
Additionally, the sidebar gives a link to the quest last entered by the user, to ensure that the user can enter at the right point of the game after leaving the platform.
The task of a quest is determined by its quest type. This type defines how the task content is displayed and how it has to be solved. In order to ensure the game to be interesting and maintain the game flow, it is of great importance to provide a wide range of different quest types.
Questlab currently provides eight quest types:
- The text entry type provides input fields the user has to fill out. The contents are evaluated against a regular expression that is attached to each input field and can be placed anywhere inside a text
- The second type, choice input, is very similar to the first one but provides drop-down lists instead of input fields. Multiple values can be deposited for each list from which the user has to select
- The third quest type is a common multiple choice item. For this type multiple questions with multiple answers are created
- Additionally, there are tasks of the type submit. This type only consists of an instruction and can be solved by submitting a PDF-document. This text then has to be evaluated by seminar moderators. If the moderators agree to the solution they can mark it as solved and unlock the user for the next quest. If they mark it as “incorrect”, they attach a comment and give the user the possibility to rework his or her answer and re- submit it. This can be done several times without technical limitation.
- The fifth type is called crossword and provides a crossword puzzle the user has to solve
- In contrast to the quest types explained so far, less text input is needed for the quest type drag&drop. To solve a drag&drop task the user has to drag graphical fields and drop them in the right area inside the graphic
- A very different type of task is represented by the type bossfight. For this type the user is confronted with a virtual opponent against whom he or she has to fight. In this scenario both rivals start with a certain amount of points. While answering questions by choosing one of multiple possible fight options, the user can reduce the boss’ amount of points, by choosing the right option, whereas choosing a wrong option will reduce the user’s points
- The last quest type does not really offer a task containing actual learning content, but provides the possibility to maintain the game flow.
To keep the system flexible and extensible, all types are organized in separate folders. Additionally, each quest type uses separate database tables prefixed by its name, which allows an independent development and gives each type a very flexible design without forcing a specific data structure.
However, any quest is always related to a greater structure by being part of a quest group. Quest groups are primarily organized hierarchically and can be used for different purposes. One way is to create a group related to a certain levels, with each quest inside this group representing a specific level, or to create a much more complex structures similar to those that can be found in role-playing games. A typical structure in these games would have acts at the top level, quest lines as second level and quests as a third level.
Another way to organize quest groups is not to attach them to the hierarchy but to attach them to a quest of another quest group, which makes them optional to pass. These optional quest groups are linked inside the prologue or epilogue of a quest of another quest group and can only be found by reading through the text. The user can continue to play even without solving the quests inside these quest groups. The reason behind this concept is to engage the user to solve tasks they don’t have to solve and to let the game appeal more interesting by not only providing a linear structure, but also explorable content. It is also a good way to provide additional learning material for users that are very interested in certain topics.
Since the quests are not meant to be done only once in order to merely completing the game, but rather to provide the option to study and repeat certain contents, topics can be assigned to each quest. Via a library the user can easily access quests already done and repeat the syllabus. The user receives feedback of how many quests have currently been solved for a topic via a progress bar. This will also tell the user how many quests are still to be discovered.
A central aspect of games and gamified systems is to provide a feedback of the user’s current progress. The progress is calculated based on points that can be earned at several opportunities stated below.
Experience Points (XP)
By solving quests the user earns experience points (XP). Since quests are organized in quest groups, the current progress is calculated and visualized with the help of a progress bar. The total amount of XP of a quest group is measured by its child quest groups, the quests attached to it and also the optional quest groups assigned to these quests.
Additionally to the XP collected from quests, the user can achieve XP via character group quests (guild quests). These points are cumulated to the total amount of the user’s XP. Since the XP are a very important game element, they are permanently displayed in the sidebar in addition to other character information.
Based on the amount of XP a seminar manager can define levels that mirror the actual experience of a character. Levels are implemented to engage the user to collect more XP, for instance by solving quests of optional quest lines, or to create avatars which are explained below.
A ranking of all characters of a seminar is created and visualized on the platform based upon the amount of earned XP. On a character’s profile page a user can view his or her current position in the ranking. The ranking is designed in a context-sensitive way and does not display more than two players with a higher status in the ranking avoid discrimination of lower ranked characters.
This game element does not only give an overview of the current progress but also motivates the user to continue the game and look for optional content to reach higher positions in the ranking.
The term “avatar” is used differently across various contexts. In Questlab it does not refer to the user’s character but shows a visual representation of their character and its progress, based on the experience level and the character type. The avatar evolves with the level of a character, creating an additional, visual feedback. The avatar can also be seen as reward: If the user earns XP and reaches higher levels, their avatar evolves and improves visually. The avatar is therefore also an additional way of comparing characters which promotes competition among the users of a seminar.
By solving quests, doing certain actions or triggering certain events on the platform, the user can obtain achievements, which are extra trophies besides regular experience points.
There are two types of achievements: On the one hand, there are achievements that are visible to the user. Their description is visible and the user will be informed how to obtain them. On the other hand, there are trophies that are listed with invisible names and descriptions that cannot be seen before achieving them, which motivates the user to look for optional content to explore.
Additionally, some achievements are unique, which means that they can only be achieved once by one character exclusively. These trophies therefore express very valuable rewards.
Furthermore, there is the possibility to assign a date to an achievement which turns it into a milestone. This date acts as a deadline so that the milestone can only be obtained before this date.
Achievements are created by assigning multiple conditions out of four condition types: First, a date and time can be set. The achievement will be awarded if the specified date and time apply. The second condition type is based on character properties. The creator can select a property from a drop-down list and can then assign a value that the property has to match. This can be used to award achievements for collected XP or for reaching a certain level. The third condition type specifies quest values. These values can be used to compare them to the current status of a character. It is also possible to aggregate quest values. A common example for an aggregation would be the amount of solved quests. The last type is the meta-achievement. This type is based on values of other achievements e. g. the total amount of already obtained achievements by a character.
If a user performs an action that fullfill all conditions of an achievement, they will be rewarded by obtaining this trophy. This will be communicated by displaying a notification at the bottom of the screen. The most recently obtained achievement will also be displayed in the sidebar.