OOP RPG programming principals

Recommended Posts

I have an OOP design question  about where best to put  my code. Say I have table object and fire object. Does the Fire  burn the table and burning code goes in  the fire class with Table object passed to it  or does the fire class simply call the burn method  for the table?  I was thinking about putting the burning code in the fire class. But each object burns differently  A table would not burn  the same as say grass  ,  a person  ,  a horse,  or a chunk of magnesium? My question is for things like  getting burned, frozen , covered in sodium-hydroxide ECT.  Where does the code most efficiently go? In the class of the Problem or the class that gets the problems. Currently Problem is base  abstract class that all problems extend and every thing has an ArrayList of Problems  that they cycle through each turn.  But I'm having a hard time efficiently splitting the code up.

Edited by macmanmatty
I cannot speel and need to correct it sometimes edit is my best freind

Share this post


Link to post
Share on other sites

If an object can be burned, then it should have a BURNABLE property. Grass, wood, table, zombie, etc would be examples.

Your next decision should be "who know what HP to deduct?". Either the Fire removes X HP from object or Object drops (internally) X HP when it collides with the Fire.

Share this post


Link to post
Share on other sites

I would personally do something like this:

  • Basic things that can be combined each have an Ingredient member object (compose, don't inherit)
  • Combining two things invokes a Combination object ("service" in some parlance) which looks at the set of available Ingredients
  • Using a data-driven model, the Combination finds the best "result" for a given set of Ingredients
  • Combinations then execute any logic necessary to resolve the Ingredient Combination into a new game state

 

So for example:

  • Table has a Flammable ingredient
  • Fire is an ingredient of, say, a Flamethrower object
  • USE Flamethrower ON Table results in a data lookup which notices that Fire and Flammables can be combined
  • A Combination object is called upon to run the logic, again data driven as far as possible
  • The Table is destroyed
  • Ashes are created at the Table's former location
  • Flamethrower ammunition (or "uses count") gets decremented
  • The Combination is now finished

 

Note that there is no requirement for a Combination to be a stateful object. Assuming a language which permits it, you can just use a free function like 

bool CombineStuff (const std::vector<Ingredient>& firstObject, const std::vector<Ingredient>& secondObject);

 

Share this post


Link to post
Share on other sites
1 hour ago, macmanmatty said:

Where does the code most efficiently go? In the class of the Problem or the class that gets the problems. Currently Problem is base  abstract class that all problems extend and every thing has an ArrayList of Problems  that they cycle through each turn.

The 'most efficient' depends on the system you're using.

It is rather common for games to employ a property or component system. Add a property or component that says an object is burnable, and it should include tunable values such as the rate of burning or the effects of burning over time such as changing textures, or transforming to another object like a pile of ash. The exact details will depend on your game engine.

You are right that each of those items burns differently. Your burnable component or burnable property could either detect the kind of object it is attached to if your system is designed around that, or perhaps could require the correct sub-type of burnable be applied, one burnable type for consumable objects, , another burnable type for indestructible objects, another burnable type for things that can die, etc. It is all up to your game's implementation

Another variation is to add a 'burning' buff, which is often the same theory as a property or component attached to an object. It still needs tuneable values for the effects, something that can be modified, tuned, and tweaked until the value has just the right feeling for the game.

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now