[Troll] Monsters With Items

[Dennis Payne <dulsi@identicalsoftware.com>]

Warning: The following is a technical discussion.  It probably won't make
sense without knowledge of OOP, C++ and Troll Bridge.

In reading _Game Architecture and Design_, I've been thinking about the
TrollSkeletalTrollWithItem.  This class annoys me.  The problem is what
I really want is TrollMonsterWithItem and have the monster be a skeletal
troll in this case.

The solution that occured to me while reading the book is to make a
TrollMonsterWithItem class that contains a pointer/reference to another
monster.  When ever anything is requested it forwards the request to the
real monster class.  Unfortunately there are a couple of problems with
this.  The main one is that the base TrollThing and TrollMonster classes
aren't pure abstract.  TrollThing has variable such as sprite, x, y, and
dead.  It could be made purely abstract but then checkCollision incur a
performance penalty as it looked up the functions and called them.
Hmm... perhaps a single function call that got x, y, xsize, and ysize so
that it had everything.  (There is then still the question of where to
put the variables currently in TrollThing.  I could create a derived
class but since TrollMonster would have to be derived from the blank
TrollThing I'd either have to make the base TrollThing class virtual and
use multiple inheritence or reimplement the information.)

The other problem is that the code dynamically casts TrollThing objects
to other types in the takeHit functions.  So the TrollMonsterWithItem
would need to be derived from TrollMonster.  Unfortunately there is some
additional complication caused by the TrollStandardMonster and
TrollUndead classes.  These probably shouldn't be derived classes instead
have a bitfield of monster attributes.

Another solution is to create a template TrollMonsterWithItem and have
the compiler do the work.  So insted of TrollSkeletalTrollWithKey, I'd
create a TrollMonsterWithItem<TrollSkeletalTroll>.  Unfortunately the
current monsters have varying constructors.  I could perhaps create a
generic constructor and then call an initialize function with the extra
arguments.

(This problem applies to the TrollItem as well.  Currently TrollItem has
a cost variable when it really shouldn't in my opinion but I ran into
the above issues.)

Dennis Payne
dulsi@identicalsoftware.com