OK Matt Beran, this post is for you…

So, as I mentioned in a previous, unfinished post (http://www.itilandme.com/?p=498), I’m working on building gamification into S***-**w.  In my original blog article, I wanted to go over more details as to exactly how we’re building our game, but then my smart-ass conscious got the better of me and I went into a rant about buzzwords.  Well, after some requests for finishing the blog (actually, it’s one request, but I want to be the first to write an authentic article on my topic, before it gets stolen), here’s the continuing saga of gamification in S***-**w.

For our first phase of gamification, we’re building a badge system. In S***-**w, this requires a few extra tables.  So, I created a new table to contain all the badge information (name, requirements to achieve, active, etc.).  But a table containing the badges isn’t enough.  There has to be some way to keep track of the scores.  So, there’s a second table listing each “player,” as well as their respective badges.  I affectionately called this the rewards table, but feel free to name it anything you want (I won’t be insulted…much).  Each one of the entries in the rewards table contains the information to track and increment each score for every badge in the system.  This means to build and maintain the table, there needs to be a some mechanism in S***-**w to allow new records to be written.  Alright, now we’re getting into rules!  So, we built a rule to keep track when a new badge is created, and then go through and creates a new entry for every player.  Consequently, there then needs to be a rule for when a new player gets “added” to the system, so I better touch on that for a minute.

In our instance of S***-**w, we have something like 20k+ users.  I don’t think we need to have all those people play our game (plus that’s a lot of entries for when a new badge gets added).  So, how do I want to limit the players?  Obviously, the game is designed for IT people, so we can limit it to the ITIL role.  But, what about tying this in to Social Media?  Here was my thought; if people join the Livefeed (S***-**w’s answer to Twitter), then they get to play.  So, there’s now a rule that watches for when a new user entry is created in the Livefeed, and then it goes through existing badges and creates the entries for the new player.

OK, so a couple of rules are in place.  But two are not enough to run this thing.  Originally I went with building a rule for every badge that would get entered into the game.  As you can imagine, this is a bit tedious.  I also won’t claim I’m a S***-**w guru (I’ve only been working on the platform for a few months, and if you haven’t already noticed, this blog has “ITIL” in the title, not “S***-**w”), so I needed a partner, specifically one that helps to bring things to Fruition and goes by the name of Jace.  With his help, we built a general rule against the task table that would take parameters from the badges, and then check for the conditions that would increment that badge.  Besides that general rule for the conditions, we also have a few global rule that actually runs the actions when a condition is met.  Those actions include incrementing the “count” field, checking if a badge has met the criteria to go up a level, and also posting the level increase in the Livefeed (we need to give people the ability to brag).  And by the way, yes, I know global rules can hit performance.  We’re going to look at using script includes down the road.

Tables, rules, what else do we need?  Oh yeah, I almost forgot – this thing needs to look relatively decent.  The final piece to the wonderful puzzle is just getting a user interface for the players.  In general, we can use the S***-**w platform with its already pre-built lists and record forms, but why not make things look cool? (Or as my colleague says, she wants it “sexy.”)  Once again, I’m still a newbie and I’ll be more than happy to admit when I need help.  But when someone helps, they also provide a Service, and once again, people are willing to do it Now.  So, we now have a very cool guy by the name of Tyler helping to make the UI page in Jelly (who uses Jelly anyway?  This is the first time I’ve heard of it, outside of a related peanut butter sandwich).  The first UI page is just to show the badges and allow users to see what else they can still achieve, but as we move along I’m sure that’ll evolve as well.

There you have it, a brief overview of what we’re doing to build gamification into S***-**w.  Is this a very easy project?  No.  Is it fun?  Yes, but we still have a few kinks to work out, and honestly, I’m worried about performance when this thing goes into production.  In the spirit of ITIL Continuous Service Improvement (there, I worked ITIL into this article so I don’t feel so bad focusing on a specific product), we’ll improve upon it as we go.  If anything, at least it’s helping to push a buzzword out of blog posts and into the real world.

And by the way, thanks to Chris Dancy for the best advice.  It went something along the lines of “just do it, be first, and improve upon it later.”  Who can really argue with that?

Michael

Started working in IT in 1999 as a support desk analyst as a way to help pay for food during college. Studied Electrical Engineering for two years before realizing biochemistry was more fun than differential equations, and so ultimately graduated with a Biology degree in 2006. Having (reluctantly) failed at getting accepted into dental school, embraced working in IT and has gone broke becoming an ITIL Expert. Likes to jog, sing camp songs, quote Mel Brooks movie lines and make dumb jokes and loves working for an Israeli tech company where December 25th is a regular work day.