30 Jun, 2010, Scandum wrote in the 1st comment:
Votes: 0
I created a brief introduction to xterm 256 colors on Mudpedia. I'm wondering if this is clear enough, or if something a little more elaborate is required.

http://www.mudpedia.org/wiki/Xterm_256_c...
30 Jun, 2010, KaVir wrote in the 2nd comment:
Votes: 0
Nice article, although it might be worth including (or linking) to your snippet, and/or add giving a small code example in the "RGB Colors" section.
30 Jun, 2010, Runter wrote in the 3rd comment:
Votes: 0
Re: musing on other thread I can't find.

I think the reason a lot of us haven't supported it is we never have seen a dire need to have different shades of colors.
30 Jun, 2010, KaVir wrote in the 4th comment:
Votes: 0
There's no "dire need" for colour at all, but it's nice to have. The 256 colours aren't any more difficult to add than the traditional 16, and sometimes it can be a struggle to differentiate between things using only 16 (for example with ASCII maps).
30 Jun, 2010, Scandum wrote in the 5th comment:
Votes: 0
KaVir said:
Nice article, although it might be worth including (or linking) to your snippet, and/or add giving a small code example in the "RGB Colors" section.

I'll probably create another infamous green protocol page on my sourceforge web space with links and examples to keep mudpedia's content as encyclopedic as possible.

Runter said:
Re: musing on other thread I can't find.

I think the reason a lot of us haven't supported it is we never have seen a dire need to have different shades of colors.

Your argument supports that 256 colors are sufficient and that there is no need for more colors.

Obvious applications are the 11 color shades from green to yellow to red which is useful for coloring health bars, and a blue to magenta to red range for mana. Then there is the full range of secondary colors with orange being the most noticeably lacking. I'd say the number of easily distinguishable colors is between 24 and 32, which is a pretty decent improvement.

Might be doable to create an 256 color standard for the ROM color notation using letters of the alphabet. Currently it's:

^d = black
^r = red
^g = green
^y = yellow
^b = blue
^m = magenta
^c = cyan
^w = white

The most notable that come to mind are:

^s = scarlet <eab> ^S = <fac>
^l = lime <bea> ^L = <cfa>
^o = orange <eba> ^O = <fca>
^a = azure <abe> ^A = <acf>
^i = indigo <bae> ^P = <caf>
^p = pink <fcf> ^P = <fef>
01 Jul, 2010, quixadhal wrote in the 6th comment:
Votes: 0
I extended the Pinkfish standard for my own game. It supports all the RGB color names from the X11 palette, as well as the numeric versions (using hex digits).

%^GREEN%^, %^AntiqueWhite%^, %^XTERM:d3%^

I find this to be far easier to work with than cryptic one symbol + one letter tokens, and if you really find yourself using them so often that the typing is too much (DBZ mud?), macros for your editor or client can make things simpler.

My terminal daemon downgrades from XTERM256 to XTERM256-Greyscale to ANSI to none, automatically, so XTERM:a1 shows up as salmon-pink, or a medium-grey, or red, or whatever the default text color is, without having to change anything but your terminal type setting.

Note that you can also extend the system to have class-based symbols (%^ROOM_DESC%^, %^DAMAGE%^), if you so choose.
01 Jul, 2010, David Haley wrote in the 7th comment:
Votes: 0
Personally, I say we just use 16, since it's been around for a while. Sure, it wouldn't look as good as 256, but that's ok. :wink:
(Yes, that is a joke, but it rests upon the more serious point that there is a reason why there are general interface improvements: expanding colors to capture more information is really the same argument as using a proper graphical interface rather than vt100.)
01 Jul, 2010, Scandum wrote in the 8th comment:
Votes: 0
David Haley said:
Personally, I say we just use 16, since it's been around for a while. Sure, it wouldn't look as good as 256, but that's ok. :wink:
(Yes, that is a joke, but it rests upon the more serious point that there is a reason why there are general interface improvements: expanding colors to capture more information is really the same argument as using a proper graphical interface rather than vt100.)

The proper analogy would be if someone were to not implement ANSI 16 color but only xterm 256 colors, under the notion that there's no point implementing inferior technology.
01 Jul, 2010, David Haley wrote in the 9th comment:
Votes: 0
Why should you bother with 16 colors if you know that target clients – the ones that support other necessary features like graphical maps – all understand 256 colors? (In fact, you'd likely just jump to full 24-bit RGB colors.)

You said it yourself: the technology is inferior. Since it's so easy to get the newer technology (where "newer" here means more recent than decades (!!!)), why bother holding back? It makes for an inferior play experience, inferior information display, inferior aesthetics…
01 Jul, 2010, Kaz wrote in the 10th comment:
Votes: 0
David Haley said:
Why should you bother with 16 colors if you know that target clients – the ones that support other necessary features like graphical maps – all understand 256 colors? (In fact, you'd likely just jump to full 24-bit RGB colors.)

You said it yourself: the technology is inferior. Since it's so easy to get the newer technology (where "newer" here means more recent than decades (!!!)), why bother holding back? It makes for an inferior play experience, inferior information display, inferior aesthetics…


Which, of course, means that the best solution is to use a generic markup for colours (like, say, <colour:#FF00FF>I'M MAGENTA!</colour>), and have a conversion routine that automatically matches it to the closest available for the given terminal.
01 Jul, 2010, KaVir wrote in the 11th comment:
Votes: 0
Kaz said:
Which, of course, means that the best solution is to use a generic markup for colours (like, say, <colour:#FF00FF>I'M MAGENTA!</colour>), and have a conversion routine that automatically matches it to the closest available for the given terminal.

That may not always be appropriate. For example if you decide to use shades of red to indicate health, shades of blue to indicate mana, and shades of green to indicate movement, it could end up using just two colours on a 16 colour terminal - in that situation you might prefer to use different colours entirely. Likewise, a yellow desert and brown swamp may end up being displayed the same shade if done automatically, which could make an ASCII map very difficult to read.
01 Jul, 2010, Kaz wrote in the 12th comment:
Votes: 0
Ah, a good point. Hadn't thought of that.

Well, they say that every programming problem can be solved by adding a layer of indirection (except for too many layers of indirection).

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.

As a bonus, it then becomes reasonably easy for players to edit their colour schemes.

Edit: you could use both schemes, by specifiying the most detailed as the target colour and have the colour matching algorithm in place for any lower detail colour scheme, unless overridden.
01 Jul, 2010, David Haley wrote in the 13th comment:
Votes: 0
I am all for using semantic markup rather than sending presentation information down the line.

That said: this is an awful lot of effort to support clients that relatively few people even use anymore. Even most console clients support 256 colors these days, and most people don't even use console clients (cf. KaVir's client stats).
I think that as engineers we have a tendency to want to engineer all problems away, even when we shouldn't really be paying attention to those problems in the first place because there are more important ones to address…
01 Jul, 2010, Kaz wrote in the 14th comment:
Votes: 0
I see where you're going, David. Mudding is a legacy from when people used green screen to connect and text was all they had. Fonts!? Bah!

I think it's fine if a game creates a client for itself in order to enhance the experience of its end users (heck, that's what every contemporary commercial games does), but then it effectively leaves the mudding arena.

The mudding arena is not hugely populated, and keeping to a common denominator enables a mud to gain access to a userbase that already has the tools it needs to join your game. There's a lot to be said for "no download necessary". Well, once you've committed to mudding and got the client the first time anyway.

Which is why I think that some of this work that's going into clients (and some of the statistics produced by KaVir saying how much of his playerbase uses clients) is great in raising up the common denominator.
01 Jul, 2010, David Haley wrote in the 15th comment:
Votes: 0
Kaz said:
I think it's fine if a game creates a client for itself in order to enhance the experience of its end users (heck, that's what every contemporary commercial games does), but then it effectively leaves the mudding arena.

So people who play KaVir's game with his MUSHclient plugins are no longer playing a MUD because there is customization of the client?

Kaz said:
The mudding arena is not hugely populated, and keeping to a common denominator enables a mud to gain access to a userbase that already has the tools it needs to join your game. There's a lot to be said for "no download necessary". Well, once you've committed to mudding and got the client the first time anyway.

There are also many more players out there, and besides that "well, …" caveat is a pretty big one.

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

Kaz said:
Which is why I think that some of this work that's going into clients (and some of the statistics produced by KaVir saying how much of his playerbase uses clients) is great in raising up the common denominator.

The common denominator will never be raised if people keep the mentality of wanting to support everything all the way back to 16 colors. :sad: Even clients like tt++ or tf, which are otherwise quite capable, necessarily keep things at a certain level because they cannot display proper graphics.

I guess it comes down to how you define "mudding". Your definition appears to be fairly narrowly specified on medium (basically, text only) whereas my view encompasses more things. I guess I'm becoming more interested in games than some narrow definition of medium. (Please note that "narrow" is not meant to mean anything bad here; I mean it to denote a very specific, small set of things.)
01 Jul, 2010, Runter wrote in the 16th comment:
Votes: 0
Quote
but then it effectively leaves the mudding arena.


That's one view, but I don't agree. I'm not sure what line you're even suggesting would have to be crossed. My point is that this line should be left up to the users. Build it and they will come, indeed. More importantly, they'll come if you build what they were looking for.

Quote
The mudding arena is not hugely populated, and keeping to a common denominator enables a mud to gain access to a userbase that already has the tools it needs to join your game.


This type argument gets repeated over and over. I'm sure you're sincere in this believe, but I just don't get it. I suspect a lot of people don't get it. Half of a really small number is still a really small number. Are we really going to be worried about alienating an almost nonexistent niche? It's one thing to make a game that you want to play that turns out not to be very popular. That's fine. That's legitimate. It's another thing to make your game unpopular to appease a group that's so small as to not really matter.
01 Jul, 2010, quixadhal wrote in the 17th comment:
Votes: 0
That, right there, is the core of the argument over TELNET vs. a custom messaging protocol *AND* the plain-text vs. ANSI vs. XTERM256 argument.

If it were possible to build everything to take FULL advantage of a message-based protocol and a full graphics-and-sound enabled client, and have it magically dumbed down so that Joe using his real vt52 terminal connected to the AT&T 3b2 in the basement which is running pppoe to get on the internet can somehow experience the game at a level where it's both fun and where he can be competitive with the folks using HTML 5 and javascriptbots, there would be no argument!

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.

I still believe text muds have a strong place in the larger gaming community. We are one of the few platforms that can still be used to create fun and meaningful games with a tiny handful of people involved. But, the audience is leaving the theater folks. Do we really want to wait for the last customers to die off before accepting change?
01 Jul, 2010, Runter wrote in the 18th comment:
Votes: 0
I imagine some projectionists don't mind being the only one in the theater.
01 Jul, 2010, David Haley wrote in the 19th comment:
Votes: 0
Quote
I imagine some projectionists don't mind being the only one in the theater.

It depends on whether you're building a model ship, or a game for people to play. Both endeavors are fine, but people need to know which one they want to do…
01 Jul, 2010, Runter wrote in the 20th comment:
Votes: 0
David Haley said:
Quote
I imagine some projectionists don't mind being the only one in the theater.

It depends on whether you're building a model ship, or a game for people to play. Both endeavors are fine, but people need to know which one they want to do…


That's my take on it, too. However, I further observe that some people on both sides have trouble relating with each other. This can lead to misunderstanding because it's hard to have a conversation about a topic when the underlying goals aren't the same on both ends. Particularly when it takes sometimes many back and forths before those goals are clearly stated.
0.0/48