Are there any MUDs that have broke away from being telnet supportive? I'm not talking about MXP or mud clients-- I know most people use clients. I want to know if there are any muds that are impossible to use telnet on, and instead have either developed their own elaborate online Java client or require players to download a client to run their mud, etc. If yes, which MUD(s)? Or if not, have any of you MUD owners considered doing it?

Our upcoming game will use a java based client. All other clients will be disabled and illegal to use.

That's what graphical MUDs do, basically. Use protocols other than telnet to run communication between the client and the server. Telnet just happens to be a pretty limited, text-focused protocol.

It's worth considering that even Blizzard knew they couldn't manage to create a non-duplicatable client protocol and opted for the potentially very expensive route of using the DMCA. Unless I'm mis-remembering, WoW trivially encrypts 1 or 2 bits of every byte, letting them claim that anyone who made a client to supplant their own would be violating the reverse-engineering provision of the DMCA, and thus gaining the ability to sue the pants off offenders.

I suppose that's a viable strategy if you have the kind of money Blizzard (and their master, Vivendi Universal) has, but it's not feasible for small games companies.

I wish you luck Hephos, but it's a paradoxical situation: The only way you're going to be able to prevent other clients in the long run is if you have few enough players that nobody cares enough to hack protocol.

--matt

Well, it won't be that hard to detect users that use invalid clients (if we want to actively do it).

Simply add a new quick check that the server sends sometime during game play, and if the wrong answer is received a warning is sent to immortals. (This could be changed fairly frequently and without warning).

This ID check could be changed VERY SIMPLY from our side, but on the illegal client side the user would need to sniff up the code (to know what is sent) before they log in every time and change the code in their client, or face a chance to get detected and banned/deleted. On their side it will be a pain in the butt. But very easy for us.

However... i'm not so sure it is very wise to prevent other clients. We're still thinking about it. The main reason is to prevent triggers, bots and other boring things.

I do hope you are aware that you've contradicted yourself here.
Preventing triggers/bots and preventing other clients are virtually equivelent statements.

Those MUDs are all over the place. All 4 of the ironrealms come immediately to mind because they are the only ones I (currently) know. There are quite seriously dozens, even hundreds, of others though, I just haven't found/tried them.

One presumes that the clients needs to recieve the code, that it doesn't change over time (one that does could go out of sync real easy, but its not impossible) and that your making the laughable assumption that the client couldn't do what I already said, check every incoming packet for the data, then send back the predetermined code? Seriously, the only way I could see that working is if you used:

1. Server side seed code.
2. Server side scrambler.
3. Client side scramber.

Basically, the same you see in the bond movie involving GPS. A constantly changing, synced code, where both the code returned, and the code expected, change in a known way, each time you make a request for it. And that just makes it inconvenient, not impossible. As the_logos points out, this is basically like using an a DRM or encrption code, which would make it illegal under the DMCA for one person to solve it "then" provide others with that solution. But, is a mud "capable" of defending its DRM rights? Is it even worth it. If not, then your right back to, "All that needs to happen, is for one person the break the code." And all that takes is a proxy, which logs a sufficient number of responses for someone to derive the scrambler you use. I.e., anything from extremely trivial, to so complicated that the code to track both ends might result in the game lagging, on both ends, every time a request for the code is made.

Worse, I doubt you will have encyrption experts on this, so the solution might even "look" complex, but be breakable with far less code and way less effort. So no, any client able to catch the packets, parse them for requests, and send back the proper response *won't* be detected, no matter how random the requests. That was my point. And even if you changed it frequently, without warning, "the client" still needs to get the new code, so it knows what to respond with. If they captured the code when it started the first time anyway, that won't matter. In fact, even if you changed it so randomly that two days had the same code for the last 10 minutes of the prior play and the first five the next day, variables in Mushclient plugins are "persistent" across executions. Worse, all they would need to do is wait a significant span of time, like only playing every friday, to make sure that they got a new code every time they connected.

"Sniffing up" the code is so rediculously silly, in any context that you can guarrentee the players can get it at all, so as to render it either a) too rediculous and inconvenient for them to bother (like an email of the code for the day) or using some sort of automated sequence at start up, which is just as trivial to manage as send the code after you have it.

I really don't think you understand what some modern clients are capable of, using just their standard functions, never mind added libraries.

I might add to this discussion that there is a rather large player base of visually impaired or blind users of muds and the like, and switching to a non-telnet client solution would affectively ban all blind players. I must say that it is rather agrivating to find a mud, get really excited about playing it, and then find out that you must use a provided (completely unaccessible) client... Grendel's revenge comes to mind.:(

Well there aren't really THAT many blind players playing text based games (or is it?)... Not enough to make it worthwile coding a custom client for a particular game for it.

Anyways I had the idea earlier to include some sort of feature to make a mud client that was aimed towards blind people. A generic client for any (telnet) mud. Was looking around if it was possible to get any kind of financial aid to produce one of those but couldn't find any. It just has to be somekind of place you can get aid from if you make free products aimed towards handicaped people... At least in our country (Sweden).

Ehmm... Of course the id checks will change over time. Every time we update/patch our client or reboot our game for example. Our users cannot log into the game with an out of date client.

We simply send a single string encrypted on the server side that will be sent to the client any time during game play (random).

The client will hold the decryption key hardcoded and will send a respons immediately as it receives the key.

If no respons is given or the wrong one, a warning will be issued to the immortals of illegal client activity.

Now, of course a user that wish to emulate the client can check every incoming data and try to find out which is the client id key. Then send back the correct decrypted string.

But in order to do that they would need to do this (EVERY DAY before they log in with their illegal client *every time*) Or at least every time they can figure out our client has been patched/updated (which happens every day):
1. Decompile the client to find the decryption algorithms or keys. Or start the client and read every incoming data and figure out when the encrypted code is received and then work out the decryption for their own client (the code is sent random and could take hours to find it).
2. Recode/update their own client with the new id checks.

If more than one person would use the illegal client, it will be a mess for them to make sure people do not log into the game with an out of date client, and get banned/deleted/whatever.

For us, this would be very easy, we can update both the server and client with new encryption keys very easily. We can also change the whole client id system, or add smaller checks that are fired at certain times without any problem whatsoever. On our side its a <5 minutes work.

The id checks don't need to be triggered when the client is started. It could be sent randomly. It doesn't need to be sent very often.

We can also make so that it is only sent when an immortal issues a command to scan for illegal clients.

They would need to decompile our software to figure out what to respond with. Which isn't really legal.

Wrong. In many countries, not only is it legal, it's actually explicitly protected.

Well i'm no lawyer. It will be against our end user license to reverse engineer the software.

Nonetheless, it will be a hassle to decompile our obfuscated binaries to figure out the encrypted id checks everytime you wanna start your illegal client.

My first question is, what are you solving with this approach?
What problem is fixed by forcing people to use your client?

I can tell you that I'm personally going nowhere near a
precompiled binary some mud admins cooked up and try
to make me run. The security implications of running such
a program, designed with the kind of planning I've seen so far,
are just an insurmountable object for my adoption.

Is there a purpose to forcing the exclusive use of your client,
other than a sense of control?

I would also comment that not only do you discourage
new players with such a hostile approach, you also are basically
challenging every clever coder out there to figure out some
way to defeat you. I think that no matter how
smart and clever and dynamic your defenses are, your efforts
to prevent the use of anything but your own client will
be foiled by someone more determined to make you look
silly. And the hackers have all the time they need to
figure it out, and they only need to defeat you once per
each client update you make.

Personally I think it's a horrible waste of time and energy to
do this, except maybe as an academic research project. If
what you're actually trying to do is run a game, this
just seems counterproductive to me. What's wrong with
letting people use their favorite mud client? What do you gain
by trying to ram your client down their throats?

-Crat

Why we would enforce our own client as only option:
1. To prevent things we don't like in other clients such as scripting, triggers, bots (to make the list short).
2. To make players use the same software and have the same "basic" tools available. Rather than having heavy scripting doing the playing, you should do it yourself.
3. Get a "sense of control" as you put it.

The reason we would NOT enforce our client as only option:
1. Might loose a bunch of players that wouldn't use anything but their particular mud client.

Horrible waste of time? As i said, this "client check" is a 5 minute hack on our side (or probably less). Its a terrible much more work on the "hacker" side trying to continually update their clients as we daily patch our software.

