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