Using the < and > characters would be a mistake because at least in Zmud those characters are used for something client side. True you can disable those and/or change them but not everybody knows enough about their client to do that. But then again Zmud uses a bunch of characters that I've had to disable so maybe I'm wrong on this.

FWIW, I use ` as the color code. It's a single character, easy to find up in the corner, and as noted, almost never used and easily replaced by '. I mapped `x to `q to make it easier to use. My friend Nibios has done the same, so we're a standard of two. Join us. :)

For those that want to discourage the use of colour, I'd say go with HTML style "tags".


Incidentally, I agree with elanthis, although I have made color easy for players to use. I use "stop light colors", green, yellow, and red, for 'consider' - you don't have to read the message to know if it's safe, you should use caution, or flee right now (consider also finds the target if you're fighting, like any combat command). Many other displays (including the dam messages) use a rainbow spectrum, with low blue at one end and high red at the other, to indicate the value. Going beyond color (as not everyone uses it (hey, my web page works in Lynx!)), my room titles are at the top and exits at the bottom of the 'look room' display. Objects indent once (which preserves the fake paragraph look of objects added to descriptions), mobs indent twice and are just above the exit list so you can quickly see what just hit you when you walked in the room.

What about player-configurable prompts? Players sometimes like to include colour in their prompts to instantly draw their attention to important details.

I also have a 'display' command which parses information much like a prompt, and is particularly useful in conjunction with aliases. Once again, players can add colour to draw attention to critical information.

While I do generally agree with your view about using colour in a consistant way, I don't have a problem with players reconfiguring their own display. It's only when they send information to other players that I restrict them; choose what colours you see, not what colours others see (and of course players can do this with their client to a certain degree, regardless of whether you provide explicit support for it within the mud itself).

What just crossed my mind, the main advantage of the system I use is that it's particularly easy to adopt 256 color support. Capital letters are used for background colors.

http://sourceforge.net/dbimage.php?id=11...

I've considered it, but the problem with that is the inability to use the grave accent for both ansi color codes and string saving at the same time; especially when saving strings containing ansi color codes. I've opted so far to use the grave accent as the string-end marker as it allows for all other characters in a string to be saved without botching anything but that one character (replacing it with apostrophe), including line breaks and other such characters. Nothing that I've thought of so far works as well as it does.

There's a very big difference between a markup language people can use as they send text to the MUD, and whatever file format you use to save data. There is no reason whatsoever for the two to be the same. There are many reasons for them to be different, in fact – one being this notion that characters have to be replaced or otherwise "fixed" when saved to file. Have a format that allows escaping (good ol' backslashes, for example) when saving to file, and then if you want people to be able to use color in their input, pick something else.

If you use a proper escaping schema for saving to file, all the problems you described here simply vanish.

The question is, is it the colour that's important, or the data? If the data is important, it might want to provide it's own colour information. For example, if you have hit points in your prompt, you might well already be tagging it as green/yellow/red as your health goes down, whereas letting the user say "hit points are red" takes away YOUR chance to provide extra information.

Of course, they can always apply whatever colouring (or font, or whatever) in their client if they aren't using raw telnet.

Or you can make it optional to have a default colorized prompt,
or whatever the user wants. I tend to lean toward giving more
options when possible, and I view player customizable colorized
stuff as being more choice, not less.

-Crat
http://lpmuds.net

I've always been a big fan of the player having full control over what they see. There is a large percentage of the world that is color blind so just cause a color scheme works for you doesn't mean it'll work for someone else. The more control a codebase gives me over color the better, cause lets face it, some people just have horrid taste and put ugly colors together. Not talking bout me having the power to change what other players see, just what I see. After all, I could care less whether they can even see color at all.

It's fairly easy to add a $c option to enable a color gradient for the next prompt item, and you could let players set a good, average, and bad color instead of settling for green/yellow/red.

Both are important.



Some of my prompt options (such as hit points) are automatically coloured, although these are always tied in to the four scaled colours for "good", "okay", "bad" and "awful", which can be customised. I guess it would make sense to let people override it with a fixed colour if they wish, but that's not something that's ever been requested.

However the majority of the options aren't coloured, nor (by default) is any normal text which the player might include within their prompt.



Only in a limited fashion.

Not that limited, I had a few friends back in highschool who had some amazingly in-depth triggers/aliases/scripts that really altered the look and feel of the mud they played. I never had the patience to actually do any of the advanced triggers except for one to send all tells and chats to a seperate window but even that was nothing compared to the things I saw one friend in particular come up with. And this is back when Zmud 4.62 was the newest version.

The client can only work with the data you provide it. If you simply give it a value, there's no way for it to know what that value represents, or how to colour it (eg for hit points with a gradient colour, unless you're also displaying maximum hit points).

For example, one of my prompt options displays the name of your opponent (if any), and uses a different colour if that opponent has their back to you. The client won't know that the text is an opponent name unless you put unique tags around that part of your prompt (it'll have to check for the tags), and even then there's no way for it to know whether your opponent is facing away from you or not.

You can use your client to apply colouring, but as I said previously, only in a limited fashion.