It all boils down to if we want to enforce our own client or not. At the moment, we're probably going to do so. It is a TERRIBLE amount of work to get our game working for any standard mud client. The game is build upon a custom client GUI and it isn't going to easily be working with any general telnet implementation.

It depends what you mean by 'many'. I've encountered quite a few, and several of my regular players are blind. It makes sense if you think about it - blind people can enjoy roleplaying games just as much as anyone else, but when it comes to computer games they can't see the graphics.

I don't think you understand what I meant. A simple example would be something like this (very simple):

[code] Server>

function send_update
send Current_Seed
end function

function send_request
send Time
end function

function recieve_code (Client_Code)
if Client_Code <> Current_Seed + Time * 3 then
call Report_Bad_Client
end if
end function

Client>

function update (Seed)
set Current_Seed = Seed
end function

function seed_requested(Time)
send Current_Seed + Time * 3
end function[/quote]

Now, the test itself is 100% random. The method used still needs to sync, based on what "time" the server thinks it is, so the correct response is returned, but the method used to get it could be a complex algorythm, not just "Current_Seed + Time * 3". Understand what I mean?

See, this could work, without completely ****ing off the player base. The problem with your approach is that, unless I am missing something, you have to download an update to the client every day. It would certainly frustrate me, since I don't have anything but dialup. It might still bug people that have better connections. And there are problems with you making mistakes in the client, which make it fail with the server, bugs that can cause crashes in the client, etc. Every time you have to change the binary of the program to adjust the encryption, you risk having and entire mud full of players wondering, "Why can't I connect?", or, "Why does by client keep crashing."

And, as someone else pointed out, the minor form of safeguard you are talking about "may" be covered in some countries under "interoperability" statutes. A full encrypted system, which uses a clear algorythm, would be covered under either the DMCA or other legislation, including that it other countries, where encrypting a few bits may not quite qualify in that country.

And you "need" to consider all of those things. The mud I play on is running in Sweden and populated by people from Sweden, England, Canada, the US and I think even one Australian. Exactly "which" countries legal stance covers you attempt to prevent duplication of the client? Probably half the players "may" be on dialup, since its one of the few things you can play that work right over it, so constant downloads of patches is "not" going to make those people happy. I know at least two people, out of about 100 "active" players on the mud I play that use text readers, and several others that have worked on tying them into Mushclient, so they can use it. And then, as I mentioned, there are all the things that go wrong.

Now, personally, the mud I play one has **very clear** guidelines for botting, and people *have* been permanently banned for doing so. Scripting they don't care as much about, as long as it only provides information to the player and "never" acts as proxy to their own input. Harder to catch, but people are "still" caught at it. I happen to be one of those that use various scripts to help me play, **none** of which directly send anyting to the mud itself, unless I specifically type something to initiate it, and even then, most of it is indirect stuff, like changing my description based on my mood, custom random emotes, etc. There is no way in hades I would use a client that cut me off from the ability to do this. I doubt "anyone" that plays on my mud would, no matter what "features" the client included as standard. In fact, most of the people there now use Mushclient, "precisely" because, even though most don't use its scripting at all, even its basic features tend to do more than most other clients.

I find it hard to imagine what could or would make playing some place that uses such a client would "possibly" make it worth all the hassles, unless the process by which the clients are authenticated is 100% transparent. But nearly any such system "can't" include the sorts of updates you are talking about, nor are most of them impossible to hack.

What about absolutely no telnet support at all? I think what most of you are assuming is that the MUD's client would be a normal MUD client clone-- just without all of the advanced trigger and scripting abilities. I'm not a coder (yet), but it seems like it would be possible to send the MUD information via another way instead of telnet, making zMud and MUSHclient nearly impossible to use since they are just complicated telnet clients AFAIK.

Either way though, I suppose that there is always a way to get around it. I would think that it's possible a person could run the MUD's client that would take care of the encrypted ID checks while running their own program that could read the parsed data and run triggers or scripts off it.

I can't imagine that there would be many such players hacking a MUD's client just so they can use MUSHclient's features instead. I could write illegal triggers or scripts for the MUD I play, but I can't reverse engineer, decrypt, etc. If there were less players hacking your custom client than breaking your botting rules, then it seems like a worthwhile idea. Of course it's not 100% cheatproof (what is?), but I really think it would reduce it.

I don't think many existing muds could successfully switch to a custom client only and retain a large percentage of their player base, but both new muds and muds that appeal to non-mudders/new players could do it. I know I could get used to playing without MUSHclient if I was playing on clients that looked as nice as . I imagine having more clients like this would help appeal more to beginning mudders (and expand the mudding community! ) , even it was a telnet supported mud.

KaViR,

I did notice some of the blind-player config options available on Godwars II when I tried it out. Do you think maybe you could explain some of the mechanics of how blind people play? This is very interesting, since it seems like a pool of players practically guaranteed to remain through whatever the MMORPGs can hurl at the MUD community. But how does it work? Voice synthesizers? I would think that would get old fast, unless the MUD were thoroughly tweaked to give the most info in the least words. Even GWII which apparently has taken blind players into consideration, I can't imagine how fast a voice synthesizer would have to babble to keep up...

Basically it just reads out what's displayed on the screen.

The speed is configurable by the client, and at top speed it is indeed very fast. You know the reaction you get from a non-mudder when they look at your screen and see all that text flying past? The way they can't understand how anyone could possibly keep up with that much information? Well my initial reaction to the screen readers was like that.

But apparently you can get used to it, just as a sighted player can can get used to picking out the useful information at a glance. You can even skip to the end of a sentence, which is useful when you know what it's going to say.

Still, there are ways to make it easier for the blind player. A way to switch off the prompt can make a big difference. The ability to set aliases to show important information, so they don't have to go through the spam of the entire 'score' screen every time they want to check their hp. Things such as colour and table layouts are pretty useless for them, so providing more screen reader friendly ways of accessing that sort of information can also be a big help.

There are various different readers (some of which are open source), but most of the blind players I've encountered seem to use JAWS (Job Access With Speech). One of my players also created a sound pack for combat messages, which was rather fun.

There's also a website dedicated to audio games, which you might find of interest (particularly the FAQ):

Several of our players use JAWS, and a few have reported other interfaces as well. Some are capable of parsing out 'nonsense' characters or repetitive text, though we have reconfigured several commands to be less intrusive for speech interfaces (example: time gives 22 lines of output; stime gives one - both give the player the game time, date, season, etc).

Regarding blocking telnet... are there not enough barriers to entry already in place? Is throwing another roadblock into the process really going to enhance gameplay?

Or, alternately to all the stuff you mention, another option would just be to not play the MUD in question. I imagine that's what route most people would take...

Bah! What would be the fun in not trying to hack the system? lol

Probably, but it would only require one person to take the sort of route shadowfyr described. One person who already plays the game, but would benefit from having an alternative client - or would simply enjoy the challenge. Then they'd give it to their friends, who'd give it to their friends, etc.

Banning other clients to stop bots/triggers might not be such a good idea. Why? Because you can write a screen reader(OCR) to scan for patterns, and then send the commands to the client with the usual Windows messages. Suddenly your own client is used by the bot, not even bypassing any encryption.

There was a big discussion on the zMUD forum a few years ago about adding support to zMUD so that MUDs could disable triggers. A lot of people mentioned different ways to bypass the system which caused the feature to be dropped.

If you want to prevent botting then you need ways to detect bots not force a client. Having a custom client available is nice, but I know personally if I'm bored enough I might find it quite fun to hack a proprietary mud client/protocol just because I can. And of course being able to do so without the insane legal measures a large scale commercial operation would hit you with.

Even if you think its unhackable and claim that it is unhackable that will just encourage more people to try.

Well I think there's a big difference between actively blocking other clients, and simply not supporting them. But if you're going to take the latter route, I'd personally suggest supporting raw telnet, as that would allow everyone to play without downloading a client.

If I have to download a client in order to play, it's unlikely I'll ever give the mud a chance. But if I can play with telnet, and like the mud, sooner or later I'm going to be tempted to download the proper client.

The problem is that supporting raw telnet is a very hard thing for us to do... Things such as our map, combat, help files, character creation, account management, mail system etc etc are all built upon our client GUI. And we intend on making even more features in the future based on a graphical GUI. We don't intend on at the same time supporting raw telnet since it is not in any way an enhancement and would only require a huge amount of extra work.

So develop your own Telnet Option, and the extra info is only sent if the client supports the option. Then people can code their own plugins to support your telnet option and get the extra info if they want.

You won't stop botting/scripting just by having a custom protocol or client, it really is just a red rag to a bull.

Too much work.

WAY easier to add a system to prevent other clients. I'm confident we'll catch almost everyone trying to play the game using another software than our own.

Then if some few persons manage to play with their own software without getting detected, we still have prevented 99% of our users from botting and scripting. I'm sure we'll catch every single abuser however, sooner or later.

You don't have to support all of the features with raw telnet - and there's good reason not to, if you want to encourage people to use your client.

But actively blocking many players' favourite clients, and forcing people to download your client in order to play, will take away one of the biggest drawing factors of muds; accessability.

You won't be able to stop people creating their own clients - if your game is worth playing, they'll find ways around your security measures. All you'll do is discourage people from trying your mud in the first place.

You think adding a telnet option to your codebase is too much work, but writing a custom communication protocol and client isn't?

No of course not.

But when we are already writing our custom protocol for a graphical interface, spending extra amount of time to implement backward compability for telnet is too much work.

Our game will not work with only a telnet client. To get the game working you will NEED components from our existing client or you will not be able to play the game fully.

The only way someone could use mushclient to play our game for example is if they extract data from our client and implement in their own code.

For example. When the player moves to x,y on the map in our game ONLY the coordinate is sent to the client which takes care of the rest. You need all the map data in your client to display it.

I guess it depends on your priorities, but in terms of "potential customers relative to effort invested" it's likely to outrank most other features.

Which is rather the point. Yes, you can make the game unviable with raw telnet - that's not hard, but it solves nothing. The people who want to exploit things at the client-end will be unaffected, all you're doing is discouraging the people who don't want to download anything, or who prefer to use their regular mud client.

Yeah... However, I don't think that will be a problem. People that won't play our game because they can't use their regular mud client isn't our primary target. Most of them are anyways WAY to dug in and addicted to whatever mud they use their client on to move to a new one.

We have not built our server and client with the intention of making it hard for people with telnet to use the game. We haven't even decided wether or not we're going to allow people to use other clients (if they code their own) or ban them.

But when building the game we have not put in the enormous amount of extra work it would take to make separate code for a dinosaur telnet client and our own. Instead we have built it optimized on resources, bandwidth and other things to make our own custom client faster and better. Adding support for telnet in a semi-graphical mud is just ridiculous if you ask me.

Umm. Wait... WHAT? How does setting up a protocol so that it does something like MXP does, and sends a "Can you do <our protocol>", waits for a, "I can do <our protocol>", then, "Do <our protocol>", followed by, "Will do <our protocol>". Hard? Yes, standard telnet clients *won't* work right. Neither will those that don't support plugins for the new protocol, but nothing prevents you from releasing specs (Clear ones though please! We are still arguing with Zugg about why his client won't follow its own specifications correctly...) then letting someone else figure out how the heck to impliment it. You still get your custom client, since initially its all that would support it, but you don't have to bury your head in the sand and hope that someone doesn't duplicate it. And, depending on the interest, you might find yourself in the embarassing position MS did a number of times, where they announced, "We have this new protocol, which we don't expect anyone to 100% duplicate.", and the tech industry going, "Really!? Just a sec... Ah, here you go. We implimented this last week. Please point out which part of your protocol it doesn't support..."

I think you are involved with a lot of wishful thinking in this plan.

That isn't at all true in my experience. We get a lot of players from Zmud, Mudconnector, and Topmudsites, and most of them prefer to use their own client to connect. Many, many MUDers are always on the lookout for a MUD to meet their currently unfulfilled desires.

--matt

I think that the point is that AeonFalls uses a more graphical interface than your typical MUD, and therefor loses a lot of what it offers if it allows a standard MUD client. They will lose some traffic of people who cannot do without their zMUD, yes, but it can be a design choice to want all players on a level and quality playing field. Whether or not it succeeds will come down to market strategies, and whether or not they are sufficient to make up for the slight loss they will take when attracting hardcore MUDers.