17 Jan, 2009, Lobotomy wrote in the 1st comment:
Votes: 0
I'm curious what sort of ideas and opinions the rest of you have with regards to the symbols used for two important things: the character(s) denoting ANSI color codes, and the character(s) denoting the end of a string as saved into/loaded from a file.

For example, consider Smaug. The ansi color code symbol is ampersand (&), and the file string save/load symbol is the tilde (~). Personally, I've found both to be characters which can come up somewhat frequently in conversation and/or various output displays, causing them to be somewhat cumbersome. I'm personally searching for what is/could be the best/optimal symbols to use for those two aspects (or maybe a replacement altogether for the use of symbols); primarily, symbols which are very rarely, if ever, used.

Where string saving/loading is concerned I've been using the grave accent (` (same key as tilde) ), and I'm finding that one rather hard to trump as grave accent is pretty much never used and can easily be replaced with the apostrophe (') whenever someone tries to use it. With ANSI though, I've been using the pound sign (#) and I'm finding that it's rather common, especially in display output. I've been thinking about switching to the at sign (@), since it seems to only see any regular use in the form of email addresses, but I'm not too sure about it.

The other thing to note is that ease of use is of particular importance as well. I'm aware of the various sorts of other characters you can get via alt/control and number combinations, but I don't think they would be particularly user-friendly.

Thoughts? :thinking:

Edit: With regards to the ANSI symbols, I primarily mean the foreground. I'm not too concerned with background ansi color at this point, but it'd still be worth discussing anyways.
17 Jan, 2009, Pedlar wrote in the 2nd comment:
Votes: 0
use { its ROMs default very uncommon to come up in conversation as well.
17 Jan, 2009, Cratylus wrote in the 3rd comment:
Votes: 0
While arguably cumbersome, I am accustomed to "Pinkfish" color codes.
These involve a sequence ( %^ ), not a single character, to open and close
the specified color code. For example:

I am %^RED%^very%^RESET%^ angry!

Is rendered as:

I am very angry!

I reiterate that I understand many people find it awkward, but it has
the virtue of greatly limiting ambiguity.

-Crat
http://lpmuds.net
17 Jan, 2009, Tyche wrote in the 4th comment:
Votes: 0
Why do you believe you need to set aside special characters?
If you need examples, check out this board or TeensyMud.
17 Jan, 2009, Chris Bailey wrote in the 5th comment:
Votes: 0
Yeah Teensymud uses tags, like Foo
17 Jan, 2009, Grimble wrote in the 6th comment:
Votes: 0
Do you want your users to be able to put color into their text (e.g., say, tell, shout, etc)?

If the answer is no, then use any reserved characters you like, and just be sure to strip them out of any input text coming from the user. Note that using a control sequence of multiple characters (like the example Cratylus gave) pretty much eliminates the chance of stripping out text that the user really did want to use.

I ran into a similar problem with storing user text in XML files (e.g., bulletin board messages). When reading the text back in, if it contained sequences such as <!\[CDATA\[ and ]]> it would mess up the XML parser.
17 Jan, 2009, Tyche wrote in the 7th comment:
Votes: 0
Actually the key to using any character or sequence you want is to escape it rather than stripping it.
17 Jan, 2009, Fizban wrote in the 8th comment:
Votes: 0
` is almost definitely the least commonly used key. (That's not an apostrophe, that's a grave accent, ie. the key on the same button as a tilde.)
17 Jan, 2009, Hades_Kane wrote in the 9th comment:
Votes: 0
Probably using [tags] would be the best way to go about it, but a close second, in my opinion, would be ROM's { character. I second the notion that it is a very uncommon character to be used within the span of normal conversation, ascii art, and the like. Probably where I've seen it used the most would be in clan flags and the like.
17 Jan, 2009, Fizban wrote in the 10th comment:
Votes: 0
Hades_Kane said:
Probably using [tags] would be the best way to go about it, but a close second, in my opinion, would be ROM's { character. I second the notion that it is a very uncommon character to be used within the span of normal conversation, ascii art, and the like. Probably where I've seen it used the most would be in clan flags and the like.


I see { used far more frequently than ` and probably more frequently than @ except in ASCII art. (Sure, emails arecommon on the net, but they're rarely exchanged on a MUD and even if they are you just type email addresses like: fizban@@tbamud.com
17 Jan, 2009, elanthis wrote in the 11th comment:
Votes: 0
For what it's worth, the entire issue is very easily avoided by just making better use of color: it shouldn't be specified by any text input at all. Use a consistent colorization setup for individual pieces of output; e.g., always print player names in green, friendly mob names in blue, enemy mob names in red, room titles in dark blue, exits in orange, etc. Pick sane defaults and add a command for users to change the type->color mappings per account.

Then you never, ever have to worry about markup for colors because sending colors would necessitate calling a specific function, e.g. send_color(ch->desc, COLOR_PLAYER_NAME).

Your MUD also becomes way more playable because you avoid all of the horrendously fracking stupid crap people do with colors while simultaneously gaining consistent semantic colorization.

Colors shouldn't be used where they look "cool." They should be used to organize and present data. Using consistent colors for the same type of data makes playing easier. For example, if you always list room titles in yellow and room exits in light blue, then a player who's trying to quickly navigate an area he's relatively (but not intimately) familiar with becomes WAY easier, because his eyes can quickly parse out the important information: where he's at and where he can go.

The human eye and brain are really very bad at parsing out text. The eyes work by recognizing edges, patterns, and colors. We can recognize shapes the easiest (hence why road signs in most countries have a different shape for different types of signs – makes it possible to "read" the sign without even seeing the text), gradients and patterns the second easiest, color the second worst, and letters the worst. By using color properly, you can mitigate the inherit limitation of using text (the hardest thing for our eyes to process) for conveying real-time information updates in a game.

If an enemy mob enters the room, and mob names are always red (and red isn't used for other common things), then I am able to start reacting before my brain can actually register what the text says. Sure, the specifics are very important and I need to read that text, but they are categorically less important than what the color would tell me: that something is about to attack me and I need to be ready to defend mysql or flee.

By not even making it possible to spit out color from descriptions, help files, or other data, you essentially guarantee that your MUD won't have inconsistent use of color based on whatever some idiot designer/player thought would look "super kewl" without bothering to understand the basics of how human information processing work.
17 Jan, 2009, Fizban wrote in the 12th comment:
Votes: 0
elanthis said:
For what it's worth, the entire issue is very easily avoided by just making better use of color: it shouldn't be specified by any text input at all. Use a consistent colorization setup for individual pieces of output; e.g., always print player names in green, friendly mob names in blue, enemy mob names in red, room titles in dark blue, exits in orange, etc. Pick sane defaults and add a command for users to change the type->color mappings per account.

Then you never, ever have to worry about markup for colors because sending colors would necessitate calling a specific function, e.g. send_color(ch->desc, COLOR_PLAYER_NAME).

Your MUD also becomes way more playable because you avoid all of the horrendously fracking stupid crap people do with colors while simultaneously gaining consistent semantic colorization.

Colors shouldn't be used where they look "cool." They should be used to organize and present data. Using consistent colors for the same type of data makes playing easier. For example, if you always list room titles in yellow and room exits in light blue, then a player who's trying to quickly navigate an area he's relatively (but not intimately) familiar with becomes WAY easier, because his eyes can quickly parse out the important information: where he's at and where he can go.

The human eye and brain are really very bad at parsing out text. The eyes work by recognizing edges, patterns, and colors. We can recognize shapes the easiest (hence why road signs in most countries have a different shape for different types of signs – makes it possible to "read" the sign without even seeing the text), gradients and patterns the second easiest, color the second worst, and letters the worst. By using color properly, you can mitigate the inherit limitation of using text (the hardest thing for our eyes to process) for conveying real-time information updates in a game.

If an enemy mob enters the room, and mob names are always red (and red isn't used for other common things), then I am able to start reacting before my brain can actually register what the text says. Sure, the specifics are very important and I need to read that text, but they are categorically less important than what the color would tell me: that something is about to attack me and I need to be ready to defend mysql or flee.

By not even making it possible to spit out color from descriptions, help files, or other data, you essentially guarantee that your MUD won't have inconsistent use of color based on whatever some idiot designer/player thought would look "super kewl" without bothering to understand the basics of how human information processing work.


From a developer standpoint you might like that but I really just can't see many builders caring for a setup where they can't color things in their descriptions to make them stand out if they feel so inclined nor do I suspect many players would be gladly told that they can't color their titles.
17 Jan, 2009, quixadhal wrote in the 13th comment:
Votes: 0
My 4000 original room MUD managed to do pretty well without color (at all), back in the day when I actually cared about running a game (rather than tinkering with code ideas)…

I think the Smaug folks used & because it's the same symbol used for the act() codes. I have no idea why ROM picked {.

Personally, I don't think it matters what symbol you use. Use whatever the community likes, or if you don't care… use whatever you like. It will always annoy someone. I'm with elanthis to some degree… I think whatever symbol you use is easy to work with (and around) in room descriptions, and I think allowing it in chat channels is stupid – and that's both where most people complain about having to escape the character AND where most people complain about random rainbows and blinking text of death.
17 Jan, 2009, Scandum wrote in the 14th comment:
Votes: 0
Emud uses the following system. It closely resembles the VT100 standard.
Syntax:  {xyz}  with x, y, z being parameters

Parameter 'x': VT100 code

0 - Reset all colors and codes to default
1 - Bold
2 - Dim
4 - Underscore
5 - Blink
7 - Reverse
8 - Skip (use previous code)

Parameter 'y': Foreground color
Parameter 'z': Background color

0 - Black 5 - Magenta
1 - Red 6 - Cyan
2 - Green 7 - White
3 - Yellow 8 - Skip
4 - Blue 9 - Default
18 Jan, 2009, Ssolvarain wrote in the 15th comment:
Votes: 0
I've used the tilde (`) and bracket ({).

Prefer the bracket, personally. It can be a pain at first, but it's second nature after so long, and I've never actually seen it used with any frequency, outside of code.

I know I have a habit of asking unrelated questions… But has anyone ever considered a tag for code, like a forum's?
18 Jan, 2009, Fizban wrote in the 16th comment:
Votes: 0
Ssolvarain said:
I've used the tilde (`) and bracket ({).

Prefer the bracket, personally. It can be a pain at first, but it's second nature after so long, and I've never actually seen it used with any frequency, outside of code.

I know I have a habit of asking unrelated questions… But has anyone ever considered a tag for code, like a forum's?


That's what teensymud uses.
18 Jan, 2009, Kline wrote in the 17th comment:
Votes: 0
Ack! uses @@. Enough to not prevent regular use of email or in conversation, art, etc…But still not too bad.

@Crat: The %^COLOR%^ is one thing I absolutely hate hate about any LP I've ever played on :(. I like to use a highly colorized prompt and my prompt string was truncated because of how long the color sequences were, and them counting as part of the string length.
18 Jan, 2009, Cratylus wrote in the 18th comment:
Votes: 0
Quote
my prompt string was truncated because of how long the color sequences were, and them counting as part of the string length


Yeah, I got that complaint and changed the lib I maintain
so that title length doesn't count the codes in commands
like who.

It's trivial to fix, doesn't have that much to do with LP itself…
but I hear ya.

Frankly I like the idea of forum style markup, but I'm not sure it's
a big enough deal to make the effort.

-Crat
http://lpmuds.net
18 Jan, 2009, Lobotomy wrote in the 19th comment:
Votes: 0
Tyche said:
Why do you believe you need to set aside special characters?

It's essentially a mix of convention and convenience. I've primarily played on muds in the past where symbol+char was the norm for generating color, with the symbol varying from game to game. While I feel inclined to stick with that trend in order to keep what's familiar, my foremost interest is what is easy(er) to use that also reduces or eliminates color code "collisions" as such wherever possible. That's primarily where the use of unused or uncommon symbols is important.

Ssolvarain said:
I know I have a habit of asking unrelated questions… But has anyone ever considered a tag for code, like a forum's?

With respect to a mud, which is what I'm assuming you're speaking of, what sort of things are you thinking of a forum-style tag system as being useful to? Channels, (bulletin) boards, and/or something else entirely? While my own bulletin board system still lacks a threaded structure as such (I'm still weighing the pros and cons of that), duplicating the effect of quote/code boxes for use within board notes sounds like an interesting idea. :thinking:
18 Jan, 2009, Fizban wrote in the 20th comment:
Votes: 0
Lobotomy said:
With respect to a mud, which is what I'm assuming you're speaking of, what sort of things are you thinking of a forum-style tag system as being useful to? Channels, (bulletin) boards, and/or something else entirely? While my own bulletin board system still lacks a threaded structure as such (I'm still weighing the pros and cons of that), duplicating the effect of quote/code boxes for use within board notes sounds like an interesting idea. :thinking:


I'm fairly sure he means something like: <color=red>Hey there, this string is red.</color>
0.0/33