Gamified Education Interoperability Language (GEdIL) is a modeling language for gamification in educational contexts, that can be serialized as JSON. It describes gamification layers in a way that they can be built using a simple multistep form, without any programming knowledge. GEdIL sets up in the assumption that its primary consumer is a Gamification Engine, which uses it as an itinerary to update the state when an event occurs or an action is performed. The only requirement that the state must meet, according to GEdIL, is to include information on the state of (1) the environment and (2) each player.
GEdIL was initially designed to fulfil specific requirements of gamification applied in programming courses [15
]. These requirements identify a vast collection of rewarding mechanisms such as points, badges, virtual items, and social status (e.g., through leaderboards), to provide extrinsic motivation, but can also affect the educational content directly through unlockable and secret content, different activity modes (e.g., speedup and duels), among others. Nonetheless, GEdIL completely separates the gamification layer from the activities being gamified, which makes it sufficiently generic to be applied to any other educational subjects, provided that activities have a unique ID.
The next subsections detail the structure of GEdIL with an example use case.
GEdIL defines a hierarchy of Challenges rooted by a Gamification Layer, in which both elements can hold Rewards, Rules, and Leaderboards. The vertical position of an element in the hierarchy determines its scope, as elements closer to the root may be accessed in lower levels, but not the other way around. For instance, leaderboards attached to the gamification layer are global and consider every challenge, whereas a leaderboard within a challenge only uses data of that same challenge and its branches. Figure 1
presents the data model encoded in GEdIL.
The Gamification Layer holds the metadata for identifying the layer, in particular, the Universally Unique Identifier (UUID) [16
] of the layer (id
), the name
of the layer, a description
of the layer purpose and contents, the set of keywords
that best categorizes the layer, and the status
of the layer (possible values are DRAFT
); as well as pointers to global rewards, rules, leaderboards, and the first-level of challenges. Despite the fact that it does not encode any logic and, thus, it is not relevant for gamification (i.e., could be replaced with a top-level challenge), the proper identification of the layers is the key to ensure their reusability and possibility of replacement.
Challenges are the core of GEdIL. They “wrap” one or more non-gamified activities with a gamification envelope, which allows locking, hiding, and/or leveling-up the summon to solve it (e.g., by using mode and mode_parameters the activity could be limited to a certain timeframe). In fact, challenges are activities themselves, distinct from the original, with a name, a description of the goals, a difficulty level (BEGINNER, EASY, AVERAGE, HARD, or MASTER), and, possibly, feedback on completion (provided through an executable script in feedback_generators). Furthermore, challenges also serve the purpose of organizing the content as they can be chained, not only providing the student with some structure to follow but also enabling the composition of more complex gamification mechanisms, such as quests, stories, or duels.
With regard to the multiplication tables domain, a possible gamification layer meeting the requirements could include three challenges connected to the root: C1—which wraps all activities with prefix A2; C2—which wraps A9.9; and C3—which is initially locked and wraps all activities with prefix A10. In this way, the only missing stem to cover RQ2 is to attach a Reward to challenge C1 of kind BADGE (other possible values are POINT, VIRTUAL_ITEM, COUPON, REVEAL, UNLOCK, HINT, and MESSAGE), with a suggestive name and description. As the badge is directly linked to the challenge, it should be delivered on its completion without the need for any additional criteria. The same applies for RQ4, as a reward of kind UNLOCK linking to challenge C3, through property unlockables, can be a child node of challenge C2. Then, when and if a student solves C2, he/she will unlock C3.
However, satisfying RQ1 is not so straightforward as it must be triggered on the completion of any activity, to reward the student. A possible approach is to wrap each activity in a challenge with a reward of type POINT, which would produce a heavy layer. Yet, GEdIL offers a fairly better strategy to accomplish this by using a Rule. Rules are triggered based on events or user actions, and they will modify the state with the value of an action attribute if their criteria are met. An action of a rule is a verb (e.g., GIVE, TAKE, or UPDATE) followed by any number of parameters. The criteria, which can also be used in rewards, is a list of conditions connected with junctors (AND and OR), where each condition has: a left_entity/right_entity—the type of entity holding the property to test, which is either ENVIRONMENT (i.e., current state of the environment), PLAYER (i.e., current state of the player related to the trigger), ACTION (i.e., the action performed by the student, if this check results of an action), EVENT (i.e., the event object, when activated in response to an internal state change or at a given time), or FIXED (i.e., a constant); a left_property/right_property—a reference to the property to test (e.g., using JSONPath); and a comparing_function—the function to use while comparing both sides.
Hence, RQ1 can be accomplished with a rule that gives a reward of kind POINT and an amount of 1 when an event has the type of submission with an accepted result. As the specific names and paths of these properties (in this case, type and result) will invariably depend on the underlying Gamification Engine, GEdIL does not set any special constraints upon them.
Finally, GEdIL also “imports” a well-known gamification mechanics, the Leaderboard. A leaderboard consists of a list of metrics
and their respective sorting_orders
to rank the players. This component is a prerequisite to fulfilling the missing requirement of the toy domain, RQ3, which now comes down to attaching a leaderboard sorted in descending order by points. Figure 2
presents a diagram of the complete gamification layer built for the multiplication tables example, masking IDs, and ignoring some empty fields.