![](https://secure.gravatar.com/avatar/a171999e450a664faab40c2bb8aa9cbc.jpg?s=120&d=mm&r=g)
Is there any push to port the inform library over to twisted-python in its entirety? It strikes me that the current "ruins" demo is lacking in many features simply because the library is so spare (for instance, "get all" is not implemented). I'm interested in this largely because Inform is non-free software, and I'd like to get back into writing interactive fiction. Inform itself was never more than just a simple bytecode compiler and object system, while the library was its true benefit. -- You are not entitled to your opinions. 01234567 <- The amazing indent-o-meter! ^ Matt McIrvin: the Nikola Tesla of tab damage.
![](https://secure.gravatar.com/avatar/e1554622707bedd9202884900430b838.jpg?s=120&d=mm&r=g)
On Sun, 18 Mar 2001, Nick Moffitt wrote:
Is there any push to port the inform library over to twisted-python in its entirety? It strikes me that the current "ruins" demo is lacking in many features simply because the library is so spare (for instance, "get all" is not implemented).
Currently there is no such push, because Inform's library is conceptually single-player only (this is evidenced by the amount of global state that it maintains, how the player is treated as a facet of the world rather than just another object, etc). However, if you're interested in seeing inform-like functionality implemented, we'd love to integrate such a thing. Even better if you can make it more multi-player aware.
I'm interested in this largely because Inform is non-free software, and I'd like to get back into writing interactive fiction. Inform itself was never more than just a simple bytecode compiler and object system, while the library was its true benefit.
We do have plans for a twisted reality standard library, but they are haphazard at this point. Look in twisted/library/ for what we've done so far. ______ __ __ _____ _ _ | ____ | \_/ |_____] |_____| |_____| |_____ | | | | @ t w i s t e d m a t r i x . c o m http://www.twistedmatrix.com/~glyph/
![](https://secure.gravatar.com/avatar/a171999e450a664faab40c2bb8aa9cbc.jpg?s=120&d=mm&r=g)
begin Glyph Lefkowitz quotation:
Currently there is no such push, because Inform's library is conceptually single-player only (this is evidenced by the amount of global state that it maintains, how the player is treated as a facet of the world rather than just another object, etc).
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.
However, if you're interested in seeing inform-like functionality implemented, we'd love to integrate such a thing. Even better if you can make it more multi-player aware.
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). 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. 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. -- You are not entitled to your opinions. 01234567 <- The amazing indent-o-meter! ^ Matt McIrvin: the Nikola Tesla of tab damage.
![](https://secure.gravatar.com/avatar/e1554622707bedd9202884900430b838.jpg?s=120&d=mm&r=g)
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/
![](https://secure.gravatar.com/avatar/a171999e450a664faab40c2bb8aa9cbc.jpg?s=120&d=mm&r=g)
begin Glyph Lefkowitz quotation:
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.
very well.
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?
Aha, I had not seen the hooks yet.
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.
Hmmm. Being able to handle more sentence forms would be nice, though.
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.
Right. That's mostly what I was thinking of, and of course having default functions take place for the "Category 1 and 2" actions from the inform manual. If you're on this, then I suppose all is well and twisted. I'm mostly playing with the ruins demo, and trying to figure out where it fails. Being able to take scenery, and the mushroom's picking actions not working seem like big ones at the moment. I realize that the ruins demo is probably not a priority, but I'd like to see all of the sample games (alice, ruins, etc) re-implemented as a proof of concept. If anything needs my volunteering, then I guess it wuold be polishing up the samples. -- You are not entitled to your opinions. 01234567 <- The amazing indent-o-meter! ^ Matt McIrvin: the Nikola Tesla of tab damage.
![](https://secure.gravatar.com/avatar/a171999e450a664faab40c2bb8aa9cbc.jpg?s=120&d=mm&r=g)
begin Glyph Lefkowitz quotation:
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.
For reference: ftp://ftp.gmd.de/if-archive/infocom/compilers/inform6/library/contributions/Verbs.htm That's got a pretty good list of actions, their associated verbs, and the format of objects and predicates. There are some errors, but it's got a pretty good list. -- You are not entitled to your opinions. 01234567 <- The amazing indent-o-meter! ^ Matt McIrvin: the Nikola Tesla of tab damage.
![](https://secure.gravatar.com/avatar/a171999e450a664faab40c2bb8aa9cbc.jpg?s=120&d=mm&r=g)
begin Glyph Lefkowitz quotation:
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.
Right, I see now. You'd much rather just have the verbs implemented in the abstract class direct object, and overload them as necessary. Yeah, using a real object system can help. -- You are not entitled to your opinions. 01234567 <- The amazing indent-o-meter! ^ Matt McIrvin: the Nikola Tesla of tab damage.
participants (2)
-
Glyph Lefkowitz
-
Nick Moffitt