Not really. By quoting me out of context, you miss the entire point I've been trying to explain - that there are benefits in using a standardised way of communicating with the client.

We already covered how you're not actually arguing with the argument that people are making.

I was thinking about this today, and I wondered what are the possible features that existing clients can't support?

With Fmud's new release and its and Decaf's support for scripting UI in the browser, I'm not sure there are any?

If you're talking about clients with scripting for graphical interfaces, you're not really talking about plain telnet anymore, are you?

With all due respect, I have yet to see anyone implement a feature (or even mention one in this thread) that is both useful/desirable in some way and not implemented in one or more existing clients. So, while it's theoretically correct that creating a custom client/protocol is needed in such situations, those situations, at least as far as I can tell, remain theoretical. The discussion could take a different path if someone were to bring up a real-world example; otherwise, it seems rather pointless to debate it.

Isn't it true that this is the pointless type of naysaying that people have always used in this community? Probably features you are using right now someone said the same thing about.

But putting that aside, building a better mousetrap is a feature. Maintainability is a feature. Efficiency is a feature. Presentation is a feature. There's no current mud clients that present the game in such a way that I think looks anywhere near modern. You've set up the argument so that no matter what I answer here you can reject it, since you don't think it's useful, but I've actually worked with clients like mush to develop extensive plugins. I've taxed the outer bounds of what mushclient can do. These clients do have extreme limitations, they're unwieldy to develop for, and they're not good at dynamic content. Doing anything slightly advanced in these clients for frontend design is like going back in time before guis are commonplace and doing the same thing that xerox had to do in the 70's. We can do better. Don't try to convince me we cannot, or that it's useless.

@Runter: Your "features" are sufficiently vague and/or subjective enough that I can't really respond to them (what is "efficiency"? what is "maintainability" from a user's perspective?). The exception was presentation, but then we've been talking about just that for two pages. I still haven't seen or heard about any presentation-related "features" that couldn't be replicated in Mush. Not that I think it's impossible for there to ever be any, but what's the point in even debating this until someone drops an example? And to that end, how do we objectively quantify the utility of that "feature" if and when they do? The simple fact that it can't be done in an existing client doesn't make it useful, or worth what you give up by not using an existing client.

What kind of attention have you been paying, Deimos? Have you not seen the work that's been doing with things like maps, health gauges, and all that? None of that is possible in straight telnet. You need custom work to get that working.

Response that was predicted in the post you're replying to, but I'm not going to play the game.

No, apparently he believes all of the custom work is 'solved' and now all front-ends for mud clients are Turing Complete. Well, in his words – Everything "useful."

@David: No idea why you're talking about pure telnet, since everyone else is talking about the benefits and drawbacks to creating a new client vs. customizing an existing one.

@Runter: David will be glad to see that you're tossing another straw man onto the pile.

It may be possible to do all of these great things with current clients, but I wouldn't say it's particularly easy. Most of them, I think, had these features bolted on after the fact, rather than making them part of the main focus. There's a lot to be said for easing the learning curve.

It's easy to call something a straw man when someone points out the absurdity of your argument.

I can't argue with that, not to mention that it's silly to spend time on an interface that players will create themselves if given the means.

These customizations are not that different from creating a new client! The difference between writing a new client from scratch and bolting on a lot of GUI customization scripting to an existing client is immaterial. The point here is not whether you are rendering with your own client or by scripting somebody else's client: the point is in fact that you are adding features that are not accessible over telnet.

What difference does it make if I write my own client vs. package a whole bunch of plugins with MUSHclient to provide my GUI? The fact of the matter is: I provided my own GUI. The second fact of the matter is: this is not available in telnet.

And then, when you get enough of those features with your custom GUI, the question becomes: why are you supporting the telnet interface when the game is truly not meant to be played that way?

This isn't about the telnet protocol; that is an implementation detail. This is about telnet client functionality. If you want to provide binary streams over telnet, then by all means, go float your boat – but you won't be providing rich GUI elements to a telnet client.


Sorry, but QFBS

Lol. So your players are creating useless interfaces? Players sure are silly people.

@David: Did you miss most of the discussion? The difference is that by creating your own client, you're doing a lot of extra work for little to no added benefit, and potentially a lot of drawbacks, unless you're able to replicate all the stuff that existing clients already have/do. Nobody that I can see is arguing that either method isn't providing benefits over vanilla telnet, so again, I think you're either misrepresenting the argument, or you don't understand it.

@Runter: If my argument was so absurd, it would be easy for you to provide an actual example of something that couldn't be done in existing clients and had to be implemented in a custom client as a result.

Can you use an existing client to create a Facebook web app that someone who hasn't played MUDs for at least 5 years might conceivably play?

Each client has its own limitations - for example MUSHclient doesn't let you reposition the input window or use character mode (although if that was a dealbreaker you'd probably be better off modifying the source code than creating your own client from scratch). This isn't a protocol problem though - I've seen muds that offered their own custom clients using standardised protocols, and it meant their players could reproduce the same functionality in a range of other clients.

I know Runter had problems with MUSHclient making intensive use of animated graphics, but I'm not sure how often that would come up with primarily text-based muds.


Yeah, FMud. I imagine you could do it with DecafMUD as well.

If you're out to attract people new to MUDs, and you think you can go toe to toe with this using this, then good luck to you.

FMud is what I load for people with older IE browsers visiting my app page. In my book, that's "degrading ungracefully."