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.
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.
However, that was 1980. These days, designing a friendly protocol that uses plain text structure and is therefore easy to debug, easy to update, and easy to write adapters for is, IMHO, a much better idea than fiddling with (unsigned char)255.
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".