Ideas to turn a single player adventure into multi-player

The basic idea is old, and I believe that every follower of interactive fiction has already thought about it. There are so many great text adventures with such great stories and sceneries, it is a pity that they are doomed to stay single player adventures! Would it not be great if we could walk through our beloved adventures online, together with others?

The other part is: I used to be a MUD player and developer. Lately, I looked on some LPC source code (this is the language used for programming many MUDs). I found it awful, could not find any documentation and quickly closed it again. It would be great if MUDs could be programmed as easily as Inform 7, for example. How about joining both?

The idea is in my mind for several years now, and I always turn it back, thinking it would be impossible to make a single-player game multi-player. There are good arguments for that. My main interest would be adding multi-player support to Inform 7. That would just rock! (Do You know if any such project already exists? I am sure that I am not the only one with that idea.)

But Inform is inherently single-player. The engine is created to support only one player.

Wait a minute! There are text adventures in which You can switch Your character, so You can control a group of people. Wouldn’t that be a starting point for making a text adventure multi-player?

Imagine the MUD server is just a program that the clients connect to, and internally, it is running a Z machine, for example. The server is really not much more than a filtering proxy for the Z machine. When player X sends command A, the proxy server forwards the command to the Z machine. But it alters the command a little bit, so the Z machine can recognize from whom the command came. For example, it might send to the Z machine: “(X) A”. The Z machine’s parser would be slightly altered, so that it recognizes this as the command “switch into character X, then execute command A”.

Then, the server captures all the output from the Z machine and sends it back to the client.

For a very first, super simple version, this might work. However, more is neccessary of course: When someone enters a room, all the other players in the same room are supposed to see something like “X has entered the room”, while the player who has entered the room should see “You have entered the room”. (I think those messages could be captured with the same mechanism that a single-player game player could “see through the eyes” of an NPC, for example when the adventure involves remote controlling a robot.)

Well, can be done. Just like the proxy prefixes every player’s command when forwarding it to the Z machine, the Z machine can prefix every line of output with the player it is directed to. In that way, a simple protocol can be defined which can be used not only with the Z machine but with every IF system for which someone wrote a multi-player library patch. (Actually, the protocol would be somewhat different. For example, it would be better to use connection IDs instead of player names.)

Of course, there would be more issues to be addressed. For example, commands like undo, save and load must be deactivated. The server would need to create a save file regularly and back it up. Probably, some engine limitations would have to be broken or bended: For a MUD, it would be good to have the possibility of creating objects dynamically. (Still, it is possible without dynamic object creation. But even a moderately frequented MUD would have an enormous number of objects soon.) Some limitations could be overcome by having several Z machines running at the same time, serving different regions of the game world. (When a player goes from one region to another, the proxy transparently switches him to another Z machine, passing all the character’s data to the new Z machine.) I also believe that the proxy would need to be able to have some introspection into the game world and the character’s states.

Another issue is the passing of time. This might be a kill criterion why the majority of existing text adventures would not work in multi-player mode (apart from the structure of the story itself, which is always only around one player and would be inconsistent with several players). Maybe this could also be solved.

Updates are also a most critical issue. How do I update the game world when a bug was fixed? (Sounds like a killer first, but I have ideas on that one.)

You might say that this would be a very great waste of performance. But think again! The Z machine runs lightning fast. (And the other IF engines as well, by the way.) I think they are better suited for MUD development than any of the actual MUD systems, at least if You want role playing flavored MUDs.

Please think about my ideas. What do You think of them? I know, it sounds naive at first sight, but the longer I think about it, the more plausible it seems to me.

Fascinating. This is almost exactly how Guncho works, but I didn’t have the idea until this year - and even then, it started out as nothing more than an April Fools Day gag about something that everyone has talked about but no one had ever gotten around to doing. I guess one other person had gotten close!

• I also used to be a MUD (well, MUSH) player and developer.
• Guncho originally hosted the Z-machine, but now hosts Glulx instead.
• The NPC action mechanism is used to show messages like “vaporware arrives from the north.”
• Player input is prefixed by a connection ID before passing it to the game, and the game prefixes output with tags to direct it to different players.
• It could theoretically work with many other IF systems, although only I7 is supported now.
• Several virtual machines run at the same time, serving different parts of the game world, and the server transparently switches players between them.

However, there are some differences:

• Guncho has no dynamic object creation: players inhabit a fixed set of generic bodies, and everything else has to be created by the realm author.
• The server knows almost nothing about what’s happening inside each game. Instead, the game can push and pull information from the server as needed. The only character data that follows a player from realm to realm is their gender, description, and which direction they’re traveling (to show an appropriate arrival message).
• There are no save files: realms can save data by pushing it to the server, but the server doesn’t bother saving the entire game RAM.

Guncho deals with the passage of time by adding a rulebook for real-time events and providing access to the system clock.

Updates are handled by:

1. Asking the game for the location of each player. (Since object names and numbers may change, the location is given as a list of directions from a specially marked room.)
2. Telling the realm to push all the data it wants to keep.
3. Restarting the virtual machine.
4. Inserting each player back into the restarted realm in the saved location.

Wow! I’ve just come across this topic and found it encouraging to find other people thinking along the same lines as me.

I, too, have had it in my head for several years now to develop (or perhaps help develop!) a multi-player IF framework. I’ve thought about different ways in which it could be done and came to the conclusion that something which converts an Inform file into another language which will then be compiled into an executable, complete with a pre-configured server framework around it - I was leaning towards C# as the syntax is very similar to Inform.

However, once I started looking, I came across Inform 7 (I had previously used I6) and almost immediately came across Guncho, which I’ve now started looking into using in anger.

It’s a bit of a steep learning curve as not only have I got to try and figure out I7, but I also need to figure out how Guncho changes things behind the scenes too.

I’m keen to progress my realm and would like to offer any help I can to Vaporware and others to progress the development of Guncho: it saves re-inventing the wheel and perhaps helps make the current one a little more rounded in places!

Regards,
Paul.

It might be interesting for my WIP to be multiplayer in some respect, like different players can inhabit different robot shells.

Found I7 last week, found Guncho last Thursday (literally in this instance). While its limited in regard to things that most MUs can do (finger info, stats, combat, persistent saving everything, realm wide administrative abilities, bulletin boards, item creation, a few other things) …at least I think, from what I’ve read off the wiki, that these things either aren’t implemented, or not fully implemented, I like the ideas it brings forward from the ideas of cooperative game play, role play potential, competition, and all from the perspective of being firmly planted in the realm of IF, rather than outright attempting to be another MU language (though I could see the ability to become a relatively easy to implement mud/mush/whatever once the rulebooks are written for those of us that aren’t sure, or able, to write the proper code.)

the advantage, as I see it, that doesn’t seem to be taken advantage of by many mush’s/muds, is that inform already has a robust method of dealing with npc’s (look at Emily short for resounding proof there.) That could most defiantly help for the wallpaper npc’s that you would need in a quasi believable world that’s populated by more than just heroic/villainous sorts.

There’s actually a multiplayer game written in Inform 6 based on Werewolf.

A less interesting way (but still potentially useful) to make a single player adventure multiplayer is to let all but one player spectate (or perhaps to allow both of them to commands if they want to). This would allow people to play together (as if they were in the same room), talk to each other to make decisions or suggestions of what to do, etc.