Colored MUDs are split into two varieties: the type where the very first thing it asks is whether you want ANSI color; and the type where it goes straight to the main login screen, which is NEVER coloured regardless of color preferences.

And yet it is possible for the MUD to determine, without the player even being aware of it, what MUD client the player is using, and thus whether it supports ANSI.

But ANSI is just one example. Others would include determining whether the MUD should provide an artificial local echo, or whether the arrow keys get sent as characters (windows Telnet) or whether they are function keys for the client itself which never make it to the MUD (zMUD).

The vast, overwhelming majority of MUDs use the telnet protocol (even though the vast, overwhelming majority of MUD owners do not even know what the telnet protocol even is). The telnet protocol allows hidden client-server dialogues which the end user does not even see, which allow the server to determine many things, one of which is what type of program the player is using to log on (ie, their mud client).

Most MUDs, however, merely ignore this awesome capability, and if the client initiates one of those hidden dialogues (to ask whether it should use local echo, for example), most MUDs merely gag it and ignore it, without responding.

These days, alot of kids and teenagers do not know what "ANSI" is. If the weird text-based game is trying to solicit this info from them (which is totally unprofessional since, as I've shown above, it is unnecessary in most cases), they'll just say "screw it" and go play Everquest.

I bounced this question off of one of our coders, because I didnt know the answer and found the idea intruiging. Here is the response I received, in case anyone is interested.

We just assume everyone can support ansi and turn it on automatically.

--matt

Yes there is.  RFC854, published in 1983.

Exploiting telnet holes?  By knowing what client is being used?  This I've got to hear!  Your coder is right in that if your client is programmed to do so, it can ignore the request or even lie (many http bots lie and say they're Internet Explorer for example).  However, if you try logging onto your shell with zMUD, chances are good (although it depends on the shell) youll get a message something like, "No templates defined for zMUD".  Guess how the shell magically knew you were using zMUD.

No.  You send the request for client type.  If you get no answer, or a client you don't recognize, do it the old way and manually ask the player for all the configuration preferences.  However, if the client responds that it is, indeed, zMUD, or Windows telnet, or putty, etc., act accordingly.  Your coder is certainly correct that there is no "one size fits all" solution when it comes to terminal gaming, but that's like forcing everyone who enters a shoe store to immediately have their feet measured no matter whether they need it or not, because of the few individuals who don't know their shoesize.

Even if you can determine what client a person is using and whether it is capable of displaying ANSI color or not, it is a bad idea to just automatically turn color on. Some people may not like your color scheme. That's a decision that should be left up to the user in my opinion.

This is actually something that bugs the #### out of me. Years ago, 25 or more.., I used a program called Telemate. It didn't even have a clue what Telnet was, since it was a pure dial-up application for use with BBSs. However, one thing it had in common with nearly all such clients is that it expected any BBS using the ANSI spec to send it an ANSI sequence requesting to use ANSI and it replied with a can-do repsonse. Then I got on the internet and started to play muds. All of the sudden this 'basic' feature was missing. Why?

The one I play on right now uses ANSI, but you have to turn it on in the terminal options, because it won't send a 4-5 byte request the istant you connect to find out if you have ANSI. Others turn it on by default, which they can get by with because even MS telnet, which is the worst client in existance, as near as I can tell, recognizes the codes. Last I checked this is 2003, there is even extensions like MXP around that 3-4 programs use and 'require' negotiation to work properly, but muds can't do something that basic dial-up BBSs could do half a century ago. This isn't about telnet and what variation of it someone may be using, it is basic common sense imho. It make no sense at all that this isn't a standard feature of 'all' muds by now, no matter how old the code base.

Yes, there are some things that can't or won't work in specific instances, but something so silly and basic? As for things not supported, about the only major thing in VT100 not supported is things like text positioning. This is a trade off, most muds don't fake animation or graphics using these features, but send text that just continuously scrolls. A few do try to be clever and use it for things they could do without, at which point you run into a problem with about half or more of the clients, including Mushclient, which I use and is figthing it out toe to toe with zMud as the most versitile one around.

Well, some special text attributes and other tricks may not be either, but most of them are purely cosmetic, while color I would argue is so pervasive that not having it is practically a matter of basic function.

The blinking issue does bug me though. In Mushclient, the default is to treat blink as Italic, but that screws up maps. Supposedly this will get fixed in a 'much' later version, probably the same time a real port is developed that will run on Linux, though I haven't a clue how scripting will get implimented in that, since it currently relies on COM.

The problem Ogma, is that it is a lot less confusing to people if they know there is color and merely need to turn it off or change it. If the first thing someone has to ask when 'all' of them log into a mud is, "Why isn't there any color?", you have done something wrong.

Of course. The user can simply reconfigure the color scheme in any of our muds or turn it off. That should just be standard.

--matt

I don't agree with reconfigurable color schemes (or prompts, but that's another topic). A game has a much more cohesive atmosphere to it if everyone's look and feel are the same. Color is a big part of that. The trick is not to overdo it to the point where people want to change them around.

It is possible in most cases, you are right.  The problem is that not all mud clients support telnet negotiations.  Most do not identify themselves.  And those that do can have that ID changed or removed by the user.  There is a document at that breaks down client capabilities nicely.

I will add my agreement that the only way to gauruntee a feature you want is to code your own client or require one particular client.

Also, it is very safe to assume ANSI support.  I have yet to come across any client that does not at least trap and ignore escape codes.  This does not there is not one, of course.  But why worry about that .1%?

But you can't control what colors a player sees. First, colors look drastically different on different clients and monitors. They are not small differences either. Further, players can already just change the color scheme using their client so why not make it convenient for them by including it in-game? I know our players appreciate it.
--matt

How can it possibly give the mud a more cohesive atmosphere? There's no way to know what other players prompts (or colour configurations) are, regardless of whether or not they are reconfigured!

I'm afraid I'll have to agree with the_logos on this one - I prefer a system whereby the player can configure their settings to whatever they feel most comfortable with (although I also like to have colour switched off by default).

I don't think you understood what I was saying.

A few points:

1) If many clients allow the ability to recongifure what color is displayed when a specific color code is received (such as ZMUD) is it really necessary to have this available in the game server as well? If the player really wants to change the colors, they can do so with the client. But the game itself is sending out consistent information to everyone, so there's no question. Interpretation of that information is, of course, up to the client.

2) I'm not sure what you mean by "not knowing what the player's prompt is". Of course you know what it is, since the server is sending it to them. You may be talking about something else.

Obviously you should provide the ability to configure settings in the server that are necessary (such as turning of special text decorations for blind players, as an example). But color and prompt (again, I'm talking about the hp/spell point/stamina-type prompt) should be made uniform so that the interface is the same for all users. Room names appear in yellow, room descriptions in off-white, wilderness/ansi-mapped room color and icons appear the same, etc., for all users.

Again, you can't control this. You're insisting on sending players the same information but you have no control over how it's displayed to them by their client. So why is it so important that you send the same color codes if those codes impact players in different ways? Even without client-side coloring you can't control what colors the display and OS is spitting out. Ansi colors look drastically different on my different computers and clients. Different to the point of yellow looking distinctly orange on one of them, for instance.

The reason to add it into the mud server (assuming you're not requiring a custom client) is to provide a single interface for players to make the color and appearance changes. Your staff is then better able to help players do what they want because you only have to support one interface.

--matt

Gee.. The_logos, by that standard, why have any color at all, just assume that everyone is a genius at designing triggers and that everyone must be using zMud, Mushclient or some other program that lets you color your own text? Get real. most clients use only ANSI. In my experience there are only two effects this has, 1) some really bad clients start with a white background and 2) on some systems, with really bad displays, Yellow can end up looking Brown. The reality is that 'most' computers differ today only in how 'bright' the image is they produce. Colors tend to be more or less the same.

We are not talking about some stupid web browser that stupidly tries to match to the nearest 'valid' color according to your system. The display may not be 100% identical, but it is probably 98% identical, even in most worse cases. That said, you are probably talking about people changing the colors themselves? Fine, but often the only way to match a line, is if you can tell the client what color it was in the first place. You can tweak all the colors you like in some clients, but that is 'your choice' and if it screws something up in the game design, that is your fault for changing it. And as for MXP colors, as far as I know you can't easilly mess with them the way you can ANSI, so the biggest worry there is if the client can display them at all.

In any case, your own point about Yellow looking Orange on yours.. I have seen that on a Windows client, Imho, that client was not dsigned for games in the first place and you shouldn't use it for that. Same with drastically different colors on different systems. I doubt if you tried to display a full color photo on the same system that the result would e equally wrong, therefor it must be the client's fault and you should find a client that works right.

When you use ANSI, MXP, etc. you are making an assumption that 'most' people will see the right things. If someone is using an OS or client designed by Joe Screwup and won't show the colors right because he thought Puce looked better than Blue and Green was a horrible color no one should use, then you already have a serious problem. Same if you expect things to look right if you are using a horrid VGA monitor from the 1980's that can't display more than 256 colors and shows Yellow as Orange in text modes.

You may as well blame your difficulty seeing something on TV on the broadcaster, because you are using a black and white TV and the intensities of everything on the screen are all nearly identical. First use something that works the way the broadcaster 'intended' it to be seen, then complain about the content and what it looks like.

You just answered your own question: Do it because everyone isn't a genius at designing triggers nor does everyone want to take the time to do it. Have color in your game and the ability to configure it in-game because you can provide for an easier interface for players to set the colors they want to see. Your game can group display items together in ways that a client cannot do without first being setup by the user. For instance, the client doesn't know the difference between an NPC and a player in a room until you tell it. The game knows it and can allow players to automatically color those in whatever color the users chooses.

Color in text is useful for highlighting or separating information. It is not the information itself 99% of the time so I'm unsure why you wouldn't provide an interface for players to set the colors themselves.

--matt

Guess I was a bit confused by your statement. Yeah, you should have some ability to configure. There are times though where it shouldn't be, but they are rare. In any case, the limitations of ANSI means that in most cases you will never get a decent set of options anyway. Color is not much more than a way to nicely seperate stuff out, in which case you have a limited number of options to do that anyway.

In any case, the point of all this started with why muds can't figure out something that is built into the ANSI protocal and has been used everyplace, except in muds, for the last 25 years or more. If you choose to turn them off or change them doesn't matter as much as either assuming that someone "doesn't" have color by default, or tht they 'always' have it. Both are wrong and a simple solution exists to figure it out, and you don't need to know what the specific name of the client is. ANSI itself has the means to find out built in.

However, between the two wrong choices, the one that makes you hunt through help files to turn on the color, instead of having it on to start, is more wrong than the other imho.

Why all the color-specific threads?  Color is only one of the possibilities of making muds that follow the telnet standard.  Another couple examples:

1.  Identify which clients send the arrow keys through as characters (rather than reserving them as client function keys like zMUD) and allow these people to use them as server-side macros for moving around (up arrow = north, down arrow = south, etc.)  Particularly appealing for MUDs which use the worldmap code.

2.  Identify which clients follow the letter of the law when it comes to local echos, and go to town accordingly.  You could make it so, when they type "password oldpass newpass", it turns clientside echo off and provides serverside echo so that what they see themselves typing is "password ******* *******", even before they press enter.  Or you could be creative and make it so when people are highly drunk, they get their clientside echo disabled and the mud supplies a server side "slurred speech" version of local echo :-)

3.  Identify which clients have advanced features like rip or pueblo supported and use them accordingly-  or if you prefer to keep that optional, it still has the advantage that people who play on zMUD at home and Windows telnet at work can have the rip at home but at work the server sees they're on Windows telnet and doesn't send it (ever logged on a RIP account from a non RIP client?  not pretty!)

4.  Make it so when players on applicable clients hit the "break" key, it unqueue's all their queued up commands (for people who type "trance" 15 times then suddenly get ambushed)

5.  In some cases, be able to determine the window size of the player's client.  I'll leave you to imagine the possibilities.

6.  If a client supports environmental variables, these could be used to reduce RAM load on the server of very specific data (things of little urgency that we dont mind people being able to hack or lose)

Anyway, I'm just trying to get some new ideas circulating, it seems a long time since the community has had much in the way of new ideas :/   Don't mean to start any flamewars

Sounds like you're underestimating the value of color in a game. Color can speak volumes - warn players with bright red text, put channels in magenta, put player-to-player conversation in cyan, etc. - it's part of the feel of a game, regardless of whether or not the colors display exactly the same on every computer. The fact is that 99% of the time, they'll be close enough to what you intended to have an impact.

Additionally, colors in terrain maps play an important role, such as blue for water and cyan for reefs or shallows, for instance. I think there's a point where you can focus too much on the interface and giving players commands to change anything.

I'm not saying that lots of configuration is a horrible thing, just that I don't agree with it, and I've given my reasons why. The entire reason I started this tangent is because the_logos stated that every game should have this ability as a standard, and I don't agree. I think it's more of how you see the game.

Just as authors wouldn't want people changing text or words in their novels, I see the look and feel of a game as essential to the final vision of the product. That includes color. True, you can't control entirely how it will look at the other end, but you can come close. Perhaps I am pickier about that than most.

This is exactly what I'm talking about. All of those examples are color used as a separator, not as information itself. What do you care if players want to see warnings in magenta or green? The point is that the color makes it or the channels stand out from the flow of information around it. What color is actually used in these cases makes no difference to the information communicated to the player. (Incidentally, we already give players the ability to configure the color of every single channel in the game).

Yep, this specific example is why I said that color is used, 99% of the time for separating and highlighting. In the case of terrain maps the color is the information sometimes. We don't let people configure what colors are displayed on terrain maps for this reason.

Authors control content, not presentation. Various editions of an authors book may be published with different text sizes, on different types of paper, in different fonts. It doesn't affect the novels at all if they were published in red instead of black text. It's the same with text muds 99% of the time.

--matt

But you're effectively saying that presentation has no impact on content, and that is completely false. Take a look at the hardback edition of "The Neverending Story" by Michael Ende. One half of the book is published in red text, the other is in green text, which corresponds with the transition from the real world to Fantastica. It makes a significant impact on the reader of the story and adds to the overall enjoyment of the book. True, the book can be, and has been published without the colors - I didn't say that you couldn't have an effective book without it - just that it DOES make a difference. Cover picture. Fonts used. Images or no. All those things are presentation, and they make a difference.

I would hope that your game would be better than a mass-produced paperback novel. Even mass-produced paperback novels know that it's all about the cover and thickness of the book - presentation again.

In text games, as in novels, presentation makes a huge difference, and keeping tight control over presentation - as tight as you can without controlling the client 100% - is a good way to do it. Having good content is nice, and that makes up the meat of a text-based game, but presentation provides the flavoring.

I mean, really - if you apply your argument to picking the characters you use to generate virtual maps, isn't there a reason water is blue and is made using tildes (as an example, I haven't seen your game), and grass is green? The same should go for warnings (red, that is an international standard, by the way - there's no reason it should be changed).

If you truly feel that the colors don't matter, try changing the colors around on your game. Put your room descriptions in screaming red, your character descriptions in bright yellow, and change the colors of your terrain to random - green water, red trees, and white plains. I think you will find that suddenly quite a bit has changed in the "look and feel" of the game, and your players are complaining. Do they really need control over that, as a standard? I think it's up to the individual server authors.

Again, what I object to is your comment that it should be a de facto standard to give users configurable colors and prompt. I'm not saying you are wrong to allow it, just that you are wrong to declare that it should be that way on every text-based game.

I believe the basic point is that there is absolutely no real disadvantage (besides an additional small investment in developer time) to allowing configurable colors, and many advantages.

After all, a significant portion of the population is red-green colorblind.

Really? What percentage, and how many of them play MUDs? Have you ever encountered any in your years of administration? And given that there are many popular clients out there that allow you to reconfigure the way ANSI is displayed itself, if you were really red/green colorblind don't you think you might use one of those and it's a tad redundant to have it on the server level as well?

So what about those who aren't using mud clients?  And even of those who are, you're going to need to add colour support anyway (because there's no way that the client can know how to colour a wilderness map, for example).  So why not put that extra little bit of work in in order to give everyone the same possibilities?

Actually I said "there's no way to know what other players prompts are".  That was in response to your statement "A game has a much more cohesive atmosphere to it if everyone's look and feel are the same".

So to put my question another way, how does it provide me with a "much more cohesive atmosphere" if Bubba the Barbarian isn't allowed to remove mana from his prompt?  There's no way that I can even see his prompt.  All it does is limit his user interface.

What possible advantage is there in forcing everyone to use the same prompt?

I hate coloured room descriptions.  In fact, I dislike them so much that I would simply switch off colour if that was the only other option.  That would be a shame, however, because I like having colour for some things (such as highlighting or underlining keywords in a helpfile, differently colouring OOC and IC channels, wilderness maps, etc).

I can understand providing default prompts and colour configurations (ideally a variety of recommended/popular versions of each), but I cannot see any possible advantage in forcing people to remain with those defaults, rather than customising their own.

In fact at one point I even planned to add player-configurable score layouts, and actually created a snippet to that end.  The only reason I never got around to adding to my mud was because of time constraints and more important tasks.

Such configurable options have one of the most desirable characteristics of any mud feature - they provide useful and desirable functionality for the players who want it, without causing any impact on those who don't.

I understand what you've said, I just disagree with it, and was hoping you could give some reason for why there shouldn't be reconfigurable colours and prompts other than "there's no reason it should be changed".  Customisation adds a great deal to a game, while taking absolutely nothing away from it.  There is absolutely no reason why it shouldn't be added, other than lacking sufficient time or technical ability.  I could understand if you felt there were more important things to spend your time on, but you actually appear to think such optional customisation is a bad thing which somehow detracts from the mud!

And you've still failed to explain how my gaming atmosphere is made more cohesive because Bubba the Barbarian is prevented from adding "berserk duration" to his prompt.

As you yourself stated, "In text games, as in novels, presentation makes a huge difference...presentation provides the flavoring".  But not everyone likes the same flavours, and by forcing everyone to play your vanilla flavoured mud, you're cutting out all of those who like chocolate, strawberry, raspberry, etc.

The logical course of action for anyone wanting to run a successful mud is to let each player choose their own individual flavour.  And when that can be done without any impact whatsoever on the other players, so much the better!

I didn't learn I was red-green colour blind until I was 18 years old, when we finally studied it in physics class.. I've met plenty other colour blind gamers as well.. not going to try to throw out a percentage, but I guess you can now say you've encountered one or something.

That depends whether you know how to program at all.  If not, then choose a language and study it.. but I'll assume you do know how.  In which case, just search for tutorials on the net, there is no reason this side of the 9th #### that you need to spend $60 on a book from Amazon, everything is fairly simple and well-tutorialized.  you'll need a solid grasp of socket programming and a good grasp of the telnet protocol would be useful but neither require a master's in comp prog :p

Gee.. Another custom client... Ok. I admit that initially I went looking around, saw KMud and thought, "This has bloody everything I ever wanted, including a mapper. Wonder if I can port it to Windows?". But I found Mushclient and got over the loss of the mapper (which often don't work well in all cases anyway).  There are a 'lot' of cheesy, low level, minimal function clients out there. I am not saying designing another one is a 'bad' thing for you, but I would hope that, if it can't compete with the top runners, you don't muddy the waters farther by introducing it to the pool of mediocre clients that already exist. But that is just my opinion. You could manage to design something truly useful, but considering the time it took to track down the one I now use and the clients I had to slog through first...

One of our builders is red/green color blind. Boy did his maps come out looking funny.

In addition, the current version of zMUD displays light grey text as dark green by default. We get players logging in all the time asking why their home city is green. So yeah, as logos said, you cant control what people see.

On the contrary, I think I explained it pretty well. As I have said countless times, my point is NOT to suggest that prompts and colors should not be configurable, just to offer alternative suggestions for the reasons why some people may NOT WANT to do that for their games, in response to the_logos's blanket statement that all text games should have that as a standard.

That's the reason there is more than one game. If one game could provide everything to everyone, no one would have the need to do another and no one would play anything but that one game. Each game has its own personality, and the look and feel is DEFINITELY part of that personality. If you want to offer a ton of options to your players, that is up to you, but it shouldn't be a standard because not everyone has the same outlook on how MUDs should operate, as evidenced by this conversation.

OF course you can control what people see. ZMUD only switches the light-gray text, not all the colors. The majority of your selections are perfectly fine. You sound like you're saying you can't control it, so why bother.

[quote= (vedic @ Sep. 29 2003,16:02)]Im not saying "why bother" at all. Im simply saying you cannot control what people see. As you just said yourself, zMUD switches light grey text. Therefore, if I want someone to see light grey and their zMUD is configured in this manner, they won't see light grey!

Do you have a point, other than to be argumentative?

No, I'm afraid you've not explained it at all.

Actually that's exactly what you've done - for example:

"A game has a much more cohesive atmosphere to it if everyone's look and feel are the same. Color is a big part of that."

And:

"color and prompt (again, I'm talking about the hp/spell point/stamina-type prompt) should be made uniform so that the interface is the same for all users."

And:

"The same should go for warnings (red, that is an international standard, by the way - there's no reason it should be changed)."

Etc.

Are you suggesting that a mud should specifically aim to appeal to a smaller audience so that it doesn't attract too many players?

You claimed that the mud owner could control what people see. Treestump disproved your claim by citing an example from his own mud. I'm not really sure how that is "argumentative"...

My point is simply that your statement that you can control what people see is innacurate. As we established, clients choose how to display information not the MUD.

Your kidding me right? I swear sometimes Zugg is trying to break his own client. Its like MXP. The spec clearly sates that < and > should be replaced with &lt and &gt for 'all' text that is not part of a tag, but then zMud simply ignores and displays invalid tags without processing them anyway. So someone like Nick Gammon comes along, implements an actually error checking system for MXP and people start complaining because some mud they log onto doesn't correctly show room titles like <This room>. Why? Because they tested it with zMud, didn't bother to look at the specs for MXP and 'assumed' that zMud's behaviour is correct. Ok..., if so, then why not specifically state in the spec what 'should' be done with invalid tags, instead of explicitly stating that you must changed non-tags to &lt and &gt, then not bothering to do anything if they are wrong anyway?

It is possible, since MXP is Zugg's spec that you could assume that it is the correct one. However the specification still makes no sense then and it isn't the first thing in zMud I have come across that literally failed to work according to Zugg's documentation.

Now you are saying that apparently the standard gray color that 99.9999% of all muds expect to be gray is green by default? Wonder what else is screwy with the latest version. lol

Kavir: I never said that the owner could control 100% what the players see. In fact, I said several times that colors and such could be changed by the clients, and that was to be expected. I don't think that because you can't control 100% of what the client sees that you shouldn't try - if you don't want to try, why have color at all? Additionally, while you can't guarantee that the client will see everything, you can come pretty close for the majority of your users. And again, if clients can change the colors easily, why bother having redundant code in your game for players to do it there, too? I'm not saying that I agree with this, just that you don't seem to be considering ANY of this when making your statements - there are other points of view besides yours. Your argument doesn't make any sense in context.

I have been trying to present an alternate point of view (to the absolute one presented earlier), but this is going nowhere. You do it your way and I'll do it mine, and we'll just agree to disagree.

Because colour is there to improve the game for the player. If you force your own configuration down their throat, regardless of their client or personal preferences, then you've just failed in that objective.

But why come "pretty close" for the "majority" when you can instead give all of your players exactly what they want?

It's not redundant. Not only do some clients not support it, but there are also many examples which cannot feasibly be handled at the client end. In fact the only scenario I can think of in which colour should be handled entirely by the client is a mud which can only be accessed via its own custom client.

Imagine you want percentage scaled health in your prompt - white is 100% health, blue is 75-100%, green is 50-75%, yellow is 25-50% and red is 0-25%. How can you simulate that at the client level without hardcoding it according to your max hp?

Or what if you want to enable highlighting of certain keywords (eg in a help file, or player/mob keywords, etc) - the client has no way to know which are keywords and which are not.

Or how about changing the colouring on an ascii map (for example, if your client doesn't handle certain colours, as mentioned previously)? I've used clients before which didn't display the "bright" colours properly, forcing me to switch off colour completely so that I could see the map.

But the biggest problem with handling colour at the client end is that at that point the only thing you know is the colour code itself - you've no way to know what it represents, and if you change it for one thing you'll be changing it for all things. Want to adjust colour in the client so that critical hit messages are displayed in white instead of red? No problem - but it'll change your "warning" messages to white as well...

The better way to handle that is to provide colour configurations based on themes (eg "chat", "say", "warning", "health", "mana", "help keywords", etc) - but that has to be handled server-side (unless, as I mentioned before, you have a custom client which is the only way to play the mud).

I have considered the points, but have yet to find any reason for not having reconfigurable colours other than lack of time or technical ability. Almost all mud features represent a compromise - they add something at the expense of something else. Reconfigurable colours, however, add something while taking away nothing. They only apply to those who want them, and give no disadvantages to those who don't.

I disagree with that point of view, then. I don't think that a MUD that doesn't have configurable colors is lacking anything, it's just a different way of doing things.

An example from our own experience.

Take the Smaug default colors - from before the days of it's own colorize command. Room descriptions were bright white, room names bright yellow. I forget what alot of the other things were, but the point is, people hated it. It was ugly, and some people complained it hurt their eyes because it was so bright ( myself included ). Then you have those clients which break "bright" support and were either displaying nothing, or text so dark the user couldn't see it.

Enter the first attempt at us changing it. I polled people, nobody offered up a workable scheme, so I changed all the defaults to my own personal preferences. People complained again that they didn't like my choices. We were back to square one.

Several people on our mud play with non-Zmud clients, many of which lack the ability to alter their client-side color configuration.

When I found the custom color snippet for Smaug way back when, I jumped on it. Me being the lazy coder I am sometimes, I set the "default" color set to the preferences I had instituted before. The beauty here is that everyone can change how things look, so if they think my scheme sucks, they can do something about it without bothering the mud. This includes those people using clients that can't customize.

You should see the color settings my Head Builder uses. I can't stand them, but he loves them. I'd puke if I had to mud with those colors, but it's what he likes and he has the ability to use it and is happy. Some of the wild combinations my players pick would make most people hurl as well, but it's what they like, and they get consistent results from the mud whether they're at home using Uberclient, or at work using XP Telnet.

This makes them happy. They don't complain about colors anymore. On the occassion someone finds something they want changed, we can easily add a customization for it, which everyone else then gets to play with too.

Do we let them change everything? Of course not. Some messages force certain colors, the ansi wilderness map uses fixed color choices to represent terrain.

So I'm in agreement with those who see no reason not to include this functionality, and it's a standard feature in AFKMud and in Smaug 1.4a now as well.

Just wanted to point this out. Its statements like the one you just made that has resulted in this drawn out discussion. To slightly reword what you just said:

I don't think that a MUD lacking configurable colors is lacking anything.

You are contradicting yourself.

The bottom line is, regardless of whether you like sparce color, no color, or Vegas color, you get what you want when the MUD has a proper color configuration system. If it does not have one, then not everyone gets what they want.

It simply comes down to some vs. all. There is really no opinion about it.

I see why you're called "Treestump" - it's like arguing with one.

But he does have a point. Why *NOT* offer colour customisation?

From a mapping point of view, we actually recommend to players that they change the default zMud colours so that our main city appears as it should - in grey not green. This also corrects their client, so that when they mud elsewhere, they also see the 'correct' colours.

Our channel and prompt code is completely customiseable so if our players want a pink prompt, with value-dependant colours for hp/mana etc, then they can. we're not forcing them into any colour scheme. We do have a default colour scheme, which in my eyes is pretty good.

As a programmer myself, I'm first to hold my hand up and admit that my attempts at a colour scheme would be awful! Why inflict that pain upon players? If we didn't have customiseable colours, then a percentage of our playerbase would whinge that they hated the colours. Why even contemplate this, when with a (relatively) small amount of time, the colour scheme can be theirs!

As lots of other contributors to this thread have pointed out, having this level of customisation is a win-win situation.

At least on RoD, a good many people preferred the bright yellow room descriptions and white titles. I sure did, and when they converted it to what is now I immediately turned it back to the old default, personal tastes I suppose.

This is off-topic though, I admit.

Re: Why not exploit the telnet protocol?
 

Major necro here...but I stumbled across this old thread while looking for something else, and found it interesting that erdos was discussing features such as client detection, automatic identification of feature support, "hidden client-server dialogues" and such, back in 2003.

There was very little interest from other posters at the time (myself included). It's pretty interesting to see how attitudes have changed in the decade since then, with an increasing number of muds now doing exactly the sort of things he proposed.

Some people argue that the mud community is stagnant, never does anything new, etc. But clearly that's not the case.

Re: Why not exploit the telnet protocol?
 

Re: Yellow/Brown. I see this. On my 1991 386 SX running DOS 6.2 and KERMIT as a mud "client" I get browns. On my 1999 P2 running Win98SE and PowTTY as client the same text on the same MUD is in fact yellow. It has nothing to do with the monitor hardware. I am pretty sure it is not the video cards either. It is the client...

Re: Why not exploit the telnet protocol?
 

It is an interesting thread, and you managed to exhume this link as well,



Which I hadn't seen before.