[The_Fury]

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

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.

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.

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.

[KaVir]

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

Originally Posted by The_Fury i don't really see the current mud player as my target audience

Originally Posted by KaVir You're creating a mud which doesn't target mudders?

Originally Posted by The_Fury Yes this is exactly what i am doing.

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

Originally Posted by The_Fury The very people that i intend to market my game to are players of web based MMO's, graphical muds and the like.

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.

[chaosprime]

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.

[MikeRozak]

Originally Posted by chaosprime One reason I'm interested in custom client development is that my feeling is that telnet, as a protocol, is a dead end...

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

[Newworlds]

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

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!

[shadowfyr]

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

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!"

[chaosprime]

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

[Kylotan]

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

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.

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.

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.

[shadowfyr]

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

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*?

[chaosprime]

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

[shadowfyr]

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

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.

[Kylotan]

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.

[shadowfyr]

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.

[Fizban]

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

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

Originally Posted by shadowfyr One would almost think they where trying to cheat people out of money, instead of providing the best product. lol

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