01 Jul, 2010, KaVir wrote in the 21st comment:
Votes: 0
Kaz said:
So in that case, the markup should instead contain contextual information about the item at hand (<colour:swamp>SWAMPY!</colour>), and given to a lookup table which knows how to convert it in the face of VT100 16-colours, xterm 256, 16 million, etc.

That's pretty much what I already do for my maps through MSDP - the mud passes index values to the client. My MUSHclient plugin uses these index values for graphical tiles, while the TinTin++ script uses them for ASCII graphics (or a custom font if available) with whatever colour the script writer prefers.

quixadhal said:
The fact is, every time you try to cater to a better class of clients and still maintain support for antiques, you are increasing the workload on the builders who have to think about how their creations look on multiple platforms, and the coders who have to try and write support code to do those "magic" transformations that somehow take a feature-rich interface and try to squeeze it onto an 80-column single text stream.

Nah, the players do that. If they can't be bothered to create a plugin/script for their favourite client then obviously they lose out, but the option is there if they want it. I created the MUSHclient plugin because I wanted to, and because I felt it provided a good example of what could be done, but there's no reason why a player couldn't have done it instead - and indeed one did, in parallel to me, and it looks like a few others have started looking into creating their own now as well.

All I do is support the basic platform, and provide data for people to add support for their own, with my MUSHclient plugin serving as an example of the latter in action.
02 Jul, 2010, Kaz wrote in the 22nd comment:
Votes: 0
David Haley said:
So people who play KaVir's game with his MUSHclient plugins are no longer playing a MUD because there is customization of the client?


I think it's likely that, one way or another, they played the mud (or a prior mud) before having the client. I believe KaVir mentioned earlier that some players had only taken to using MUSHClient because other people spread the word about it.

David Haley said:
Do you think somebody would be more willing to try a game that looked nice, or one that presented them with Walls Of Text ™?]


As I already said, mudding is a niche market. I got into it because I was at university, and my regular computer was one in the computer science lab that ran on an antediluvian Unix system that had no real software for it. It had telnet, and I found muds almost by accident. Having grown up with text adventures elsewhere (perhaps a traits that is not shared today), this wasn't totally unfamiliar territory. In my case, there was no possibility of using a nice client or a game that 'looked nice'. There are still classes of players to whom this applies today.

And perhaps my view of muds is quite narrow. Perhaps this is because I'm looking into what the possibilities are using current technology, without requiring extra downloads (Scandum's screenshot where his TT++ user uses a script to read MSDP to update his client is possible completely server side with a standard telnet client, for example).
02 Jul, 2010, Runter wrote in the 23rd comment:
Votes: 0
Quote
I think it's likely that, one way or another, they played the mud (or a prior mud) before having the client. I believe KaVir mentioned earlier that some players had only taken to using MUSHClient because other people spread the word about it.


How does that change the fact at all?

So let's get this straight. It's still a mud if they didn't use the features the first time they played, but if they jumped straight to the custom client it's not a mud?

Quote
Perhaps this is because I'm looking into what the possibilities are using current technology


This is lawl.
02 Jul, 2010, KaVir wrote in the 24th comment:
Votes: 0
Kaz said:
Perhaps this is because I'm looking into what the possibilities are using current technology, without requiring extra downloads (Scandum's screenshot where his TT++ user uses a script to read MSDP to update his client is possible completely server side with a standard telnet client, for example).

Hrm not sure I follow. The user still needs to download the TinTin++ client and the MSDP script. In some cases even a "standard telnet client" may need to be manually installed (eg Vista).

However there are also web-based clients that don't require an extra download (assuming you've got a browser), and those can offer a graphical interface much like my MUSHclient plugin. John over on WGFriends is currently working on just such a client, so perhaps some day I'll be able to offer players a similar GUI without any downloads.
02 Jul, 2010, Kaz wrote in the 25th comment:
Votes: 0
Runter said:
Quote
I think it's likely that, one way or another, they played the mud (or a prior mud) before having the client. I believe KaVir mentioned earlier that some players had only taken to using MUSHClient because other people spread the word about it.


