[Rathik]

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?

[Hephos]

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

[shadowfyr]

Don't bet on it. Hmm..

[code] function OnPluginPacketRecieved
if <some Aeonfalls code> then
send "proper response"
return false 'Don't let client handle the line.
else
return true 'Clean non-server specific, let the client handle it.
end if
end function[/quote]

That lasted about 5 seconds. lol

Seriously. Something like Mushlcient, even if you stripped things down to UDP and built a special TCP/IP like system on top of that (some companies did that in the past for their systems) there is still the Simulate command: Sends data from the script to the client as though it was being recieved from the mud, for testing triggers and scripts. So, all you need at that point is a socket library and the script system that would support it. Lets see... Python? Yep. Lua? Yep. Others? Sort of, but you can't create threads in them to handle the inbound data properly, without locking up the client while waiting for the script.

But heh, good luck trying. You might actually scare off enough flexible client lovers, like myself, to avoid someone hacking the system the day after its implimented. lol If not, then its a "lot" easier to update a Mushclient plugin to handle new codes, then upload it to the net, than it is to completely rebuild both the clients and the server to disable the previous system, which did get hacked. I am not sure its really realistic now to try to prevent people using other clients, not without changing the system to such an extreme that its not even possible to identify the differences effectively, never mind code around them.

[the_logos]

Originally Posted by (Rathik @ Aug. 24 2006,15:31) 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?

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.

[the_logos]

Originally Posted by (shadowfyr @ Aug. 24 2006,19:59) I am not sure its really realistic now to try to prevent people using other clients, not without changing the system to such an extreme that its not even possible to identify the differences effectively, never mind code around them.

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

[Hephos]

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.

[Smith]

Originally Posted by (Hephos @ Aug. 25 2006,19:08) 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.

[Hephos]

Originally Posted by (Smith @ Aug. 25 2006,04:32) 8--> Originally Posted by (Hephos @ Aug. 25 2006,19[img http://www.topmudsites.com/iB_html/non-cgi/emoticons/wow.gif[/img]8)]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.

Yes thats what I am saying... On one hand it opens up for more possible users allowing any type of client. On the other hand that also opens up for trigger and bot abuse (among other things). So we're still considering both options, but are leaning towards only allowing our own client in a similar way that other muds make bots illegal (enforced by active immortals).

Then we have other problems. Our client includes game specific things that other clients will have a very hard time to implement (although a very fanatic person could probably do it ). That includes things like help files, map images and coordinates, character creation, mail system etc etc.

[fire_phoenix]

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.

[shadowfyr]

Originally Posted by (Hephos @ Aug. 25 2006,04:08) 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.

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.

[shadowfyr]

[quote= (Hephos @ Aug. 25 2006,04:43)]

Originally Posted by Smith,Aug. 25 2006,04:32 Our client includes game specific things that other clients will have a very hard time to implement (although a very fanatic person could probably do it <!--emo&). That includes things like help files, map images and coordinates, character creation, mail system etc etc.

Hmm.

1. That could be a problem, but not impossible, just not something you can just glue something on and have work. Then again, if someone wanted to do so, its not hard to have the script make an OS call and run the help file. You just need to get your hands on the file.

2. Trivial, as long as someone uploads the maps someplace, or they are (most likely) FTPed from the server. Though, right now there is insufficient GUI support in Mushclient to manage it. I am actually working on an add-in that would include a form designer and common GUI elements. With LuaCOM I don't even need to reinvent the wheel when using a COM bridge to get events from the controls and once you can make a window, add controls to it, then capture events, you are only limited by what controls you can create. Fact is, if I was willing to ignore half of the client's users and did it in .NET, I could have all those for free, including the designer (well, as free as needing to install the .NET framework).

3. Trivial.
4. Trivial.
5. Very trivial.

Next problem? lol

[Brawndel]

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.

[Hephos]

Originally Posted by (Brawndel @ Aug. 25 2006,23:52) 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).

[Hephos]

Originally Posted by 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:

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.

[Hephos]

Originally Posted by 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.

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.

[Kylotan]

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

[Hephos]

Originally Posted by (Kylotan @ Aug. 26 2006,04:38) 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.

[cratylus]

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
http://dead-souls.net

[Hephos]

Originally Posted by (cratylus @ Aug. 26 2006,12:50) 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 http://dead-souls.net

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.

[KaVir]

Originally Posted by (Hephos @ Aug. 26 2006,09:53) Originally Posted by (Brawndel @ Aug. 25 2006,23:52) 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?)...

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.

[shadowfyr]

