intfiction.org

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 https://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?