WebSocket support?

[DavidRieman]

I did a bit of exploration for #46 to find out how hard it would be to have an admin command open a web page for a light web-based MUD client. That route is problematic so far, but...

Fleck was a really easy to use .NET Core NuGet package for WebSockets. Test code was pretty much straight from the Fleck tutorial example, like this:

var server = new WebSocketServer("ws://127.0.0.1:4001");
server.Start(socket =>
{
    socket.OnOpen = () => socket.Send("WELCOME!");
    socket.OnMessage = message => socket.Send(message);
});

When I connected to it with Telsocket, it just worked - the "WELCOME!" which I put in to simulate giving an automatic splash screen appears. Type a thing in Telsocket, hit enter: OnMessage parrots that back to us. It's easy to compare this interaction being much like a telnet client in this form. So, imagine OnMessage just routed the line to the same command handler as Telnet connections. And when we receive data to send back, we just wrapped it appropriately for a WebSocket response, formatted for some web-based MUD client's protocol. This feels really within reason to support.

However, are there any good WebSocket MUD protocols/clients out there, that aren't proprietary? Are there any which would be easy to support as a second, raw-output-centric port, to co-house Telnet-based and Web-based players? If not, if we had to build our own light web-based interface (some day), I imagine we'd want to keep it simple, but ready for options for admins to expand on. Like adopting a JSON format for responses:

{
  "type": "raw",
  "out": "Lines of ANSI-color-formatted strings here, exactly as would be sent to a Telnet client.  Followed by prompt > "
}

and then later if we wanted to expand on this to have a few specific renderers for specific scenarios, we could do so. Like:

{
  "type": "room",
  "name": "Damp cave",
  "description": "Fungi lines the walls of ...",
  "image": "http://path/to/room/image",
  "exits": { ... }
  "things": { ... }
  "players": { ... }
}

which would allow the web client to build a UI around the context of the response, maybe giving clickable dropdown menus on things for quick actions, or whatever.

Anyway, WebSocket support probably wouldn't become a priority within the 1.0 timeframe (and certainly not if it means having to build our own client from scratch or even complex changes to support an existing one). But I wanted to get the idea out here for thinking and potential discussion anyway.

[ghost]

I know WrittenRealms (written by Thibaud Morel l'Horset using Python) uses websockets and provides an open implementation of his client at :

https://github.com/teebes/herald

Also Eric Oestrich of the ExVenture mud framework (Elixir), the grapevine inter-mud chat protocol and co-host of the [Titans of Text](titans of text) podcast would probably be a person very much interested in developing a standard and probably Thibaud as well.

I think I'd probably start just creating the bare minimum web client sans all formatting just to get the ball rolling and prove out the general notion and then start thinking about encoding formatting, maybe starting with looking at what those two have done. Reaching out to them afterward would seem to be a logical next step.

As project champion of wheel mud you might consider reaching out to the Titans of Text podcast peeps and maybe do an episode talking about your goals. It would probably be a good way to attract some developers to the project. There must be scads of .NET programmers (relative to Elixir programmers) who listen and might like to contribute. I think the on-boarding process to wheel mud is pretty good...you've been helpful and encouraging, the docs are good, and I think a lot of the pain points / friction have been addressed by yourself since I started poking around.

Just my .02 of course but personally I like C# and would like to see a mud grow up based on the cross-platform dotnet ecosystem.

[DavidRieman]

Yeah, I did encounter WrittenRealms recently while researching options for #46. While it didn't fit the bill for those needs, I do love the aesthetic. It is a beautiful client. It would be a fantastic first candidate to assess what it would take to hook it up such a client to a WheelMUD WebSocket for a server that accepts both Telnet and WebSockets client connections.

I think we can start down this road with even less than a bare minimum web client - starting with just having a WebSocket port configurable in app.config that treats connections very much like a Telnet connection. Testing at that stage would require connecting with a tool like Telsocket to manually type commands and read responses. (I've now created #87 to track trying out this first stage.)

I think from there, once we've proved that multiple-connection-modes is viable, we could look at the next steps. As you point out, I agree that phase could be exploring options like:

• Building our own bare minimum web client.
• Looking into whether something like WrittenRealms' Herald client can be used against our engine without compromising our core architectural goals. (E.G. if most the client behaviors suit us well but a few do not, we could think about a "WheelMUD Herald Fork" that we'd maintain.)
• Reaching out to see if collaborating on something in-between (standards?) is on the table.

---

On PR/Promo/Recruiting fronts, yeah I'd like to do more of that stuff again at some point. Those are some good leads. I feel I haven't put enough time into this project lately for it to be a daily priority and fresh enough on my mind to excel at such recorded discussions ATM, but I would like to get there again. I also still have an administrative backlog to reduce (like restoring the rest of the old design discussions) before I can tackle that stuff guilt-free, and feel ready for a larger influx of community. For now I continue to make it a priority to help ramp all newcomers though, and will revisit how I can produce best impact here as these variables change. Thanks for the feedback!

[ghost]

I'll do some exploration on #87 in a branch of my fork to get up to speed. Based on some reading I've done I suppose SignalR might interesting as it provides some fallback options when websocket support isn't available for whatever reason?

With regard to promo/PR stuff I completely understand. It has to be prioritized against everything else going on with WheelMUD and life in general. It would probably make sense to have an active "world" up and running before unleashing the hounds as well. :)

