I was having a discussion the other day with a PHP developer, helping him architect a gamification layer for a website he owned. He had this ridiculously broad table of everything the user could earn, and I winced and said, "What if you want to add a new badge?" He hemmed and hawed and allowed that might cause some difficulty. I then proceeded to walk him through the logic of using a meta-table for currencies-- the things you earn when gamifying. For example, in Stack Overflow, which I consider an examplary example of gamification, users earn reputation for certain acts, and they also earn badges for certain specific events-- your first post with 10 likes, or your first post you deleted even though other people liked it because you considered the answer wrong. Each of these is a currency: "a post," "a post with 10 likes," "an answer with 10 likes," "a deleted accepted answer."

I showed how one table of currencies, and another of user/currency/current_amount, was all he needed to track what a user was earning. He accepted that and said, "How do we track when a currency awarded?" We talked about the trade off of doing event-driven aspect-oriented programming versus interval analysis.  Currency awards are metadata derived from database events; you could do the full analysis from database logs with every event, but that would be expensive. We also talked about when badges and privileges were awarded, and how watching the user/currency/current_amount table was how that happened.

We hit a complication. It's apparently not unusual with PHP to store SQL, PHP, and DSLs in the database. He wanted to store the rules for awarding as a DSL. After a while, we agreed that this was a difficult issue. The badge awards were fairly easy: "when X > 10 award Y". It was the rules for awarding currency in the first place that he had trouble with.

Today, I hit upon the answer. First, you have to ask the right questions: "When is currency awarded to a user?" There are three answers: (1) When the user does something; (2) When the user does something for someone else; (3) When someone else does something to an object owned by the user. You get currency when you post; you get currency when you answer another question; you get currency when someone else likes your answer. It occurred to me the second I wrote those down that they looked very familiar.

They should: they're lifestream events. They're at the core of every "What your friends are doing!" display on every social network worth your attention.

Gamification is metadata about what you and your friends are doing on a social networking site. It uses exactly the same data and processing, and exactly the same analysis. All it does is add another layer, showing you and your friends the extent to which you participate on the site. A layer that might be computationally demanding. A layer this absolutely difficult to get right from a design point of view. But from the programmatic layer, is trivial for a modern application server such as Django, Rails, or Express.