The Future is About Two and a Half Weeks From Now or Maybe a Little More than That (Was: Re: [Reality] Command handling?)

Glyph Lefkowitz reality@twistedmatrix.com
Fri, 14 Jun 2002 01:10:48 -0500 (CDT)


----Security_Multipart(Fri_Jun_14_01:10:48_2002_454)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

From: Christopher Armstrong <carmstro@twistedmatrix.com>
Subject: [Reality] Command handling?
Date: 11 Jun 2002 15:48:02 -0400

> Yo, glyph. exarkun and I are hearing rumours that you have something of
> a sentence replacement dreamed up. Can you explain what your ideas are so
> far so we can take a look-see?

Well, there's a lot to discuss here.

First and foremost, I am planning to integrate Reality as much as possible with
Beyond 2.0, which is the next iteration of Jason Asbahr's definitive white
paper on the topic of virtual worlds.  I'm really not sure at this point what
all the pieces are going to be called when that's done, which will be "reality"
and which "beyond", but I really don't want TR to be a text-only solution from
bottom to top; it should use virtual world abstractions which are more
universal.  I don't want to rush Jason's design, so there will probably be some
delays in my involvement as we work things out for a much broader category of
games than Reality was originally intended to be used for.  (On the plus side,
there are lots of things in the graphical components of Beyond that Reality
won't need to move forward, initially.)

So, that said, the initial motivation I have to do something to sentence will
be to separate the process of parsing text (determining intent) from the
process of dispatching actions (determining consequences).  Each game will need
to both extend the parser and dispatch new kinds of actions.

The parser is -- obviously -- going to be a text-specific extension.  Games
that want to have a text representation will need to implement this in order
for players to be able to request an action from them.  Dispatch will probably
work based on a "prefix" (not a verb) so you can register the prefix '"', 'say
', 'pick ', 'pickup ', or 'pick up '.  Resolution will work from shortest to
longest matched prefix, and each verb will get to do some fairly ad-hoc
nastiness.

After nearly three years (gods... was it really that long?!) of trying to
perfect a moderately strict, non super-smart NLP system for players to enter
commands to a text-based world, I officially give the hell up.  It can't be
done.  sentence.py was a noble experiment, and it has failed.  I've known this
for a while, but I didn't have a better solution, and I had lots of other
things to work on.

The lesson I have learned is that no matter what you get your parser to do, no
matter how well you document it -- believe it or not, there was a time when
Twisted Reality was a project with really good documentation:

    http://twistedmatrix.com/users/glyph/old/twistedmatrix/www/twistedmatrix.com/reality/ripoff.html

Goddamnit, where'd you go, tenth? ;)

Ahem.  As I was saying.  No matter how well you document it, your users will
type the craziest shit you could possibly imagine, because it seems somewhat
reasonable, and they will be surprised that it doesn't work.  If I had a nickel
for every time I had to explain that "say foo to bar" needed quotes around it
in order for the parser not to catch the preposition... well... I'd have at
least five, maybe six nickels.  But that would be one for just about everybody
that used the system aside from me and tenth!

"The craziest shit that you could possibly imagine" does not just mean
unnecessarily verbose english phrases, either.  It means _everything_.  "get
foo 2" "get second foo" "get foo-2" "pick up the # 2 foo" "bob, shut the fuck
up or I'm calling your parents", etc.  In order to catch a reasonable
percentage of this stuff, you need to monitor your users' input and add ad-hoc
hackery to every verb and have a large library of utility functions, to catch
every case where they might reasonably have said something worthwhile.  You
can't really have a tokenizer, either.  For example, individual ' marks and "
marks are common in unstructured user-input and are expected by various mud
conventions.

Once you're done dealing with whatever mangled garbage the so-called "user" has
deposited at your prompt, you only know what they *want*.  You don't know what
they can do.  The plan for doing things at this point is that the parser will
not make any policy decisions, but emit an "Intention", which will be the sort
of new equivalent of a Sentence.  Unlike Sentence, however, this will be an
instance of a user-defined class; a sentence that begins with "pick", you might
parse to an instance of a PickLock, PickUp, or Choose.  Each of these might be
from an entirely different game system.  Each of these _also_ has its own
dispatch rules -- I don't know if you've noticed this yet, but a set of rules
designed for dispatch of take/drop/look/hit doesn't work so well when you're
trying to deal with verbs like "taste" or "unscrew".

One last thing before I go.  I want to move away from the "everything is a
unique object" mindset that TR had before.  This mindset was itself a rebellion
against MUDs where the rules of the game were completely inviolate,
self-contained, always consistent, and fairly boring.  I wanted to have spice
and flair in the objects in Divunal, so I designed a system that revolved
around uniqueness.

I still like this, in a very abstract philosophical light, but unfortunately it
maps very poorly into the real world.  For example; there tend to be more
players than content creators, by an order of magnitude, in any given virtual
world, so you need to make the rate at which players can devour content
_glacially_ slow.  The best way to do this is to provide an enjoyable,
repeatable experience that they can engage in on a regular basis.  Players
complain if this is *too* repetetive, but they need some form of repetition,
otherwise the game is so constantly unfamiliar and weird that they'd never
develop a sense of accomplishment and want to play it more.  This may all be
obvious to you, but it took a long time in coming to me ;-)

I believe a more realistic solution to the game getting stale is having
boundaries between various "game systems" that are thicker-walled than
elsewhere; providing an abstraction for the overall 'game system' as well as
the relationship of each player to each game system.  So there will be a Game
called Combat and a GamePlayerRole instance associated with all players who can
fight called CombatSkill, which will all point to (probably the same) Combat
instance.  I would likely also have a DiscovererSkill which might include
statistics related to aspects of the game like lockpicking.  In addition to
statistics, it would also include the player's default processing code for the
actions involved in that part of the game.  Ideally these GamePlayerRole *Skill
objects (terrible name, I know, working on a better one) would be able to
implement the Reality.IParserEnhancer interface to provide additional rules for
the parser to match against and the Beyond.IActionSource interfaces to provide
new capabilities to the player.

One of the other outcomes of this is that the games would be well-understood by
the player.  I want this to be interactive fiction in which the player *very
clearly understands* what they can try to do, and the game isn't just
guesswork.  It's an adventure; MANY different kinds of gameplay come into it,
but they're all explained through an interactive help system.  If all the
actions can be listed and the parser extensions are well-understood, it should
be possible to provide the player with examples of everything they can do with
a new item when their character understands how to use it.

I still have a lot more thought to give this, since I'm re-treading ground I
haven't walked on for quite some time, as well as waiting to see how the
critical related components of Beyond turn out.  Any comments on the general
direction?

-- 
 |    <`'>    |  Glyph Lefkowitz: Traveling Sorcerer  |
 |   < _/ >   |  Lead Developer,  the Twisted project  |
 |  < ___/ >  |      http://www.twistedmatrix.com      |

----Security_Multipart(Fri_Jun_14_01:10:48_2002_454)--
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQA9CYjsvVGR4uSOE2wRAlvQAJ49vRo3PsqY04LruNfHzTU0JJtBUwCghJFp
w/6O2fyPz/rX38heXC/6gXA=
=JKEl
-----END PGP SIGNATURE-----

----Security_Multipart(Fri_Jun_14_01:10:48_2002_454)----