Except that telnet is the right tool for this job.

You seem to want to replace it with something newer purely for the sake of using something newer. That isn't just pointless, it's counter-productive.

From the player's perspective, the only noticable difference would be that they could no longer use their favourite mud client.


So your proposal is to replace telnet with something more bloated? Do you think players would care how easy the protocol is to debug? Or do they'd only notice how much faster they hit their bandwidth limit when using their cool new mobile phone client?

Why do you think many mud owners look for ways to reduce their existing bandwidth, such as MCCP? In fact the owner of one of the biggest muds on the net has stated "…if we ever have to move to a host that charges for bandwidth [MCCP] could very well mean the difference between being able to afford to stay online or not."


And a client with your new protocol would be shipped with all modern operating systems, would it?

Browser-based clients can also connect through telnet. There are numerous examples of such clients, and they don't require any specific downloads.

However many modern gamers are also quite used to the idea of downloading something before they play, and that's where the more powerful and established mud clients come in.


I accept plenty of new ideas - indeed my whole foray into telnet options was based on proposals from donky and Scandum. You seem to think you've discovered the next "best thing", the silver bullet of mud design, but talk is cheap and (as any competent mud owner will tell you) some ideas are simply nave or ill-conceived. You'll need to come up with something a bit more compelling than "telnet is old".

So, players are the ONLY consideration? I've seen plenty of broken MUD clients that do things wrong, and I'd bet many of them are broken because the RFC maze of TELNET is annoying complicated to navigate. The fact is, many of them don't even realize they're broken because they handle the normal traffic and small handful of common negotiations well enough. But that's OK, because the players won't notice. The entire family of DikuMUD derivatives had the basic *LINE ENDINGS* wrong for 15 years, and it was so solidly accepted that some developers said the RFC must be wrong when it was pointed out to them.

I'd be curious to know how many people have a "favorite" MUD client that's their favorite because they tried many of them and found one they really liked, vs. how many are simply the one they've invested the time into configuring and don't want to try anything else because of the hours of configuration needed.



Well, let's assume a standard text screen of 80x25, or 2K of raw data. Let's say each user is managing to get a whole screenful of text every second of their connect time (doubtful). Let's assume they play 8 hours a day (doubtful). So, a single user playing a MUD like a maniac for 8 hours straight uses about 60M of bandwidth. That's about the same as watching a 5 minute youtube video.

Let's say you're a popular MUD and have 50 players on average, at any hour of the day (doubtful). If they all have usage patterns like the above sample, that's 3G of data transferred per day by the server, which is about 90G per month.

The couple of hosting plans I glanced at in the $50/month range quoted numbers like 2000G and 5000G per month. Just how much bloat do you think I'm talking about?



Show me a mud client that's ready to use out-of-the-box, and doesn't require me to spend hours fiddling with regexps to try and determine which bits of server output go to which windows? I'd like to see one.

I'm perfectly willing to accept that my idea is naieve or ill-conceived, but so far nobody has shown it to be so. People have derided it as unnecessary, and defended TELNET as it I had insulted their religion, but aside form saying "nobody will use it", I haven't heard any reasons why it would be a bad thing.

I accept that the burden of proof is on me, as the person trying to convince people that it's a good idea. But I get the feeling you're not really hearing anything besides "mumblemumble TELNET BAD mumblemumble". So, rather than being able to talk about the hypothetical idea to see if it can be made into something useful, I'm backed into the corner of "hand us a fully implemented perfect example, or go away."

Perhaps you can explain to me why seperation of data and presentation is something that just about every part of software development has striven for over the last 20 years, yet in the special case of text mudding, is somehow inappropriate and counter-productive?

No, but if your primarily goal is to have a large playerbase then players should be one of your main considerations - something that players don't even notice is unlikely to have any impact on the popularity of the mud.

And if you do succeed in attracting a large playerbase, then bandwidth may well become an important consideration as well.


MUSHclient and Mudlet can be preinstalled with custom plugins/scripts and made available for download from a mud's website as an out-of-the-box solution - although in the future this shouldn't be necessary for Mudlet, as the lead developer is planning to add an autoinstaller for muds that offer custom GUIs. CMUD can also do a lot of graphical stuff automatically through MXP. And of course there are numerous custom clients that are tailored to a specific mud.


