-
Notifications
You must be signed in to change notification settings - Fork 11
Game model
Each game model consists of a set of elements, such as:
- game actions,
- game concepts,
- rules,
- levels (optional),
- leaderboards (optional).
During the game execution, the game state is being populated and maintained. The game state is represented with the state of its individual players, namely user state, such as current user scores, badges earned, challenge status, etc.
The game is a container of other elements and is defined with the following set of attributes:
- id: automatically assigned from system. It uniquely identifies the game within the engine instance. The game ID is important for relating the actions to the game state during the execution,
- name: the game name,
- owner: the user owner of the game. This is the ID of the game manager, and is relevant for the multi-tenant execution environment,
- game model: the set of concept instances used by this specific game (different types of points, badges, rules, classifications, etc),
- settings: a set of configurations to customize game functionalities.
The game actions represent the game-specific events that triggers changes in the game state. The game actions may be external and internal. The external actions correspond to the user actions (when triggered, e.g., through a mobile app), while the internal ones correspond to the system triggers (e.g., timers to recalculate periodic user leaderboards). Each action may carry some data with it (aka InputData).
The game concepts represent elements like scores, badges and challenge models. Each game may define its own set of scores (green points, community points, etc.), as well as badge collections. Participating to the game (through the actions), the user can earn points (i.e., her state changes), gain badges and win personal or couple challenges.
The rules defined the mechanics of a game and the challenge validation. In details they defines how the state of the users changes in reaction to some actions. Rules follow the “event-condition-action” paradigm, where event corresponds to the game action triggering the rule, condition represent the situation around the current user state and the action payload, and the action defines how the state should evolve (e.g., scores that are added, badge that is earned, and the notification is sent).
Currently gamification-engine are based on
Currently, the Drools Rule (http://www.drools.org/) language is used for specifying the game rules. Engine is based on JBoss Drools 6.5
It’s possible to define a set of levels in the game.
It’s possible to define a set of leadearboards in the game.
Every leaderboard is bound to a PointConcept defined in the game.
It’s possible to generate an internal action for a leaderboard and provide a name for trigger the right rules in the ruleset ( example: a weekly leaderboard can trigger an engine action to assign the leaderboard badges for the N players on the top)
The leaderboards can be:
- general, bound to the total score of the relative
PointConcept, - incremental, bound to a particular period of the relative
PointConcept.
Available configurations:
- Game expiration: it’s possible to define a deadline for the game.
- Challenge visibility: it’s possible to define a disclosure date for challenges assigned as hidden.
Every time a change occur in the score of selected 'PointConcept', it will be notified on event bus.
- NotifyPCName: holds the value of selected 'PointConcept'to be notified