[CF-Devel] CF object structure (was RE: brief introduction)

[Mark Wedel]

Tim Rightnour wrote:

>
     
      Personally.. all I want is a Class/Subclass *field* in the objects that I can
     
     >
     
      use to categorize them.  I don't fully comprehend what Mark really wants, or
     
     >
     
      what the benefit for it is, but I'm just trying to throw this out and get a
     
     >
     
      feel for what people want with it.
     
     
 adding such a field is pretty easy to do.  Making it meaningful is a little
more difficult.

>
     
     
     >
     
      I guess my point is this.  Mark's idea seems logical, from a structure point of
     
     >
     
      view, your idea does as well, but involves c++, which I have an inherent hatred
     
     >
     
      for ;)  What I don't really see, is what the payoff is for either.  Basically,
     
     >
     
      all I want to be able to do is classify items better.. so.. my vision is this:
     
     >
     
     
     >
     
      Item Type:  Food, Furniture, Ring, Amulet, Armor, Weapon
     
     >
     
      Class: Sword, Axe, Dagger, polearm, couch, chair, fountain, etc
     
     >
     
      Subclass: slash/bash/stab
     
     >
     
      Flags: Drinkable, two-handed, throwable, sittable(?), giant-only, dwarf-only,
     
     >
     
             etc
     
     >
     
     
     >
     
      I don't need a whole inheratance structure.. all I want to do is be able to
     
     >
     
      specify with more precision what an object is.  For example, if a fountain was
     
     >
     
      marked:  Furniture, fountain, drinkable.  Then it wouldn't be difficult to make
     
     >
     
      drinkable fountains, or reusable chests.
     
     
 One of my ideas is to give the objects more common abilities, which means they
are easier to expand or create interesting new ideas.  For example, wands,
potions, and scrolls effectively do the same thing (cast spells).  The
difference is potential charges (potions and scrolls have one charge, a wand can
have many), and skill check for success (to read a scroll, you have to have
literacy and there is a chance of failure).  Given that, you could make these
one object type, with scroll/wand/potion be the subtype.  Then in theory, you
could have potions with multiple charges.  This is a pretty trivial example, but
the general idea is for more objects to have more fields in common to mean the
same thing, so that it is more extensible (the by expanding the ability of what
a scroll could do, that would effectively extend what the potion can possibly
do).

 I'm not sure if I agree with the use of flags - In some sense, the
class/sublcass should dictate a lot of that, and flags should more often be used
for things that are global to all objects (or things beyond the one type).  For
example, if the item type is food, and subtype is booze, that should infere it
is drinkable.  Likewise, it type is furniter, subtype is fountain, that should
also imply drinkability - values within the object should determine how many
times it may be drinkable, and if you want something that looks like a fountain
but is not drinkable (like a lot of the stuff now), you just have is subtype be
something like 'mundane', meaning it has not special abilities.

 On to some notes from Andreas:

Andreas Vogl wrote:

>
     
      The approach with union types does not seem satisfying to me.
     
     >
     
      I mean, sure it would have a few benefits over the current structure,
     
     >
     
      but is it really worth the while - say: the work?
     
     >
     
      When I imagine the implementation of this scheme, I get the feeling
     
     >
     
      that the code won't get any shorter nor any better structured.
     
     >
     
      We'de always have to handle down long lines of pointers everywhere,
     
     >
     
      always doublechecking if the ones we want are actually defined.
     
     >
     
      This means a lot of ways to segfault and *very* long expressions to
     
     >
     
      mess with. Imagine the whole code looking like this:
     
     >
     
     
     >
     
         tmp_object.type.item.subtype.equippable.fire_resistance =
     
     >
     
         new_object.type.player.blabla ...etc;
     
     
 I agree.  The need to unions exists much less now than it did some years ago,
when memory consumption was more an issue and all those background objects
chewing up full object space memory seemed wasteful.  Now days, trying to save a
couple hundred bytes for background objects seems pretty pointless.

>
     
     
     >
     
      If we just extend the map-editor to give the user a true idea how
     
     >
     
      to work with the arch attributes, at least the multiple usage of
     
     >
     
      attributes (like "last_sp") won't be so troublesome anymore. The
     
     >
     
      editor can put a nice GUI-mask over it with appropriate names and
     
     >
     
      good hints.
     
     
 Note that only fixes one of the problems (and the least worrisome in my book) -
confusion on the player part.  You still have a problem of the fields having non
obvious meanings in the arch's, and developers coming along saying 'I don't
think xyz is used for this object, so I'll use it for the new value I want to
store', which then results in some bug when it turns out xyz actually is used in
some obscure cases.  Likewise, if your debugging and say 'print *object', you
now need to know what meaning last_sp may really have for that object if it may
relate to that bug.

 I do think the easier approach is to just clean up all those multiple
meanings.  This may mean adding 20 or so new fields to the object structure, but
see not above about memory not being that big an issue.  And of course, call
these these new elements something that makes sense to their purpose, and not
something like 'last_heal', which has some meaning for skill objects when using
permanent experience (or food representing charges in a wand, etc).  Some of
these things could have names that are used across object classes - you could
add a field called 'uses', which could represent both the wand charges as well
as how much a teleporter could get used (not that there is any functionality
like that right now, but IMO, rather than things being use_once or use forever,
having charges on other attributes would probably be useful).

>
     
     
     >
     
      However, if the redo of the object-structure is to be done, I would
     
     >
     
      choose to go the object-oriented/C++ way. A proper inheritance-based
     
     >
     
      class hirarchy seems the only way for a *real* improvement IMHO.
     
     >
     
      Like this:
     
     >
     
     
     >
     
      class object { ... }
     
     >
     
      class item: public object { ... }
     
     >
     
      class equippable: public item { ... }
     
     >
     
     
     >
     
      I don't want to go deep into explaining the numerous advantages
     
     >
     
      of object-oriented programming and inheritance models, assuming
     
     >
     
      that most of you know about it.
     
     >
     
      But in short: We'd have perfectly structured and eays-to-read code.
     
     
 Yep - its been discussed before.  It probably makes sense - at least more sense
than rewriting the object structure with unions.  But I think the realistic
approach is to just add the necessary fields to the object structure and clean
up some of the code so there are not as many special cases of ob->xyz means this
if the object is of this type, but means something completely different for
another object type (I'm thinking more equipment here)