# Trophies programming design pattern [closed]

What design pattern is best for implementing trophies in a game? I am not a games developer, but is it easy for each player's action to check and update conditions that satisfy 50-100 trophies at any time aside from everything that goes on in the game engine? How is it best done?

• Are you asking about the "technical" way it is done, or the way to "design" trophies? Jun 7 '11 at 8:58
• @3nixios, The way to design them. However, an example in python would also be great! Jun 7 '11 at 9:03

I think the best way to design something like this is first to inspire yourself from the best, Assassins Creed 2 is a good example.

You find a trophy for each chapter and one for completing the game on each difficulty. These are generally 'Complete Chapter x' or 'Defeat Boss xyz'. I would prefer having really exmplcit names eg 'Complete Chapter x', as you don't want the player to check his trophies every time he finishes a chapter because he thinks he got someting cool.

You also should have trophies that will push the player to play how YOU want him to.

For exploration you will have a collectible trophy, for fighting you will have a 'Kill x Guards' etc. These can help to force the player to explore more, and even learn to play better.

The biggest difficulty in my sense is Hidden Trophies. The name needs to imply what needs to be done but without spoiling any of the game. You don't want for example 'Kill the Traitor' when you only have one Ally in the game. These should also be some of the hardest trophies where people could rarely get them without specifically trying for it.

There can often be half of the total trophies that are secrets.

Of course, 'Lolphies' are also good and will inspire or reward a certain type of play.

Trophies are very game-dependant though and require a lot of thought!

• The thought process before you start implementing is indeed very game specific. When implementing them, I believe you can come up with a universal game engine design for them. Jun 7 '11 at 9:40
• This is what I tried to do in my answer, maybe it wasn't clear enough? Jun 7 '11 at 9:41
• Ah I see, the game-design tag threw me off a bit. You could have a base class trophy, which assures that a trophy can only be awarded once, and will be awarded dependant on a condition. A trophy has a name, a description and an image. This could be a base class, and each trophy could inherit from this class, overriding a function 'bool isConditionMet()' for example. You could then have a trophy manager that not only keeps an instance of all trophies together, but also remembers which trophies have been won, and initializes them accordingly. Jun 7 '11 at 10:00
• To be honest that was off the top of my head, It's probably not a great solution for the trophies to check themselves if their condition is met, though it is a simple one. The manager could iterate through the trophies you have not yet achieved and check one every t/number of trophies left, where t is the maximum latency you want between getting a trophy and recieving it. This assumes that the condition, once is it met, will continue to be met for at least t, which is probably bad design. Jun 7 '11 at 10:21
• You could however have the trophy manager monitor variables necessary for trophy completion, and when one changes iterate through the isConditionMet() of each trophy. This would make it easy to seperate the trophy code from the rest of the code, and you wouldn't use unecessary CPU time. Jun 7 '11 at 10:23

Basically you want at least 3 types of data structures:

Counters: This happened. A gun was fired. An enemy was killed. This polygon was touched.

Conditions: If Counter X > 500. If Counter Y = 0.

Trophy: If condition A is met, this condition is visible. If condition Y is met, this condition is invisible.

In your game code you sprinkle counters firing where appropriate and forget about it.

Some other class either in response to an event of the counter firing or periodically will check the list of conditions and see if they've been met. After, again either in response to an event or periodically trophy's will check if all their conditions are met. If so it gets rewarded.

Your UI can iterate all trophies and display the visible conditions. If no conditions are visible, then the trophy is hidden.

Everything is separate and during the update loop all you need to do is increase a number and maybe flag the data as changed, anything else can be deferred to when there's more time / even a separate thread.

If you are asking for a technical way: I'm a very, very noob game developer, but this is how I implemented my AchievmentManager (I think it's the observer pattern):

Class BaseAchievement{

public abstract boolean checkAchieved(Game game);

public abstract String getName();

//etc. etc.

}


Manager:

Class AchievementManager
{
public void notifyScoreUpdated(Game game){
for(ScoreListener s : scoreListeners)
{
boolean achieved = s.checkAchieved(game);
if(achieved) unlockAchievement(s.getName());
}
}

public void notifyPlayerMoved(Game game){
for(MoveListener m : moveListeners)
{
boolean achieved = m.checkAchieved(game);
if(achieved) unlockAchievement(m.getName());
}
}

public void unlockAchievement(String name){
//bla bla bla
}

}

• Why was this downvoted? Is there a better way? I really would like to know. Also, I don't think the accepted answer answers the question, although the comments below it might. Aug 30 '11 at 23:48