Up to Main Index                           Up to Journal for October, 2018

                    JOURNAL FOR FRIDAY 26TH OCTOBER, 2018
______________________________________________________________________________

SUBJECT: The mouse moves!
   DATE: Fri 26 Oct 22:31:40 BST 2018

Work on the new actions functionality is progressing. However, I’ve hit a few
problems I still need to work out. Having said all that, I’ve introduced a
mouse to the tavern. After hacking around for a while and lots debugging the
mouse moves! Just don’t open the tavern door! :) Here is the mouse in action:


  Tavern bar
  You are at the tavern's very sturdy bar. Behind the bar are shelves stacked
  with many bottles in a dizzying array of sizes, shapes and colours. There
  are also regular casks of beer, ale, mead, cider and wine behind the bar.

  You see a small mouse here.

  You can see exits north, west and northwest.
  >
  The mouse sniffs around.
  >
  The mouse squeaks.
  >
  The mouse washes its face with its paws.
  >
  You see a small mouse go north.
  >n
  Tavern entrance
  You are in the entryway to the dragon's breath tavern. To the west you see
  an inviting fireplace and south an even more inviting bar. Eastward a door
  leads out into the street.

  You see a small mouse here.

  You can see exits east, south, southwest and west.
  >
  You see a small mouse go west.
  >
  You see a small mouse enter.
  >
  You see a small mouse go southwest.
  >


The current definition of the mouse looks like this:


       Ref: M5
      Name: a small mouse
     Alias: MOUSE
  Location: L1
     Reset: AFTER→1m
   OnReset: A small mouse scurries into view.
    Action: AFTER→3s JITTER→3s
  OnAction: $ECHO The mouse squeaks.
          : $ECHO The mouse washes its face with its paws.
          : $ECHO The mouse sniffs around.
          : N
          : NE
          : E
          : SE
          : S
          : SW
          : W
          : NW

  This is a small, furry, grey mouse.
  %%


At the moment I’m using the original $ACTION command, as a kind of proxy, to
script the commands. For the final implementation I want attr.Action to queue
the commands directly.

The biggest problem I’m having is with repeatable commands. For example, in
the above definition of the mouse I’ve listed out the commands for movement
explicitly. This causes the mouse to sometimes just sit there, it repeatedly
fails to move because there is no exit in the direction randomly picked.
Ideally a $MOVE command should find the available exits and pick one of those.

The problem with implementing $MOVE is: we can get a list of exits, we then
pick an exit to go through. Say we pick ‘North’. We then have to reacquire the
locks for the current location and the new location. However once we hold the
locks we need to call the $MOVE command again which (usually) picks a
different exit when called the second time.

I had a variation of the same issue when invoking the $ACTION command. You
would pick a random action, find out you needed to reacquire locks, and then
end up picking a different action to carry out. This is one reason why I am
using the $ACTION command as a proxy, so that I can save some state.

Another reason for using $ACTION as a proxy is that it schedules the next
action. This then raises the issue of only scheduling the next action to occur
if we are not going to be reacquiring locks — otherwise we would start queuing
too many actions. The rescheduling problem is fixable, but not a quick fix. I
need to have an event interface for scheduling, cancelling and other eventy
type things and have OnAction, OnCleanup and OnReset use it. Then the event
package can handle events in a more general manner instead of relying on
specific commands to do the right thing.

So while I have things working, the changes are a complete mess :(

I know that picking a command at random from a list isn’t exactly the pinnacle
of gaming artificial intelligence. It’s a start, and for simple behaviour it
can work surprisingly well. I have more, better plans for the future.

I did find two small bugettes. In the event package, if logging events with
Debug.Events=true, it would erroneously report cancelling an event. It hadn’t
actually cancelled the event, the event had already fired. The other buggette
was in the SAY command, where the initial letter of the name of the speaker
was not being uppercased. This resulted in messages such as "a small frog
says: Ribbit!" where the initial ‘a’ should be ‘A’.

Both fixes are now on the public dev branch.

Only 5 days left till Halloween… /\oo/\

--
Diddymus


  Up to Main Index                           Up to Journal for October, 2018