Re: Spells and fireballs

[Keith Lucas <keith@fysh.org>]

> I'm trying to create a combat system for a RPG, but the magic is giving
> me some problems. First: I'm programming in c++.
> 
> When the combat is going on I intend to create a combat engine that
> handles where the creatures and obejts are located on the battle field,
> and also handles who's turn it is.
> 
> When the creature casts a spell which sends a ball (like a fireball)
> against an enemy, the spell gives a spell_ball object to the combat
> engine. The spell_ball haves a function that handles impact:
> 
> virtual ?? impact(creature *);
> 
> The reason that the function is virtual is that I plan to derive a new
> class for each spell, and then reimplement the impact function.
> 
> My problem is that a firebolt which only damages the target it hits
> directly, does not need to return anything, but a fireball that damages
> an area need to return an int that tells the radius of damage. If those
> where the only two options, I would not have any problems, but som
> spells like to return an array of new spell_balls (consider a spell that
> shatters into 10 new small pieces when it hits an object). How do I
> handle this most gracefully?


The reason you're having trouble is that you're slightly violating one
of the rules of OO programming. The rule is that objects are alive:
you're trying to take some of their life away and put it somewhere
else.

What you need to do is have a "universe" which contains all the
objects, and which all the objects know about. Impact is a void
function, it does all the impacting and exits.

Within impact(), the object can do all sorts of stuff. You can have a
baseclass "shatterable" which spawns off a whole bundle of munitions:
you supply it a constructor function - maybe as a template parameter
which will create its children. Created munitions are supplied with a
position and motion information and add themselves into the universe.

Other munitions damage things, other ones go looking for objects in
their vicinity to damage. Again, you'd have a base class "area effect"
which knows to go look for everything within distance N and call the
member "damageObject(target&)" on it - the I hurt what I hit" is a
special case of this.

The trick with this sort of thing is not to break the consistency of
the metaphore you're using. In the "real" world, it's the munitions
taht do the hurting, so let them keep doing the hurting inside the
simulation.

The universe doesn't need to know anything about how the objects are
reacting to each other, beyond being careful object objects that
delete themselves.


---------------------------------------------------------------------
To unsubscribe, e-mail: linuxgames-unsubscribe@sunsite.auc.dk
For additional commands, e-mail: linuxgames-help@sunsite.auc.dk