21 Mar, 2012, KaVir wrote in the 81st comment:
Votes: 0
Runter said:
Markup exposed to the client would make this trivial as well, which is actually my preference. I don't like backend controlling interface and presentation so heavily.

My server-side colours are customisable, and I support xterm 256 colours, so it would be pretty easy for the user to define a different colour for each type of message, and have their client treat that as a (rather ugly) markup.

Deimos said:
@KaVir: /^You hurl (.+?) at (.+?) hitting (him|her|it) in the (.+?)\.$/

My mud has over twelve thousand fighting techniques.

Deimos said:
If the styled text == $2, read the color.

There are no colour to read. The colours I described are what I want your solution to display, using regular expressions.

So to use one of my examples, this is the raw data you receive from the mud:

A desert nomad stabs his right scimitar over his left scimitar and into a scruffy watchman's face, drawing blood.

No colour or escape codes of any sort, no hidden markup, no out-of-band data, just a human-readable string.

Your regex solution needs to identify all creature names in that string, and colour them white - or red, if they've got their back to you.
21 Mar, 2012, Deimos wrote in the 82nd comment:
Votes: 0
@KaVir: The number of fighting techniques isn't really relevant. I assume that number is actually due to combinations of discrete sets of choices. If you really have 12000 distinct techniques, each with their own messages, then you've made a game design blunder of epic proportions. ;-) As an example, we can combine multiple variations into one regex:

/You (hit|smash|cleave|chop) (.+?) in the (.?)\.$/

I don't know what a technique is or consists of wrt output, so I'm flying blind here.

And, of course there are existing colors to read. This whole conversation is about how to change those colors (read: customization). If you're asking me to determine crticial hits and player positions on the client with no indicators from the server, that's impossible, and I don't understand how it's relevant to color scheme customization at all.
21 Mar, 2012, KaVir wrote in the 83rd comment:
Votes: 0
KaVir said:
Regular expressions are of limited use. It's not uncommon for muds to colour things that couldn't be done easily (or even at all) through regular expressions.

Deimos said:
I don't believe that for a second. :-p

(snip lots of pointless discussion)

Deimos said:
If you're asking me to determine crticial hits and player positions on the client with no indicators from the server, that's impossible, and I don't understand how it's relevant to color scheme customization at all.

I'm glad you finally agree with me, and will accept your surrender.
21 Mar, 2012, Deimos wrote in the 84th comment:
Votes: 0
@KaVir: Okay, well I guess you misunderstood what I was suggesting initially. You most certainly cannot color things client-side based on server-only knowledge, and I never claimed otherwise. That much is obvious to everyone, I would think. If a server does color something, it's trivial to modify that color on the client, though, which was the point I was trying to get across.
21 Mar, 2012, Hades_Kane wrote in the 85th comment:
Votes: 0
Lyanic said:
Hades Kane said:
We all eventually run out of major things that need coding or get to a point where the game world, area wise, is relatively complete and much of the building from that point turns toward filler and extra areas, and further customization on the display may be worth addressing at that point.

Speak for yourself. I've been working on my game for 10+ years now, and I typically keep To Do lists for 2-3 years out. I'm convinced I'll never run out of major things to work on.


Maybe I should have said "core" or "essential" features :p

I want to recode weather eventually, which will be a pretty big thing, but I wouldn't consider that core or essential, to clarify what I mean.
21 Mar, 2012, plamzi wrote in the 86th comment:
Votes: 0
Hades_Kane said:
Lyanic said:
Hades Kane said:
We all eventually run out of major things that need coding or get to a point where the game world, area wise, is relatively complete and much of the building from that point turns toward filler and extra areas, and further customization on the display may be worth addressing at that point.

Speak for yourself. I've been working on my game for 10+ years now, and I typically keep To Do lists for 2-3 years out. I'm convinced I'll never run out of major things to work on.


Maybe I should have said "core" or "essential" features :p

I want to recode weather eventually, which will be a pretty big thing, but I wouldn't consider that core or essential, to clarify what I mean.


Heh, weather is on my to-do list, as well. It's way way down, and still a good bit ahead of allowing full color customization. :grinning:

That said, if any of the honorable gentlemen advocating for the importance of such a feature were to offer to code this feature into my game, I would gladly take them up on it. Contrary to what DH seems to believe, I've never advocated that not having a usability feature is better than having one. The more features, the merrier. It's just that due to a unique combination of factors (many of which have to do with my individual perspective), this particular usability feature is very low priority for me. And TBH, I think the case for caring more about it hasn't been made yet.

@Lyanic:
Actually, I don't think anyone's talking about being able to remap colors (turn all green text into red, etc) because that kind of thing is very easy to do in the client (or custom client) and also quite easy to do on the server (I can see myself coding that in on a whim on a slow day). I think the discussion is about the importance of letting users configure the color for hundreds, potentially thousands, of individual events / event types. Depending on how deep you want to go down this rabbit hole, I imagine such a project can take weeks, even months.
21 Mar, 2012, David Haley wrote in the 87th comment:
Votes: 0
Lyanic said:
What was advocated as "full color customization", and is still being advocated as best I can tell, is to allow each player to remap any color X to any other color Y via server-side configurations. For instance, a player could have all grey text remap to white, and all white text remap to blue.

No… it's not mapping color X to color Y. It's assigning color X to type Y. There's a pretty big difference. Your color scheme might have room desc and exits in white, but I might have room desc in green and exits in blue (or whatever).

This is the big difference with remapping colors client-side (as opposed to parsing and assigning color), and having customizable color server-side. If it wasn't clear that we were doing type mapping, not just blanket color reassignment, it's not surprising that people thought the feature was dumb. :smile:

Lyanic said:
The assumption is that each component of text is assigned a single, static color. If all room titles were magenta, it would be easy to allow a configuration that changes them all to green. If, on the other hand, the base color varies by the plane of existence and also includes words that may have other information encoded via color, the problem is quite different.

Why is this different?
Room title Plane 1 -> blue
Room title Plane 2 -> green
Room title Plane 3 -> red
etc

As long as you can identify a type of message, you can associate a color with that type.

Now yes, of course, this can get complex quickly. The point is that it's not a challenging technical problem. Just as you need intelligent design in a color scheme, you need intelligent design in your customization. Like I said earlier, you can get a lot of payoff for even relatively simple customization, and you can hard-code the rest. So, you can pick your customization categories judiciously, get the payoff, keep your intelligent default color scheme, and you get the best of both worlds without having to spend a huge amount of time on it all.
21 Mar, 2012, David Haley wrote in the 88th comment:
Votes: 0
plamzi said:
Contrary to what DH seems to believe, I've never advocated that not having a usability feature is better than having one.

I never said or implied this. I'm not sure what you're arguing with.
21 Mar, 2012, plamzi wrote in the 89th comment:
Votes: 0
David Haley said:
plamzi said:
Contrary to what DH seems to believe, I've never advocated that not having a usability feature is better than having one.

I never said or implied this. I'm not sure what you're arguing with.


David Haley said:
I'm not sure how you can possibly disagree with the statement that customization of colors is better than lack of customization of colors, completely independently of any other consideration.
21 Mar, 2012, Hades_Kane wrote in the 90th comment:
Votes: 0
David Haley said:
Why is this different?
Room title Plane 1 -> blue
Room title Plane 2 -> green
Room title Plane 3 -> red
etc

As long as you can identify a type of message, you can associate a color with that type.

Now yes, of course, this can get complex quickly. The point is that it's not a challenging technical problem. Just as you need intelligent design in a color scheme, you need intelligent design in your customization. Like I said earlier, you can get a lot of payoff for even relatively simple customization, and you can hard-code the rest. So, you can pick your customization categories judiciously, get the payoff, keep your intelligent default color scheme, and you get the best of both worlds without having to spend a huge amount of time on it all.


Let's say a builder sets a room title to: {rAlong a Path in the {YFIRE {RC{ravern{x

Obviously that's ugly, but that's beside the point for a moment, just using it as an example. Or let's say (using an actual example):

{wThe walls here to the north are highly decorated, with flowers and
various posters and flyers. A cooling sea breeze blows through this area,
seemingly moreso from the west. To the east is the center of Termina,
signified by the large blue design etched into the ground there. {cA blue
and red door sits to the north, with a sign above it reading 'Bar.'{x

Is it feasible to allow customization of both the room title and the room description while also simultaneously accounting for the fact that (particularly in the case of the room description) that particular bits are highlighted for emphasis? Along with us often times using a different color for indoor/outdoor areas to help emphasize the drastic change of scenery, we also generally highlight doors that should be obvious to allow players to quickly skim a room description and have a visual indicator of an obvious door. The same can be said for the ugly room title example I provided, as sometimes things are colored different or highlighted for a particular reason. I think this is the issue Lyanic was bringing up.

In my "mid point" color customization thing I referenced, the thought I had would be to run the code to strip all color codes before it is sent to the player and then send it whatever color I (or if I allowed the players to set it) chose. This would basically eliminate all highlighting or variation in the room descriptions that are placed there by builders for emphasis or pointing out more obvious features of the room.
21 Mar, 2012, Deimos wrote in the 91st comment:
Votes: 0
@Hades: Indeed; color customization becomes less trivial when you allow arbitrary coloring within elements. Maybe even to the point of impractical, unless you allow builder-specified colors to override defaults.

Personally, I dislike the idea of allowing this, though. IMO, it's adequate to say "room names are cyan." Then, wherever your display code is at, you can simply replace the hard-coded "{cRoomName" (or whatever) to something like "<rname>RoomName</rname>" and allow your color filter to dynamically set the color based on the user's preference.

Of course, as I said, what do do when the room mame itself contains color codes is ambiguous, and makes life harder.
21 Mar, 2012, David Haley wrote in the 92nd comment:
Votes: 0
Plamzi, you should maybe look at context. You made a nonsensical or non sequitur statement (I'm still not sure what you were saying). So I gave you one in return. I had hoped that the sarcasm would be clear, especially given my preceding sentence, but, oh well. You gave a flippant response when I made the exact point you now say you've been making all along. Well, I don't really care… my point should be pretty clear to those interested in having the discussion. In the interests of preserving interesting discussion, I'll reply to you if you make points, rather than snipe at me.

Hades_Kane said:
Is it feasible to allow customization of both the room title and the room description while also simultaneously accounting for the fact that (particularly in the case of the room description) that particular bits are highlighted for emphasis?

If emphasis is a universal concept, then sure, you could have "emphasis" as a color type. I would make the same argument that Deimos did, which is that if you want to highlight an exit in the room description, you'd use the exit type rather than a manual color override. If you wanted to identify outdoors and indoors, you could use colors for that too. (My game has the notion of day/night in/out, so you can pick colors for nighttime outdoors description elements, for example.)

In any case, I still feel that you're taking the notion of color customization and pushing it to an extreme of allowing every single color in the entire game to be customized. That might not even be a nice feature, because the interface for customization would be very complex. Technically, it's easy, but from an interface perspective, it's impractical.

Color customization is important when you need to quickly identify specific pieces of information.
If your game is such that the focus is less on quick identification like this, then, clearly, color customization becomes more important.
In my experience (playing and designing games) color customization is most important for things like fast-paced combat, where messages scroll by very quickly and you need to tell at a glance which messages you really need to care about, and which messages are less important.
21 Mar, 2012, Rarva.Riendf wrote in the 93rd comment:
Votes: 0
Quote
Is it feasible to allow customization of both the room title and the room description while also simultaneously accounting for the fact that (particularly in the case of the room description) that particular bits are highlighted for emphasis?

Definitely I do it. when I apply color to a room I go look for the player wanted color for room description, if I encounter a hardcoded color, I apply it, and when I encounter a specific 'end color marker', I revert to 'previously user defined color'
Pretty easy to do. Just have to define good practice for your builder so they dont forget to 'close' their color tag.
21 Mar, 2012, Hades_Kane wrote in the 94th comment:
Votes: 0
Rarva.Riendf said:
Quote
Is it feasible to allow customization of both the room title and the room description while also simultaneously accounting for the fact that (particularly in the case of the room description) that particular bits are highlighted for emphasis?

Definitely I do it. when I apply color to a room I go look for the player wanted color for room description, if I encounter a hardcoded color, I apply it, and when I encounter a specific 'end color marker', I revert to 'previously user defined color'
Pretty easy to do. Just have to define good practice for your builder so they dont forget to 'close' their color tag.


The vast majority of our non default color descriptions work in such a manner of:

{yThis is a dense forest in which the {gtrees{y overhead sway with the wind.
The {csky{y overhead can be seen through the tops of the {gleaves on the trees{y
and a {rrocky{y path to the south is visible.

Mind you, most descriptions aren't this colorful, but the Lope colour code that my game and many others use has no "close" on color tags. It's not like html where you go <red>this text is red</red> or something to that degree. Even if in a default colored description, the colored word or line begins with the desired new color, and at the end of the word or line, the color code for our default color {w for descriptions would be used by the builder after the fact.

Without going through and rewriting/recoloring EVERY colored description in the game along with rewriting the way color codes are handled, I see no way to do what you are suggesting.


David Haley said:
Hades_Kane said:
Is it feasible to allow customization of both the room title and the room description while also simultaneously accounting for the fact that (particularly in the case of the room description) that particular bits are highlighted for emphasis?

If emphasis is a universal concept, then sure, you could have "emphasis" as a color type. I would make the same argument that Deimos did, which is that if you want to highlight an exit in the room description, you'd use the exit type rather than a manual color override. If you wanted to identify outdoors and indoors, you could use colors for that too. (My game has the notion of day/night in/out, so you can pick colors for nighttime outdoors description elements, for example.).


Thing is, though, emphasis isn't a single color game wide, either, it's based on the preference of the builder describing the room, generally based on what other colors are in the room. For example, in a forest type of area, the descriptions might be dark green with the emphasis on a door to the north being in either dark yellow, bright yellow, or bright green. Emphasis on a city street for something worth noting might be bright white, dark or bright cyan, etc. Also the -thing- being emphasized would likely be colored depending on what it is. A fountain being emphasized would likely be a shade of blue, while a tree would be green, or raging fire bright red.

Short of rewriting a lot of code and subsequently a lot of descriptions, I see no feasible or "not that complicated" way to maintain the aspect of being able to emphasize in descriptions while also allowing players to customize the colors in which they display.

The other option, of stripping color codes and displaying the user defined preference, may allow the player to view titles and descriptions in their preference of color, but they are probably hindering themselves more in the long run by basically forcing themselves to be unable to quickly glance at a room to catch obvious details, and is one of the reasons why I feel like such an option would see such a tiny minority usage that I have trouble justifying spending any time on it. I may still add in a "lite color" option at some point down the road when I'm working on a "lite combat" option, but I don't really forsee it being used very much.

Quote
In my experience (playing and designing games) color customization is most important for things like fast-paced combat, where messages scroll by very quickly and you need to tell at a glance which messages you really need to care about, and which messages are less important.


It sounds like to me that a sensible default color scheme is the solution here, not necessarily allowing customization of the colors. At a glance, a player should be able to tell pretty quick when they've been hit and for how much, how much they've been hit and for how much, and perhaps same with allies. Being disarmed, blinded, dazed, knocked down, or any other condition in battle that has changed that should draw attention should also be easily identifiable as well.
21 Mar, 2012, Rarva.Riendf wrote in the 95th comment:
Votes: 0
Quote
Mind you, most descriptions aren't this colorful, but the Lope colour code that my game and many others use has no "close" on color tags

Guess that is why you are stuck. But that was a bad choice to begin with.
I see a way to modify that pretty easily though, remove ever {y that is at the start of a line, and replace all the others by a 'close' tag, then applying white before you send room text. Will need some hand correcting in some places for sure though.

Quote
It sounds like to me that a sensible default color scheme is the solution here, not necessarily allowing customization of the colors.

Tell me what you need I will tell you how to make without seem to be the only solution in this case for you and Deimos :)
I can see why you dont want to change it though now that you explained how your color are coded.
21 Mar, 2012, plamzi wrote in the 96th comment:
Votes: 0
David Haley said:
Plamzi, you should maybe look at context. You made a nonsensical or non sequitur statement (I'm still not sure what you were saying). So I gave you one in return. I had hoped that the sarcasm would be clear, especially given my preceding sentence, but, oh well. You gave a flippant response when I made the exact point you now say you've been making all along. Well, I don't really care… my point should be pretty clear to those interested in having the discussion. In the interests of preserving interesting discussion, I'll reply to you if you make points, rather than snipe at me.


Actually, anyone who knows how to roll back can see that you took the first snipe by calling something you only thought I was saying "silly". That's a straw man + ad hominem argument and doesn't move the discussion forward. When I pointed that out, your response was that I must be smoking weed. Given these reactions, it's hard to believe that you care for the quality of this discussion. It's also hard to believe that you're accusing me of sniping when you yourself have been far more acerbic.

After 7,834 posts, you should know that sarcasm in writing is tricky, and that adding a smiley at the end of an arrogant and abrasive post does not constitute "context". Like I said before, if you don't understand another person's comment fully, then maybe you should read it again. It's also wise to not address it at all, or to ask for clarifications. If you assume that anything you don't understand is "silly", you are doing the opposite of elevating the discussion, and you risk coming across as much more flippant than the person you're doing it to.

Not sure why I'm wasting my time giving you the 1001 on this because as far as I can tell you're aware of what you're doing–you just don't like being called on it.
21 Mar, 2012, Runter wrote in the 97th comment:
Votes: 0
Quote
After 7,834 posts,

Quote
Not sure why I'm wasting my time giving you the 1001 on this because as far as I can tell you're aware of what you're doing


lol. I too want to increase my post count. Let me in on this.
22 Mar, 2012, Hades_Kane wrote in the 98th comment:
Votes: 0
Runter said:
Quote
After 7,834 posts,

Quote
Not sure why I'm wasting my time giving you the 1001 on this because as far as I can tell you're aware of what you're doing


lol. I too want to increase my post count. Let me in on this.


I remember when I was on the top posters list for a little bit.
22 Mar, 2012, Chris Bailey wrote in the 99th comment:
Votes: 0
Anyone want to split everything that has been discussed since the OP to another thread? =P
22 Mar, 2012, Runter wrote in the 100th comment:
Votes: 0
100th
80.0/221