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

[Hwei Sheng TEOH <>]

On Thu, 2 Sep 1999, Mark Wedel wrote:

[snip]
>  The main goal for 0.96.0 at least is to redo the object structure to make it
> easier to expand and remove many of the special cases (for example, the grim
> reaper is its own object type because it hits 10 times then disappears).
> 
>  This won't completely disappear.  I am currently working on 0.96, and
> the model currently has 5 top level object types (backgrounds, creatures,
> equipment, effects, and missile).  Beneath this, objects get further broken
> out.  Instead of the current flat object model, where the object structure holds
> information for all objects, the revised model is a bit more tree like (so you
> may have something like object -> background -> exit).
> 
>  The original goals of such a rewrite where:
> 
>  1) remove overlapping meanings of fields (for example, exp for rings meant
> speed bonus, sp and maxsp had various meaning for gates, and so on).  This
> resulted in non intuitive code.
>  2) Reduce memory by only allocating the memory for the needed object -
> in 0.95, things like backgrounds, which have minimal information, use the
> same amount of memory as a monster, which has a lot of information.  Originally,
> this was seen as some problem, but with the drop of ram prices, this is much
> less an issue.  The revised model will make it easier to do that, but at current
> time, I am not doing that to hopefully make debugging easier (debugging should
> be easier since the object structure will be the
> size of the largest object - this then means if some code assumes the wrong
> object type, it only overwrites data within its own area, and doesn't overwrite
> some other object.

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)

>  With some coding done, there are some other advantages that will be seen:
> 1) Objects will be more general in nature (right now, objects tend to be very
> specific in what they do).  This will make it easier to add new
> object types or extend existing features.
> 2) Processing of some objects will be easier, because the object type itself
> will tell you something.  For example, of the 5 objects listed above, only
> equipment can actually be picked up.  This should reduce the need for some
> flags.

What about situations where you don't really want the player to pick something
up? (eg. should be able to pick up gravestone of a dead player, but kinda
strange if able to remove tombstones from graveyards!)

> 3) Code will be grouped by objects.  In 0.95 (and earlier), you have code for a
> specific object all over the place.  For example, for a gate, you may have
> something in button.c, apply.c, and time.c.  For the rewrite, I am grouping the
> code together - all background object code will be in background.c or subsidiary
> files.  this should generally make maintenance easier (this of course does not
> require a rewrite of the object structure to do that, but is a good time).

Hmmm, I don't suppose we plan to migrate to C++, but this sure does sound like
OOP. :-)


T

-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to ]