[patio11]

Integrate this with a selection of a few dozen no-programming-required badge templates and a badge/achievement designer, though, and you could have something.

Example: there should be a quick fire-and-forget Javascript method to increment a per-user arbitrarily named variable that you keep track of, and then when you exceed some threshold of that, you get a badge. That allows you to use one system to support everything from "Slay 100,000 orcs" to "Print out 75 bingo cards", with negligible work from your API consumers. The fact that it is negligible work creates value whereas your base offering (show that you've slain 100,000 orcs on your teaching bingo site profile! Booyah!) does not.

Other easy things to measure are stickiness (time since registration), collecting all of a set of API calls, etc (For example, in the hosted badge designer, you could say "A Dragonslayer is anyone who submits any [dropdown: two] of the following events: killed-red-dragon, kill-blue-dragon, and kill-green-dragon. Then customer site only has to fire killed-#{monster.name} as appropriate, and boom, dragonslayers.)

[vyrotek]

I must admit, this type of thing as you and dflock have described has always been in the back of my mind. I kept tell the thoughts to go away because thats a pretty big undertaking. Fortunately, I actually have experience building customer facing rule engines.

This is dangerously tempting to work on. Should I go for it? Perhaps I would need to provide both methods of awarding badges. I dont see StackOverflow.com wanting to re-implement their badge system rules in the KaBadge system.