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.