Fairly sure most MMOs use a chat server for communication. I might be out in left field as per usual, but… meh.

Well, fwiw, most mmos use services for many commonly trafficed parts of the games. (Chat server, instance servers, login servers, update servers). But these are often design decisions made with high traffic and the server sharding paradigm in mind. For a hand full of players (read less than thousands on multiple servers) there may be no good reason to do something like that.

so…all it would take to start using a new text mud protocol would be for a few enterprising mud developers to put it in their servers and then whip up a cross-platform client or modify something like Mushclient/Mudlet, right…?

Well, if you're talking about the community using such a new protocol then I'd say no, that's not likely to change, but it's super easy for an individual to. If you're already developing something that won't be compatible with other clients there's really no reason not to. It's already off the beaten path, so to speak, and you won't get any benefit of legacy.

I wrote a packet system for a MMO project I work on the side. (concerns of efficiency aside, it processed 10c/s with concurrency on my 1.6 gigahertz single core laptop. That's only a few thousand times higher than most populated muds ever need. All written in Ruby.) Which makes everything "out of band." There's no reason to differentiate, really. When you send everything as structured data things are nicer, imo.

There's a lot of room in 'not likely' though. Given that I have no reason to believe that people are going to stop playing muds and making new muds any time soon, why not start now? There's a big difference between someone making a protocol for themselves (Archons of Avenshar did just this with a production game) and making it publicly accessible, documented, etcetera.

Certainly, efforts at community standards have seen their rough spots. But do people agree think it's that important to use the advantages of a new protocol, or are they blowing hot air?

So I did some digging around to answer my own questions about 3D MMO protocols, and came across this product site for a ready-to-use network protocol with API's for pretty much anything. It turns out David is right – they're using UDP "for ultimate speed and performance".

Some other interesting tidbits: it's written in C/C##, runs on a Windows server, and is free for up to 1000 concurrent connections.

One thing I've been thinking, though. If I write a server for a 3D game, how would that be any more a MUD than any other enthusiast 3D MMO out there? While telnet is not the defining feature of a MUD, I believe that easy extendability is. And every step I take down the road of full 3D means the server will become far too specialized for users to contribute content meaningfully. So what kind of a beast are we really talking about here? What would a "new MUD" using a modern network protocol and (I presume) a modern 3D client look/feel like?

Wait, are you talking about a graphical mud at this point? You could point to Second Life and the Hero engine by Simutronics as possible examples of modern servers designed with a text mudlike OLC. Though for that matter, I wouldn't be suprised if commercial MMOs didn't have similar functionality anyway.

eta: check this out, http://www.heroengine.com/herocloud/

"I like tew'dels"

So, wait. You're telling me I can do what I already do, but in 3d and better?

WHAT THE F….. I hate you ROM.

It was not meant to be taken as proof; indeed, it is hardly proof. It is rather a way of saying that I do not have time to provide proper education on this topic. :smile:


Well, FWIW, you came across as fairly dismissive (if not slightly insulting) to people saying that telnet wasn't always appropriate, essentially saying that they were saying it for no other reason than wanting to pick a "fashionable" protocol. If that wasn't the case, that is good to know…

Does telnet even handle gracefully utf-8 ? I doubt so.


Snicker, a graphical game will never be able to offer you the same capabilities a text game can. As not everything can be visualised and still stay coherent enough.

I don't know if I get you right, but I know at least one MUD that can read and write a subset of UTF-8 characters since 2002 and there is no technical reason why it wouldn't support all of them.

Yes, it does. UTF-8 is backward compatible with ASCII, and doesn't use byte values of 245+, so there's no conflict with telnet options. I actually used UTF-8 in the demo GUI I created for Realms of Despair, although only for display purposes.


Text and graphics each have their pros and cons, and they're not mutually exclusive.

The short version is that it is not a good idea to send transitory game data – that is, data that changes frequently, such as placement of an enemy, etc. – over a reliable medium such as TCP. This is because, if a packet gets lost, you end up re-sending stale game data, where you want to be sending the newest game data each time. For that reason, such sessions are usually built on UDP, which is an unreliable transport protocol. Hence, because Telnet is a primarily textual session protocol built on top of TCP, it is unsuitable for such use cases.

Ok, telnet is so old I would not have thought it could (I never checked actually as I do not care that much hence my doubt and not certitude about it )



I think when you go graphical you lose a lot in term of possibilities. And first problem is input. With text the only limit is what the coder want to do.
With visuals you are limited to whatever your device is (joystick/mouse/keyboard)
Then you need to decide how you want it to look. Either you go first person FPS style, or camera style. Both limits you in some ways
Fps will limits you becase of the input devices we have:turning head while running in another direction while aiming at something else is not possible right now. Only ten fingers and feet….
Camera angle will limit what is graphically coherent (how do you sneak in a room where the person can see the whole room and even behind him…)

That is why I think text based game can be way more interesting than visual one. No limitations, actually.

Sure, but the muds we're discussing here are still primarily text-based (unless the argument is that muds lack innovation because they're not fully graphical).

The way I've implemented MSDP, it only sends data when it changes. So if someone teleported next to you and the packet was lost, you wouldn't actually see them appear on your map until they moved again.


Okay…let's say I replace my ASCII map with a graphical one, and the hp/mana/move in my prompt with a set of energy bars. What possibilities have I lost?

I'd like to see a text interface for manipulating groups of units on a map giving them motion instructions, waypoints and so forth.

Or how about a text interface to manage, at a glance, a large number of real-time strategic data feeds.

Let's see… what about even a simple two-axis line graph?

It's pretty well established that graphical information is extremely rich and that as human beings we parse information extremely quickly in graphical form, and are slower with text. Your position that text is unambiguously superior is somewhat surprising. :wink:


You say anything is possible with text because it's up to the coder's competence. Why don't you allow the same excuse for people developing input devices? It seems that you have a double standard here… :smile:

I don't see the code any more, I just see blond, brunette…

Wait I do not say that text is more efficient or faster or anything: Muds are basically turn based anyway. then it just depends how fast you want your turn to be.
I just said there is no limitation to what can be do with text. Graphical info is very quick to aquire and parse for sure, but limited to what can be represented.
And not everything can be. Everything ca be described with text, not the more efficient manner for sure, but no limitation either.

And for developping input devices….thing is we cannot read the human mind effectively (yet) hence limitation. This will go away in the future I bet, but not right now.

And for most part client can do a whole lot already:graphical bar for hp etc I do in zmud fine, programming a lot of units easily ? triggers and aliases. (And about that I have a necro class that can deal with up to five charmies, so you need aliases and/or trigger to play this class anyway).

I'd say that at least in terms of the ASCII map it is graphical. I know that's not the point you are making, but I think it's important to note the difference. A text game is just one where the world is described with words rather than images; it doesn't matter whether those images are ASCII art or 3D polygons, just as it doesn't matter whether the information is transmitted over telnet or some other protocol.

Most of us who have a clue probably agree that describing the world primarily with words doesn't preclude using graphics where they may do a better job.