Exactly. It's less trivial than you've been making it out to be.


That is just your opinion, though. You're welcome to have that opinion. Don't assume it's more than an opinion.


I always had a base. You just baselessly assumed that my assumption was baseless. Also, that's twice you've misspelled my name now.


I started out reading this thread with the assumption that the discussion pertained to mapping colors to types. That seemed to get dismissed after the arguments about quantity of types. That's when I switched to assuming the discussion pertained to mapping colors to colors. And yes, it did seem exceedingly dumb. Still, even when we go back to colors to types, my same basic issue holds. If we use my room titles example where color is differentiated by plane of existence, and may also contain other color representing additional information - we end up requiring a non-trivial amount of logic and seven (unless we're only allowing selection between preset color themes) different user configuration settings just for room titles. That's a lot for one type, and I'm not even sure I'd consider it an edge case. HK already touched on this some, and so did you - it gets complex quickly.

On another topic, I think the biggest issue in this thread is the misleading nature of the word "full", as it has been applied to color customization. When I see the word "full", I interpret it as giving the ability for players to fully customize every instance of color in the entire game UI. Obviously, that will produce an unwieldy UI just for configuring the colors, unless we're talking about a very simple game and/or one with sparse color. It seems that the scope of the color customization we're discussing is slowly being dialed back now. So, where exactly do we draw the line between what IS being discussed and something simple like 'color <off/minimum/standard/maximum>'?


Something is core or essential the moment you decide it is. I typically decide that about most things, as I'm always looking for ways to more deeply integrate new features. My weather system is something I used to consider core and essential - it was one of the first major systems written for my game (early 2002). However, the weather code hasn't been touched since then; so, it is now outdated and has a much smaller impact on the game world than I would like. It must be rewritten (in 2-3 years when I reach that point on the list)!!

One could take a sections like this:

"{RH{rot {RL{rava"

which in the diku world is different shades of red and determine that for any room name they want to use the color… cyan.

