Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


#ActualJTippetts

Posted 20 July 2013 - 06:14 PM

Typically, you want to remove your achievements from the actual guts of your game, since acheesements don't really have anything to do with your gameplay. They're just frosting. So your gameplay shouldn't ever be doing anything like "if (achievement criteria==true) then do achievement end" because it just doesn't belong in your gameplay code. Instead, your achievement system should "hook" into your gameplay code and observe things as they happen, siphoning off the events that it cares about. For example:

 

Every time an enemy is killed, the gameplay system will send some kind of "Enemy Killed" event. This event can be listened for by various subsystems in your game to handle the various things that should happen when an enemy is killed. One of the subsystems that might listen for this event would be the Statistics subsystem, which keeps a count of all enemies killed so that the player can know how awesome she is. Another subsystem listening for that event would be the Achievements subsystem, which would handle that event by passing it on to the various achievements who sign up to listen for it. One of these listening achievements would be the First Kill Achievement which would fire off its payload upon the receipt of an EnemyKilled event, then disable itself (to prevent subsequent events from repeating the payload). This way nothing has to actively poll to see if the achievement should fire, it happens instead by passively listening and you don't waste CPU time in a huge nest of if conditionals.

 

Of course, this does require that the heart of your gameplay system be event-based, but that's a pretty good idea anyway.


#1JTippetts

Posted 20 July 2013 - 06:14 PM

Typically, you want to unhook your achievements from the actual guts of your game, since acheesements don't really have anything to do with your gameplay. They're just frosting. So your gameplay shouldn't ever be doing anything like "if (achievement criteria==true) then do achievement end" because it just doesn't belong in your gameplay code. Instead, your achievement system should "hook" into your gameplay code and observe things as they happen, siphoning off the events that it cares about. For example:

 

Every time an enemy is killed, the gameplay system will send some kind of "Enemy Killed" event. This event can be listened for by various subsystems in your game to handle the various things that should happen when an enemy is killed. One of the subsystems that might listen for this event would be the Statistics subsystem, which keeps a count of all enemies killed so that the player can know how awesome she is. Another subsystem listening for that event would be the Achievements subsystem, which would handle that event by passing it on to the various achievements who sign up to listen for it. One of these listening achievements would be the First Kill Achievement which would fire off its payload upon the receipt of an EnemyKilled event, then disable itself (to prevent subsequent events from repeating the payload). This way nothing has to actively poll to see if the achievement should fire, it happens instead by passively listening and you don't waste CPU time in a huge nest of if conditionals.

 

Of course, this does require that the heart of your gameplay system be event-based, but that's a pretty good idea anyway.


PARTNERS