How does that change the fact at all?


I was trying to demonstrate that (what I would estimate is) a large portion of mudders start mudding because of the lack of requiring any software beyond that which had already been provided for them. Today, downloading is far less of a pain than it was ten years ago, but it's still a hurdle to overcome.

Also, see later*

Runter said:
So let's get this straight. It's still a mud if they didn't use the features the first time they played, but if they jumped straight to the custom client it's not a mud?


Back in the days, we would proudly point out that Ultima Online and Everquest and WoW and the like are really just "graphical muds", and that still applies, but it's not helpful in the current context. You can't uses the WoW client to talk to any muds, and you can't use generic mud clients to talk to WoW.

If you write a mud that can only use a particular client, then you effectively set forth on your own leave the mud arena behind. Not that that's necessarily a bad thing, but again it doesn't help us here. That client is not helpful for anyone else's mud.

Runter said:
Quote
Perhaps this is because I'm looking into what the possibilities are using current technology


This is lawl.


Possibly a bad choice of words, but I'm pretty sure you knew what I meant.

KaVir said:
Hrm not sure I follow.


All I meant was that you can achieve that output through ANSI control codes alone.

Quote
In some cases even a "standard telnet client" may need to be manually installed (eg Vista).


Good point. So… looking forward, what's the best way of re-enabling "click and play" (where you could go to a webpage, click on someone's "telnet link" and be playing), while still maintaining compatibility with clients that seasoned mudders are comfortable with, mmm?

* Also, it might be interesting to survey how many players first came into mudding while their OS did not have a terminal emulator either by default (i.e. telnet) or by accident (they just happened to have PuTTY installed for something else…)
02 Jul, 2010, KaVir wrote in the 26th comment:
Votes: 0
Kaz said:
I was trying to demonstrate that (what I would estimate is) a large portion of mudders start mudding because of the lack of requiring any software beyond that which had already been provided for them.

I've actually noticed quite a few first-time mudders download GMud from the GW2 website before connecting. To be honest I should probably remove it, if they're going to go to the effort of downloading a client they might as well grab MUSHclient with the plugin.

At some point I'd like to package up Mudlet with a custom GUI as well - it's simpler to use and more easily portable than MUSHclient. Having a point-and-click browser client for first-time players would be the best option though, IMO. I could already do this via the MudGamers FMud link, but the display can't be customised.

Kaz said:
Back in the days, we would proudly point out that Ultima Online and Everquest and WoW and the like are really just "graphical muds", and that still applies, but it's not helpful in the current context. You can't uses the WoW client to talk to any muds, and you can't use generic mud clients to talk to WoW.

You could - the restrictions are legal rather than technical. If WoW were to make their client open source, I bet you it wouldn't be long before someone started adapting it to a mud. Likewise, people have already created third-party clients, but they tend to get banned for it.

Kaz said:
If you write a mud that can only use a particular client, then you effectively set forth on your own leave the mud arena behind.

Hrm its difficult to know where to draw the line. I mean, you could (try to) make a stock DikuMUD block every client except TinTin++, but I don't think that would stop it being a mud. Some of the commercial muds (like the Skotos ones) require custom clients, but people still seem to refer to them as muds.

Kaz said:
All I meant was that you can achieve that output through ANSI control codes alone.

Ah, then you draw the line at downloading graphics? The background images, the avatars, the icons, etc, all of which are specific to a single mud?

The energy bars are drawn with MUSHclient's built-in functionality though, and I could actually draw the maps the same way if I wanted to (although it would be more effort). If you take a look a look at Nick Gammon's Miniwindows showcase, quite a lot of it can be done without downloading special graphics.

Kaz said:
So… looking forward, what's the best way of re-enabling "click and play" (where you could go to a webpage, click on someone's "telnet link" and be playing), while still maintaining compatibility with clients that seasoned mudders are comfortable with, mmm?

