Architecture of badge system similar to StackExchange?

Question

I want to implement gamification in my education mobile application. I have a database with user activity and I want to analyze it and give badges to a user. There will be many badges with totally different conditions. Some badges will be given once, others repeatedly.

My current approach:

1. badges_awarded table that contains a badge, timestamp and string argument holding id of data that were used for this award
2. badges_evaluation table holding last invocation of each badge algorithm and date when it shall be executed again
3. when user finishes some game I run a script in background that will perform awarding rules. Evaluation table is used to skip some algorithms that have next run time in future.
4. if game produced some conditions that invalidates rules of some badges I will updated their next run time in badges_evaluation table (e.g. a badge that user makes no mistake 5 times in a row can start counting again when a user did mistake in the game).

This tactics reduces some evaluations and database queries. The game runs on a mobile device so I must reduce complexity as much as possible. I would like to read some tips and strategies. It is critical to design this feature efficiently.

Another approach represents Fitbit: upload data to server and receive badges back. But I prefer to award kid even when offline.

Badges example:

1. user played 3 consequitive days for silver and 7 days for gold badge
2. user made no error 10x, 25x or 100 times in a row (bronze, silver, gold)
3. user finished a game under X, Y or Z seconds (bronze, silver, gold)

Answer 1

Your approach will work, and is probably the most common way of achieving this. If you've benchmarked it and it's too slow, there is a more efficient way, but it's much harder to implement.

What you can do is to transform each rule into a finite state automaton with transitions when relevant events occur. For example, say you have a badge "complete both task A and task B within 1 hour". You might translate this to an FSA with the following state transitions:

state 0
  - if task A completed, go to 1
  - if task B competed, go to 2

State 1
  - if task B completed go to 3
  - if 1 hour elapsed, go to 0

State2
  - if task A completed go to 3
  - if 1 hour elapsed, go to 0

State 3
  - award badge

You can then maintain a list of active events that can cause a transition, and update the state when the event occurs, without needing any background task or database queries. The only problem with this is that each badge becomes much harder to implement. If you have a lot of them it might even be worth designing a simple DSL that compiles down to the appropriate transition lists.