[DGD] Game interface question (brainstorming)

[Noah Gibbs]

  Oops!  I meant to send this to the list, and didn't.

-------------------------------------
Bart,

  Thank you for your quick reply!  My thoughts are
below.

--- Bart van Leeuwen <bart at wotf.org> wrote:
> While full control over a users screen can be
> desirable (we need it for
> example for playing ansi animations and similar
> stuff), anything that
> is not going to just produce text + colour codes
> will very likely disturb
> terminal functionality on the client side

  This is true.  If a game-side user code can send
anything it wants over the connection, then it can
also  screw up the terminal quite badly.  There's a
tradeoff, though, because games might want to send
international characters, MUD-client protocols and
other binary data that would be bad for a regular
telnet terminal.  I'm not sure how to balance those
needs.

> Also, to support functionality like snoop and
> optional logging or (like we
> happen to do) a game provided replay/scrollback
> buffer, it is a good idea
> to keep all user i/o in a controllable object so you
> also have control
> over when game objects get free access to the
> terminal.

  Well, yeah, but you get that even with inheritance. 
Since only objects in /usr/System can directly send
information (I'm using the Kernel Library), I'll
automatically have a basic level of control because
the game's User object will need to use the inherited
functions for all privileged operations.  I'm just not
sure if I should have them write objects that register
themselves with the User object (kinda like the
wiztool works) or directly inherit from a User object
library and do it that way.

  But snooping and logging are easy, even with the
inherited interface.  You can also enforce what
characters get sent that way, though I probably won't
for Phantasmal.

> (set an input and/or output object, and
> that object will get
> receive_message calls whenever something comes in,
> and send_message will
> do the expected thing as well, however, the (kernel)
> user object will sit
> inbetween and ensure that logs/snoops/scrollback
> buffers etc are updated.

  This actually sounds a *lot* like how the inherited
interface would wind up working.

> Optionally, this allows you to put filters in place
> to translate terminal
> controls as to support odd or user configurable
> terminals.

  And this sounds more like how user_state objects
work, except that they can easily push and pop each
other, so filters can add and remove other filters in
a very dynamic way.  I use that for scrolling text and
for editing object descriptions.

> I personally dislike allowing inheritance of the
> user object outside the
> kernel, I prefer a clean seperation between the user
> object as a kernel
> level interfact to a users terminal, and the player
> object as the non
> kernel object that interfaces with the game on
> behalf of a user.

  Bear in mind that the privileges *would* be
separated this way.  I'm very careful to
access-protect almost all my function calls, and the
inherited user object would gain privilege mainly by
carefully-selected static function calls that it could
make.  So the user-supplied object would still be
going through a layer of security.  That's how the
Kernel Library works, too -- Phantasmal's
/usr/System/obj/user inherits from /kernel/lib/user,
and the Kernel user object exports a few
carefully-chosen functions to let me do my I/O. 
Similarly, an inherited interface would still only
give limited control to the game-supplied user object,
and there would still be an API.  It's just that the
API would be called as static functions, not with
call_other().

  I'm definitely not in favor of passing along every
Kernel-supplied API function unmodified.  That would
be silly.  I'm just not sure whether inheritance or a
separate object makes a cleaner-feeling interface to
this for a coder.

  Your comments have been very useful -- mainly you've
convinced me that there's not much difference between
the two approaches, which I hadn't fully realized
before :-)



=====
------
noah_gibbs at yahoo.com

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd