custom clients. Good or bad?
 

Greetings everyone! I have spent the last 4 years working on a Mud engine, before scrapping it and starting over fresh. I wrote the new version of the engine in C# with .NET 3.5, and I am currently in the process of finalizing a Gui based tool kit for designing the Mud project. The only thing that concerns me is my lack of knowledge when it comes to telnet and networking. I had planned on writing my own server code, and the server would sit on a couple Windows based servers (or linux when the project port to Mono is completed) and then write a custom client that users will download and use to connect to the server. I thought a custom client would be good, as I can share most of the code between .Net, .Net compact Framework, and Mono, but I suppose cross platform could be easily achieved with a telnet client or PHP based client.

What do you guys think? The goal is to have a version of the engine running on windows & linux, with client support on windows, linux, Mac OSX, Windows Mobile & PalmOS. What are the pro's and cons for running a custom client? If telnet is the best solution, where should I go for documentation on it? I don't know anything about coding telnet.

Thanks in advance!

Johnathon
Airhead Gaming

Re: custom clients. Good or bad?
 

Cons:
Pros:

One thing to keep in mind is that if your custom client won't include common functionality of existing telnet clients, you're probably better off just implementing telnet.

Re: custom clients. Good or bad?
 

Having a client to download is actually barrier removal.

For example, if you have a 'PLAY NOW' button on your front page, or you have a form based login page that immediately starts a client when they submit, you are light years ahead of most MUD's.

Most muds require a player to download a third party client. The person then has to be savvy enough to configure and install. Then they have to figure out how to use this beast to connect to your game (and not someone else's). This is a lot to expect from someone who has never played a MUD before. This problem is one of the biggest barriers facing MUDs.

At the very least you should have a simple custom client that will allow them to connect to your game quickly and easily. The key being quickly and easily.

Once a player is into a game, understands how MUDs work, they will learn about custom clients with more power for what they may want to do.

Re: custom clients. Good or bad?
 

Fewer players willing to try:

Studies on various shareware dev sites has shown that as a client gets larger, it gets fewer download. I think the current sweet spot is 50-100 meg. (NOTE: This is way more than your typical MUD client. :-) )

Flash seems to the popular choice for language today because (according to the wisdom of the forums) almost everyone has Flash installed. (You might want to look at metaplace.) Java seems like the next choice (runescape has done well with this), followed by your own C++/etc.


Customizable UI - I think this is important, but I suggest you go beyond teletype () functionality and have multiple windows, maps, etc. (As has been discussed in other posts.) If you're just doing the same-old UI with a pretty background, your own client may not be worth it.

Re: custom clients. Good or bad?
 

Gold jacket, green jacket, who gives a ****.

Re: custom clients. Good or bad?
 

Perhaps - but requiring the download of a specific client, as the OP seems to suggest, is a big entry barrier for muds. Requiring the use of a specific client can also be an entry barrier for experienced mudders, as you have to convince them to stop using their favourite client.

Most muds don't require any downloads at all - they work with raw telnet, or can be accessed directly from certain mud sites. The prospective player may be encouraged to download a client, and having a decent custom client can certainly be a big plus (although not so much in terms of reducing the entry barrier), but they are not usually required to download anything before they enter the mud.

Re: custom clients. Good or bad?
 

I think if a client helps to make a great game, then it is good. For example downloading a client for a 3D game is usually no problem for me as long as there appears to be some quality.

If say you make a text MUD client, and it is worse than zMUD and adds nothing really new then that would make me hesitant to download it. However say I primarily use telnet instead because I don't want to buy a client, then your client could very well become the client of choice if it isn't worse than telnet.

It is fun to download new software :).

Re: custom clients. Good or bad?
 

Agreed.


Lets face it, raw telnet sucks. I even hit a couple site to see how well Vista telnet works, and it would not fire up for any of the game sites I hit. I got a pop up window asking if I wanted to telnet, but it never worked. Of course, I did not try to figure out what was wrong, and I doubt most people would.

The best option for MUD owners is to have a simple flash or java client on their site which can quickly get new players into the game. Nothing that requires installation, it just play right in the webpage. Then move them on to something more powerful.

Re: custom clients. Good or bad?
 

Yeah, I agree. Your client is not going to be better then zMUD. (not without a lot of work)

