I wrote my own MUE with a port of the Inform 6 Library

(Sorry if this isn’t exactly the right category for this post.)

[TL;DR: Floating Objects don’t work for a multiplayer environment. Can you suggest design alternatives?]

I realize that there is already Guncho, but I don’t like that the Guncho system is just a .NET wrapper around a custom interpreter running specialized inf code.

So I wrote my own mud/mue, and ported the Inform 6 parser, grammar specification, and English and Verb libraries to Ruby.

However, I have reached a point where I will start needing a little more help than just the small questions I’ve asked about the Inform Parser code so far. (The parser port of mine is still a bit wobbly. I need to complete disambiguation. I also need to flesh out the Locale routine, which is rather imposing.)

But, to the point of this post:

I need to find a design replacement for the Floating Objects implementation in Inform. Floating Objects don’t work for a multiplayer environment.

I realize I will probably have to give some more detail. I will and can, but for now, I was just hoping to start a discussion about some design considerations for the case when an object such as a door must exist in two different rooms as more or less the same object.

It would be nice if I could interact with this object as if it were actually a child of two rooms. However, this is not absolutely necessary. Nor would I like the idea at all of allowing objects to actually have two parents.

I hope that I can inspire some good discussion here. I am well on my way with this project. It is currently being used to host a game which is in its build-phase being built by three of my friends.

Please direct any questions off the topic of this thread to nels.n.nelson@gmail.com.

Thanks in advance you guys! I’ve been using Inform since I was 16, and I’m 33 now. I love this community. :slight_smile:

I’m a little out of my depth here, but I think I understand the problem. If a floating object (such as the sky) is invisibly moved along with the player each time the player moves, in a MUE the object would disappear from the scope of player A when player B moves to a new room.

One solution would be to spawn an instance of each floating object for each player. This would work, but you would need to figure out how to handle the case when two players are in the same room, because you don’t want there to be two instances of the sky object in scope.

If a door is implemented as a floating object (with a found_in of room_A and room_B) then it gets messy, because the door can change state. If player A and player B are in the same room, and then player A goes through the door and closes the door, player B needs to see a closed door.

The way TADS handles doors is by creating two door objects, one in room_A and one in room_B. These two objects are linked in such a way that when one object changes state, it sends a message to its linked object and the other object changes state in the same way.

Ooh, interesting question (and I don’t have time for a long answer right now).

In the abstract, the I6 library does most of its “where is a thing” checking through top-down tree iterations. (The scope test is the core case; also the top-down process for printing a room description.)

The add_to_scope mechanism is a way to “multi-locate” something into the top-down iteration tree. If you extend that to room descriptions, you’ll have a lot of what you need.

There are plenty of parent tests, too, but they’re ad-hoc rather than systematic and you’ll have to deal with those on a case-by-case basis. Just be careful not to introduce too many scope iterations into a turn… it might be wise to have a double-ended mechanism, where object X can say “add object Y as one of my iteration children” and object Y can say “add object X as one of my iteration parents”. There’s more data to keep in sync that way, but it gives you efficient checks both upwards and downwards.

Jim, thank you. That’s awesome information. I never really got much into TADS, but I deeply respect the technology, and it is encouraging to learn that this approach is their solution for the problem.

It was the very first thing that I thought about – and I may very well wind up doing it this way. I am reluctant to write code to maintain the states of such “mirror” objects because I am lazy. :smiley:

However, it seems far preferable to actually breaking my nice neat object tree model. :slight_smile:

Thank you so much for your thoughtful input, Jim.

Thanks for this zarf. This seems like a good way to seamlessly integrate the idea of a shared object into the scopes of multiple players at once. It would let me maintain the state of a single object, and have a more-or-less single entry point for the shared object into processes that deal with room contents and events.

Basically, whenever something happens in my system, it publishes its action description to its subscribers, which are in turn either implicit (mostly determined by the results of the InScope method) or explicit. I could just add an extra step to pull in the shared objects.

However, I am not sure how I might conventionalize this.

I suppose I could just come up with a new relationship, called “shared_with” or something. (Currently, all room exits and other specialized relationships are established using a “link” pattern. I.e.: nw_to -> Some Room)

But then, I would have to sort of reverse scan for those links during the InScope routine. Sorta meh. Still thinking…

Zarf, man, this is very insightful. I will totally investigate the add_to_scope line. Thank you so much.

This project has forced me to understand the design decisions of Inform way more than I ever thought I would need to. It’s been an awesome experience, but a complete maze of twisty passages. :smiley: Especially with all the freakin’ labels and jumps? ZOMG.

FWIW, the next version of Guncho will do a bit more than just shuffle text between players and VMs, supporting more languages and runtime environments. The Z-machine/Glulx based design was necessary for supporting I7, though.

Well, the Guncho solution is to switch POV several times per turn, updating the floating objects each time. If two players in different rooms can both see a backdrop, it will be in the right place during each player’s report phase, even though it’s never in two places at once.

Since you have a system that’s inspired by Inform but not actually subject to Inform’s design constraints (such as the Z-machine’s hardware object tree), I’d recommend taking another look at allowing objects to have multiple parents. Floating objects and scope tricks are approximations of that; why not implement the real thing? Another alternative would be to generate proxy objects in each location, which would forward most calls to the original object, so they’d all be interchangeable except for having different locations.

Oh, Guncho is still being actively developed? I played with it a while ago, but it was pretty much a ghost town at the time…

It’s still a ghost town, I’m afraid, but I have gotten back to developing it (currently in the middle of some major refactoring). Perhaps if I build it, they will come.