Jump to content
  • Advertisement
Sign in to follow this  
Micha? ?mia?ko

Achievements Engine Architecture

This topic is 549 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey! :)

I'm building achievements engine to my mobile app. It's not a game but it does gamyficate the sport. 

I'm wondering about its architecture. Achievements can be complicated- they can have multiple conditions, analyze big sets of data etc. Evaluating them on every event coming in would kill the performance. 
Plus, it would be great if they could work real time. 

I've found such article:
http://www.quilageo.com/…/Framework-for-Designing-Eval-1130…

 

I'm wondering if that's the right way. I would really appreciate your feedback and sharing your experience in that matter :-)

Share this post


Link to post
Share on other sites
Advertisement
The article posted by the OP does a pretty good job dissecting and explaining all the major elements of an achievements framework, but it's really only a conceptual overview. The devil is in the details, and unfortunately it doesn't go into much detail on possible implementations of their framework.
 
The issue is that a lot of achievement logic is very heavily coupled with game logic, and I can tell you from experience that most of the challenge is in designing a system that's reusable across multiple projects, supports the needs of achievements that can have very specific or arcane conditions and prerequisites (designers can be really creative), is data-driven enough to allow designers to tweak and iterate on relevant achievement parameters, and can integrate seamlessly with multiple 3rd party achievement back-ends (Steam, XBox Live, etc.), so those are good problems to think about first.
 
There's a lot of good advice in Spidi's blog post:
  • Have your game communicate indirectly with the achievements via events. This keeps your achievement code and your game code completely decoupled. Plus it's likely that these events can be reused and consumed by other gameplay systems.
  • Implement your own achievement persistence and tracking backend, and just publish to 3rd party platforms. Minimize the coupling with these platforms as much as possible so you don't unnecessarily limit yourself to only what services they provide.
  • Come up with simple yet flexible "formats" for expressing your achievements. The most basic formats are on/off, counters, and lists (i.e. complete levels A, B, and C under conditions X and Y). Remember that at the end of the day, achievements are observed and consumed by the end-user, so that puts a practical constraint on the formats.
As for describing the achievements themselves in data, in the past I used an approach similar to Spidi's in which I created a descriptor "language" for achievements, typically in XML. I found it to work pretty well in most cases, but there's a limit to how complicated you can make such a descriptor language before it becomes unwieldy and difficult to use, which in turn limits what your achievement logic can handle. Plus there always ends up being a handful of "must have" achievements that aren't easily expressed as data, so you end up writing one-off, special-case tags and code anyway to handle the really complicated cases. It's the classic problem of encoding logic as data.
 
If I ever had to write another achievement system, I'd probably forgo trying to design a framework for describing logic and instead do everything in script. Have one script per achievement, and provide it with interfaces for subscribing to game events, querying game state, setting its achievement state (using one of the aforementioned formats), and persisting its relevant data. That way, the script can do whatever it needs to do in order to implement the achievement functionality, without having to (or being unable to) pigeonhole itself into some rigid descriptive framework. The technical designers would probably have a field day with it too :)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!