IMO? By replacing that "telnet link" with a browser client. It's still one click, but it allows you to embed a custom client and draw upon the built-in functionality of the browser, giving you an interface that is more familiar to today's gamers, and which can innately support graphics and sound. I recommend taking a look at the Maiden Desmodus client as a good example of what I've got it mind.
02 Jul, 2010, Kaz wrote in the 27th comment:
Votes: 0
KaVir said:
Kaz said:
I was trying to demonstrate that (what I would estimate is) a large portion of mudders start mudding because of the lack of requiring any software beyond that which had already been provided for them.

I've actually noticed quite a few first-time mudders download GMud from the GW2 website before connecting. To be honest I should probably remove it, if they're going to go to the effort of downloading a client they might as well grab MUSHclient with the plugin.


Probably a good idea. GMud didn't even support telnet negotiations last time I checked.

KaVir said:
Hrm its difficult to know where to draw the line. I mean, you could (try to) make a stock DikuMUD block every client except TinTin++, but I don't think that would stop it being a mud. Some of the commercial muds (like the Skotos ones) require custom clients, but people still seem to refer to them as muds.


Let's stop with that and have a thought experiment. Consider putting out a mud that communicated exclusively via MSDP. Your website offers TT++ with a script to parse the output from your mud, and let's say, for the sake of argument, it looks awesome.

What happens next?

KaVir said:
Kaz said:
All I meant was that you can achieve that output through ANSI control codes alone.

Ah, then you draw the line at downloading graphics? The background images, the avatars, the icons, etc, all of which are specific to a single mud?


I'm pretty sure that whatever line people think I'm trying to draw is entirely imaginary. I started off in response to David Haley saying (paraphrase) that, hey, if we're going to *gasp* 256 colours (!!) then we may as well go for 16 million. The point is that a lot of clients don't support 16 million. A lot of clients *do* support 256.

There is the "mud arena" term that I keep using and, in the context of generic mud clients and generic mud protocols, these are the muds that matter. A cloud of muds that are usable with generic clients, which are usable with other muds. WoW is not in there. IIUC, Skotos isn't either. There would be no point if the developers from Mythic came onto this forum and talked about their generic protocol for transmitting 16-million colour text in Warhammer Online, because it wouldn't matter a jot to anyone.

Writing up an article about xterm 256 colour, however, does.

Now, with that aside, I'm all for the arms race (which is why I had such high hopes for mudstandards). Mud works with client. Either client or mud develops new protocol to enhance play for that mud. Feature spreads to other clients or muds, status quo is advanced.

KaVir said:
I recommend taking a look at the Maiden Desmodus client as a good example of what I've got it mind.


Link appears to be broken. Question #1: can I play your mud with their client?
02 Jul, 2010, KaVir wrote in the 28th comment:
Votes: 0
Kaz said:
Probably a good idea. GMud didn't even support telnet negotiations last time I checked.

It still doesn't. But neither did GW2 until a few months ago, so its only recently become a concern.

Kaz said:
Let's stop with that and have a thought experiment. Consider putting out a mud that communicated exclusively via MSDP. Your website offers TT++ with a script to parse the output from your mud, and let's say, for the sake of argument, it looks awesome.

What happens next?

I can only speculate, but…

I imagine many players would try to connect with their regular clients, fail, and assume the mud was broken - they would hit a blank screen and their input would be ignored. Perhaps some would post a reply to my adverts asking what was wrong, while a few others might actually read the website sufficiently to realise they needed TinTin++ and the MSDP script. Of those, I imagine many would decide it wasn't worth the hassle.

First-time mudders would be the least impacted, having no real expectations from prior muds. They would check the website for instructions, download the client and script, and start playing. Such players are relatively uncommon though.

Building up an initial playerbase is very difficult, and this process would make it far harder than normal. If the mud still managed to eventually pick up popularity, despite the increased entry barrier, then fans of MUSHclient, zMUD, etc, would eventually write plugins that allowed them to connect with their preferred clients as well, and then offer those plugins to others. So in the end you'd still end up with other clients connecting to the game.

