Achievement System

I'm no game developer but I've played my fair share of video games.
From Zack McKraken to The Witcher 2, the best innovation that added significant value to gaming experience was achievements.
Back then (way back), we just played games and that was it. Now we see what we've accomplished within a game and we can brag about it or go back to accomplish more.

For HotelConfidential.com, we wanted to provide some gaming experience to shooting videos of hotels.

Anatomy of an Achievement

Actions

Activity from a player. For example, login, share, upload, killed zombie, etc.
Those can be defined for an achievement to dictate what activity the player needs to perform to complete an achievement. Some actions might also carry points.

Points

A unit that is appointed to players when an action is performed, or an achievement is completed.
This is the basis for any leaderboard but it can be also use for levels.

Levels

Unit or label associated to the player usually based on points. For example, level 10 (unit), or "Captain" (label),  or "Rookie" (label).

Achievements

An accomplishment from the player. Usually composed of actions, it could also be based on the state of a player (e.g. number of zombies killed, number of rare items collected, number of steps, etc.)
Achievements can also have the following attributes.

Badge

This is the pictorial representation of the achievement. Usually in 2 flavors (locked usually in grey scale and unlocked in full color), it is displayed for the player and everyone to see (aka the "pieces of flair" in Office Space).

Multipliers

Certain achievements can be completed multiple times. A multiplier is usually shows graphically (e.g. "x2") and associated to points (e.g. an achievement of 100 points, with multiplier 3 is worth 300 points).
Foursquare uses those when someone checks in multiple times to the same place or type of places.

Campaigns

Achievements can be organized by campaigns. A campaign could be a special limited (in time) event, or a theme. Campaigns are rare in traditional video games but more frequent in online ones.

Anatomy of an Achievement System

The following diagram[2] depicts the architecture of an Achievement System:

Fig. 1. Achievement System (AS)

The idea is that, based on the state of the game for a given player, the Achievement System (AS) will determine if anything has been accomplished (achievement-wise not game-wise).
For the AS needs information in order to detect achievements, namely:

• action(s) performed by player counting towards achievements (called "achievement action(s)")
• definition of those achievements
• optionally some statistics and/or counters related to the player and her activities (like number of saves made, number of potions taken ,etc.)

What result is the progress or completion of achievement for the player. Based on those results, the player might see a new badge on his profile and a new place in the leaderboard.

For HotelConfidential.com, we came up with a slightly different architecture.

Fig. 2. Action-based Achievement System (AAS)

This is an Action-based Achievement System (AAS), which, as its name implies, is more action based than the previous one. In the previous system, the client would submit the game state to the system which would trigger the whole achievement detection process starting by figuring out actions done by player ("Action Detection" in Fig. 1).
Here in AAS, the detection of action is done on the client side and thus the client submits actions done by the player directly to AAS. The game state could still be passed along with the achievement action and have the system take this state into account for the completion of actions, but the idea is that there is no action detection in an AAS.

In the case of an Achievement System as a Service this architecture makes sense: the client is already a product where interaction (i.e. action+feedback) with its users is already happening. and thus the detection of actions is intrinsic. Therefore, the client can setup achievements and actions in AAS and send player actions to the system to trigger achievement detection.

Action State

Some action can be repeated and certain might need a little more logic beyond the action itself.
One of the rules at HotelConfidential.com is that, a hotel review is considered as such only when at least 4 videos have been uploaded (and encoded). When our client submits the "_review" action, it will pass the number of videos available to watch for that review. It's pretty much a tiny version of Game State, but restricted to that action. Rules defined in the system will then decide if that action will count towards any achievement.

Another advanced feature is the ability to track certain state without counting repeats.
Every time a user uploads a video on HotelConfidential.com, an action is sent to AAS. It's that same action mentioned earlier: "_review", along with the number of videos available this far. So for the same review, if the user uploads 4 videos, 4 different actions will be sent to the AAS (each with a video count different, but the same action name of "_review").
With this advanced feature, we can keep track of that review when it reaches 4 videos for example, and skip it from that point on.
The alternative would have been to send the Game State for the player: some summary saying player has 1 review with 2 videos, 2 reviews with 3 videos, etc. But again, this system is action-based, not game-state based.

Considerations

Scalability & Distribution

In AAS, actions the player completed towards an achievement need to be persisted.
With 1,000,000 players and 100 actions across all achievements, the worse case scenario is 100,000,000 player achievement action records to be persisted.

The client will submit actions regardless whether all achievements this action is associated with are already completed. Those don't need to be persisted though so we can save space and ignore "replays".

Each action may not be independent of another here.
First, if the AS enforces an order on actions (say for a Konami-code type of achievement), order will need to be respected in a distributed environment.
Second, care must be taken to avoid lost update problem. If a client submits 2 actions for the same player, one after another, and 2 different agents process each an action, any update to player achievements might be lost for one of the 2 agents.

Logs and Audit

For audit and troubleshooting purposes, it's a good idea to persist every single player action, for a certain period of time. Those logs could be "cold" and be processed only on an on-demand/case-by-case basis later on.

References

[1] Achievement Systems Explained, Luca Galli, Oct. 5th 2012
[2] Framework for designing and evaluating achievements, J. Hamari & V. Eranti, Feb. 10th 2011