Up to Main Index                              Up to Journal for July, 2015

                     JOURNAL FOR TUESDAY 21ST JULY, 2015
______________________________________________________________________________

SUBJECT: You want it all? You can't have it all!
   DATE: Tue 21 Jul 20:48:18 BST 2015

Back and coding again after getting rid of the dreaded lurgy. Working on the
commands and exit changes and while doing so came across an old issue I
thought I'd sorted out. There is still an issue where a Narrative attribute
can be confused for an Inventory attribute - in fact I still have a BUG tagged
in the 'look' command source.

I've also been asked if I will be implementing the 'ALL' behaviour for
commands as implemented in the Java version. Also will I be implementing
multiple items for commands. Some examples:


  GET ALL
  GET BELL BOOK CANDLE


There is actually a bigger issue here - that of players 'competing' over
items. If two players type 'GET ALL' at the same time who gets what? Does the
first player picked get everything? What happens when you have a player on a
much faster or slower connection? As I see it there should be some fairness
and a level playing field for all.

So I've given this some thought. One of the first things I think should be
implemented is command rate limiting. So you can issue a whole bunch of
commands - maybe the client you are using lets you define macros - and they
are queued up and executed one at a time but no quicker than, say, one command
a second or something. This would level the playing field a bit for slow or
fast connections - or clients with macros.

This then leads to a solution for the 'GET ALL' and 'GET BELL BOOK CANDLE'
examples above. What could happen here is that the ALL examines the location
and finds the items 'BELL', 'BOOK' and 'CANDLE'. Then the commands 'GET BELL',
'GET BOOK' and 'GET CANDLE' are queued up and carried out. For the second
example the same commands are queued up and carried out for the specific
items. In effect the commands are just expanded.

Now when two players issue 'GET ALL' they both execute the same commands and
they are interleaved by the Go scheduler - or maybe some custom code - and you
might get one item but not the others. Even if a player issues 'GET ALL' a
little later than the other player they might still get something :)

Things will start getting interesting when expanding commands such as 'TAKE
CHEESE BREAD APPLE LUNCHBOX' which would expand to:


  TAKE CHEESE LUNCHBOX
  TAKE BREAD LUNCHBOX
  TAKE APPLE LUNCHBOX


In this case we would have to assume that the last item on the command is the
container to take the other items from. It would also be nice to implement
stop words in the parser so we can type commands more naturally:


  TAKE CHEESE BREAD AND APPLE FROM THE LUNCHBOX


Parsing is a huge area where things can get very interesting if you like
working on natural language parsing and processing problems :)

If anyone has comments on this, or better ideas, I'd be glad to hear from
you! As always drop me an email and we'll have a chat: diddymus@wolfmud.org

--
Diddymus


  Up to Main Index                              Up to Journal for July, 2015