[DavidRieman]

This thread contains restored content from prior forums; see #134 for details.

[July 2010]

Beyond Telnet

Do you have any plans to make the MUD into a .NET web application? That is certainly a lot more modern than a Telnet app. Yes, I know you can have a telnet app on a webpage, but that's not what I mean. You could do a lot of really cool stuff if it was a proper web app and wasn't held to the limitations of Telnet.
For example, sound effects, chat pane, map screen, and pretty much everything you could do in a modern game. You are effectively then creating a hybrid of a MUD client and the MUD server.
I am still keen on keeping the interaction text based, but I think it would be a lovely compromise and tap into a part of the market that's not utilized. If you can take the fun and imagination involved in a MUD, but add the user functionality of a .NET web app, then you have something really special.

I have actually been thinking about something similar. The way I can see it working is to change the way our commands work so that they abstract the client away. To do this I was thinking about a script returning a predefined object that models the information gathered in the script. An client specific interpreter would then translate this information into the correct output for the connected client, ie text for a telnet session json or xml for a windows client.
Lots of design decisions to be thrashed out with this, but I think it could be doable, it would make scripting more difficult though

I personally don't have the energy for this. I would prefer that if you guys want that, to make a fork. I have no desire to work with multi-media, and don't want to get into providing that sort of content. Text is easy.

I also don't feel a full-blown .NET web client (sans Telnet) should be in scope, prior to v1.1+

What if we kept it text, but still made it browser based? The trick is to have multiple panes that do separate things. For example, you could make it similar to WoW. A main pane for navigation, two smaller panes for messaging and combat text.
Or even simpler. One pane for normal MUD. One pane for messaging. The thing is, social interaction is key. However, an issue I've had in the past is when you are fighting then text is scrolling across the screen and you miss messages from people. Then you have to scroll back to see what they said (if you noticed they even said anything).
It could also be nice to have a window that always show the current room desc and available exits or a small pane for health bars, etc., but messaging really is the biggie for me.
Point is, text based can still be modern and more user friendly. If you want to carry on and have one scrolling wall of text for now then that's fine, but I do personally think this is the best way forward. At an absolute minimum, I will make it browser based (even if it's just browser based telnet) instead of simply telnet (or in addition to). You want as few barriers as possible. Most people don't even know what telnet is nowadays, much less have the desire to install something for a decent UI.
Don't get me wrong, I love the old school stuff. It's just that it's a dying breed. Telnet, ANSI art, BBS... that was the most fun time of my life.
No problem to carry on as is and leave this for 2.0. Just throwing it out there...

Interesting ideas for the future, but for now...
There are many reasons I'm definitely against expanding our scope to include non-telnet networked technologies.