And process that string such that it can find the new distance away that {R and {r should be from cyan assuming that {R {r are a certain distance away from white. So I think it's not at all a deal breaker to say that if a part that you want to customize on the client has different embedded colors in it that you will have to disregard them. Even if we had markup which clearly told us this is a room name, we very well may have the same problem if it contains more complex markup like spans. It is solvable and relatively easy math can get you the answer. The main issue is that the colors may correspond to something particular. Like fire is red, ice is blue. But the builders intentions there is unknowable. Even in the case of markup there should need to be included an attribute to denote that a certain span is literal and should not be modified by client. "This element should always be red for best experience" type of semantic.

TLDR
In general with wacky colors, you can change the base color of the text with the assumption white was the natural base and let all of the wacky colors that are embedded combine with the new base color. The results could be good, especially if the colors are just being used for distinguishing parts of text within text.

def mix(color1, color2, weight = Number.new(50))
  assert_type color1, :Color
  assert_type color2, :Color
  assert_type weight, :Number

  unless (0..100).include?(weight.value)
    raise ArgumentError.new("Weight #{weight} must be between 0% and 100%")
  end

  # This algorithm factors in both the user-provided weight
  # and the difference between the alpha values of the two colors
  # to decide how to perform the weighted average of the two RGB values.
  #
  # It works by first normalizing both parameters to be within [-1, 1],
  # where 1 indicates "only use color1", -1 indicates "only use color 0",
  # and all values in between indicated a proportionately weighted average.
  #
  # Once we have the normalized variables w and a,
  # we apply the formula (w + a)/(1 + w*a)
  # to get the combined weight (in [-1, 1]) of color1.
  # This formula has two especially nice properties:
  #
  #   * When either w or a are -1 or 1, the combined weight is also that number
  #     (cases where w * a == -1 are undefined, and handled as a special case).
  #
  #   * When a is 0, the combined weight is w, and vice versa
  #
  # Finally, the weight of color1 is renormalized to be within [0, 1]
  # and the weight of color2 is given by 1 minus the weight of color1.
  p = (weight.value/100.0).to_f
  w = p*2 - 1
  a = color1.alpha - color2.alpha

  w1 = (((w * a == -1) ? w : (w + a)/(1 + w*a)) + 1)/2.0
  w2 = 1 - w1

  rgb = color1.rgb.zip(color2.rgb).map {|v1, v2| v1*w1 + v2*w2}
  alpha = color1.alpha*p + color2.alpha*(1-p)
  Color.new(rgb + [alpha])
end

@Lyanic: It's trivial for the vast majority of MUDs, because they have {YRoomNames, not {YRoom{GNames. That said, it's still possible to allow custom palettes by abstracting your hard-coded colors into a map. You just lose the structure, and have to come up with abstract settings like "emphasis" instead of familiar things like "exits".

And thank you, but I'm fully aware that that was my opinion, which is why I used such terms as "personally" and "IMO" (in my opinion) back-to-back. Did I not do a good enough job disclaiming it to make you feel the need to reemphasize it? Next time I'll try bolding it as well…

No, sorry. Assumptions are, by definition, baseless (it was rather redundant of me to use both in concert). And I made no such assumption. You explicitly told us that you were merely operating on a hunch at that point.

Just to point out, pretty much every MUD I've ever played save for maybe 2 have a habit of multi colored room names or different colors used in descriptions for different reasons.

I think we have reached a point in the discussion where the assertion that it would be easy or trivial for MUDs to allow their players to easily customize their colors is passed.

With that said, it then becomes a question of is the work worth the payoff, which from the outset I have asserted that I don't feel that it is, but perhaps offering a mid point between full color and no color might be.

Color is a sensitive topic. :-/

Ha Tyche, it is indeed :P

No, you just assume it's the "vast majority" of MUDs, because the select group of MUDs you've chosen to play have followed that scheme. I second HK's assertion that most MUDs I've played utilize schemes with more colors.


I wouldn't need to emphasize it if you didn't make the habit of assuming that your opinion is shared by the majority and needs to be forced upon the minority. You have a rather nasty habit of that, which I've seen crop up in a couple threads now since your recent return.


Except the thing we're talking about (whether !requested == !popular) was not something I used the words "assumption" or "hunch" regarding. I asserted my point, and gave supporting reasons. You're the one who called it a "baseless assumption", simply because you disagree with it. Besides, I think you're getting mixed up about which thing you're even talking about now. Maybe that wouldn't happen so easily if you learned to use the quote tags properly.

Plamzi, the big difference is that while I thought, and still think (given no clarification on your part despite repeated attempts to engage), that your position was ill-founded, I did you the courtesy of explaining why and attempting to engage in a discussion so that we could all hopefully learn something. If you want to talk, let's talk. Given the way I'm explaining myself to people actually talking to me, I think it's pretty clear that this is a discussion I'm interested in having, and I'm not sure why you feel remotely reasonable saying that I'm not interested in having a real conversation. :shrug:


Sure. But I don't see any of this as really being a problem. It comes down to design decisions. If you want a game in which things like this happen, maybe you shouldn't customize room descriptions.

I'm not sure why this is being perceived as an all-or-nothing affair. When I say "customize colors", why does that mean customize absolutely everything? As I've said several times, you can get great returns for even simple color customizations. If you don't want to customize your room descriptions because you have things like you just described, then great! That's not a problem. You can allow other customizations, e.g., combat messages.


FWIW I don't see this feature as being terribly interesting at all. This kind of semantic-ignoring customization can be done more reasonably client-side, if I really want to remove your colors.


I've never argued against having a sensible default color scheme. Arguing against such a thing would be kind of brain-dead, along the lines of arguing against having a functioning motor for the car you want to drive.


Yes, of course. This is exactly the kind of thing I'm talking about. And this is where color customization can become very important; perhaps your sensible color scheme makes sense to you, but it doesn't for me. Perhaps I'm used to seeing my attack messages in red and yours in blue, and it really messes with my ability to parse things to have all colors be different.


Just so we're all clear, the difficulty here isn't technical, but in presenting a good interface to the user to manage customization. (The "user" here could be the player or the builder. If you have 1,000 color types, it will be difficult for the builder to deal with it all.)


As far as I'm concerned this has always been what I have been discussing. Too many types being bad doesn't mean that the idea of types is bad. Like you said, just remapping colors seems kind of dumb. :wink:


Not really, at least not from my perspective. For some games, I would argue that full color customization is exactly what you want. For other games, where you use freeform color as an almost artistic expression (which is what HK is talking about with his builders picking color schemes for his areas) then it makes less sense to customize the artistic expression.

@Lyanic: I have no such habit, and have no idea why you seem to like to read between the lines of people's posts and inject whatever thoughts and opinions best suit your argument at the time, instead of asking for clarification. I can only be held responsible for what I say; not for what you hear.

With respect to how I post, as far as not using quote tags - if you bothered reading my posts, instead if searching so hard for building materials for your next straw man, you'd have caught the fact that I post from a phone. I have neither the patience, nor the time to fumble around with copy/pasting on a touchscreen and don't particularly care if you can't remember what you said to me in your last post well enough to understand my replies.

And on the topic of baselessness, you said it was a hunch, and I know exactly what I'm talking about. Whether you had reasons for your hunch or not is completely irrelevant to the fact that it was just a hunch, with no evidence backing it. Hence, baseless.

As for the topic at hand, I think I've made my opinion on the matter abundantly clear, and don't wish to muddy the waters bickering with you any longer, so I'm done with this conversation. Have the last word if you wish.

I'm not reading between any lines or injecting any thoughts. You're fairly explicit about the fact that you have X opinion, X is the correct opinion to have and any opinion !X is obviously wrong.


It is your choice to post from a phone, but you don't get to use it as an excuse when it starts impacting your ability to interact. I have no trouble remembering what I last wrote/what you're replying to. I suggested that YOU have trouble keeping up with that information. Your reply here only reinforces that hypothesis. Otherwise, I have to assume your reading comprehension abilities are sorely lacking. Also, WHAT STRAWMAN!? I have not misrepresented your position to support any arguments.


I never once said it was a hunch. I never said anything remotely synonymous to "hunch" regarding that. I even addressed this already! Are you getting my posts mixed up with HK's, perchance?


Ok, so we're roughly in agreement at this point.

Welcome to MudBytes :)

I find that taking a few weeks off after a thread like this one does wonders to repair my nerves. Take lots of walks, stare at greenery, meditate on life. After such a hiatus, I am able to take up to a month of:

A. I have X opinion, X is the correct opinion to have and any opinion !X is obviously wrong.

B. You have X opinion which I didn't read carefully / didn't understand. So I'm going to pretend you said something stupid and patronize you.

C. You tell me you've experienced X, but I haven't, so you must be smoking something.

D. I haven't played your game, but I can speak on behalf of all your players and say that you're really messing it up.

E. My codebase / custom code is so much superior to yours that only someone with an amoeba brain (e. g. you) can think otherwise.

F. Observing a reverse correlation between those people actually having a conversation, and those people bemoaning the lack of conversation.

:wink:

Oh, I know. Your reasons are but a few of why I don't comment on MUDBytes nearly as often as I used to.

You forgot this one on your list:

G. Your list of things isn't right because you forgot one…

Hate when people do that especially.

DH,

You say you want to have a discussion. I'll take you up on it. Let's see if we can back up a bit, filter out all the ad hominem's, and address the substance of each other's points:



As I think many people here will agree, it's easy to add basic customization and hard to add complete customization. Nothing in your posts so far indicates that you're arguing for basic customization. Even if you're trying to say that the stuff many people here find involved is easy for you to do, please allow others do make their own estimates on how much time it would take them. Agreed?



Here's one of those instances where you lift half a sentence to construct a straw man (I've added the missing parts).

If you wade through any of the hundreds of threads regarding "features I like/dislike", the only consistent theme is that for anyone posting that they hate such and such, there's another person posting that they love exactly that. In the case of offering extensive event color customization, it's not a simple love/hate thing. No-one is going to hate having this high-end feature in-game (most likely they'll just never use it). But is anyone at all going to love it? I imagine a case where I spend 100 hours allowing you to customize every event I can think of. I then imagine you logging into my game and saying (right before you quit), "Why can't I group such and such events together and set a color for all of them? It's such a waste of time having to do this for each event." So I just spent 100 hours trying to guess what you'd want to customize and how, and I still didn't get it right.

Again, no-one here is arguing that offering full color customization is a terrible idea. What I and others have been questioning repeatedly is the value of investing many hours into it, hours that can be invested into developing other features or content that may appeal to a much wider audience than that. I believe that any hour spent on designing a good default color theme equals ten hours spent on allowing end user customization. Even if you base your "empirical evidence" only on opinions voiced in this thread, you'll see that this is far from being a foolish belief. As far as I can tell, you are the only one who has shared that they will quit a game if it doesn't let you remap the color of individual events. Several other people have said that they'll quit the game as soon as they see a default color scheme they don't like. So whether that game has the customization you're advocating or not is completely moot to them. Simply put, I believe the empirical evidence suggests that most people will quit a game rather than look for whether it supplies a power user with server-side tools to "fix" it. I extend this belief to all usability features in my game–I value out-of-the-box easy-to-use over arcane-power-user code-your-own. But this is just my philosophy, and my game aims to appeal to casual non-mudders, so you're allowed to disagree completely.




What exactly was silly about my statement? Suggesting that individual preferences vary a lot and that you'll never please everyone? And how exactly does your personal opinion counter this point? Isn't that like believing you can speak for everyone?

Discuss.

I must read it wrong then, but I think most agree that offering customizatin of borders [hades kane] is not really wanted in the first place.
There is a difference between allowing a door to be of a player customized color, and allowing every kind of possible door to be colored depending on the sector the area is in. ( and I find that a bad idea in the first place, as it gives no useful information, and changing text depending on sector as well, it makes the mud a rainbow barfing pool of colors)
It is not about trying to guess what players would want to configure, but about what is common sense.
Having a fast way to see what are exits, what are mobiles (that include players) an what are objects is a basic that I await from every mud. I like the color I am used to and will not play a mud if I have to concentrate to get those simple infos from the text when a basic color could give them away.
The time to implement that may vary depending on how you decided to deal with colors, but that is another problem. Still is a trivial job you can progressively implement when you are stuck on something else. It really is a no brainer job.

This simply boils down a good point as well that many people make time again over many different aspects of MUDing… People get used to something, and anything different from that won't do. People spend probably 95% of their MUDing life either trying to find (or make) a game that reminds them of their first/favorite MUD.

If someone won't play my MUD because the colors aren't what they are used to, I have no doubt there will be easily a dozen other things about my game that isn't what they are used to that will keep them from playing. I find little incentive to spend a good bit of my time working to make my game have the ability for players to make it look/play/feel like someone else's MUD… You'll never manage to succeed in trying to do that, and as soon as you please one group another will be unhappy with it, and that's kind of a slippery slope.

Increasing the functionality of a color scheme is a bit different. Having an option to either customize or further highlight critical information, or reduce the presence of non critical information, is a matter of play-ability more than anything, but trying to appeal simply to someone's aesthetic preference isn't something I find to be worth spending any notable amount of time on.

Well put. We recently spent a good amount of time allowing users to customize their event filters to reduce spam and allow them to focus on what's important (to them). I can easily see us spending some time allowing users to highlight what's important, maybe not by selecting what exact color it will be in, but whether it will stand out in some way from what's around it, produce a ding, etc. That's time well-spent.

You just missed everything I said: I dont care about your color, I can change them, I care about a way to have my color scheme. If you do not provide a way to change them it is a problem not because of the color, but because I am unable to use the same pattern to retrieve the info I need to play from your mud.
Hell I do not even use telnet colors on my own mud. (or any others I eve played) as I redefine them in my client (green is yellow, stuff like that…) So it is nt even related to th emud I play.

Judging by the length of both the thread and the individual posts therein, I'd say regardless of how much time you all think it may take you to individually implement customizable colors in your respective games, you've likely either already surpassed that amount or are fast approaching it simply by reading and responding about it over the last week.

So, at what point does time investment become a rather absurd reason not to do it? Just sayin'. ;-)