24 Aug, 2010, Oliver wrote in the 1st comment:
Votes: 0
Over the time that I've played MUDs, I've noticed a couple things about color in MUDs. First, that (in my opinion) designers tend to either way overboard or way underboard– ie, way too much color or so little that the game becomes difficult to parse.

I'm wondering how the MUD designer community feels at large, because I've recently noticed that games with a whole lot of bright colors tend to attract players– do people generally prefer lots and lots of colors (and why?) or do you like designs that have color only placed to emphasize certain things (room names, subjective combat damage verbs, etc.)?
24 Aug, 2010, David Haley wrote in the 2nd comment:
Votes: 0
I like it when messages are given semantic categories and I can tell the MUD which color to use for the categories. For example, combat messages affecting me in red, combat messages affecting others in gray, room descriptions in white, and so forth. This lets me choose to give different messages different colors, or the same color, if I don't need them highlighted.

I don't like it when room descriptions use color – without using category names – because that interferes with my own colors. But a room description could say something like: "There is some <C:WATER>water</C> here" (using a totally made up notation) instead of making it blue. This way, if I want my water to be green, it will Just Work (TM).

I don't like it when MUDs force color schemes on me, because a meaningful color to one person might not be meaningful to another. (Plus, some people are colorblind and wouldn't be able to distinguish certain colors in the first place.)
24 Aug, 2010, bbailey wrote in the 3rd comment:
Votes: 0
David Haley said:
I like it when messages are given semantic categories and I can tell the MUD which color to use for the categories. For example, combat messages affecting me in red, combat messages affecting others in gray, room descriptions in white, and so forth. This lets me choose to give different messages different colors, or the same color, if I don't need them highlighted.


+1

In addition to the above, I also greatly appreciate the ability to disable any user-generated color (or other markup in general). I like when users have the ability to add color to their messages (says, emotes, channel text, descriptions, titles, etc), but it can become distracting for me at times. It is very useful to me to be able to (temporarily, usually) suppress the user-generated color while leaving the built-in color intact.
24 Aug, 2010, KaVir wrote in the 4th comment:
Votes: 0
Oliver said:
Over the time that I've played MUDs, I've noticed a couple things about color in MUDs. First, that (in my opinion) designers tend to either way overboard or way underboard– ie, way too much color or so little that the game becomes difficult to parse.

It's a bit like the saying that "Anyone who drives faster than me is a maniac. Anyone who drives slower is an idiot". The amount and usage of colour is very much a matter of personal preference, which is why you're probably better off allowing people to customise it - because otherwise, half your players will think you've gone overboard, while the other half will think you've gone underboard.
24 Aug, 2010, JohnnyStarr wrote in the 5th comment:
Votes: 0
I agree with everything said so far. I think that it would be nice to offer schemes, I believe SMAUG does this?
Or SmaugFuss perhaps. If you built your own scheme, it could be added to your account folder. This way, if you
have multiple characters, they could share the schemes. Also, you could offer pre-built ones, much like the way
in WoW if you are Horde everything looks different than Alliance.

Is there such as thing as "mud color protocol?". Might be worth standardizing.
24 Aug, 2010, Rudha wrote in the 6th comment:
Votes: 0
My MUD will have a configuration option that is a three-state switch for colour markups, once I test it and its solid:

OFF - Colour for most strings is disabled.
ON - Colour for most strings is enabled and uses the server defaults.
CUSTOM - Colour for most strings uses colours defined by the user.

CONFIG CUSTOM COLOUR lets users set what colour code they want to use for the following in my test implementation (subject to change!):

ALLIES - certain players marked by the player as their allies. This highlights strings containing that character's name.
ENEMIES - certain players marked by the player as their allies. This highlights strings containing that character's name.

CITY ALLIES / CITY ENEMIES - as above, but for the player's city if they belong to one.

GUILD ALLIES / GUILD ENEMIES - as above, but for the player's guilds, if they belong to any.

SAYS - Highlights SAY and SAYTO strings with this colour.
EMOTES - Highlights EMOTES with this colour.
TELLS - Highlights TELLS with this colour.
COMBAT - Highlights combat skill strings with this colour.
TRADESKILL - Highlights trade skill strings with this colour.

ROOM ITEMS - Highlight items in the room description with this colour.
ROOM CHARACTERS - Highlight characters in the room description with this colour.
ROOM EFFECTS - Highlight any special effect strings in the room description with this colour.

HEADER - Colour to display SCORE/STAT/etc headings in.
FOOTER - Colour to display SCORE/STAT/etc footers in.

User colour is stripped from descriptions titles/etc, I don't like players being able to use colour in that kind of thing, honestly. I -might- allow it in the designs for craft items - Im undecided.

To specify, the parser first strips any existing color from a string before it colours it according to either the server defaults, or the players custom colour if they're using custom colors. Im also considering having players of different levels show in different colours on WHO. Undecided about that.

——–

To address the more general issue of colour: colour is a tool. When its used to help segment and organise information into the important and unimportant, or some other logical organisation, its very helpful. When its pasted haphazardly all over the place like someone let a kid loose all over the place with the crayons, then it just detracts from things, and puts people off.

It's worth noting, however, that you can utilise that if you wanted to get artsy. You can make a chaotic sort of environment or such seem all the more chaotic when you have colour all over the place. Myself, personally, though, I'll probably avoid that.

Maya/Rudha
24 Aug, 2010, Scandum wrote in the 7th comment:
Votes: 0
256 colors are pretty widely supported nowadays, I wrote some public domain code a while ago that may be of interest to those wanting to implement them while keeping 16 color backward compatibility. http://www.mudbytes.net/file-2596

Regarding the original question, I prefer configurable colors, and dislike custom description coloring.
24 Aug, 2010, KaVir wrote in the 8th comment:
Votes: 0
Rudha said:
My MUD will have a configuration option that is a three-state switch for colour markups, once I test it and its solid:

OFF - Colour for most strings is disabled.
ON - Colour for most strings is enabled and uses the server defaults.
CUSTOM - Colour for most strings uses colours defined by the user.

Why differentiate between "on" and "custom"? Just set their colours to the default values when they create, and allow them to change them if and when they wish.

It might be worth having an option to indicate 256 colours though. You could use TTYPE and base it on the client, but that won't work for all clients. I'm not sure how consistent MXP implementations are with the SUPPORT tag, but in theory that should allow you to identify clients that support 24-bit colour - anyone know how reliably this is implemented across clients?
24 Aug, 2010, Rudha wrote in the 9th comment:
Votes: 0
Its not set in stone yet. The idea is to avoid duplicating the server defaults in every players pfile.

Very poorly, if you mean by MXP. It's why some people get very angsty about implementing it. The 'protocol' itself, if you can call it that, isnt too bad to implement, but accounting for the differences in implementation can be .. ehhhh.

Maya/Rudha
24 Aug, 2010, David Haley wrote in the 10th comment:
Votes: 0
Quote
The idea is to avoid duplicating the server defaults in every players pfile.

Only store a color if it deviates from the default.
24 Aug, 2010, Rudha wrote in the 11th comment:
Votes: 0
I suppose that could work, but it seems like more "work" on the programming end to iterate through every colour when it goes to save or load pfiles. I suppose the memory/cpu time we're talking here is really negligable, though, so that's probably the best way to do it. It would mean I could put it all in a single command. Or rather a single sub-command of CONFIG.

Maya/Rudha
24 Aug, 2010, David Haley wrote in the 12th comment:
Votes: 0
Yes, it's a single iteration over color categories. Even if you had 1,000 colors, this would be a very fast operation, and you're only calling it when people save. If you had the implausible situation of 100 characters each saving once per second, with 1,000 color categories, you'd be hitting the color arrays 100,000 times a second, which is not really a lot.

