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

[David Andrew Michael Noelle <dave@Straylight.org>]

Mark Wedel wrote:
> 
> Hwei Sheng TEOH wrote:
> >
> >
> > Hmmm, couldn't we have an extra field that encodes exactly what type the
> > object is, so that any code that needs to assume a certain object type can
> > always check it? (Might be useful for tracking down buggy code)
> 
>  Yes - there is still a type field (container one of the 5 object types).  Below
> that, many of the specific object types will have a subtype field.

    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.


>  The other difference which I did not mention is that arbitrary constants won't
> be used in the save files anymore.
> 
>  For example, right now you might have something like:
> 
>  attacktype 212412 (which looking at the arch tells you nothing).
>  Instead, that would be something like
>  attacktype fire weaponmagic fear ...

    Yes!  Definite improvement.  We'd still have to remember to spell things
right, and to keep the attack types seperate from the apell paths, but
that's a good deal easier than all the binary arithmetic.
    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.


>  This is an interesting question.  I had thought about some things, and using
> C++ would be easier in that regards.
> 
>  IF (and that is a big IF) we want to go to C++, now is probably the time to do
> it.  It would certainly make some code cleaner.  And the amount of work may not
> be as great as one might think - ANSI C code (which crossfire is) for the most
> part compiles under C++.  So while some areas may not be in the OOP model (like
> maps and treasures), the code could remain as is (ANSI C) and still get compiled
> in and work OK.
> 
>  Thoughts?

    Personally, I like C++, and I'd use it if we wanted to go that way, but
I know from experience how easy it is to create amazingly ugly and
untraceable bugs if you're not extremely careful with it.  In an open-source
project, with an unknown number of contributors tweaking each others' code,
I don't think C++ would be a good idea.  Class (a.k.a. archetype) and object
design is a good thing, but I suspect object-oriented programming would just
make things messier in this case.


-- 
            -Dave Noelle,                 dave@Straylight.org
            -the Villa Straylight,  http://www.straylight.org
Coalition Against Unsolicited Commercial Email  ==  http://www.cauce.com

Disclaimer: Any similarities to the opinions of any real or fictional 
persons, living, dead, or undead, are clearly the reader's own delusion.

Quote of the Day:
"There is no such thing as 'social gambling'.  Either you are there to cut
the other bloke's heart out and eat it, or you're a sucker.  If you don't
like this choice, don't gamble." - Lazarus Long
-
[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]