[DGD] Game interface question (brainstorming)

[Bart van Leeuwen]

Noah,

On Sat, 29 Nov 2003, Noah Gibbs wrote:

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

Heh, I bet that went wrong because my initial reply was not to the list
either.. let me forward that one to the list as well..

Anyway... I do not think there is much of a difference in what you can
achieve technically between the 2 options.

I personally like the seperate object idea, it feels cleaner to me, and in
fact it may make your access protection a bit simpler.

>
> -------------------------------------
> 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
>
_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd