[shadowfyr]

Originally Posted by (Fern @ Aug. 28 2006,04:56) 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?

Its also meaningless. I created a proxy to echo info back and forth to the client, for testing. We don't need it anymore, since there is now a "simulate" script command, but all I did was impliment a listener for TCP/IP, which when it recieved the packet, simply echoed it back the other way. Telnet is almost "pure" TCP/IP. So, blocking it is flat out silly. The only "protocol" involved it purely the "IAC+some_request" segments. With Mushclient, you can look at and handle the raw TCP/IP packets, before they ever get to the client. Other commands exist to intercept outbound packets, and alter them too. At "worst" someone could use a socket library in Python of Lua to connect instead. People have already done that in a few cases. Though, imho, its rediculously complicated to have your "script" create a TCP/IP or UDP connection to a second world, so you can feed data to it, based on what your "actual" game window is recieving.

Basically, the only question is, "How complicated would the new protocol be to duplicate?", not, "can it be duplicated." The client can be forced to act as though its entire Telnet protocol doesn't even exist, funneling all the data, going both directions, through scripting instead. Remember, we are not dealing with a client that is using TinTin++/zMud scripting or some lame Microsoft script engine that they intentially hamstrung to keep people from doing things in. If you can code a client in Java, which uses a different protocol, for this mud, then you "can" code the same thing in Mushclient using Python or Lua (most likely Lua, since its the *default* language, which comes with the client, now).

All blocking telnet does is make things more complicated for your coders, more complex for the players and make someone like me spend 30 minutes to figure it out, instead of 5.

Wish I knew what some of the other buttons on the bottom of the snapshot you linked did though.. Makes it rather hard to guess what I need to design a plugin to duplicate the interface. lol Though, being lazy, I might not try that hard. After all, I have to figure out how to tie in LuaCOM and wxLua to support it, unless I go all the way through the process of designing the custom system I had originally wanted. And the documentation for how to get them to work together is rather... flaky.

Originally Posted by (shadowfyr @ Aug. 28 2006,15:54) Originally Posted by (Fern @ Aug. 28 2006,04:56) 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? Its also meaningless. I created a proxy to echo info back and forth to the client, for testing. We don't need it anymore, since there is now a "simulate" script command, but all I did was impliment a listener for TCP/IP, which when it recieved the packet, simply echoed it back the other way. Telnet is almost "pure" TCP/IP. So, blocking it is flat out silly. The only "protocol" involved it purely the "IAC+some_request" segments. With Mushclient, you can look at and handle the raw TCP/IP packets, before they ever get to the client. Other commands exist to intercept outbound packets, and alter them too. At "worst" someone could use a socket library in Python of Lua to connect instead. People have already done that in a few cases. Though, imho, its rediculously complicated to have your "script" create a TCP/IP or UDP connection to a second world, so you can feed data to it, based on what your "actual" game window is recieving. Basically, the only question is, "How complicated would the new protocol be to duplicate?", not, "can it be duplicated." The client can be forced to act as though its entire Telnet protocol doesn't even exist, funneling all the data, going both directions, through scripting instead. Remember, we are not dealing with a client that is using TinTin++/zMud scripting or some lame Microsoft script engine that they intentially hamstrung to keep people from doing things in. If you can code a client in Java, which uses a different protocol, for this mud, then you "can" code the same thing in Mushclient using Python or Lua (most likely Lua, since its the *default* language, which comes with the client, now). All blocking telnet does is make things more complicated for your coders, more complex for the players and make someone like me spend 30 minutes to figure it out, instead of 5. Wish I knew what some of the other buttons on the bottom of the snapshot you linked did though.. Makes it rather hard to guess what I need to design a plugin to duplicate the interface. lol Though, being lazy, I might not try that hard. After all, I have to figure out how to tie in LuaCOM and wxLua to support it, unless I go all the way through the process of designing the custom system I had originally wanted. And the documentation for how to get them to work together is rather... flaky.

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

[shadowfyr]

Originally Posted by (erdos @ Aug. 28 2006,20:53) 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

[KaVir]

Originally Posted by (erdos @ Aug. 29 2006,02:53) 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...

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.

[Aeran]

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

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.

[Toraux]

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.

[Hephos]

Originally Posted by (Toraux @ Aug. 29 2006,08:33) 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, if nothing else, maybe its an easy way to get "bored hackers" to code plugins to existing clients

It is a *****load* of work for us to code the server to support any telnet client.

[KaVir]

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.

[Hephos]

Originally Posted by (KaVir @ Aug. 29 2006,09:26) 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.

[DagdaMor]

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.

[Hephos]

Originally Posted by (DagdaMor @ Aug. 29 2006,10:08) 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.

[KaVir]

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.

[DagdaMor]

Originally Posted by (Hephos @ Aug. 29 2006,10:35) Too much work.

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

[Hephos]

Originally Posted by (DagdaMor @ Aug. 29 2006,12:26) Originally Posted by (Hephos @ Aug. 29 2006,10:35) Too much work. 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.

[KaVir]

Originally Posted by (Hephos @ Aug. 29 2006,19:16) Originally Posted by (DagdaMor @ Aug. 29 2006,12:26) Originally Posted by Hephos,Aug. 29 2006,10:35 Too much work. 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.

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.

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

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.

[Hephos]

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

[shadowfyr]

Originally Posted by (Hephos @ Aug. 29 2006,13:16) 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.

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.

[Hephos]

Yeah.. I guess one solution to make it possible to use other clients is writing a specification and providing all material needed to run another client for download would be one way to approach it.

I guess that wouldn't be much work. A zip file with data, and just publish our networking protocols javadocs would be enough.

We'll see which way we're going to approach it Not decided yet.

[the_logos]

Originally Posted by (Hephos @ Aug. 29 2006,17:12) 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.

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

[DonathinFrye]

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

[KaVir]

Originally Posted by (DonathinFrye @ Aug. 31 2006,23:50) 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.

The problem is that you can't guarantee a level playing field, because you can't stop people from creating their own clients. All you can do is stop them from using their favourite clients, and that's going to put a lot of people off even trying the game.

[DonathinFrye]

Originally Posted by The problem is that you can't guarantee a level playing field, because you can't stop people from creating their own clients. All you can do is stop them from using their favourite clients, and that's going to put a lot of people off even trying the game.

I don't disagree that it'll turn some people away, but just as anything, if you want to prevent something - you can only take the steps necessary to discourage it as much as possible.

An example of what I refer to is the combat dev concept of scripting and howmuch it should be allowed to effect PVP combat(or discouraged from effecting combat). There are certainly precautions you can take that will reduce scripting's effectiveness, and those precautions may turn players who are very script reliant away from your game - however, there will still be some hardcore, talented players who find ways around your precautions. I believe the same could be looked at here - it's a dev choice, just like anything else, and they have decided that their target does not include people unwilling to try their MUD without running zMUD/etc. This could definitely bite them in the ass, as you predict - and as long as they are aware of that and aim their marketting well, then perhaps they will not suffer more than they are willing to for that decision.

It'd be my personal suggestion that they keep it open to a a possible future change. If it seems that they could be doing much better if they go back in and make the interface zMUD/etc compatible, then they could have that option at a future time.

[Hephos]

I have to add that we have not really decided yet which strategy to use.

1. Make !ao clients illegal to use.

2. Put up a specification and data files for download for those who wish to code their own. Possibly writing a proxy server that simply strips off every extra protocol info we have and send simply raw text to the player.