[DGD] Dworkin's mudlib

[Mikael Lind]

Hello,

I thought some more about using light-weight objects (LWOs) for things
such as items in a game. As I understand it, they are managed in the
same way as arrays and mappings, meaning that they can be shared
between several persistent objects (POs) during an execution round.
However, when the execution round finishes, shared LWOs are duplicated
so that each PO referring one gets its own copy of it.

The above poses a problem for a game. The scenario is a mud with rooms
(represented by POs), creatures (POs), and items (LWOs). If a creature
enqueues a take-action for an item in a room, where the take-action is
stored in the creature, and the take-action references the item via an
object reference, and the take-action is to be executed during another
execution round, then the item will be duplicated, which is
undesirable. I am also thinking that the same problem would occur in
many similar scenarios.

I was thinking that some kind of indirection would be appropriate,
where rooms and creatures associate handles (ints) with the items they
contain, so that other POs may reference the items across execution
rounds without duplication. The other POs would not store object
references but instead an indirect name (string), perhaps on the form
PON:IH, where PON is the persistent object name and IH the item
handle. It would be possible to lookup indirect names and get a plain
object reference to the LWO for manipulation. call_other() could also
be masked by a second-level auto object in ~System to properly handle
calls to indirect names.

Then I thought of using specially treated LWOs as proxies to items,
masking more functions in the second-level auto object, completely
hiding items from user code, similar to how lib objects are hidden by
the Kernel Library. Internally, proxies would probably use a method
similar to the one outlined above for tracking their items.
This is where I am right now. I am still not sure about which PO
should own an item, which is important for swapping.

Does anyone have any thoughts on the above, or the subject in general?
To summarize, I am trying to explore how to simulate distinct,
non-duplicating objects using LWOs. Though they are referred to as
items throughout the message, there should be other uses for them than
representing game objects.

Regards,
Mikael