More interesting questions are what happens when the default changes; you might want to distinguish between a person leaving a category at the default, and deliberately setting it to the default. If the default changed, then in the former case they might want the color to change too, but in the latter case they made a deliberate choice. This is, however, over-thinking things and not really something to worry about. Changing colors is not likely to happen enough to justify all this complexity.
24 Aug, 2010, KaVir wrote in the 13th comment:
Votes: 0
The effort is negligible, from both a CPU perspective and programming perspective.

Presumably you already have something like this in place anyway, for loading pfiles - otherwise how would you know what values to assign to missing variable fields? All you do is check against those same default values when you save.
24 Aug, 2010, Rudha wrote in the 14th comment:
Votes: 0
Quote
, for loading pfiles - otherwise how would you know what values to assign to missing variable fields?


If it's something I've programmed, it will have comphensation yes. The original NM codebase Im not so sure about. The reason I pulled the 'body part' system it had in there originally is because it started complaining about characters without body parts and stuff, and it became easier to just rewrite it.

Anyways, I'm more wondering about the xterm 256 colours now. I dont think I've see a NM implementation of it, so I guess Ill have to write one.
24 Aug, 2010, JohnnyStarr wrote in the 15th comment:
Votes: 0
I liked David's idea.

Could look like:

def convert(str)
colors = {:blue => "\e
def convert(str)
colors = {:blue => "\e[1;34m",
:green => "\e[1;32m",
:white => "\e[1:30m"}

codes = {'[water]' => :blue,
'[rare]' => :green,
'[/]' => :white,}

codes.each {|k,v| str.gsub!(k,colors[v])}

puts str
end

convert "You pick up a [water]glass of water[/]. It has [rare]a silver spoon[/] in it."

#OUTPUT
# You pick up a glass of water[1:30m. It has a silver spoon[1:30m in it.
[/code]
24 Aug, 2010, Rudha wrote in the 16th comment:
Votes: 0
I missed that comment! I feel kind of silly now. That could certainly work to make it easier, then you just have to put it through a parse function and you can get any custom player settings within that function.

I think I may even do that.

Maya/Rudha
25 Aug, 2010, chrisd wrote in the 17th comment:
Votes: 0
Rudha said:
Anyways, I'm more wondering about the xterm 256 colours now. I dont think I've see a NM implementation of it, so I guess Ill have to write one.


Stendec wrote an excellent implementation in Python for NM that's MIT-licensed. I believe it can be found on the mailing list somewhere.
25 Aug, 2010, KaVir wrote in the 18th comment:
Votes: 0
Or you could just use the public domain version Scandum linked to earlier.
25 Aug, 2010, Scandum wrote in the 19th comment:
Votes: 0
The way my 256 color snippet works 256 color tags can be translated into either 256 color codes or 16 color codes. So all a player would need is some config option to switch between 1 color, 16 colors, and 256 colors.

Automatic detection would be nice. One idea I have is for clients to report a special MUD TTYPE, so TinTin++ for example would send TINTIN++, followed by XTERM (if that was the terminal emulator used), followed by MTTS 1734012. MTTS would stand for Mud TTYPE Standard, and the number would be a bitvector, and the MUDs could check the bitvector for 256 color support.

Biggest downside is that MUDs would have to cycle through the terminal types, biggest advantage is that it's fairly easy to add for clients.
25 Aug, 2010, quixadhal wrote in the 20th comment:
Votes: 0
I implemented an extension to the Pinkfish style color code system, used by many LP MUD's. The codes themselves are defined in mappings, so symbols like %^AntiqueWhite%^ gets mapped to the right escape sequence for XTERM256, XTERM256-GREY, ANSI, or DUMB. The nice thing is you can change your terminal type on the fly, so if you want to see things in greyscale, just set your TERM variable to GREY and it only uses a subset of the normal XTERM256 codes.

Minimal CPU overhead, because the mappings are pre-generated and loaded, so it's just the mapping lookups, which should be pretty fast.
0.0/32