[Reality] Re: other TR tasklist items

Glyph Lefkowitz reality@twistedmatrix.com
Sat, 22 Jun 2002 07:06:00 -0500 (CDT)


----Security_Multipart(Sat_Jun_22_07:06:00_2002_806)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hope you don't mind; I'm Cc:'ing my response to the list, because these are
generally useful questions...

From: Allen Short <washort@twistedmatrix.com>
Subject: other TR tasklist items
Date: Sat, 22 Jun 2002 04:04:57 -0500 (CDT)

> i keep hearing you say you wish you'd never used the 'intelligence'
> system used by Thing for user interface. what should be done instead?

Wow... where to begin.  There should be parallel simulation on the client.
There are too many notifications that the user *might* want to be aware of but
might want to ignore; lots of things that are quiet, subtle updates that they
could see if their visual focus were on one area of the screen and not another.
This indicates that the client should be receiving more information than the
user can physically see at once in some cases (this is *especially* true of
things that, e.g. interrupt you while you're reading a book.  The hacks we went
through to make you "look up" when that happened... oy vey...)

There should be real event notifications, not willy-nilly method calls all over
the place.  Events should be tracked, so you can record and replay interactions
on the client.  Events should be ignorable so the client can be extended.

There should be a sensible way to "posess" someone in the game; there is no way
to redirect the calls on "intelligence" to another object currently.  (This
could be hacked without "real" events, but let's not.)

> also, do we want to rename all the *Hears methods?

Yes.  Better yet, re-implement them using real events and let's actually make
sensory channels and notification types and all that good stuff.  Given the
game-system-not-unique-object focus of the New Reality, let's also construct
event types rather than having ad-hoc flavor text inline with the code.

(OK, ad-hoc flavor text is sometimes useful, especially for debugging, but
let's try to make that a utility method and not a core part of the API)

> and why is all this gunk from Player moved into Thing?

Because we have no sensible model for AI yet, so Thing needs to be able to
"hear" messages that are sent to the room and parse them.  People have been
telling me I was an idiot for doing it this way for many years:

    http://twistedmatrix.com/pipermail/divunal-devel/1999-June/000008.html

and I have finally decided that they were right.  Changing things to use real
events (as above) will probably not make much of a difference in terms of the
ratio of code in Thing to Player, but it *will* make it a little more sensible
that said code be in Thing.

> the ambiguity between 'locate' and 'find' is particularly bothersome.

Uh... yes.  I really should have thought up better names for those.  Probably
'lookAroundFor' and 'findInContents', respectively, would have been better
names, but I think that 'locate' was primarily support for sentence and will
probably be moving into the parser anyway (or into parser support libs).

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

----Security_Multipart(Sat_Jun_22_07:06:00_2002_806)--
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA9FGgqvVGR4uSOE2wRAq+0AKCkNccAjC9gYRIyF4SaUJpeN0H/MQCcC91b
V1YrcrP5jOh3AkSC50qOK2E=
=360/
-----END PGP SIGNATURE-----

----Security_Multipart(Sat_Jun_22_07:06:00_2002_806)----