I’m just curious if anyone has been working on a multiplayer T3 game, whether full-fledged or as a proof-of-concept. If I wanted to where would I start?
Start with webui.t and look at what it provides for you in the way of session handling. For a true multiplayer game you would need to change what happens when clients connect - allocate a player object, for instance, which gets discarded (or taken over by AI) when the client disconnects.
webSession looks promising - specifically the addClient and removeClient methods.
Event handling is already per-client but you will need to expand the library’s logic for reporting input and output to others. Right now output goes through the OutputFilters and gets broadcast to all attached clients. You probably want to divide output into at least two streams - one for player feedback and the other for nearby players. I don’t know how much help the adv3 support for POV messages will be, though it would be great if it could do some of the heavy lifting.
I have a multiplayer game in the embryonic stage but nothing in code yet. I’m planning to write my own library since a lot of what adv3 offers in the way of parsing and world modeling isn’t relevant for my goal of a keyword based text MMO/MUD.
I was reading up a little on tads-net earlier; am I correct that if I wanted persistent connections (like a telnet or websocket connection) I’d have to set up some kind of long-polling through the tads web server? Maybe the basics are there to incorporate websockets? I’m thinking of what I would need for something more like a MUD rather than a persistent browser game for example.
The system library would need to be extended with support for other protocols - at the moment it only does HTTP.
The Web UI implements AJAX style long-polling. That may be sufficient if you remove the logic that terminates a game session after five minutes with no players connected.
For very long running games I would be a bit concerned about VM stability or resource depletion. I don’t know of any specific issues but it’s not a scenario that comes up in normal use, and you don’t want to discover it when your MUD loses six months of player data.
So there’s a need for external storage, probably DB driven, so you can recover state after a shutdown. If you get that working reliably you can leave the five minute termination check in place; that would ensure the recovery code stays well tested.
I’m slowly but surely working on the next version of Guncho (a multiplayer IF system very much like a MUD), and one of its features will be the ability to support more languages than just Inform. I’d love to add TADS to that list, but I’m totally unfamiliar with T3 and I don’t know what’s involved in embedding the T3 VM or how much modification its library would need for multiplayer support.
(For I7, Guncho silently switches the player between the person who types a command and the others who witness it, running the “report” rules multiple times with the player as an NPC to generate the appropriate responses.)
This might make sense for I7, but not for Tads. This should be done in Tads code so that it works with all interpreters instead of introducing a special interpreter for this.
Of course. The point of that design was to take advantage of the work that had already been done for I7’s action system, so authors could use the knowledge they already had. If TADS has a different way of doing it, great! Guncho just needs some way to pass messages in and out - what the game does with them is its own business.
Well, there are advantages to hosting a game on Guncho, especially for “something more like a MUD”: it gives you player profiles, access control, and collaborative editing; you can link your world to other games; you don’t have to leave your computer running all the time, etc.
But there are also advantages just in having a common programming interface for the stuff that all multiplayer IF has to do, like directing messages to players or reacting when a player connects. Many of the library changes you’d need to make for multiplayer IF are the same no matter how the game is hosted, so if you’re designing a multiplayer IF library, it’d be good to keep that in mind and build in some abstraction so your code and authors’ knowledge can be reused.
That’s a highly interesting idea, I wasn’t looking at it that way.
However I have been working on writing a mud where you can use any programming language to write the game services. I feel like these two things are linked but practically speaking I don’t know how yet, food for thought!
Do you mean so a multiplayer game would run in an interpreter like Gargoyle (for which I don’t see much of a point), or just so it won’t crash if you open it with Gargoyle, or as some sort of future groundwork for multiplay interpreters that also run single-player T3 games?
That sounds a lot like what I’m doing! My project is at bitbucket.org/jmcgrew/guncho/ if you feel like collaborating. 
There’s a good chance we can at least come up with some common interfaces.
I have logged into Guncho in the past, but I only have a foggy idea of how it works. Is it correct that your server talks over a system pipe to a modified I7 Glulx interpreter (one VM instance for each realm), passing player commands in and routing messages out?
For my mud I’m a little stuck on the inter-service messaging right now. It seems like my choices are to choose some format (which probably won’t support, for example I7 or T3), or write my own message networking for every language I want to support (not practical as I want all languages 
). Guncho would seem to fit in this second option, where the service language would need some way to talk on the Guncho server pipe.
I should say that really I don’t want game service authors (analogous to Guncho game authors) to worry about the messaging at all.
As it stands now can the Guncho server process send messages to an IF VM running on a different server?
Basically. It hosts the VMs in the same process and uses a .NET interface instead of a pipe, but it’s still passing messages as text through the standard read and print operations.
The server sends in player commands prefixed with a player ID, and system events as specially formatted commands. The realm sends out text with embedded tags to direct output to different players, and “out of band” text on a separate FyreVM channel to make special server requests (although those could be done with tagged text on the main channel instead). The server responds to those requests through the regular input stream.
However, I’m not convinced that this is the best interface for all platforms, so the new version has a more abstract message system (see below).
The new version represents messages as objects, and leaves the question of how to get them in and out of the realm up to the module that implements the realm type. The realm instance is just an object implementing Guncho.Common.IInstance that’s provided by some module selected by the realm author.
A realm written in C# could implement that interface directly and deal with the messages in their “natural” form, while an I7 realm would have a wrapper provided by the I7 realm module that manages a VM and converts messages to and from text. That conversion between message objects and text is available for other modules to use if they want, but they’d also have the option to use something else. For TADS, maybe the game would register an object and messages would become calls to its methods.
I think writing special code for each language is unavoidable. Even if you use a standard text interface, you still need to modify the TADS and Inform libraries to speak it, and you need to supply parsing and printing functions in general-purpose languages if you don’t want authors to have to write their own.
That’s easy enough for IF languages, just build it into the library. For general-purpose languages, you can at least provide code to handle the message formatting.
Currently all the VMs run in the same process. If I wanted to add networking, one way would be to write a module that passes messages over a socket, probably using the same text converter. Another would be to use .NET Remoting so the IInstance is actually running on the other server and passing message objects across the socket.
Great, that sounds like the way to go.
Regarding Tads 3 Mike Roberts posted the other day on the T3 development list about work resuming on the Mercury library (a lighter weight alternative to the standard Adv3, see tads3.livejournal.com/8607.html? … 471#t45471 ). So maybe this is a good opportunity to hook up Guncho and T3 without having to deal with the whole of Adv3.
Given that T3 is written in C++ so that it’s portable to every platform and OS, while Guncho is a C# thing for Microsoft, I don’t see how T3 would “hook up” with it.
C# and its runtime environment are ECMA standards with multiple implementations on multiple platforms, and I intend to keep Guncho compatible with Mono so it can run on Linux and OS X (as I’ve done for other projects such as ZLR). Like I said, I don’t know exactly what’s involved in embedding the T3 VM, but the two main approaches to communicating between C# and C++ would be to put the C++ code in a shared library and use P/Invoke or put it in a separate process and use system pipes.
You need people to port the GUI (otherwise it’s gonna look like ass), unless you intend to support various environments (mainly KDE and Gtk-based ones like Gnome) on your own. And if you don’t use C or C++, good luck with finding anyone. .NET is widespread on MS platforms. People on other platforms don’t have any use for it so they never use it.
Guncho consists of a web site and a MUD, which you can use with whatever browser and MUD client you like, so there is no GUI to port. If I were to develop one – say a client with an integrated editor – there are cross-platform libraries I could use such as Gtk#. But the first step would be to make a public API, and at that point anyone could write the client using whatever tools they like.
That’s not true, but look, I’m not going to bother justifying my choice of language to someone who can’t take the time to click a link and see what my 4-year-old project is about. Your uninformed opposition to all things Microsoft is duly noted.