Your best bet is to make a simple client that can be played directly in your webpage. It should have simple alias, macro, and trigger support. It should have clean graphics, status bars, and so on. Something professional looking that will get a player right into the game.

Once a new player learns more about MUD's they are probably going to move up to something more powerful.

Re: custom clients. Good or bad?
 

The question is if you actually want to have macros/triggers :). My opinion is that if you feel the game you design requires the player to write macros/triggers then you might need to ponder what the game is about. The game should probably be designed so that triggers aren't needed.

Re: custom clients. Good or bad?
 

Umm, I disagree. People use triggers and macros ***even for MMOs***. I use a program to track my DPS and everything I have killed in EQ2, by reading the data in the log file (annoying, since it would be a lot nicer to read it directly from the data stream in their client). Suggesting that you need to rework the game if people feel the need to use such things is just.... absurd. There will almost always be some things that you want to display in windows that the mud, even with a custom client, won't display they way you want, information the player wants to keep track of that the client/mud doesn't, or tasks that, no matter how well designed, may be easier to assign to a keypress than having to type them all manually. Its not about "requires", its about, "flexibility", and frankly, the ones that laughably try to ban "any" use of them, instead of just nailing the botters when detected, annoy the hell out of me, as do the ones that insist I have to use their client, because doesn't have scripting, or triggers/macros that are worth anything (being too limited).

But it is a catch-22. The more someone can do with you macro, trigger, alias and script system, the more vigilant you have to be at watching for people botting, but at the same time, the happier the user is with the client they use, when employing "allowed" tricks and helpers. And, *almost everyone* is going to find something they wish they could display differently, work out without using pen and paper, or use to help them in a way the existing mud/client won't, as it stands.

Re: custom clients. Good or bad?
 

Thanks for the tips everyone, the main goal of designing this engine is to make creating MUDs easy, it has a tool kit with a real clean UI with drag and drop support for linking rooms to doors. I don't plan on building a large MUD with it, but rather releasing the MUD for 3rd party developers to make games with.

That being said I would not know where to begin with the telnet side of things, how would I go about writing a server that supports telnet?

As for custom clients, the goal was to provide a new user with a simplified experiance. Alot of times trying to remember all of the commands available or what commands do what can confuse a new player, and thus the reason behind a possible custom client with a UI so the user won't need to enter commands. The client download size should be less than 1MB (not including the .NET framework for windows machines) due to the server containing all of the files. The client should just send a command to the server, server parse it and send back text to display in the console. Am I going about that in the right way? clients should not have any of the game files stored on their local machine to prevent hacking correct?

Thanks again everyone.
Johnathon
Airhead Gaming

Re: custom clients. Good or bad?
 

Yeah, I can't remember who said this, but the quote goes 'always remember the client is in the hands of the enemy'. ;)

Re: custom clients. Good or bad?
 

A lot of the display needs can be handled by easier methods than advanced triggers. For example the server could handle different ways to send the output to the client. In e.g MXP I believe you can set client side variables as an example how it could be done.

It is when the triggers are capable of sending data back to the MUD you start to get very close to automating gameplay. If you look at some scripts on Zugg Software's forum you can see that some of it is pretty questionable. Atleast if you would like to run a game that is somewhat fair to users both with and without zMUD.


In some rpgs I have played botting has been so common that real play is rare. When you look at how some of those games are designed many of them almost force you to consider write a bot to endure the gameplay :D. That's in my opinion the kind of gameplay to avoid designing.

Re: custom clients. Good or bad?
 

Vista comes with telnet (client and server), but it is disabled by default.

To enable it you have to:
1) Click Start
2) Click Control Panel
3) Select Programs and Features
4) Select Turn Windows Features on or off
7) Click the checkbox beside the telnet client
6) Click OK

Hope that helps.

Re: custom clients. Good or bad?
 

Couple links to get you started:



Google is my friend!

Re: custom clients. Good or bad?
 

Thanks for the links and info, I'll take a look at it. Maybe the best thing to do is instead of writing my own networking engine, write it all to work with telnet, provide a custom client as an optional download, but still allow the game to be played through traditional telnet clients or php based web pages for those that have clients they prefer.

Re: custom clients. Good or bad?
 

This is true, and a "lot" if it can be solved by incorporating in features like MMOs have, like command toolbars, auto-targetting, etc. But, like I said, you still get cases where something is just a pain in a backside to do in the game, or the information you are looking for is not easily kept track of via the client.

Some simply can't be though, without having at least "some" questionable interactions. The rule the mud I played at has is, "It can send commands, as long as all you do with the result is display information, or do things that do not directly effect game play." This means you could have a trigger "set" the name to be used to heal someone, based on some event, but you still have to "cast" the spell. You can send commands to check your inventory, to make sure you put away all your stuff, as a sequence of things needed to log off, but *you* have to issue the command that starts that sequence of events. If it was something in combat, instead of a log off, that would be even more restricted, you can't have one command cast a series of buffs, but you could have triggers register the fact that you did cast the spells, then set timers to warn you when they where about to need to be recast. The timers **cannot** recast them though. At one point I even came up with a joke, based on sending multiple lines through tells, where my tell would respond like an NPC and display a price list for made up items. Other people grabbed the idea and set of shops to sell extra items they collected. This has become redundant (mostly), and there are now restrictions preventing multiple lines being sent over anything "except" tells, where its still allowed. But, its one case where technically the client "is" doing something one its own, completely separate from the user, but it has *zero* impact on actual game play. (Unless you consider telling people you have a piece of armor for sale as "effecting advancement". lol)

I don't know, I just like to have "some" control over what my client is doing and the ability to tweak some things to fit how I play. Limiting what the client can do, severely messes with that ability.

Re: custom clients. Good or bad?
 

I guess one way to go between the both solutions is to have an API on the server the client user can access, e.g remote procedures similar to xmlrpc. It would give huge advantages to retrieving information to display, but still make it possible to limit bot-style scripts.

Re: custom clients. Good or bad?
 

A custom client is the ultimate way to go. Muds need to come into the 21st century and use all the tools available to them and a custom client is certainly one of those tools.

That said, if all your going to do with the client is to offer a dull black screen and a connect button aka any telnet app out there, and by app i mean everything from windows telnet to zmud and mushclient then you might as well just embed some dumb java app into a website and call that connectivity.


Take a look at the Bat Mud Client for inspiration, those guys have written a truly amazing client for their mud. Its has good features and is easy to use and enhances the game play experience.

If you ever wish to gain players from outside the mud community you need to start offer non mudding players something that they understand. The understand download client, or click here to play, they don't need confusion of telnet or download someone else's client and try and work out how the hell to connect to the game you wanted to play. A mud client should be like every other game out there, you click start and your in the welcome screen with the press to connect button.

I have run some small scale tests on this with my children, their friends and with 2 classes of year 7 students (12 year olds) at school i have access too, using my own test muds website as an example. I found from talking with them that they find it confusing to have to download a 3rd party program and connect to a mud, 85% of them were happy to click the play now and use The Bean Client and none of them could work out how to use mushclient even when it was installed already for them.

Re: custom clients. Good or bad?
 

There's these two neat programs, they've both shipped on every version of Windows in existence except for Vista, their called telnet, and hyper terminal... (Hell, even on Vista their incredibly simple to install) As for Mac/Linux, well telnet has shipped in EVERY version of them, so yeah stating that to play muds requires having to download a 3rd party client is really just well, not true, for most people.

Oh, and to stay on topic, custom clients are great, as long as they aren't enforced. Custom clients being an option is neat, being the only way to connect to a mud (goto crackwhip.com if you aren't sure exactly what I mean) is lame and will cause many people accustomed to their favorite client to flat out not play your game at all.

Re: custom clients. Good or bad?
 

A MUD will be slitting their own wrists if they direct a player new to our type of games to play on telnet or anything like it.

Re: custom clients. Good or bad?
 

Yeah. 1) They are usually intended to be "basic" shells for talking to networks, not games, 2) they can't do jack beyond that, and 3) at least with Windows versions, they don't automatically default to ANSI, but require archane methods of starting them to activate it, never mind any other extended features that clients may have, which means the game will look bad, or not work at all with them.

If default Telnet apps where upgraded, instead of languishing in the same state that MS also kept MS Sort-of-Paint and Barely-a-Notepad, this might not be true. Instead, they decided not to *ever* even upgrade it to something as basic as *supporting* ANSI automatically, instead of making you manually turn on the older V-100 standard, but actually *disabled it* by default in the latest OS... This is just completely nuts.

Re: custom clients. Good or bad?
 

If an applet in Windows isn't going to be used by at least a million users (as a wild guess), Microsoft tends to remove it. You're lucky (in a way) that the Telnet apps haven't been removed completely.

Reaslistically, very few people use the Telnet apps, and even if they were super-souped up, the number of people using them wouldn't increase that much.

Re: custom clients. Good or bad?
 

Probably true, but then, like you said, this is MS mentality. Never correctly support anything old, make people upgrade, even if it doesn't work with prior documents/systems, then *insist* that this is to make the system more efficient, despite the fact that a) its more bloated, slower, consumes more system resources, etc., and b) other people somehow manage to make "better" systems, without cutting out every single application thats gotten "old". One would almost think they where trying to cheat people out of money, instead of providing the best product. ;) lol

Re: custom clients. Good or bad?
 

This is may be true if the only person your marketing your game to is the existing mud player who understands the differences between clients and has over many years come to understand how one particular client works and no matter how much better something is, will not for the love of god give up his particular client. We all know those who play using gmud or telnet or something equally as stupid IMO.

On the other hand, if you want to market your game specifically to non mudders and to grow new players into a text based game medium then your going to have to offer them an experience that they can understand. A custom client download is one method and an really good web interface would be another.

For the game that I'm currently working on, i put in a lot of time into researching various aspects of the game design and connection methods by surveying 140 people from 2 different age groups that I have identified as being my target audience. (Sidenote: This also was used as my university statistics project)

The one huge standout from the analysis was that nearly everyone saw the 3rd mud client as a barrier that would stop them from playing a game and that it was very confusing. When offered a choice between a web client and a propriety client download, they would take the download.

I have also been able to run practical experiments with 70 upper primary students, (12 y/o). When offered a choice between telnet, mushclient and a webapp, they all connected via the webapp. Not one could connect to a game using telnet, or mushclient. When offered a propriety client as a download that was configured in such a way as to connect to the game either automatically or via a quick connect method then nearly all were able to connect and progress through creation. (for this part i used a pre-configured mushclient and portal-GT)

The smart muds will come into the modern age and will offer prospective players a custom mud that has either been designed with a single game in mind like BatMud which in my opinion is absolutely brilliant or they can offer a preconfigured mushclient or similar as a download to overcome initial barriers. Mushclient with its plugin architecture is the perfect client for use in such situations.

As for limiting access to only one type of client + a web interface, i am considering this for my own game. i don't really see the current mud player as my target audience, so potentially missing out on a few players that way is not really an issue to me.

Re: custom clients. Good or bad?
 

Emphasis mine. It's true if any of those you are marketing your game to are existing mudders. Also note that "better" is a subjective term - you might think your client is great, while someone else might think it stinks. If people have the choice then they'll use what they prefer, while if they don't they might decide to give your game a miss entirely.

You can still offer them a custom client without excluding other clients. Forcing people to use your client won't make your mud any more appealing to newcomers, it'll just raise the entry barrier for existing mudders.

You're creating a mud which doesn't target mudders?

Re: custom clients. Good or bad?
 

Some of the most successful games (of genres) have been simplified/revised games targeted at non-core games.

For example:

Real-time strategy games - Real strategy games (from Avalon Hill) took hours per move, and all sorts of complicated rules. The same complexity was included in the computer equivalents. Then RTS was invented, which is a strategy game that's targeted at non-strategy-game players.

Myst - You could think of it as a redesigned/simplified adventure game.

Runescape - A simple MMORPG with crappy graphics. Real MMORPG players despise it. Runescape has 9M players.

Adventurequest and friends - A very simple CRPG with anime graphics. Heaps of players.

Re: custom clients. Good or bad?
 

What forcing someone to use a specific client does tho, is allow you to offer a game experience that is uniform across all players and it allows me as the developer to have total control over every aspect of my game.

Raising the entry level to mudders in some situations might actually be a good thing. Lets be honest a great majority of mudders are pretty fickle, they dislike change and are happy with what they like and are comfortable with.

To elaborate much on this is difficult without sounding whining, there are a huge list of reasons based on my experience that has led me down this path, . tho if i was to make use of a 1 client policy it would be because i want to control every aspect of my game.

Yes this is exactly what i am doing. Firstly i do not consider my game to be a MUD from a traditional standpoint. And while i share features with muds and use text as the interface, i feel my game fits more into a FPS MMORPG category better than it does a MUD.

I do not see a lot of potential for growth within the existing mudding audience. I see it as a shrinking demographic of mostly over 25's who have been playing MUDs for a number of years who are well catered for by the existing games that own most of the market share and to break into this the existing mud market is extraordinarily hard. I feel that covers about 95% of the players out the, the other 5% are encompassed by the tinkerers who put up a stock base to play with for a while or those who are programmers who have a need to make something new.

I see the greatest potential for growth in the 12 to 19 y/o casual game segment, where the players actively try new games, play for a short period of time and move on to something new. Pretty much the opposite thinking of muds that like to gain players and keep them for extended periods of time.

My game has been designed to keep someone interested for between 4 and 6 months and then after that they would most likely move on to other games. I have developed a rather in depth marketing strategy for the game that i feel will be able to get it off the ground, and will be directly marketed to 35,000 individuals in my local community through a partner ship with a retail games outlet.

The game itself is competition based that will offer 6 to 8 weekly competitions with cash and prizes begin offered in a number of catagories.

I am happy to elaborate further if you want, im just rushed right now and cannot add more.

The_Fury.

Re: custom clients. Good or bad?
 

But how many successful games have been specifically targeted at people who don't play that type of game at all? Perhaps there are some, but I can't imagine there are many. A mud designed to appeal to people who have never played Diku, EverQuest, MUSH, WoW, etc...that's going to be a pretty hard sell.

Not really. There's nothing stopping a dedicated player from creating their own client - and if there is value in doing so, and your game is successful, then sooner or later that's exactly what will happen.

As I said before, all it does is raise the entry barrier for existing mudders.

It'll still be a type of mud, just as MMORPGs are a type of mud (indeed some of them are little more than Diku clones with a graphical client). Muds come in many different shapes and flavours, and those who play your mud will also be mudders.

You're deliberately discouraging existing players from trying your mud, and those who do play will be expected to leave after 4-6 months? If I were attempting to create a popular mud I would be doing the reverse - appeal to existing players as much as to new ones, and attempt to keep them interested for as long as possible.

Re: custom clients. Good or bad?
 

I think your connecting dots that do not exist here Kavir. The very people that i intend to market my game to are players of web based MMO's, graphical muds and the like. There is a huge segment of the gaming market in the 12 to 19 y/o bracket who play games on a more casual basis, games that are quick and fun and do not have huge learning curves or are overly technical, that do not take huge inputs of time to be successful at. It would also appear that this segment is more willing to try something different and are more easily persuaded by their friends to have a go.

I would not say that i am discouraging them, but rather i am intentionally ignoring them as i do not see them as my target audience. In just the same way as a large segment of the mud community does not see DBZ players as their target audience, being that they are generally young and somewhat immature,( which really is to be expected,) where as other muds cater for a more mature audience.

What DBZ was able to do however, was to bring young people from other styles of games into the world of text based games, something i dont see a lot of from other mud genres. They came from runescape from pokemon online from other tamagotchi type web games. And while the established muds slammed anyone from DBZ, they were able to do the very thing that most muds cannot do, and thats grow new players into the mudding world.

I did not say that anyone would be expected to leave. Rather i said that the game was designed to keep someone interested for around 6 months, a time that my research suggests that the target demographic get sick of a game and naturally move on.

Re: custom clients. Good or bad?
 

I think we're getting mixed up over terminology here:

You are targeting mudders - just not text-based mudders. If you're creating a graphical mud, and specifically targeting those who play other graphical muds, then I can understand why you'd want to require people to download a client. That's pretty much a requirement for graphical muds, after all.

Re: custom clients. Good or bad?
 

One reason I'm interested in custom client development is that my feeling is that telnet, as a protocol, is a dead end because of the mind-bogglingly poor protocol implementations of most telnet clients and most telnet servers. There is just too much installed based of crap for it to ever go anywhere. Even 'real company' telnet product vendors aren't interested in improving their protocol support; I made a serious effort to communicate to VanDyke Software (makers of CRT and SecureCRT) how their character-mode support was broken, and got fobbed off with a cheap, easy "oh, the server is doing something wrong" (not the case, and obviously so to anyone who had actually read my detailed bug report). That leaves a lot of space in the area of interface that MUDs can't move forward in as long as they're hobbled by telnet.

Re: custom clients. Good or bad?
 

IMHO, telnet (as a living protocol) died sometime around 1995 when the WWW made HTML popular.

Re: custom clients. Good or bad?
 

Telnet died when dialup died. The great thing about Text Muds is that you can still play them on telnet AND dialup and at 400 baud modem with an 8088, 4.77 Mhz machine.

Try playing WoW on that! :D

Re: custom clients. Good or bad?
 

Lets be clear here. The *big* companies don't care, since they never intended the clients to run games or support anything other then the "basic" font. By definition, telnet has, until muds came along and people started trying to do wacky stuff with it, been solely a means to connect one text based interface to another text based interface, so that you can send commands to the remote system and get responses. Character support isn't needed, because, the presumption is that **both** ends are using the text mode of the graphics card, which has one single OEM font on it, which, unless you are using a MAC or some such, hasn't *significantly* changed since the first system that actually supported a full 8-bit character set, instead of 7-bit. The reason most are broken, is because there is *no* .TTF font that isn't also "broken" with respect to that original font. Most telnet game apps either use a .FON, which does have the right characters, or, if its real clever, it *may* use something like Lucida Console, and *translate* the codes for the high bit range into the correct UTF-8/unicode designations. However, *most* fonts don't support those characters.

Its what you get from having games that *still* operate using a single font, for the most part, still treat the font as though its the original OEM GPU font, but every fracking machine in existence now uses graphical systems, which employ *typesetter* fonts, which have *never* matched the OEM. It only gets worse when you actually "send" unicode, since then the client and server both need to know its being used, have the right font and correctly figure out "which" type of unicode is being used. And, that isn't broken telnet, that is broken unicode support, sitting "on" telnet.

The problem isn't telnet. Its just a means to get data from point A to point B, using a system that is stream driven, which things like HTML are not. HTML is "request driven", i.e., you have to "tell it", you are asking for the content, before server sends anything. Telnet opens a path, then just streams things, both ways. That is what you *want* for a game, unless you are going to have 4-5 different ports open, each talking to a different subservice on the server.

The **real** problem is, no one can both agree on a protocol to put on "top of" the stream to do more with it, *or* implement them right when they do. Zugg's MXP idea had some merit, but his own client doesn't fallow the specifications "as written", and nothing has come out of Nick Gammon's attempt to talk about whether its more reasonable to follow the precise specification, or allow it to remain broken. Result - Nick's client won't work for many muds out there, because they made it work with zMud, which ignores the part of the specifications that implies that "unrecognized tags" are **errors**, and that to display "text" containing a "<", you need to use &lt, not just dump something like, "<<Happy Fish Pond>>", in the middle of the stream of data.

What is needed is an agreement on how the fracking stuff should work, which isn't ambiguous, and some idea how or *if* a second port needs to be used for some data, and precisely "how" that information should be displayed, or integrated into the text window, if you allow that in the specification. Instead we have a dozen different, only rarely used, concepts, half the features of which are either not used, used wrong, or are so ambiguous in description that no one knows how they "should" work or interact with each other the right way. And, just to make things even dumber, since many people throw up their hands, decide they don't want to help find a solution, then just write their own "my server only" client (i.e. a custom one), and end up doing nothing but adding one more protocol to the mess, possibly not even documented any place other than on their own machine.

Telnet still works perfectly. Its the refusal of anyone adding to it to agree on anything, or come up with reasonably sane implementation specifications that makes it a disaster. And that includes the bozos that write unicode support that flat out doesn't work right, a problem you get, just as often, in applications that have nothing *at all* to do with telnet. All they do is buy/build some library that "looks like" it works right, in a few test cases, then argue that, "because we spent $5,000 to license this thing that doesn't work, it **must** work, so the problem has to be on you server, not our overpriced bug terrarium!"

Re: custom clients. Good or bad?
 

What you're saying about add-on layers is entirely on-point. However, telnet does not work perfectly. Telnet is broken. Why? Because character mode is part of the specification. Some vanishingly small percentage of running code actually implements the specification for it. A much larger percentage of running code implements a transitional out-of-spec hack for it from back in the day, and generally does a crap job of even that. What I found with SecureCRT was that it does support character mode, using the out-of-spec hack, if you engage character mode at the beginning of the session, after which you can never switch back to line mode. (This is to say, VanDyke's developers already had all the code they needed, they just needed to switch it on or off under any definable conditions, in-spec or out-of-spec, and couldn't be bothered.)

Re: custom clients. Good or bad?
 

You are confusing HTML and HTTP. Admittedly, you could claim Mike was doing this in his post too, but I think he was more making the point that when HTML became popular, the relative usefulness of protocols that are oriented towards text-only data dropped significantly.

MXP is a poor protocol. The various special cases and hacks make it awkward to implement, and it reinvents several wheels that didn't need to be invented. The low level should have been handled via telnet subnegotiation rather than pushed inline, and most of the presentation tags are more than adequately addressed in XHTML and CSS without needing to duplicate that effort under new names.

Re: custom clients. Good or bad?
 

Ok. I can see where that would be real dumb. The question is, of course, whether or not there is any real point inventing a new protocol, which no one is using, and would likely be complicated to change code bases to, instead of getting fools like those you mention to just fix their code so its not doing the equivalent of trying to use Mosaic to try to read a page made with XHTML and CSS. Will anyone *use it*?

Re: custom clients. Good or bad?
 

The appeal of using a custom client specific to your game is that you can use your own protocol and only worry about whether your game works, not spec compliance (your own or others' failure of).

Re: custom clients. Good or bad?
 

Wrong! Why? Because, as someone pointed out on the "first" page of this thread, the moment you create a protocol and someone decides they want the client to do something it won't, they are going to try to figure out how to talk to your server **without** your client. You still end up having people using broken code to talk to your system, and if any of those protocols involve "anything" that could effect game play in any way...

Your better off with an open protocol, not just because it means having good specs to follow, but because they will find bugs you miss, and come up with ideas you won't.

Mind you, the appeal is there, its just, imho, its short term, limited and mostly illusionary.

Re: custom clients. Good or bad?
 

If someone uses a hacked client to access your game and some parts of it don't work, that's their problem. And open protocols don't necessarily have good specs, the MXP example being a good case in point. A custom protocol at the application level makes a lot of sense; the problem is just getting the client out to the end user.

Re: custom clients. Good or bad?
 

Didn't say having good specs is "automatic".

As for getting it out to the client... A lot of people end up pushing out things like Java clients. The problems being that a) if you use "real" java, or something similar, then the install of the engine is going to be bigger than any client download (unless they already have it for some reason, and b) you are relying on *their* libraries and engine to be stable, which they may not be. This especially becomes true when using anything in the Active Script line, like Jscript. You are fine, as long as the client doesn't introduce on-demand code. The moment you start adding and removing a large number of blocks of code, like, for example, in triggers, where you want to "temporarilly" run some bit of code that changes each time the trigger text varies, then garbage collection blows up on you, and you get a slow and persistent memory leak. As near as those of us that used to use them with Mushclient can tell, this is a **universal** problem with how Active Script based engines handle such on-demand code execution.

Frankly, I am surprised that surfing too many web pages doesn't crash IE from the same bug, though, they may be doing something different, undocumented, or just "left out" of the instructions that everyone else uses to integrate the bloody scripts.

In any case, I don't personally "trust" things that run on those languages. The underlying engines often have bugs in them, or odd implementation problems. And even the full Java seems to have those issues. Its taken multiple versions of some bittorrent clients to get them "stable", and not all of the issues with that where in the code of the client. Many where problems in how certain things, like memory, where being handled "in" the engines.

At least with a compiled application, you can be fairly certain that the behavior will remain stable, in terms of how it worked when released, for as long as the OS it runs on still exists, or at least "supports" what ever libraries you ran it with. This isn't "quite" as certain with all the fancy, "You don't need to install nothing, just let the intertubes feed you the applet.", style stuff.

Re: custom clients. Good or bad?
 

What was the last version of windows you used? Telnet on windows has had ANSI turned on by default for about the last decade...

That's because that is what they're doing.