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.
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'. ;-)
Actually, while I was taking a break from this thread, I added an experimental feature–full game customization. Before he/she even begins character creation, the user is prompted to specify the game he/she would rather play. Upon receiving a response (it can be the name of a discontinued game, or simply a detailed description) the server generates a matching instance that fulfills all the requirements. The user is then prompted to accept or reject, and if they reject, they enter a simple wizard to recreate said game.
Initial response has been overwhelmingly positive. There are only a few small kinks to iron out, like e. g. getting people to play together.
P. S. This was very easy, 15-20 min. at most. Just use C.
Only in the mud community can there really be so much grand theatre and appeal to absurdity generated by the proposition that games with customizable interfaces colors aren't that bad.
Only in the mud community can there really be so much grand theatre and appeal to absurdity generated by the proposition that games with customizable interfaces colors aren't that bad.
Games with customizable colors aren't that bad…
unless they make you customize your colors in order to level up…
or, they make you customize by threatening to kill your family…
To players who want to customize the chat color on muds and be annoying at the same time to make a point:
Just make a macro that puts the color code in the chat channel before anything you say. Most muds let players insert arbitrary colors that EVERYONE is forced to see, but for some reason it's taboo to let you just configure stuff that's totally innocuous. Oh well. That's a lawlsy way to do it that will appeal the sensibilities of the people designing the color schemes in the first place.
27 Mar, 2012, Hades_Kane wrote in the 125th comment:
To players who want to customize the chat color on muds and be annoying at the same time to make a point:
Just make a macro that puts the color code in the chat channel before anything you say. Most muds let players insert arbitrary colors that EVERYONE is forced to see, but for some reason it's taboo to let you just configure stuff that's totally innocuous. Oh well. That's a lawlsy way to do it that will appeal the sensibilities of the people designing the color schemes in the first place.
Yeah, we have players that do that. I'm considering stripping all color codes from public channels as a result.
I'm considering stripping all color codes from public channels as a result.
Yeah, I did that ages ago. It got really annoying when some jokers decided to write scripts that interlaced all characters of channel text with random color codes. I've since decided that players can't be trusted with access to customize much of anything that can be viewed by other players.
27 Mar, 2012, Ssolvarain wrote in the 127th comment:
Most muds let players insert arbitrary colors that EVERYONE is forced to see,
That's always been one of the most obnoxious things I've ever seen. That and little tags they'll generally try to slip in there, too.
27 Mar, 2012, Hades_Kane wrote in the 128th comment:
Votes: 0
I've already disallowed the most obnoxious color codes from being usable in public channels, titles, etc. by players. I can see the use for occasional colored text in a public message, which is the main thing keeping me from disallowing all color for public like that, but when someone feels the need to change the color of every OOC message, it does get bothersome. Similar to the the topic being discussed here, because that isn't the color I'm used to seeing that channel in, my eye tends to filter it out as background noise and I often times miss what those players are saying.
I'm also, in general, hesitant to modify code just because I'm being anal about something like that which is relatively harmless.
I allowed players to use color codes anywhere they wanted… But they wouldn't appear for any other player at all. So stripped out for others, and functional for the person who used them. Which extended to pretty much anything the player did. Like naming their own equipment and color coding it like an idiot. There was a configuration for other players so that they could see colors by other players if they really wanted. The default for this option was off. I found this to be a reasonable policy since you don't have to worry about finding that new place where color codes are being abused. The setting was automatically this way for every new feature added.
I allowed players to use color codes anywhere they wanted… But they wouldn't appear for any other player at all. So stripped out for others, and functional for the person who used them. Which extended to pretty much anything the player did. Like naming their own equipment and color coding it like an idiot.
This is the approach I've started taking with some things. It's still a bit experimental, but I might expand it in the future.
Runter's method seems like the best compromise. Another method I've seen is limiting the number of color codes in a given command/line/whatever (e.g. can only use 1 color for public channels).
I actually find the arbitrary renaming of stuff more problematic than the colors, and I used the same system in dealing with that. Players could rename gear through a "dubbing" process that was basically an expensive way to modify an existing piece of gears name. Here are the three configurations.
low
Quote
a rusty sword [dubbed]
medium
Quote
a rusty sword dubbed, 'Rusty Nail'
high
Quote
Rusty Nail
So basically my approach in these things was to allow a personalized experience that didn't really compromise the game, and kept a lot of the nonsense and shenanigans to a minimum for people who didn't want that experience. So overall I don't think anyone will quit a game because there's customization even in unusual places as long as it's properly exposed to the player and the default is sensible. I do think players will quit your game if you have no sensible alternative to something wacky. Also the "play somewhere else if you don't like it" attitude isn't the best one to have when dealing with users of your software.
Furthermore, I think this type of configuration also makes it far less needed to start having to investigate all of the scams and what not going on to abuse a system like item renaming. Overall it removes the overwhelming need to police everything players do, like naming gear a certain way or making the colors such that players can't read their equipment. Etc
I actually find the arbitrary renaming of stuff more problematic than the colors, and I used the same system in dealing with that. Players could rename gear through a "dubbing" process that was basically an expensive way to modify an existing piece of gears name.
I agree completely. For the longest time I completely disallowed any type of renaming of equipment (all equipment in the game is crafted), because some player would invariably take 'an iron ringmail' and rename it to 'WeEd L0L'. I only recently created a 'recognize' skill, which allows arbitrary renaming of objects, but only displays the new name to the person who gave it that name. The configuration(s) allowing other players to opt into having those renames displayed to them isn't a bad idea. I might end up implementing that.
Runter's approach makes a lot of sense for any game that allow free-form item customization. I want to allow partial customization via certain crafts, and I also want part of the value of that craft to be creating something unique that you can show off to others (e. g. a weapon with a cool name whose stats people can wonder about) or remember an alt by (e. g. a special ring with the emblem of your first alt). So the "solipsistic" approach is not going to work for me, but it's a neat idea still.
Don't be afraid to let them show Your true colors Your true colors Are beautiful like a rainbow
28 Mar, 2012, Hades_Kane wrote in the 136th comment:
Votes: 0
Definitely a neat idea, but I have to wonder what the point is for customization if only the player customizing will see it? I understand Runter made it configurable so that others can decide whether they want to see what others customize, but for games that might allow channel coloration or restringing for only the people doing it. I would think a big part of the point of any of that is for others to see it, so I guess I'm not entirely seeing the allure here for the player doing it.
Definitely a neat idea, but I have to wonder what the point is for customization if only the player customizing will see it? I understand Runter made it configurable so that others can decide whether they want to see what others customize, but for games that might allow channel coloration or restringing for only the people doing it. I would think a big part of the point of any of that is for others to see it, so I guess I'm not entirely seeing the allure here for the player doing it.
Actually, there are a number of good reasons. In the case of the equipment restringing, let's say that the player has crafted three identical pieces all named "an iron ringmail". By allowing customization that only the individual player can see, those iron ringmails can be uniquely renamed, such that each is easily addressable, without fear of breaking immersion for others. Otherwise, the player would have to resort to awkward syntax for addressing a specific ringmail of the three.
28 Mar, 2012, David Haley wrote in the 138th comment:
Votes: 0
plamzi said:
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?
Technically, it's the same task – once you have a map to pass color types through for color codes, ten or one thousand color codes is the same amount of implementation.
Of course it depends on how complex your (non-customizable) color schemes are in the first place. For some games, "every single bit of color" isn't that much. For other games, "every single bit of color" could be thousands upon thousands of color types. I don't have hard data on this, but I'd venture to guess that the latter kind of game is more rare.
The point being: this is not a hard problem to solve in terms of implementation.
plamzi said:
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.
Sure… you might not satisfy everybody 100%. What bothers me about what you're saying is that it sounds like your reasoning is: "we can't please everybody, so why bother?" It also bothers me that you ascribing a very large number of hours when really, I'd be skeptical that it would/should take that long.
You know, honestly, if this was something that would take you a hundred hours to implement, then I might actually agree that it's not worth your time. I just am highly skeptical that it would actually be 100 hours – that's over 12 full-time work days.
Also, for what it's worth, I didn't say this was the highest-impact feature a game could possibly add.
plamzi said:
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.
I didn't say this. I said that I would rather be able to remap colors.
I wouldn't consider a game very seriously if it had rainbow barf colors, whether or not it let me change them, because IMO that says something about the game's general culture and that is not a fit for me.
plamzi said:
So whether that game has the customization you're advocating or not is completely moot to them.
To those people you described, sure.
My point is that lacking customization can frustrate some people. But adding customization won't frustrate people, and will make some happy. They might not be completely happy with the customization, or they might not care at all, but they won't quit because of customization.
plamzi said:
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.
I find it slightly offensive to phrase an obvious statement in a somewhat adversarial form. It would be brain-dead to disagree with the statement that out-of-the-box ease of use is always a good thing to have. Again, I never disagreed with the statement that having a good default is always a good thing.
plamzi said:
Suggesting that individual preferences vary a lot and that you'll never please everyone?
No, obviously individual preferences vary. That's a given. I thought it was a poor position because it is essentially saying that it's not worth bothering because you won't please everybody. It's a grey line fallacy of sorts, if you will.
The point is not to see if you will please everybody; the point is whether you will please enough people to make it worth it. As I said above, the only true cost to customization is the time it takes to implement it (which isn't much) – it won't turn people off if there is an option somewhere to change the colors.
So, I thought it was kind of silly (and a little offensive, to be honest) to say something utterly obvious as if it was making an important point: we all already know that you won't please everybody 100% in all cases, but that was never the question. My point is and always has been that this is not a difficult feature to add, can give huge payoff to some people with very little work, and is not a feature that will turn people off (unless you stuff it down their throats or something – within reason, etc., as usual).
(As a note, if I'm telling you what I found offensive, it is in the interests of clear communication, not assigning blame.)
Hades_Kane said:
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.
To be honest, I'm not sure why you're saying this. It sounds to me like you just agreed that customization for playability's sake is good. I don't think anybody here has been advocating for color customization as an aesthetic alternative; it's always been about highlighting information for quicker/more efficient visual parsing of data.
Hades_Kane said:
I'm considering stripping all color codes from public channels as a result.
In the vast majority of cases, we don't allow any player-generated color at all, anywhere, anytime. Any use of player color, in things like titles or restrings (vanity names) on items has to be imm-approved.
30 Mar, 2012, Chris Bailey wrote in the 139th comment:
Votes: 0
I was adjusting the way I colorize some information by default and decided to go ahead and add color customization for players. It took me about an hour and I ended up with several bits of information that can be customized. Standard things like room names, room descriptions, exits, players, npcs, objects, ships, and some slightly different things like grouped, friendly, and hostile players. I believe the interface is fairly straightforward and shouldn't be difficult to use even for casual and novice players. Examples - colorset friendlyplayers green, colorset roomdesc cyan. Anyhow, the whole thing was pretty simple and got me to add flagging of players as friendly and hostile which I had been meaning to do.
30 Mar, 2012, Hades_Kane wrote in the 140th comment:
Votes: 0
I wish I could get some discussion this lengthy on one of my ads for my game :p
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.
So, at what point does time investment become a rather absurd reason not to do it? Just sayin'. ;-)
Actually, while I was taking a break from this thread, I added an experimental feature–full game customization. Before he/she even begins character creation, the user is prompted to specify the game he/she would rather play. Upon receiving a response (it can be the name of a discontinued game, or simply a detailed description) the server generates a matching instance that fulfills all the requirements. The user is then prompted to accept or reject, and if they reject, they enter a simple wizard to recreate said game.
Initial response has been overwhelmingly positive. There are only a few small kinks to iron out, like e. g. getting people to play together.
P. S. This was very easy, 15-20 min. at most. Just use C.