views:

896

answers:

2

I'm attempting, poorly, to implement an achievement system into my Ruby on Rails application.

I have a long list of achievements I'd like to check for. All are triggered by some create action in various controllers.

I've had the idea that I'll have a achievement model, which includes the controller and action it responds to. Then do a before filter for the create and check for applicable achievements. I get stuck when it comes to actually defining/executing the achievements. Each achievement may require different data. For example one will want to know how many questions a user has answered, another how many comments they've made, and a third how many people the user invited have responded.

IS the best thing to do to actually just embed all the necessary ruby code straight into the DB? I could see doing a self contained block that does all the active record finding, etc and returns true/false, though there we are still some issues about knowing what is setup in advance (i.e. current_user, etc).

Any reasonable best practices out there that don't make me feel dirty? I could see a full on policy/rules engine being one path, though that may scare me more than plan a.

thanks! Oren

+11  A: 

I agree with your idea to use an Achievement model.

You should probably not implement the triggers in your controllers, though. Imagine that you have two ways to post a comment; you will inevitably get code duplication. This sort of behaviour belongs in a model.

Suppose you want to track the number of comments that a user makes, and award an achievement for 100 comments. You could have the following models:

class User < ActiveRecord::Base
  has_many :comments
  has_many :achievements

  def award(achievement)
    achievements << achievement.new
  end

  def awarded?(achievement)
    achievements.count(:conditions => { :type => achievement }) > 0
  end
end

class Achievement < ActiveRecord::Base
  belongs_to :user
end

class Comment < ActiveRecord::Base
  belongs_to :user
end

class CommentAchievement < Achievement
  def self.check_conditions_for(user)
    # Check if achievement is already awarded before doing possibly expensive
    # operations to see if the achievement conditions are met.
    if !user.awarded?(self) and user.comments.size > 100
      user.award(self)
    end
  end
end

The different achievements are all subclasses of Achievement model, and use single table inheritance so that they are stored in just one table. The subclasses can contain all logic required for each individual achievement. You can also store additional information in this model, such as the date on which the achievement was awarded. To make sure that the database rejects duplicate achievements, you could create a UNIQUE index on the type column.

CommentAchievement.check_conditions_for(user) can be called whenever you wish to. You may create a background job that runs every now and then, or you could create an observer:

# app/models/comment_achievement_observer.rb
class CommentAchievementObserver < ActiveRecord::Observer
  observe :comment

  def after_create(comment)
    CommentAchievement.check_conditions_for(comment.user)
  end
end

# config/environment.rb
config.active_record.observers = :comment_achievement_observer

The above is just one idea of how to do it, of course there may be others. The code is just an example, I haven't actually tested it. Hopefully it's of some help to you.

molf
I was thinking of something different, and possibly stupid. I'd prefer not to have to push new code for every achievement, so I was designing it so that the achievements are stored in the DB. I would then query the achievement for applicable records (by action and controller) and iterate through some "logic" for each of the found results. The trick is, this is a lot of 'eval'ing, which feels dirty.
teich
Eval is also a huge security risk. Imagine if someone managed to enter data into your achievements table, they might add an achievement which had the following logic: 'system("rm -rf /")' ;-)Perhaps you can translate the logic to some predefined set of options? For example, make an achievement types table that contains the name of an association on the User model, and a field that indicates the amount when it is triggered. In this way you still have some flexibility without storing application code in your database.
molf
Sleeping on it, and I realize that anything in the DB is probably a dumb idea - it makes it impossible to test reasonably. Thanks for the pointer!
teich
+6  A: 

Really nice solution, molf.

I rolled this in to a plugin / gem with generators for new achievements:

http://github.com/paulca/paths_of_glory

Happy achieving!

paulca