[MUD-Dev] data structure design in a new mud

[Kwon Ekstrom]

----- Original Message -----
From: <pauli.saksa at ztango.com>

> In my opinion the negative sides of a central list are greater than
> the positive sides.  In our model there is no central list,
> therefore

I'd like to know what these negative sides you're talking about are.

> The more interesting part of the topic is the connections between an
> item type and an item instance.  If a blacksmith wants to create a
> sword, where does the code find the correct attributes?  If a
> blacksmith creates 20 similar swords, all the attributes don't have
> to be stored separately in the memory for each sword.

I'm in favor of building items in small parts with modifiers based on
choices and skill of the smith.  There was recently a discussion on
player created items, so I won't go in depth.

> In our model each item has two different sets of attributes: item
> type data (=shared) and item instance data (=unique).  Shared data
> is actually shared in the memory as well.  In addition to saving
> memory, this is a major step towards easier balancing: if some type
> of a sword is too good, all swords of that type can be downgraded in
> one place.

I've seen similar systems, but in truth, it seems that you're saving
memory at the expense of cpu.  Since if an item is part shared, and
part unique, then the code will have to scan the object to see if the
unique parts aren't really shared parts that have been changed, and
then check the shared portion to build a list of it's current state.
Checking the shared portion on-loadup could allow the centralized
balancing, but wouldn't save memory (but likely save storage space)

-- Kwon Ekstrom

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev