Sign in to follow this  
TheyDontCallMeMatt

Dynamic Calculations

Recommended Posts

I'm trying to understand a new concept that I could use for defining specific damage calculations for specific abilities. (note: I'm trying to cut down on the amount of classes that are defined) I think I can have a class cAbility with a function pointer in it called CalcDmg and an int called Damage; So im thinking to define a good looking function pointer : typedef const int (*CalcDmg)(Player* pla); //and a class definition class cAbility { public: CalcDmg _CalcDmg; } cAbility Fire; void FireDmg(Player* pla) { return(pla->GetIntelligence() * 5); } Fire._CalcDmg = FireDmg; This is just a theory but I'm thinking that a function pointer in cAbility will let me apply certain (algorithms?) to certain abilities.. If someone could help me understand this and make this work, it would be greatly appreciated, or suggest something different to do the same thing would be as helpful. edit: This is killing me x_x [Edited by - TheyDontCallMeMatt on June 2, 2007 12:21:15 PM]

Share this post


Link to post
Share on other sites
Well what I did for now.. was put in a constructor for cAbility
cAbility(AmtOfDmg p):_AmtOfDmg(p){}


So I made a function..

const int FireDmg(cPlayer* pla)
{
return (pla->GetIntelligence() * 5);
}
cAbility Fire(FireDmg);


this way i can just call Fire._AmtOfDmg(&pla) to return unique damage based on a the fire ability

Share this post


Link to post
Share on other sites
Or you could use virtual functions to accomplish the same thing with subclasses:


class cAbility
{
public:
virtual int _CalcDmg(Player* pla) = 0;
};

class cFireAbility
{
public:
virtual int FireDmg(Player* pla)
{
return(pla->GetIntelligence() * 5);
}
};

cFireAbility Fire;


Also read this.

Share this post


Link to post
Share on other sites
Oh goody, it works, now I can give player some abilities
Player joe;
joe.AddAbility(Fire);

then Fire is added to a list to be referenced from;

then subtract list[number]._AmtOfDmg from the enemy health when he is attacked!

Share this post


Link to post
Share on other sites
Quote:
Original post by TheyDontCallMeMatt
I'm not a big fan of defining a bunch of classes that are specific to certain things

That's a common feeling among people who are beginners to OO programming, but it's something that deserves to be questioned. Ask yourself: in that case, why are you a big fan of defining a bunch of functions that are specific to certain things?

Share this post


Link to post
Share on other sites
Quote:
Original post by TheyDontCallMeMatt
... I'm not a big fan of defining a bunch of classes that are specific to certain things and that also I might use once. ...


it sounds like you don't fully understand OOP. What you're saying here is "I'm not a big fan of utilizing the most powerful underlying concepts behind the tools I'm using".

Share this post


Link to post
Share on other sites
Quote:
Original post by TheyDontCallMeMatt
Thanks Sneftel, but I'm not a big fan of defining a bunch of classes that are specific to certain things and that also I might use once. The solution I have now pleases me :)


Variations in behavior are what polymorphism in OOP is designed to handle.

As suggested, you'd have to write a separate function for each different ability using straight C or some other procedural language.

The advantage of OOP in cases like this is being able to use the many different variations without changing every place where the original is used.

In C or other languages, you'd have to change each function call and/or copy and paste a lot of code.

OOP also gives your code more structure, and is much easier to understand quickly, if you have to come back to the code after not looking at it for some time.

Share this post


Link to post
Share on other sites
Quote:
Original post by Verg
In C or other languages, you'd have to change each function call and/or copy and paste a lot of code.


Not if you use function pointers, which is what TheyDontCallMeMatt is doing. I think it is totally sane to use function pointers, they often minimize coupling and sometimes save typing compared to subclassing. However, if there is some kind of hierarchy/structure that you want to model - go for subclassing. If you want more power you can use function pointers on steroids: boost::function.

As for the specific problem - I would avoid these small specific funtions. I would try to write one or a couple of very general algorithms that can handle all different cases. The reason for this is that I think it should be possible to add and change items/weapons/spells/enemies just by writing datafiles. Very specific things which change often should not be written in compiled code.

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

Sign in to follow this