Kaz said:
The point is that a lot of clients don't support 16 million. A lot of clients *do* support 256.
Of the 25 muds listed on Mudpedia, 15 support 256 colours and 8 support MXP (which is the only protocol I know of that offers 16 million colours). However it's interesting to note that only 3 clients support both MXP and 256 colours - zMUD, for example, supports 16 million colours through MXP, but doesn't support 256 colours. And it's a very popular client, used by a lot of players.

Kaz said:
There is the "mud arena" term that I keep using and, in the context of generic mud clients and generic mud protocols, these are the muds that matter. A cloud of muds that are usable with generic clients, which are usable with other muds. WoW is not in there. IIUC, Skotos isn't either.

Well some of the Skotos games are LPmuds IIRC - I believe the block is an artificial one, because they don't want other clients connecting.

Kaz said:
There would be no point if the developers from Mythic came onto this forum and talked about their generic protocol for transmitting 16-million colour text in Warhammer Online, because it wouldn't matter a jot to anyone.

It would be much less appealing to server developers if it wasn't supported by any public clients, and vice versa, but if the protocol was well-written it might still be of interest. It wouldn't be much different to some of the protocols discussed on MudStandards - you just need to get some major clients and a few popular muds to agree to implement it.

Kaz said:
Now, with that aside, I'm all for the arms race (which is why I had such high hopes for mudstandards). Mud works with client. Either client or mud develops new protocol to enhance play for that mud. Feature spreads to other clients or muds, status quo is advanced.

But isn't that what's already starting to happen with MSDP? My plugin is really just an example of what can be done, but there's an example for TinTin++ as well, plus I've spoken with the developer of a new client which will support MSDP natively. Likewise, my plugin would work on other muds that support MSDP, and I know of at least one other mud that's considering adding it.

Kaz said:
Link appears to be broken. Question #1: can I play your mud with their client?

I messed it up, here it is again. The Maiden Desmodus client could connect to any mud, but it's been locked to one. A watered-down version of the same client is available and that can connect to any mud.
02 Jul, 2010, David Haley wrote in the 29th comment:
Votes: 0
Kaz said:
I'm pretty sure that whatever line people think I'm trying to draw is entirely imaginary.

No, you have very clearly drawn at least one line, which is that if a MUD only supports one client, you have left the MUD arena. Given that statement, and your above statement, it seems that your definition of what constitutes a MUD is basically that a MUD is whatever can be connected to with a generic text client like telnet.

So by that definition, I ask you again: are people playing KaVir's plugin-enhanced MUD still playing a MUD? Your previous answer:
"I think it's likely that, one way or another, they played the mud (or a prior mud) before having the client. I believe KaVir mentioned earlier that some players had only taken to using MUSHClient because other people spread the word about it. "
was not answering the question. I don't care what they did before or why they chose to play it. I'm asking whether the game is still a MUD.

I suspect you will answer yes, because they could still play "the game" with plain old telnet, and just not get all the features. Eventually, though, one wonders if it's still the same game.

But perhaps before we start asking ourselves existential questions about whether taking a MUD and replacing all its parts leaves the MUD as the "same", we should ask ourselves what the point of this is. You said that MUDs are a niche market. Well, yes. I say to that that you've defined it as the niche market, and therefore it will always be a niche market to you.

Kaz said:
Feature spreads to other clients or muds, status quo is advanced.

Yes, until you get people hollering about such-and-such feature being unfair or "un-MUD-like" because it's not available in plain old telnet, and therefore you get a disadvantage for not using the newer clients. (Don't laugh: that's not so different from what's happening in this very thread.)
02 Jul, 2010, Kaz wrote in the 30th comment:
Votes: 0
David Haley said:
David Haley said:
Kaz said:
I'm pretty sure that whatever line people think I'm trying to draw is entirely imaginary.

