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