One thing I'm now certain about is that Telnet is a dinosaur, and an overcomplicated one. It's got bells and whistles and efficiency and extensibility well beyond the needs of any MUD server, in my opinion. I feel like the only reason to support Telnet as a client is to get the MSDP messages, and to tell the server to stop implementing very annoying defaults, like trying to do word wrap for you, or telling you "I'm done!" at the end of every message. Further, it's unnecessarily difficult to code against because of the mostly unnecessary options negotiation protocol (the standard options are unattractive), plus the special characters it uses as option codes and other markers don't map to printable characters, making debugging a serious pain.
If I ever develop a server, Telnet can bite me. Yeah, that means users on standard clients might not have a great time, but I think Telnet just doesn't deliver enough value to be useful. I'm thinking of the following changes:
- UTF-8 encoding by default.
- No word-wrapping or pagination on server-side (let the client decide how to display text).
- Out-of-band messages encoded in a human-readable format (yes, I would document it carefully).
- I'd probably use managed code despite the performance hit, because I'm more interested in showing people what MUDs can be (proof of concepts) than running a production server.
- I'd probably have to call it something other than a "MUD server" due to these changes.
I like developing for telnet, it's an interesting challenge and imposes design constraints on how the game can be presented to players. That inspires innovation in a certain direction that custom clients veer away from due to being different experiences.
ReplyDeleteYours, OpenIDSux.
Don't worry, most mud clients and servers hardly implement Telnet at all anyway. You'd be better off including minimal Telnet to support current mud clients and then add your own client/protocol as well, customized to your game, in order to draw players over to your new standard.
ReplyDeleteWhatever people say about the need for drawing in players completely new to muds, I don't think you can just ignore the existing mud playerbase and hope to have a successful (mud) game. Of course, if you don't present it as a mud at all all bets are off, but at the same time then you're losing the benefit of the niche marketing you could have done if your game was a mud.
If by telnet you're referring to the VT100 escape codes, I wouldn't bother. As George said, few clients support them, and few muds use them.
ReplyDeleteUTF-8 can be queried through CHARSET, word wrapping can be done through NAWS, and MSDP is of course one of several mud protocols that transmits out-of-band data.
You may want to check this out to see what sort of features different clients offer: http://www.mudpedia.org/wiki/Comparison_of_MUD_clients
Thanks guys for all the thoughtful commentary. I'm aware that few MUDs support much of Telnet, and really that's the point I was trying to make - it's the standard across MUDs, and yet so much of Telnet is useless. So instead of being an empowering factor, it's a tax on development for both server and client developers.
ReplyDeleteAs for MSDP Kavir, your point is well taken. While I was looking into the details of MSDP, I also looked through some info on other out of band protocols (MXP, MCP). Again I'm really disappointed because the value of a protocol is supposed to be that one implementation of the protocol makes lots of connections possible. But these protocols seem unnecessarily difficult to implement, frustratingly incomplete, and too fractured (there are at least these three) to serve that purpose. This means that any "general purpose" MUD client will always be lowest common denominator at best, forcing every server developer to also develop a custom client if he wants to deliver a full-featured player experience (with status bars and an automapper, for example).
Woops, there I go ranting again... I'm shaking my fist in frustration at having to settle for a second class client just because I want to be useful for more than one MUD. Maybe I'll blog about that next week...
MCP and MXP are really in-band (the latest version of MXP allows you to transmit out-of-band as well, but I believe CMUD is the only client that supports it, so I doubt many muds would bother using that option).
ReplyDeleteAside from MSDP, the other notable out-of-band protocols are ZMP, GMCP, ATCP, 102 and NEW-ENVIRON.
But in practice, I'm not aware of any muds that use ZMP or NEW-ENVIRON, and the only mud that uses 102 is Aardwolf - which also supports ATCP and GMCP. The IRE muds also use ATCP and GMCP, while the GUI snippet I released yesterday (and which a few muds are already adding) supports MSDP and ATCP.
So technically you could just support ATCP and you'd cover all the muds I'm aware of that use out-of-band protocols. But supporting MSDP and GMCP would be better, as ATCP is now only used as a fallback option.
MXP is still a useful protocol though - it's basically a mud markup language, so you can use it for things you wouldn't want to handle out-of-band, like clickable links, 24-bit colour, inline graphics, etc.
My ideal client would support TTYPE, NAWS, MSDP, GMCP, MXP, MCCP2, UTF-8, XTerm 256 color and possibly MSSP.
Thanks for the clarifications, Kavir! I think that complexity is a big part of what's keeping hobbyists out of the MUD client space. Offering all the niceties we'd like to provide for our users means climbing a huge learning curve and writing and testing a LOT of code.
ReplyDeleteAs for the distinction between in-band and out-of-band, my bad. My intention was to lump all data that aren't meant for direct output to the end user together under one term.
To clarify my point for anyone else, lots of information is useful but either not suitable for end-user consumption (like data about mapping), or designed for end-user consumption to the point of being too difficult to parse reliably. Some protocols try to deliver this type of information by marking it in a special way, but each protocol does it differently, and these protocols tend to be complex. So writing a client that supports these "nice but not essential" features like automapping and clickable links that make your character do stuff in the game which will work for practically any MUD server out there is a very, very big task. I decided not to include any of this in my "bare essentials" client.