Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualParadigm Shifter

Posted 24 July 2013 - 03:07 PM

Assuming C++/Java/C#:

 

I'll second the have some kind of container (vector, list) of objects which are derived from a base class which has a pure virtual

 

bool SatisfiedAchievement()

 

method which returns true if the achievement is satisfied, so it can be removed from the container after it has been completed.

 

But what you don't want is each achievement to be a separate class derived from the base class - most achievements are similar (kill enemy X, collect X items, kill X enemies of type Y, etc.), so you want to have the different types of achievements as classes which take parameters on construction (or a separate initialisation step) which provides the details.

 

You can still have really complicated achievement types to have a class of their own, but these should be an exception rather than the norm. Also consider compound achievements which can have several subtasks (such as kill X goblins and collect Y golden nostrils), you can have a compound achievement class which checks for both (so will contain 2 or more instances of concrete achievement classes as members) which only returns true from SatisifiedAchievement when both tasks are complete.

 

 

If you are using C, you can do the same with function pointers.


#2Paradigm Shifter

Posted 24 July 2013 - 03:06 PM

Assuming C++/Java/C#:

 

I'll second the have some kind of container (vector, list) of objects which are derived from a base class which has a pure virtual

 

bool SatisfiedAchievement()

 

method which returns true if the achievement is satisfied, so it can be removed from the container after it has been completed.

 

But what you don't want is each achievement to be a separate class derived from the base class - most achievements are similar (kill enemy X, collect X items, kill X enemies of type Y, etc.), so you want to have the different types of achievements of classes which take parameters on construction (or a separate initialisation step) which provides the details.

 

You can still have relly complicated achievement types to have a class of their own. Also consider compound achievements which can have several subtasks (such as kill X goblins and collect Y golden nostrils), you can have a compound achievement class which checks for both (so will contain 2 or more instances of concrete achievement classes as members) which only returns true from SatisifiedAchievement when both tasks are complete.

 

 

If you are using C, you can do the same with function pointers.


#1Paradigm Shifter

Posted 24 July 2013 - 03:06 PM

Assuming C++/Java/C#:

 

I'll second the have some kind of container (vector, list) of objects which are derived from a base class which has a pure virtual

 

bool SatisfiedAchievement()

 

method which returns true if the achievement is satisfied, so it can be removed from the container after it has been completed.

 

But what you don't want is each achievement to be a separate class derived from the base class - most achievements are similar (kill enemy X, collect X items, kill X enemies), so you want to have the different types of achievements of classes which take parameters on construction (or a separate initialisation step) which provides the details.

 

You can still have relly complicated achievement types to have a class of their own. Also consider compound achievements which can have several subtasks (such as kill X goblins and collect Y golden nostrils), you can have a compound achievement class which checks for both (so will contain 2 or more instances of concrete achievement classes as members) which only returns true from SatisifiedAchievement when both tasks are complete.

 

 

If you are using C, you can do the same with function pointers.


PARTNERS