It doesn't offer any new functionality, it's just a less-efficient alternative that isn't supported by any existing mud clients. If all you want is verbose human-readable messages, you could stick with telnet and just invent your own in-band mud protocol.


Clearly I don't think it is, or I wouldn't have spent the last year working on ways to separate the two. This is something that telnet handles perfectly well.

I'll try out your new protocol Quix. :P

EDIT: Removed spit infinitive.

Agreed. But that's a deficiency of MUD clients, and it's there because, OOB, they aim to support a wide range of servers. It's not a deficiency of the telnet protocol itself.

In my view, any MUD that wants to survive another decade would have to start looking long and hard into creating custom GUI's to improve the end user experience and reach a wider audience. And yes, it will require hard work. But the real damper is not the telnet protocol – it's focusing on server features (easier and more fun, admittedly) and surrendering the user experience over to the makers of generic MUD clients.

From what KaVir has shared, it looks like MUSHClient offers a lot of scripting flexibility. Also, I've shared some web-based code here that people can use to write a facebook/web GUI which can potentially leave any browser-based MMO out there in the dust. The ball is, I believe, in the court of MUD server developers (has been for years)–they need to start taking charge of the way players experience their game. And if you look at the most populous MUDs at the moment, you can clearly see that a custom client and success are strongly correlated.



As I understand it, your idea is to design another text protocol, better suited for text-based games. There may be some value in that, I don't know. What I do know is that in about a year, I modded a pretty old-fashioned CircleMUD codebase to drive this GUI. In doing so, I never felt restricted by the telnet protocol as a means of exchanging data with the client–plenty of other headaches, but not from telnet. I've also developed a web-based UI, and again, I had far more grief from cross-browser compatibility of div layering than I had with parsing telnet input.

In all my client projects, the data communication part over telnet has been the only trivial part. So I don't think telnet holds anyone back. What I believe is that most MUD devs are letting others worry about the game client, and they're doing it at their own peril.

The only good reason to use the telnet protocol is supporting a multitude of broken clients who depend on you using the telnet protocol in a dumbed down way that only half works on most/all of them. So how many of those clients are driving your fancy gui?

PS It is about time for the great telnet war of 2011.

If I had to start a project from scratch, I may forego telnet altogether, sure, depending on the client platform(s). But Bedlam is an offshoot of a MUD (AnotherWorld) I used to play in my college days and that I really wanted to revive, together with its custom zones, atmosphere, gameplay mechanics, etc. Unlike many of the pro's here, I have no interest in writing custom codebases and I see no point in rewriting the communication layer now that there's a relatively easy way to make a mobile telnet app, a web-based telnet app, etc.

Also, I do want to support the multitude of telnet clients out there. Believe it or not, a lot of people who've never played a MUD before start on the GUI app, become proficient, and graduate to MUSHClient/Mudlet (at least while they're on a computer). Veterans from AW are also able to play side by side with a new generation of mobile players. People have fun competing on different clients…

If it works, why break it?

I do not think mudstandards died because of a reactionary rejection of new ideas.

I think it died because the people who ran it either did not understand or did not feel
a need to accommodate the presumption of the objectors, namely that a community
project would involve the development of consensus…or at the least, lacking full
consensus, compromise and willingness to negotiate.

Since it was billed as a community project but clearly the community was not particularly
valued as participants, mudstandards earned mistrust and resentment. Which, by the
way, the owners seem to care absolutely nothing about, pretty much proving the point.

If KaVir is suggesting that Quix is an unconscionable ballbuster and strident reactionary,
I suppose a case can be made for that. However I think that it just as fair to view skeptically
the proliferation of protocols and standards from Just The One Guy to whom every
problem is a nail he has the exact tool for..if only people would use his brand of hammer
and nail.

Regarding the specific question of "lol telnet", let me bore you shitless with another
long rambling Cratnecdote:

I've been obsessively watching Carl Sagan's Cosmos documentary over the past few months.
I don't really know why, maybe I'm trying to recapture the wonder I felt 30 years ago
when I first saw it on PBS.