• We'd never get done with 1.0; we have to have boundaries for scope.
• A MUD engine has a reasonable (and finite) boundary for common features - it's easier to get everyone on board for direction of individual features, etc.
• WheelMUD's already been rearchitected a ton and IMO we've got something quite workable this time; imagine what would happen if we opened up to another vast new territory.
• There's a ton of such MMO-ish projects popping up and dying every day.
• OSS devs are now avoiding such projects as per the above - The situation at the gamedev.net 'help wanted' section is so bad that "MMO projects must be posted with a thread title beginning with [MMO]" in order to adequately prevent such devs from wasting time with even opening the thread. Being text-only gives us a somewhat better chance at appealing to talent who normally wouldn't touch an MMO project with an 11 foot pole.
• Right now we don't need any web-dev area experts, artists, etc.
• Server setup is simple. No reliance on, say, detailed IIS setup steps (and supporting people who don't get it right), etc.

That's fine. I'll just add a java based telnet client to my webpage. I just wish something could be done about the messaging dilemma. Private messages, guild chat, trade channels, etc. I'm just concerned it will get lost when you are running from room to room or in a fight.

Actually a couple of things we can do about this, with Telnet.

• The communications/channels should be buffered and able to be recalled with a history command. I've seen this implemented in MUDs as a per-channel command like "gossip -h" would show the last couple dozen gossips (perhaps even if they were done while you were offline) but there could also be such a command like "commhistory" or something which would repeat all communications you've received lately (regardless if they were a tell, say, channel, etc.)
• More challenging (but theoretically possible) may be splitting of the output area and using coordinate-text output codes to essentially split-screen the telnet window for a communications section and otherwise; running through rooms wouldn't change the communications area. Output might be slower since cursor-setting commands would be getting sent constantly. IMO this is less bang for our time too. (Modern telnet clients can be configured to do this stuff for you instead of via complicated telnet cursoring commands, and worse, not all clients will support said cursor moving stuff anyway.)
• MUD admins can always add other technologies to the engine to communicate with web components they write, or extract communications from the telnet server and do communicatinos in their own component displayed next to a web-telnet-client, etc... lots of advanced options are still possible. I just think we should avoid catering to such scenarios ourselves, before the v1.1+ timeframe.

Yeah, I know about chat history commands and such, but not quite as slick. Fine to have it as 2.0 or try to figure it out on my own (not likely).

On "gossip -h"... In the MUDs that I've been playing, a "replay" command was used for this purpose. Passing it without parameters would print all player communication in chronological order (including messages sent while you were offline, linkdead or whatever), or it could take a channel as a parameter, e.g. "replay gos".

Yea that setup makes sense to me (as its own command with optional parameterization) - getting fancy on the RHS of channel/communications commands is a bit awkward as people would sometimes accidentally send a message of what they thought was going to be an argument, etc. PlayerName gossips "history" ... oops!

[DavidRieman]

This thread contains restored content from prior forums; see #134 for details.

[2012]

Browser GUI

In addition to being able to simply connect through any telnet client, I think a browser based interface is essential to capture the younger audience that has never used telnet before. One MUD that I was toying with had your basic text window, but then in the right pane you have an auto-mapper, who's online, inventory, chat channels, player info, and trigger settings. There's also a settings button which takes you into quite a lot more settings, like key bindings, variables, etc. Be nice if there was an Admin/Builder interface built in as well (might be).

This is actually quite a bit of work. I've started several times on web front ends. Web projects require graphical assets and design, which are beyond my skillset and patience. ;) A lot of programmers gravitate towards MUDs precisely because these have limited UIs.
I'm not opposed to merging Web tech with WheelMUD. It's just that this would require a lot of time and effort to do, even more than just the plain text stuff. Nobody has step forward to work with web technologies in the 14 years that WheelMUD has been around.
There's another MUD project, called CoffeeMUD, that has web connectivity. That project is in Java though. It's over here: http://coffeemud.org/

I think looking into various clients that exist and seeing what kind of features we can support for targeted instances would be a good idea for the polishing phase around v1.0. Hopefully most client features like triggers don't impose technical restrictions on the server since that sort of thing usually occurs on the client side. (Something like a constant Who's Online pane may require the server to issue updates to the client amid the normal text stream but which aren't actually shown to the user as text.)

Personally I wouldn't want us splitting focus on building a client itself any time before v1.1+ timeframe. Perhaps, worse, having/advertising a custom client effort as part of our feature set might harm our first impressions to devs who stop by, with possible notions of this being a proprietary client-server architecture rather than good ol' telnet-compliant server architecture? shrug

I agree it makes sense for this to be v1.1+
I do believe this opens up a wider audience though. Just look at how successful Iron Realms is compared to other MUD groups. I don't think their MUDs have any amazing coding in them, but the interface allows it to be more user friendly, particularly to newbies, and doesn't really simplify the game.

Agreed, a good embedded telnet client is a great idea for individual MUD administration teams to embrace. Hopefully at the v1 timeframe we start transitioning from being solely a MUD platform site to being more of a strong community of MUD administration teams who are using our tech, pulling and pushing advances from/to many games over time... It would be great to have forum discussions like "Here's how to embed telnet client X into your website and get the most out of it!"

I'm glad you brought up the Iron Realms client. That client is called the "IRE Flash Client" by the developer (Matt) at bc-dev.net. He also made FMud - I believe they are based on the same code but I could be wrong. A couple years ago I asked Matt if there was a way to automatically pass parameters to the client for logging in the character; For example, if your MUD's website has an authenticated login itself, why not have the webpage rendering code pass some username and unique security token to the client, to automatically log in their character when they browse to that client page? Then in v0.9 he added the "name", "password", and "hide_password" parameters to FMud which should make that possible. :) The moral here is that other parties may be interested in making embedded MUD clients awesome, so hopefully we can cooperate/leverage that instead of rolling our own.

