Re: CF 0.96.* (Was: Re: CF: corpses and Animate Dead spells)

[Mark Wedel <mwedel@scruznet.com>]

David Andrew Michael Noelle wrote:
> 

> 
>     Only five main types, and everything else is a subtype of one of those?
> Seems a little coarse to me, but that's just a first impression.  Can
> objects be sub-types of other sub-types, or only sub-types of one of the
> main five?  For example, weapons, armour and rings are all "equipment", but
> are swords, clubs, and axes sub-types of "weapon"?  Are longswords,
> falchions, and katanas sub-types of "sword"?  I think an object hierarchy
> like that would be better than just having two levels.  The whole notion of
> object "race" could then be replaced by tracing object sub-types.

 Yes - sorry I did not state it.  There are 5 top level object types, and from
there it can branch out like a tree.  So to follow that, I would see something
like:

 object -> equipment -> weapons -> possible specifics needed.

 Note I don't want to get too specific.  A katana vs shortsword as different
types probably does not make sense - things like different speed and damage and
what not can be controlled in the weapons field above.

 My main goal is to try and keep what code can remain common common,
and then split of specifics.  So for example gates vs timed gates - they are
slightly different, but close enough I think it made sense to put them under a
common gate subobject, with a few extra fields that may not be used for the non
timed gates.

 There are two competing interests and it can be difficult decide on the middle
ground.  The two interests in generality of objects, so if you want to do
something new you just tweak a few fields a specific way and hopefully something
wonderful happens, and restraints, so one type of object doesn't do 50 magical
things depending on how all its various fields may be tweaked.

 My goal is to try and make it so that one object subtype does one specific task
- a gate opens and closes.  An exit transports player from one map to another. 
However, this does not always work out - something like the trapdoor is a
composite - if open, you transfer maps - if closed, nothing happens.

 Now the trap door could even be split into multiple objects - an exit object,
and on top of the exit object is the trap door type which acts like a type of
floor - if closed, it is a floor and you can't apply objects below it, if open,
you do, and thus transfer maps.  Some things like that are tough calls - the
current way a trap door is implemented is pretty clean, and the trap door is
still pretty specific.

 

>     Does that also include object type constants in archetype definitions?
> Not everyone finds it easy to remember the difference between a type 88 cone
> spell, and a type 12 bolt spell.

 Yes.  This will obviously make loading a little slower to parse all that, but
not a big deal.

 Some things still use numeric values of course - hp, speed, connected values. 
flags use 0 and 1 for true/false - not a big deal there.
 
 As I'm converting the arch's, I'm arranging the files in the same way the the
souce code object tree will be (background/exits, background/gates, etc).  This
should also make things easier to find in most cases.
-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to crossfire-request@ifi.uio.no]