In one of the episodes he describes the way much of New York City was updated, upgraded
and renovated over the centuries…if major routes ended at a ferry terminal, the
routes dictated where the new bridge would be built. For the same reason, a new tunnel
would have adjacent endpoints. While new things were added, old things needed to still
work. And thus he described the sedimented nature of the evolving brain…many
inefficiencies, many redundancies, but the thing still had to do the old jobs while
adapting to the new ones.

Our ways of loving our games is open to evolution, but I suspect that the emotional
bonds of familiarity with the systems we toiled to create is such that tossing them in
favor of a Great New Way is understandable intellectually but unacceptable emptionally.
I don't think this qualifies are reactionary rejectionism, I think it's more to do
with affection for the old ways even while acknowledging the merits of the new.

I propose that New Ways don't need to wipe the chalkboard clean. As inefficient as it
might feel, it is also natural for transitional states to usher in evolutionary changes,
particularly when the risks of revolutionary change are high.

-Crat
http://lpmuds.net

QFT. I believe the term for this is Path Dependence.

Whether we like it or not, it is a fundamental feature of the human brain in how it deals with problems. When confronted with the messiness and near-irrationality of the current state of an evolving system, some people have a more negative reaction to it than others. But, like Crat, I believe that having a strong reaction to the downsides of path dependence doesn't make one more likely to revolutionize.

I think player driven UI development is the future for MUDs. The obvious advantage is that server developers only have to provide game data through MSDP or GMCP, without having to worry about the actual representation or implementation of the user interface.

It'll be interesting to see how the graphical clients handle GMCP, I do predict the downfall of Mushclient if it doesn't step up in that department as it'll be tempting for MUDs to switch to preconfigured interfaces as promised by zmud and mudlet, while any sufficiently unique MUD might prefer MSDP combined with the flexibility of Mushclient.

I don't have hostility towards those who try to push the envelope. I have hostility towards Scandum, for all the dumb shit he's said in the past, and I don't trust anything he's ever written with regards to clients, or snippets for various codebases. And I will continue to ignore just about everything he works on, until someone I do trust to have a clue in what they're talking about or doing gets involved. Hence why MSSP DID NOT go into any FUSS Project Codebase until after the MSSP protocol was well out of Scandum's control.

For the record though, MSSP went into the FUSS Project bases because someone suggested a simple to add solution that didn't require us having to wedge yet another telnet subnegotiation into DIKU's already flawed subnegotiation handling. Thus MSSP-Plaintext was added to the FUSS Bases. It's also readily available as a snippet for addition to any existing FUSS Base. We elected for the plaintext alternative because it was easier to implement for anyone who just updates their MUDs with FUSS Fixes, instead of downloading the whole codebase every time we release an update. Fiddling with DIKU's Telnet handling is by no means a simple change for your run of the mill MUD Admin.

It certainly is possible to keep the krufty old TELNET port while making a new port to talk a new protocol, for those existing games that already do all the legwork of pre-formatting things for TELNET output. You'd still see a benefit for newer clients being able to more easily identify content, but you won't see the simplicity of code that you'd gain from dropping TELNET entirely.

What I mean here, is that if you develop a new content-oriented protcol, your MUD no longer has to deal with formatting things to the right terminal width, tracking pager state information, adding the right colors to the right type of content, and all the other stuff you have to fiddle with on the server now, blindly hoping the client will display it the way you intend.

If you used a content protocol, you'd send the data and let the client handle presentation. There may still be some places you want to embed tags to control color/etc inside an element, but those are usually pretty rare. MOST of the time, you send tags to surround elements with the color of choice, which usually doesn't change very often.

In a normal MUD, a room might be a structure with a title, a description, and a list of exits. Now, with TELNET, your particular game might let users set the colors for the title and exits. So, to send that data, it has to build a string where it first looks up the user's title color, then looks up the actual terminal type of the user and translates to the ESC codes, then adds the title string, and the appropriate reset ESC sequence. Then a CRLF, then indentation (maybe) and the description string, another CRLF, and another set of lookups for the exit color codes, the exit listing, and another reset code. THEN, this all has to be re-formatted to make sure it doesn't exceed the user's terminal width. Finally, that all gets stuff into the user's socket (or buffer).