---

[2012]

Should Telnet go away?

When it comes to MUDs, I've always been sort of a purist, telnet all the way. Through the years I've looked at other protocols for piping data. Recently, I read a blog post from Oren Eini, better known as Ayende @ Rahien, that made a very compelling case about the "raw" protocols. His blog post is titled Why TCP is evil and HTTP is king.

In a previous life, I was a system and network administrator. Ethereal (now Wireshark) was THE tool to look at packets going across the network. This is also the tool that I had to use when debugging telnet issues. The last tangle we (the WheelMUD Team) had was with the MCCP protocol.

...
As Oren points out in his blog, it's the tools around the protocols that make for a better experience. Web servers can handle a lot of things that we have to do by hand with telnet over TCP. Web servers can handle compression, port assignment, and several other things that MUDs have to handle themselves.

Another blog post, by Eric Sink, makes a balanced discussion about HTML5 vs Native. His post is titled Mobile Apps: HTML5 vs Native. One of his points is the size of the pipe that transports data. When I started MUDs back in 1992, most people did not have a connection to the Internet. College students and researchers were the main users at the time. I still remember having to use an old VAX mini to connect to the college's VAX mainframe. I remember telneting from VAX session and seeing the wonder of multi-user text games.

The pipes have come a LONG way since then. HTTP and HTML rule the Internet these days. There are tools built by 3rd parties to work with these two technologies. On top of this, they are quite a bit more human friendly. XML and JSON are two of the most common packaging technologies for data across the Internet. Both of these can be read by a human quite easily.
I feel that the time is here to move MUDs over from Telnet to HTTP. I'm not going to touch HTML here. That's a whole different topic.
I have no idea how this movement to HTTP will take place. I'm not willing to make MUDs into web servers, but I'm willing to leverage the features built into them to MUD servers advantage.

There is 1 big issue with HTTP in a MUD environment, it is predominantly a request response mechanism. There are ways to turn http into a push mechanism but they each have their flaws. This basically means that you would need a client to poll to get updates and the overhead with that poll is not insignificant.
With Telnet on the other hand you have an open duplex channel, both the server and the client are free to send information. This means that the client can be informed of things that are happening as opposed to having to ask.

There is nothing stopping you sending xml or json information over telnet or even implementing your own http style of protocol on top of it. Telnet is a very light protocol on top of a raw socket after all. The main reason people don't is the fact that MUD (telnet) clients wouldn't know how to talk to it.

With HTML5 there is a standard coming out called Web Sockets, which basically is an open socket between a web browser and server that uses http as its protocol. This has some mileage IMHO but will move you away from the traditional MUD client route again and mean that you host something in a browser.

The duplex channel properties of telnet is what makes it attractive in MUD environments. The issue I'm having is that it is still fairly hard, for visually oriented people like me, to debug and work with. I always feel like I'm back on buggy and whip when I fall back into telnet from other protocols.

You're right about sending xml or json. That's already being done by IRE.
The client side has concerned me for a bit. Zuggsoft has had to stop development on their MUD client. Commercial MUDs appear to have gone the route of creating their own custom client.

Yeah, I've seen several web apps using web sockets. The pro for browser based clients are that it is a well known app ecosystem, and it is a fairly robust presentation vehicle. The second pro is that there is a large number of programming tools. The cons would be "It's the browser!"

Ed. Update: A great discussion above. Although I missed this thread at the time, I just want to add a couple things now:

• MUDs are very retro at this point, and much like the difference we feel playing single-player ASCII in true ASCII mode versus an imperfectly simulated fascimile of it, not supporting Telnet would be driving apart a big portion of our nostalgia potential as nobody could play it in the same style of client as they have nostalgia for.
• I think we can certainly abstract our communication transport so multiple transports can route commands to and output from the game system. (An admin should be able to configure, say, that they want both Telnet and WebSockets or whatever, to be enabled for their given MUD instance.) Again, a v1.1+ feature to do so as we need to limit scope, our existing Telnet already works, and extra protocols at this point feel like gravy to our core mission here.

Basically, I feel like Telnet is locked in as a core feature, but I am not opposed to expansion into new realms on this front!