Originally Posted by (Hephos @ Aug. 26 2006,04:36) Originally Posted by 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. 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.

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.

[Rathik]

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.

Originally Posted by (shadowfyr @ Aug. 26 2006,13:11) 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.

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 this. 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...

[Trip]

Originally Posted by (erdos @ Aug. 27 2006,09:56) But how does it work?

They just have to switch to the braile font of course. I kid! I've had a few blind players play and I have nothing but respect for them because I know somtimes I have trouble keeping up with the pace of the text, much less having to run it through a text to speech type thing or a braile display screen.

[shadowfyr]

Originally Posted by (Rathik @ Aug. 27 2006,03:10) 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 this. 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.

Hmm.. Yeah. Neat GUI elements. Someone built a map system for Mushclient that worked with a Mechwarrior based mud. I myself built a test case, which I worked on "long" before I even had access to the client's parent window (I used the API call FindWindow to get it instead). It then used other API calls to figure out how big the main client window was, then resize itself to fit on which ever side you wanted to locate it. It could also float over stuff. Now, if I rewrote it, I could probably make it faster, and use more specific Mushclient functions to get information, like the Clients window handle, size and position. However, all my gadget did is let you spark off some fireworks. It was intended to provide a more visual version, through a trigger system, of the fireworks they sometimes shot off on the mud occationally, though I never did incorporate algorythms for the goofy ones they sometimes came up with, like plaid and multicolored. lol

Now, because of some new features in the client itself, its both much easier, and much harder, to generate such GUI elements. Easier, since I now can get more direct info on the client, harder because I would need to use only the 1-2 supported languages that work properly with such elements, Lua and Python, and because I have since discovered that the standard ActiveX version of system controls, including those lovely checkboxes I would need to have to duplicate Aeonfalls' interface, are DRMed (sort of). If you don't own a version of VB 6 or earlier, you don't have the license installed to use them completely. You "could" hand code all the element designs into a plugin, so they automatically adjust the client and GUI windows to match (with minor exceptions, like the Hit/End/Mana/Bal display, which I am not sure I could shoehorn into the actual client window... However, my intention was to set up a "design" plugin, which would let you set up your own layouts, so someone could duplicate any system at all.

The problem of course.. Is that you can't use "design mode", where you drag and drop, then resize your controls, using the mouse, because you need a) the VB OCX file *and* the registry entry that licenses you to use those in design mode. I might be able to create them in run mode, then switch to the later (maybe), but haven't tried, because I don't know C++ beyond hello world type stuff and "at minimum" the window you place controls on would need to be hand coded, since there is no such thing as an ActiveX "form" window, which supports design. Worst case, you still can't use the OCX's design mode features, so you are stuck custom making "all" controls you plan to use.

This problem is the "only" thing keeping me from duplicating the client in that link (well, other than not knowing what data is sent to update its GUI system), within a matter of a few hours. Thing is, some of us know we could manage the same, with the flexibility of Mushclient, have discussed it, occationally some have designed specialized ones for specific muds, but its simply that no one has put it all together.

Would also help if there really was a standard ascii range TTF font, which everyone agreed to use, instead of a dozen, less readable, alternatives, only a few of which support the set that Windows jokingly calls the "System" font, and even then "only" as part of their unicode ranges. And to make this even more fun, if you don't have access to that range in the client (such as using UTF-8 instead of a form that doesn't prevent use of some the unicode characters), is that they can't seem to agree on what characters "should" be in the 127-255 range of the ASCII set, or where the undefined "gaps" should be in it. Nor, to make things even more fun, does the stuff they do agree on "match" the OEM system font that all PCs have used since practically the first display card for the first PC was ever made.

But that is a completely different gripe. lol

[KaVir]

Originally Posted by (erdos @ Aug. 27 2006,15:56) 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?

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

Originally Posted by I can't imagine how fast a voice synthesizer would have to babble to keep up...

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.

Originally Posted by (KaVir @ Aug. 27 2006,17:20) 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.

I would like to try one of these readers out for myself, which ones are available for which OS's? Or is this generally very specialized, expensive software?

Just when you think you know about everything there is to know about MUDs, along comes something to turn your whole world upside down...

[Hephos]

Maybe you can even select some sexy female voice to do the reading for you

"You slash an ogre VERY HARD!"

[KaVir]

Originally Posted by (erdos @ Aug. 28 2006,01:32) I would like to try one of these readers out for myself, which ones are available for which OS's?  Or is this generally very specialized, expensive software?

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): http://www.audiogames.net/

[Fern]

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?