No, you have very clearly drawn at least one line, which is that if a MUD only supports one client, you have left the MUD arena. Given that statement, and your above statement, it seems that your definition of what constitutes a MUD is basically that a MUD is whatever can be connected to with a generic text client like telnet.


To clarify: if a mud supports one client, and that client supports only that mud, then yes, you are striking out on your own and no longer useful in the context of talking about generic mud protocols.

David Haley said:
So by that definition, I ask you again: are people playing KaVir's plugin-enhanced MUD still playing a MUD?


Of course. KaVir's game is accessible in a number of ways, which happen to be identical ways to connect to the vast majority of muds. Bonus features are good. I don't think I'm arguing what you think I'm arguing.

David Haley said:
I suspect you will answer yes, because they could still play "the game" with plain old telnet, and just not get all the features. Eventually, though, one wonders if it's still the same game.


An interesting philosophical question. Is Street Fighter IV still Street Fighter IV on a black and white TV?

David Haley said:
You said that MUDs are a niche market. Well, yes. I say to that that you've defined it as the niche market, and therefore it will always be a niche market to you.


Well, I say that you have defined me to have defined muds to be a niche market. We can all play that shell game. I'm not sure what point you were trying to make there except to be disagreeable, though.
02 Jul, 2010, David Haley wrote in the 31st comment:
Votes: 0
Kaz said:
To clarify: if a mud supports one client, and that client supports only that mud, then yes, you are striking out on your own and no longer useful in the context of talking about generic mud protocols.

I must have missed where we were only talking about generic MUD protocols…

Kaz said:
Of course. KaVir's game is accessible in a number of ways, which happen to be identical ways to connect to the vast majority of muds. Bonus features are good. I don't think I'm arguing what you think I'm arguing.

Then don't tell me what you're not saying, and tell me what you are saying.

Kaz said:
An interesting philosophical question. Is Street Fighter IV still Street Fighter IV on a black and white TV?

A poor analogy, because unless color is imparting important information, one could argue that yes, it's basically the same. However a map showing your surroundings is not just eye-candy: it provides important tactical information based on which decisions are made.

Kaz said:
Well, I say that you have defined me to have defined muds to be a niche market.

Oh sorry, my bad, I must have completely misunderstood the following of yours: "As I already said, mudding is a niche market."

Maybe you're using the Clintonesque 'is' and not the definitional 'is' … :rolleyes:

Kaz said:
I'm not sure what point you were trying to make there except to be disagreeable, though.

The point I was making is that whatever conundrum you seem to think you're in is one of your own making.
02 Jul, 2010, KaVir wrote in the 32nd comment:
Votes: 0
Kaz said:
An interesting philosophical question. Is Street Fighter IV still Street Fighter IV on a black and white TV?

An apt analogy - a player might use a colour TV, a black and white TV, or even no picture at all. They might be using a $150 Tournament Edition Arcade FightStick, a standard controller, or some old unresponsive pad with a broken button. But it's still the same game, it's just the interface that varies.

My plugin provides energy bars to replace the prompt and graphical maps to replace the ASCII ones, but it's still the same information that you'd get on a regular client - on the other hand, take a look at the features offered by most clients, usable on any mud, and you'll see things like aliases, triggers, macros, timers, variables, multi-session support, speed-walking, logging, scripting, compression, gagging, highlighting, tab completion, etc, etc. And of course other clients offer graphical maps and gauges as well.

Many of these features have been around for a long time, and you could quite reasonably argue that they create an uneven playing field when compared to a basic telnet client - but as long as they're available to everyone, I think that's enough. If someone chooses to use an inferior client, they'll be at a disadvantage - but IMO that's better than blocking them entirely. If they feel hard done by they'll upgrade soon enough, but if you require them to upgrade before they can play, many will simply look for another game.
02 Jul, 2010, David Haley wrote in the 33rd comment:
Votes: 0
KaVir said:
They might be using a $150 Tournament Edition Arcade FightStick, a standard controller, or some old unresponsive pad with a broken button. But it's still the same game, it's just the interface that varies.

Yeah, I guess you're right. This book here? I'll rub off half the letters and make the ink run for the rest, so it's mostly illegible, but hey, it's the same book, just with a different interface.

Seriously, though: it's rather bizarre to pretend that the interface to a game isn't a considerably important part of that very game. Some games would be completely unplayable with poor interfaces (especially with broken buttons, geez).

Your plugin is displaying information differently, it's not doing anything like breaking buttons on controllers. That's a terrible comparison.

Furthermore, there is a remarkable difference between a map that's available on demand and takes up room in the main channel, and a map that's continually updated in real time in a separate area of the game interface. These are sufficiently different that they are not presenting the information in any functionally "same" way.
02 Jul, 2010, quixadhal wrote in the 34th comment:
Votes: 0
From my perspective, a MUD is a multi-user work of interactive fiction that uses prose as its primary means to describe the game environment, the storyline (via dialog), and the events that are happening to and around the players.

The fact that it happens to use TELNET, or a packet protocol, or something else entirely doesn't make any diffrence. That's the difference between reading a hardcover book, reading the same book on a kindle, or on a microfishe reader.

The fact that is has sound and/or graphics to show tactical information, summarize or emphasize events, or just to make it look pretty is also irrelevant. The use of ANSI or XTERM256 or MXP is the same as the use of 3D-flaming-spinning-graphical buttons, it provides eye-candy and allows those who can see them to get a quicker summary for faster reactions than just text.

The fact that mud developers currently limit themselves because they assume people who are currently using dumb clients, or have invested time into customizing some particular client, is what I'm more concerned about. This is a chicken-and-egg problem. Back when color television was invented, all TV broadcasting was in black & white. The first color TV's were very expensive, and when they hit the market there were only one or two shows that were doing color broadcasts. I'm sure many people in the days tried to say it was silly to upgrade their cameras and broadcasting equipment to support what would only be a toy for the wealthy. Go try to buy a black & white TV today, in any retail store. Go ahead.

THAT is what I see TELNET doing to MUD's. TELNET is keeping us in the black & white era, when everyone else has not only adopted color, but is running towards 3D high-definition on-demand with surround sound. I suspect we could build something really cool when HTML 5 actually gets into the hands of more of the public. A mud "client" could simply be a browser plug-in using javascript and web sockets, and something akin to CSS could easily route messages to specific windows or browser screen regions. The question is, would it offer the same level of control that a curses client has now? We'll see, maybe. Or, maybe not. Maybe we'll stick to stream-based TELNET with markup tokens as the One True Way. I guess there are a couple of TV networks that still make money showing reruns of Andy Griffith. :)
02 Jul, 2010, KaVir wrote in the 35th comment:
Votes: 0
quixadhal said:
The fact that mud developers currently limit themselves because they assume people who are currently using dumb clients, or have invested time into customizing some particular client, is what I'm more concerned about.

Is that really so common though? I'm a pretty staunch advocate for remaining playable with basic telnet clients, but that doesn't prevent me adding support for more advanced features - and I don't see why it would prevent anyone else, either.

Perhaps it's just a common misconception that adding more advanced features would make a mud incompatible with older clients? Or maybe its just not something that many mud owners think about or have much experience with? As something of an old-school mudder I stuck with a basic telnet client for a long time, and as a result I didn't even bother reading up on the various mud protocols until fairly recently. If I'd really known what they could do, I'm sure I'd have looked into them long ago.

quixadhal said:
Go try to buy a black & white TV today, in any retail store.

Few people use them, even in the UK where a black and white TV licence is much cheaper than a colour one - but that doesn't mean they should be blocked from receiving the TV signals (if such a thing were even possible), or that they're holding back advancements in film-making.

quixadhal said:
THAT is what I see TELNET doing to MUD's. TELNET is keeping us in the black & white era

