Up to Main Index                              Up to Journal for June, 2020

                      JOURNAL FOR SUNDAY 7TH JUNE, 2020
______________________________________________________________________________

SUBJECT: A blather about inventories and command processing
   DATE: Sun  7 Jun 18:00:04 BST 2020

This is a longish, blathering journal entry of me thinking out loud and trying
to convince myself of the right thing to do. Some people like to know what I’m
thinking and what goes into coding WolfMUD, this entry is for them :)

After my last journal entry I thought I’d take a quick look at putting mobiles
into their own linked list in the Inventory. As I said in that entry an
Inventory has four linked lists: Players, Contents, Narratives and Disabled.
This allows for quick lookups and quick movement of items between different
Inventories.

At its core a MUD, at least how I write them, looks up and manipulates Things
in Inventories. A player moving, getting an item, putting an item somewhere
all manipulate inventories. The other core concern of a MUD is networking,
getting input from and sending output to players. So there you have it in a
nutshell, to write your own MUD develop the network code and an efficient
inventory/container system :)

Back to WolfMUD’s Inventory. The changes to put mobiles into their own linked
list were fairly simple and quick to make. Unfortunately everything else fell
apart — a lot of the player commands broke. The main issue being that the
commands called Inventory.Contents to find items — which no longer included
mobiles. So you couldn’t EXAMINE a mobile, you could GET a mobile as get used
Inventory.Everything but then it was invisible to the INVENTORY command and
you couldn’t drop it again.

A possible quick fix could have been to just have Inventory.Content also call
Inventory.Mobiles to restore the previous behaviour. A nasty hack :(

I took a look at the commands to see if they could be easy fixed. Urgh! Since
the matcher code, commands are not as nice to work with as they once were :(
There is too much boiler plate code dealing with non-matches and not enough
matches. Plus there is now the looping required for commands that take more
than one item, as in “GET SWORD AND DAGGER”. For commands that don’t take
multiple items, like EXAMINE, you have to handle that special case[1].

That leaves me in a bit of a pickle. I’m working on adding combat — which
everybody also wants to see added. I also have a lot of command code I’m not
happy with. I could put combat on the back burner and sort out the command
processing — but the command code is working even if a bit of a mare…

How would I fix the commands? I’d partially go back to the old model of each
command being ‘single shot’. For example the GET command would only get a
single item. So a command such as “GET SWORD AND DAGGER” would actually be
processed as “GET SWORD” and “GET DAGGER”. The GET command would no longer be
concerned with matches and non-matches.

For this to work the matcher would need to be hoisted further up the call
chain. One possibility would be to call it in the command handler before
dispatching to the command processor. So in cmd/handler.dispatchHandler call
the matcher then call the command processors. But there would now need to be
multiple dispatch methods. For example GET is a simple multiple dispatch: “GET
SWORD”, “GET DAGGER”. The PUT command needs to repeat the last item — the
container to put the items into. For example “PUT SWORD DAGGER CHEST” would
need dispatching as “PUT SWORD CHEST” and “PUT DAGGER CHEST”. What if there is
no chest? Processing should stop after the first PUT so an abort signal needs
to be passed back. It also means that the CHEST would have to be validated and
processed for each PUT. Then there are commands that need raw access, such as
the ‘SAY’ command. For example “SAY This is all a right shambles”.

At the moment commands register a process handler via a addHandler call. I
think I’d either need a way for commands to register different handlers, maybe
something like addItemHandler, addRepeatingHandler and addRawHandler or just
pass in a handler function — maybe as a closure.

Another problem is the matcher processes different inventories in different
orders for different commands. For example: the GET command looks at the items
in the current location’s inventory, the DROP command looks at the actor’s
inventory and the EXAMINE command looks for items at the current location and
then the actor’s inventory.

If the heavy lifting is done outside of the command processing does this mean
that the command state object currently used becomes simpler? Hrm… something
else I need to think about.

With so many problems and ideas I’m going to park/undo the Inventory mobile
changes while I have a long think about commands and command processing. For
now I’ll just get on with the changes needed for combat…

--
Diddymus

  [1] The EXAMINE command doesn’t allow multiple items as otherwise players
      could go on ‘fishing trips’[2] and discover items with commands like
      “EXAMINE ALL WEAPONS” and “EXAMINE ALL ITEMS”. This is also why none of
      the commands allow ‘ALL’ to be used, like “EXAMINE ALL” or “GET ALL”.

  [2] Is this still a valid argument? ‘ALL’ could be limited to either what a
      player can see — those items listed at a location or in a container — or
      what a player has in their inventory. The only problematic command I can
      think of is ‘EXAMINE’ which would need to exclude narrative items at the
      current location if used with ‘ALL’.


  Up to Main Index                              Up to Journal for June, 2020