Up to Main Index                             Up to Journal for March, 2018

                     JOURNAL FOR TUESDAY 13TH MARCH, 2018
______________________________________________________________________________

SUBJECT: A lot of loose ends
   DATE: Wed 14 Mar 01:22:05 GMT 2018

I’m still working on code for marshaling items so that players, potentially
the whole game world, can be written out to files. In doing so I’ve had to go
digging in the code for junking, clean ups, resets and locking.

Examining the current code I have come to a conclusion, permanently disposable
items can be simply identified as any item that does not have an origin. This
could simplify the code for junking items. It could also simplify the code for
saving players. Simple is good — no more checking for resets with special
handling for items without a reset.

I’ve already completed some preliminary work analysing all of the items in the
current game world. All items, when put into the world, automatically have an
origin set, with a few exceptions. Exceptions without origins are: locations
(things with exits), the opposite side of doors, players and spawned items.

Locations, I think, are fine for now as players cannot pick them up. Although
it’s possible to create an item, like a large crate, with a ‘door’ and exit. A
corner case I need to look into — although the crate would have to be put
somewhere, and so have an origin.

The ‘opposite side of doors’ are automatically generated. It should be quite
easy to set their origin.

Should players have an origin? It’s not necessary, but may be useful in the
future when players die and need to be put back into the world somewhere.

Spawning an item already removes any origin when the copy is made.

I’ve also been thinking about the related issue of items that cannot be
junked. For example those where the JUNK command is vetoed — like the lattice
in the current test world. I think this situation can be handled via a reset.
What if the item does not have a reset attribute? It could be instantly reset
back to its origin. However, this raises the issue of whether an instant reset
could be abused by players. Something else to ponder.

The main goal is to save and reload players. To do that we need to be able to
clean up a player and their inventory when they leave the game. To do that
permanently disposable items need to be identifiable — without a lot of
special rules. Junking should still be the one way to dispose of items and
have them cleaned up, reset or disposed of as appropriate.

I also need to revisit my current version of Thing.Marshal. It processes
Inventory recursively looking for permanently disposable items to save. That
means it’s no longer a generic way to save anything and when it comes to
saving the world it won’t work as it won’t save everything. The recursiveness
and checking for permanently disposable items should be in the save command
and Thing.Marshal should just save what it is told to save.

That’s the state of play. A lot of fingers in a lot of pies and many loose
ends that need to be tied. I think it’s going to take a little while longer
before it all comes together. It’s not that bad, overall the code will be
cleaner and easier to understand.

--
Diddymus


  Up to Main Index                             Up to Journal for March, 2018