[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Adonthell-devel] Adjustments to items.h ?

From: Kai Sterker
Subject: Re: [Adonthell-devel] Adjustments to items.h ?
Date: Wed, 13 Feb 2002 22:27:17 +0100 (CET)

On Wed, 13 Feb 2002 15:41:03 -0500 Mike Avery wrote
> I've just remembered where I left off last time around.  Objects/items.
> I've read over the items stuff  (, item.h, item.txt).  Further to the 
> email I sent last time, should we expand the existing item superclass to 
> incorporate weapon/armour/foci attributes or do Kai/Alex have a different and 
> preferred way to do this?

I don't know if it should be in the item superclass. Basically, it depends
on what attributes certain items need. Even if all items need those
attributes, it might be cleaner to put them into a different class.

But if there are plenty of attributes only needed for weapons or armour or
foci or gems, etc., then it would be better to have a generic
weapon/armour/foci class with only the attributes it needs.

Which means you cannot equip the lamb chop, unless it is meant to be a
weapon ;).

> I'd like to start on reworking the old melee algorithms into something more 
> generic, modularized and extendable.  At the same time I would like to be 
> able to pull in entities used in calculations from a generic object 
> interface.  Since one is dependant on the other, its probably a good time to 
> decide where attributes which effect melee/magic are to be kept, and how 
> these properties can be accessed, and perhaps manipulated.  It is also 
> possible that combat events could effect the properties of the items used.
> Should combat-specific object modifiers (such as base damage, dexterity 
> penalties, foci properties etc)  be managed in a core item system?  It makes 
> sense to me.  We could make "the cook's burnt lamb-chops" equipable, and 
> enable players to use just about anything for melee if they feel like it. :)
> I suppose the concern is that the class could become HUGE.

Maybe it might be better to split the item class into classes that build
upon each other (i.e. inherit each other) instead of putting everything
into a single, bloated superclass.

* There could be a class with the most basic attributes, like name, 
  description, weight, size, quality and value.
* A class dealing with equipping/unequipping and the rest of the effects.
* A 'container' class.
* A class with the combat attributes.
* A class for combining/improving an item.
* ...

If one class inherits the other, so that the class at the top contains all
properties of all the lower classes, we had items that can do anything,
yet the code might be cleaner.

That are just some basic thoughts though. The matter is really complex,
and I haven't thought it through, so you are more or less on your own.

Perhaps the best might be to put some items together with the properties
you need for battle. We could add to that once we want to be able to do more
with our items.

That should be easier than writing a complete item system in one go :).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]