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.

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.

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.