On Tue, 20 Mar 2001, Nick Moffitt wrote:
> Ever played with the Floyd stuff? Some folks set up a MUD
> with inform once, and they just removed one line from parserm.h.
> Have a look for multifloyd.h in the informlib contrib section of
> if-archive.
>> I don't think the player is as "integrated" as you may think.
No, and that sounds interesting.
> Well, I was just thinking that it would certainly help
> adoption if the system behaved a lot like Inform. I'm thinking mostly
> of:
>> The way the objects are created, and the way the code flows (I
> think that a constructor for a game object should set the name of the
> object as well as the parent (location), just the way that the "Object
> -> ..." line does in inform).
Why? This adds complexity and I don't understand how it creates any
value. Many objects do not have a "parent". Thing("foo")(location=bar)
and Thing("foo",location=bar) seem pretty much equivalent, to me.
> The system should use pre- and post-action rules in a
> dictionary inside an object. Perhaps we'd have before and after
> dictionaries, with names of actions as keys, and functions as values.
I intentionally avoided the pre/post action rules in favor of verbs
because they're harder to make sense of in a "real" programming language;
inform's object system was weak in some ways and I felt that was one of
them.
If you want something similiar you can always use twisted.hook but I think
that for most cases such an idea is inadvisable. Is there something I'm
missing about the pre/post stuff that adds functionality which is not
available otherwise, or makes something common easy?
> The parser should just be ported over, or at least enhanced to
> the point where it supports everything that the informlib parser does.
> The code uses a lot of gotos and is pretty gory, but I think that
> could be easily taken care of.
If you think it's easy, does that mean you volunteer? :)
I do agree that the current parser is in sorry shape; however, making it
inform-style might make the interface (to the parser) more complicated
both for users and developers. However, to automatically parse 90% of
common verbs into "actions" with a higher-level interface makes sense to
me; I've already started doing something like that in CVS, and there are
emerging conventions about how to represent that.
In the meanwhile, though, patches to make the current parser less heinous,
or emulate Inform style, will be graciously accepted.
______ __ __ _____ _ _
| ____ | \_/ |_____] |_____|
|_____| |_____ | | | |
@ t w i s t e d m a t r i x . c o m
http://www.twistedmatrix.com/~glyph/