And yet earlier in the same post you wrote "The fact that it happens to use TELNET, or a packet protocol, or something else entirely doesn't make any diffrence". What makes you think it's telnet that's keeping us back? We've already got telnet muds with graphics and sound, and web clients that can provide a browser-game style interface to any telnet mud. I get the feeling that telnet is being used as a scapegoat.
02 Jul, 2010, David Haley wrote in the 36th comment:
Votes: 0
KaVir said:
Perhaps it's just a common misconception that adding more advanced features would make a mud incompatible with older clients?

Perhaps you aren't responding because you know it's a problem with your position and you'd rather side-step it, but the simple fact of the matter is that some of these features do more than simply provide bells and whistles: they can provide important information that affects game decisions. Therefore, while the MUD is "compatible" with older clients in that it can talk to them, it eventually becomes a rather useless definition of compatibility.

Frankly I think it's really quite odd for you to be moving forward in such interesting ways with your plugin, and still say things like you are. It just doesn't make much sense. Clearly you think that you are providing a superior interface, that will let people enjoy the game more.

It would be like pairing up people with fully functional controllers that can use all the latest information displays and quick access to commands with people with those wonderful unresponsive and broken controllers of yours. Can they both "play"? Well, let's put aside the silly notion of being able to play a game with a broken controller and say that they can both "play". Clearly, though, the ones with the better control will be able to play much better because they have a much better interface to the game.

Soundbite version: the interface to information and commands for a game is not really separable from the game itself.
02 Jul, 2010, KaVir wrote in the 37th comment:
Votes: 0
David Haley said:
Perhaps you aren't responding because you know it's a problem with your position and you'd rather side-step it, but the simple fact of the matter is that some of these features do more than simply provide bells and whistles: they can provide important information that affects game decisions.


KaVir said:
My plugin provides energy bars to replace the prompt and graphical maps to replace the ASCII ones, but it's still the same information that you'd get on a regular client - on the other hand, take a look at the features offered by most clients, usable on any mud, and you'll see things like aliases, triggers, macros, timers, variables, multi-session support, speed-walking, logging, scripting, compression, gagging, highlighting, tab completion, etc, etc. And of course other clients offer graphical maps and gauges as well.

Many of these features have been around for a long time, and you could quite reasonably argue that they create an uneven playing field when compared to a basic telnet client - but as long as they're available to everyone, I think that's enough. If someone chooses to use an inferior client, they'll be at a disadvantage - but IMO that's better than blocking them entirely. If they feel hard done by they'll upgrade soon enough, but if you require them to upgrade before they can play, many will simply look for another game.
02 Jul, 2010, Scandum wrote in the 38th comment:
Votes: 0
I'm kind of puzzled by the current sentiments. KaVir's GW2 interface, while nice looking, is nothing new and tactical interfaces have been in existence since 1993. They do give an advantage and will steer players toward compatible clients, but the game will still be a MUD.

What people don't seem to understand is that client side tactical interfaces are easy to build (there's a three/four year old screenshot of a split screen tactical interface for gw2 somewhere), so KaVir isn't providing a new service, he simply made tactical interfaces more accessible to the average player.
03 Jul, 2010, David Haley wrote in the 39th comment:
Votes: 0
Well then KaVir, why are you talking about compatibility unless it is in some trivialized sense? You have, by your own words, introduced a competitive incompatibility: why then do you speak of common misconceptions when you endorse the same mentality?

You also have not really addressed at all the separability (or lack thereof) of interface and game - if you did, it would explain why your statement is not trivialized.
03 Jul, 2010, Tonitrus wrote in the 40th comment:
Votes: 0
KaVir's plugin doesn't offer a competitive advantage to the game, it just helps with presentation. You don't really gain anything in GW2 by having a constantly up-to-date map, it just looks nice. You could turn the map feature off altogether, and it'd only make dungeons a bit of a nuisance. For fighting mobs or players in the main world, you don't even need the in-game map, much less the MSDP map. The only competitive advantage I can see is removing your prompt from the spam, which I do anyway with tintin's #prompt command.
20.0/48