[DGD] Game interface question (brainstorming) (fwd)

[Bart van Leeuwen]

Heh, this should have gone to the list alos.

---------- Forwarded message ----------
Date: Sat, 29 Nov 2003 23:34:54 +0000 (GMT)
From: Bart van Leeuwen <bart at wotf.org>
To: Noah Gibbs <noah_gibbs at yahoo.com>
Subject: Re: [DGD] Game interface question (brainstorming)

Hey Noah,

While I am not very aware of the internals of the Phantasamal project, I
am facing similar choices for my own project, so maybe my thoughts are of
interest to you still.

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 (for example home/clear screen
messing up scrollback buffers).

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.

Because of that, we opted for a setup where a game object can
request a 'direct' connection with the user input and output, this will always go
through the (kernel) user object, but once permitted, is pretty much
transparant. (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.

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

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.
This provides a clear seperation of privileges and functionality, which
imho helps a lot keeping your design clean and secure. As a concequence,
the user object should delegate required features to the player object
using a clearly defined and restricted api.

Hope this helps.

Bart.

On Sat, 29 Nov 2003, Noah Gibbs wrote:

>   I've asked this question on the Phantasmal Forums on
> SourceForge, but I think it's of broader interest so
> I'm going to ask it here also.  There's a long-winded
> explanation of why I'm curious.  If you're feeling
> helpful but don't want to read this much, skip to the
> bottom and read the last couple of paragraphs.
>
>   The upcoming 0.015 release of Phantasmal has had
> some major restructuring.  Those of you who follow
> Phantasmal closely will have already seen the new and
> extensive API documentation, and the crude beginnings
> of "how to set up a Phantasmal-based MUD" that got put
> up also.  Most configuration files have moved out of
> the /data directory, and more will be doing so shortly
> until there are none left.  Everything is going to be
> under one /usr/foo/ directory or another.  I consider
> that a good thing.
>
>   Specifically it will soon be possible to set up a
> Phantasmal-based game without modifying anything in
> /usr/common or /usr/System.  You just add a bunch of
> files under /usr/game to set up your specific game.
> This is a lot like how the Kernel Library works -- the
> Kernel Library gets its privileged operations from the
> DGD driver, puts its internal files into /kernel, and
> delegates privilege to files in /usr/System.
> Phantasmal gets its privileged operations from the
> Kernel Library (through /usr/System), keeps its
> internal files in /usr/common, and delegates privilege
> to files in /usr/game.  So far, so good.
>
>   For daemons and objects, it's mostly pretty easy --
> certain operations are considered fully safe, and
> anybody can call them.  Many operations are internal,
> and only Phantasmal stuff (in /usr/common or
> /usr/System) can call them.  But most operations,
> especially exported, documented operations, can be
> called only by a file under /usr/game.  That's what
> I've been doing all this API documentation for --
> stuff that can be called by anybody, and stuff that
> can be called only by /usr/game.
>
>   Okay, so...  What's my question?  I know that stuff
> in /usr/game should get full control over the user's
> console and what he sees.  It should be able to fully
> override commands, parsing, etc.  That just makes
> sense.  But what should the interface be like?
>
>   My two favorite choices are:  use a very restricted
> API, or just let /usr/game declare its own version of
> the user object that inherits from the Phantasmal one,
> just like the Kernel Library does it.  The restricted
> API would instead have the game stick "user states"
> into Phantasmal's user object, which is kind of like
> Melville's "input_to" function except that the input
> goes to an external object in /usr/game instead.
>
>   Thoughts?  Preferences?
>
>
> =====
> ------
> 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