ESC
ESC[36mA boring room.ESC[0mCRLF
SPACE SPACE This is a boring room that you don't want to be in.CRLF
Obvious Exists:SPACE ESC[32mNorthESC[0mCRLF
[/code]
Using a content-based protocol, you'd send just structured data and be done.
[code]
{
    "room" : {
        "title" : "A boring room.",
        "description" : "This is a boring room that you don't want to be in.",
        "exits" : [ "North" ]
    }
}
[/code]

Now, how does the client know what colors to use?  Well, either the user set them directly in their own configuration, or the MUD could have sent it as part of negotiation, once.

[code]
{
    "colors" : {
        "room-title" : "cyan",
        "room-exits" : "green"
    }
}
[/code]

The client is free to ignore such a suggestion, or store it and do whatever translation is appropriate for itself without the server having to know (or care) what that might be.  A web-based client might convert "green" into <span style="color: #00FF00;">.  A terminal based client might use ESC[32m.  A custom windows version might make whatever OS call sets the drawing color to green.

Of course, you could implement this as a terminal setting and have existing mud's just emit the raw codes, but your server code will still have to do all the work of translating and formatting, because it won't know the client is going to be doing it all again anyways.  Unless you really want to split processing down two paths based on connection type, and all the headaches involved in maintaining two distinct chunks of code.

I've been following this thread for a while and been wondering why I disagree with you, Quix. I think I've just figured out where that's been. Telnet says nothing about colours. You're not talking about telnet at all, which is an out-of-band protocol-enabling protocol. You're talking about ANSI escape codes and the like.

Well… ok. I can agree with you that that is far from an optimal protocol for visual display. But Telnet itself? Nothing wrong with that.

Telnet says nothing about colors, but that's not really the point, is it?

Telnet is the medium by which the user connects to the mud, and it is the arbiter of how the mud discovers what the user's terminal can do. In essence, the mud uses telnet to find out what kind of features the user supports, and then has to customize its display to match those capabilities.

This is bad, because it mixes data and presentation. It requires that the server make educated guesses about how things will actually look on the client's end, and that it does a bunch of extra processing to try and accomplish this. In turn, the client doesn't get data that's differentiated properly, so it has to do a bunch of extra processing to pick it back apart and identify which parts are which data.

Now, you could run a protocol like I'm suggesting on TOP of telnet if you wanted to, but there would be little point. If you're sending data that's already broken up into a packet stream by type, a raw TCP socket works just as well as telnet does. In fact, most DikuMUD derivatives don't actually implement TELNET at all, but simply use a raw TCP socket and follow a tiny handful of the TELNET conventions, so the clients are happy.

My example focused on color and presentation, because that's one of the things that would benefit the most from moving to a structured data stream. The concept of in-band and out-of-band only applies to an unstructured stream like TELNET, because you assume all the data is for presentation unless told otherwise (OOB). A structured system doesn't need that, because it's up to the client to decide what to display (and how).

It's not a question of speed, although you could make the case that sending binary data would, in fact, have needless overhead because you need to worry about escaping special telnet codes.

So when trying to send a message, it is rather odd to not consider what messenger you are using. When the question is how well a message is being sent, why doesn't it make sense to "blame the messenger"? The point is that telnet was designed to send text in a linear line-based stream. Not all data is linear line-based text. Saying that it would make total sense to transmit 3D game data in telnet is missing the point and a position only worth holding for rhetorical amusement.

Let's ask another question, also perhaps only for rhetorical amusement: why don't people use telnet to transmit their 3D game data?


Yes, you can. But you can do lots of things. So what?

Even for line-based text data, telnet has shortcomings. Out of band data is a good example of this, and yes, you can use the subnegotiation mechanism, but there are issues with that that have been covered ad nauseam in many places.

This could take forever, or never happen. Or, a power user with excellent scripting / coding skills may come along and write a killer client and never bother to share it with others. I simply can't take that risk. Refusing to take charge of the UI, while understandable given how most of us are solo enthusiasts with limited time and resources, is bound to dampen the reach of any MUD over time.



You have my rhetorical answer already – because most people find it old-fashioned. And that's a self-fulfilling prophesy. I believe that the reason telnet may be harder to utilize in a modern 3D RPG is because at some point writers of low-level protocols for network games picked up a new toy, not because there's something inherently wrong with it.

If I ever try to build a 3D MMO, I would definitely pick network protocols based on whatever is freely available and provides a solid stepping stone for an enthusiast project. But if I take a stab at a faux-3D UI for my MUD, I'm pretty sure I'll find that telnet is enough for my needs (mostly because I don't think I'd be able to go completely roomless), just like it's enough to drive 3D room renditions in MUSHClient plugins. Like what happened with my faux-2D UI, I decided that it's far less work to mod the telnet output than to add another protocol, which would have to be coded and maintained separately.

Edit: fixed quote attribution - Orrin

quoted for nonsense

You might want to look up whether people even use TCP/IP for this, let alone telnet.
I really mean no offense but it seems that you have relatively little experience with network protocols and stacks. I mean, you've implied as much yourself, and furthermore have qualified yourself as a hobbyist programmer in the past. So, it seems that you're giving opinions but without really knowing the topic. I am by no means an expert but even with what I know it's pretty obvious why telnet is utterly inappropriate for 3D games.

Put another way, I'm pretty sure that people smarter, more knowledgeable, or both, than you or me have spent a fair amount of time thinking about this, and came to the conclusion that different protocols were more appropriate.

If you want to make this argument – that telnet truly is fine and dandy for everything – you'd be better off sticking to MUDs, even with "faux" interfaces. You're not doing yourself any favors by saying telnet is just fine for true 3D games. :wink:

Incidentally, whether or not it was less work for you to accomplish this or that task is a wholly separate discussion, is it not? Saying that telnet is appropriate for everything is really quite different from saying that telnet is appropriate for sending data in a primarily text-based game for your particular case.

Agreed. Incidentally, the full quote is "If I ever try to build a 3D MMO, I would definitely pick network protocols based on whatever is freely available and provides a solid stepping stone…," which is what you said in other words. So no disagreement here.



None taken. I am absolutely a hobbyist and amateur when it comes to network protocols. I gave an opinion based on what I've done, i. e. build a 2D GUI for a telnet MUD server.

As far as 3D clients go, I can sense that you and Runter think the utter inappropriateness of telnet for driving a 3D client are obvious, but I've yet to learn the obviousness of it, which someone has to take the time to explain. Otherwise, it's just an opinion.



I'm afraid this won't cut it as proof. At worst, it'san argument from authority, a type of logical fallacy. At best, I'll need some links where these smarter people take some time to explain why they did what they did.



I don't. You may have to re-read my post to convince yourself of this, but it's laid pretty bare. Like everyone else here, I want to pick the right tool for the job. I am at least that smart :).



The point is I don't know if telnet is just fine for true 3D games and I'm ready to be shown either way.



Absolutely. Which is why I said the latter, but not the former. Again, my point was that if I want to build a faux-3D interface, the game will continue to be primarily text-based, and I probably won't need to look further than telnet. If I want to build a true 3D world, I'll be looking around for what those proverbially-smarter-than-us people have shared.

And finally, a topic can only move forward if we take the time to read each others' posts carefully and respond after grasping the substance of each other's arguments, and not if we split into camps over imaginary disagreements. I don't think anyone here is pro-telnet or anti-telnet across the board. We're just coming from different experiences and discussing what could potentially move our various projects forward. At least, that's what I hope we're doing…

I think it's worth mentioning that telnet isn't even simpler. In the past I've done things that were more simple for projects than perhaps I should have, but telnet is an example of something accomplished in much more simple ways (if we're talking about just the data transportation layer). There's been a false dilemma on this thread committed upon the readers. The two options. On one hand, use telnet protocol. On the other hand, reinvent the wheel and all that it entails to get a protocol like telnet. But this isn't true. Generally option B, the other protocol, would be something as simple as dumping serializations into a stream and reading them on teh other side. Like… 10 lines of code counting client and server. Or we can implement telnet protocol in a... So let's consider the "right tool for the job" argument, I'm not sure that telnet is even the right tool for the job. I'll leave Quix to mention the analogies about cracking tiny pecans with sledge hammers. As I've already mentioned, there's a use for reverse compatibility through the telnet protocol. I.e. communicating with applications that already understand the telnet protocol. So legacy. But that's a quite different story from people jumping on a bandwagon because new network toys are shiny and the entire world except a hand full of hobbyists are ignorant of the sweet, sweet lovin' that telnet gives.