well, as just an observer, it's wandered a little afield…

Well, finally we got beyond the silly name-calling–that's good.



I'm not sure why you're so bothered by my own estimates given that I know much more about my own game and myself than you do.

For instance, as a CircleMUD-based game that traditionally has used color pretty extensively, we're in the hundreds upon hundreds range, and our outputs to user are scattered across all of the code files, with very few points where you can intercept entire event categories.

Also, let's not forget that when you allow the customization of, say 50, event types, you'll need to store and allow the user to update 50 individual preference items. And what about hundreds upon hundreds of individual pref flags? (I imagine each of those flags can store something much more influential than whether your healing spells will be shown in cyan or magenta.)

Finally, if I'm going to do something, I know I will want to do it right.

So believe me when I say that *for us* this will be a hard problem. I'm not saying this to diss your overall point, but to provide a counterpoint to your "it's easy" argument. It is possible for this to be very easy for you and your game, and very difficult for mine. Given how clear I am that this is hard (for me), if you try to tell me how easy it should be (for me), then I might infer that you're trying to insult my coding skills.



I think what you're missing while feeling offended is the keyword "value". The fact that I place more value on the default color scheme means that if I have a spare hour and I need to decide where to invest it, I would invest it into color design and not into color customization. That's all. It doesn't mean that I find color customization stupid, just much less important to have.



My game is at a point where I have a mile-long list of things that I *know* will please nearly everybody. Putting time into a feature to see if someone will use it at some point is not something I can afford. Please don't be offended by that.



I think what ticked you off is that I took your initial comment as one of those LFM posts where the user claims that they love everything about such and such MUD except that there are elves, or everything about such and such MUD except the room descriptions have too much blue in them. You and I know that what most of those folks are really looking for is to re-visit the excitement of their first MUD, and that there really is no pleasing them. I usually try to counterpoint with something like what HK has been saying–that if you don't like the blue, and I code something to let you customize it, you'll still quit over the next thing. I don't say that to offend you personally but to try and benefit the community. I think especially new MUD devs can waste a lot of cycles trying to cater to LFM posts and they might forget their overall game design in the process.

We'll have to agree to disagree about the value and effort involved in what you're suggesting. I hope that's OK.

The most difficult (read: irritating) part for me was chasing down all the places that color was used. Mapping colors like "red" and "green" to the color codes I use was trivial and took less than five minutes. I can see how frustrating it might be to implement if you have extensive content with color spread throughout it though.

The fundamental disagreement here is that about whether or not it is a lot of work, hard, etc to implement color customizations or not. If you can't come to an agreement on that, then there's absolutely no way you would be able to come to an agreement about whether or not it's worth it.

It would be like arguing about if it's worth it to buy a stick of gum. Where DH is telling you it's just 10 cents, and Plamzi is saying it costs 10 dollars. Users can make up their own mind if this proverbial stick of gum actually is 10 cents or 10 dollars. I actually think it's closer to 10 cents. Ergo, fairly easy. At face value it's just a lot of boiler plate. The logic is very simple.

Well, to be honest, the basic structure for color customization should be able to be done in < 1 hour in any sane codebase. This much is pretty indisputable. It's then up to the developer(s) to decide at what level they want the customization to be integrated. By this, I mean it's trivial to make just room names customizable; but, if you want to make 100 some different elements customizable, then sure, depending on your code, it could take quite a while.

Not everything has to be customizable just because it's colored, though. You can find a small subset of basic elements and start with that. Your players might ask you here and there to add customization for X element, but since the structure is already in place, it might only take 5 mins a pop.

Because I'm talking about people in general, not just you.


We already discussed how you can get considerable gain without customizing every single color absolutely everywhere.


As above, we're not necessarily talking about hundreds of customization option. You seem to be introducing this as a reason why something is hard, but you're not talking about the same something.


Without insulting your coding skills, you said yourself you were a hobbyist. Of course, most MUD coders are, so I am of course saying that this is not a hard task at the hobbyist level, so no insult is meant to coding skills.

What I am saying, however, is that you're making this problem harder than I was, and I've been pretty clear with what I think is easy. If you want to push that to something far, far bigger and harder, then yes, of course, it becomes more complex.

Deimos put it in just one sentence:
"Well, to be honest, the basic structure for color customization should be able to be done in < 1 hour in any sane codebase."

Alternatively:
"Not everything has to be customizable just because it's colored, though. You can find a small subset of basic elements and start with that. Your players might ask you here and there to add customization for X element, but since the structure is already in place, it might only take 5 mins a pop."


As I said, it wasn't your preference that bothered me, but how you chose to phrase it. As I said, you made a tautological statement, but phrased it as something I might disagree with entirely. In other words, what was offensive was to rhetorically push me into some corner of disagreement with a basically indisputable statement.


Again, the issue was that you are making it out to be that I disagree with the indisputable statement that preferences vary.


I gotta admit I'm not sure what post you're referring to. :smile:


Yep, agreed.


This statement makes sense if all the players you're talking about have that attitude of quitting immediately when they see some thing. Surely not all players are like that? Is that really what we're saying about players?


Of course it's ok to disagree. :smile: What bothers me is when you disagree with something I didn't suggest, or you take some extreme version of it and disagree with that, ignoring the substantive bulk of the suggestion.

And again, I have no interest in convincing you what to do with your particular MUD; I am making only general statements.

I agree. The only sane codebases I know of are the ones written from scratch and maintained by one single person. Ours ain't :(



I was referring to the post that started this digression:


The implication was that all MUDs should. I replied with some of the reasons why some MUDs may not have that feature. Then all hell broke loose…



It seems to me that the players who are not like that are not the players who start an LFM every few months. So, to me, there is much more value in observing people in-game than in reading and acting upon LFM posts.

On the other hand, it seems to me that the people who start LFM posts are exactly the people who would quit over any one of a thousand things my game doesn't have. So I rarely do more about it than browse.





Straw men are very annoying, agreed, and if you saw one in what I posted, then I apologize. I think I've pointed out in multiple places already why this feature rates low in my book and why it might rate higher in other people's. I've repeatedly pointed out what makes my case ($10, as per Runter) special. All this was in response to your initial statement, which was a blanket one, and implied that all MUDs should place a lot of value on this feature. If mine is any indication, I don't think all MUDs should.

But if you feel different, that's fine–we can still have a beer sometime.

I don't think the conversation has anything to do with how easy or hard something is in your (admittedly not sane?) codebase. It's how easy or hard it is to do as a general programming technique or pattern assuming other factors are reasonable. Like you're not writing your code in lolcode. So it looks like you agree that it should be easy given no unreasonable factors as a general design decision.

Honestly, I have zero interest in discussing general programming techniques or how easy everything should be. If I can't share my experience here, then I'd rather go get some stuff done.

That's fine, but it seems like people got heated up in this thread while arguing two different things. It's impossible to have a debate if you can't actually grant certain things and talk about the same thing, at least in turn.

I think that's a fair point. Discussing the theoretical difficulty of the problem is mostly irrelevant within the context of advocating implementation on codebases that are in use out in the wild. As we all know, 90%+ of the MUD codebases in use are not "sane" (to keep up with the terminology we've got going here). Therefore, the actual difficulty of implementation would be much higher in practice.

I guess my codebase is sane (in some regards) because implementing this was cake.

I like cake.

If you cannot implement something like color on object (structure whatever) type easily, it means that you already have a bigger problem than implementing new (and more complex) features anyway.

I admit I did it in a pretty hackish way, but it was quick and easy.

First, I just added some persistent data to players to save their color preferences. I just use the actual color tag that will be inserted into the text.

@color_set ||= {
      :chat       => '#y',
      :chatname   => '#Y',
      :say        => '#c',
      :sayname    => '#C',
      :player     => '#R',
      :playername => '#R',
      :npc        => '#c',
      :ship       => '#y',
      :shipname   => '#Y',
      :roomname   => '#C',
      :roomdesc   => '#c',
      :roomenter  => '#r',
      :exits      => '#G',
      }

Then I made a simple map between color names and color codes to simplify things on the player end.

$colorset_table = {
  :red        => '#R',
  :darkred    => '#r',
  :blue       => '#B',
  :darkblue   => '#b',
  :green      => '#G',
  :darkgreen  => '#g',
  :cyan       => '#C',
  :darkcyan   => '#c',
  :purple     => '#P',
  :darkpurple => '#p',
  :white      => '#W',
  :grey       => '#D',
  :darkgrey   => '#w',
  :black      => '#d',
}

After that it was just a matter of modifying a couple things that insert color to use the color tag from the players colorset data instead of manually writing it in. The default color scheme is set up in the colorset preferences of each new players. When a player inputs "colorset chat red" I pull out the color, downcase it and convert it to a symbol, and update the color in their preferences if it matches a key in the previous table. Maybe it was just easy because I'm missing some critical component.

I think a relatively basic level of color customization would likely be easy across all codebases. I'm not sure that's in question and I think the ambiguity of "full" color customization has been part of the impasse overall. You've done what I would consider basic color customization (which DavidHaley, I want to say, has been pushing for at least that, declaring that even at a base level, it would be a big improvement).

Plamzi, myself, and others, if I may attempt to lump our collective concerns into one, is that when you get to where you are trying to account for a wider variety of color modifications, from things like reskinning the color theme of your score sheet, who list, etc. along with individual events within combat that people would like to highlight (things such as being disarmed, blinded, etc) that the level of what goes into can drastically increase if you are attempting to be consistent among what is allowed to be colored. As an example, the messaging for being disarmed may be in a completely different function and part of the code versus what you may see when getting the message of being blinded. If you are customizing those two events, then it stands to reason and follow that any "significant" event within combat that should draw a player's attention needs to be customized as well (at least in my opinion, only allowing customized highlighting of a few out of potentially dozens of highlight worthy events in combat would seem lazy, sloppy, and half-assed). When you start going that route, you have a lot more work on your hands. Then as has been discussed, you set color preferences for room title and description (as you have done) and that brings up the concerns of how you handle highlighted information (often times conditional on what is being highlighted, what type of sector, or some cases what plane you are in).

That, at least, is what I would call a summation of the concerns being drawn in the "it's a lot of work" camp.

Most of us are hobbyists, and for most of us, if the idea of color customization wasn't a concern at the beginning, and we have years worth of designing the game and its areas, shoehorning the system into the game can be quite a bit more work than what others may think, particular for those of us that has preferred utilizing color throughout the various menus and display parts of the game along with the areas.

Like myself, many of others have also "inherited" the code we are working with, with sometimes multiple coders having been in there since the base was built up from Stock, and many of us having worked alongside other coders as well. I learned "on the job" as it were, and so while my game is functional, relatively free of bugs, crashes, and freezes, the code itself is a bit of a mess.

I'll concede that it could be time consuming in a scattered codebase and extremely difficult if your game doesn't lend itself to color customization. It will of course require more time as you add to the list of things that can be customized, but I don't see it as being more difficult. I added (and later removed) the ability to color other players based on their status as friendly/hostile/grouped and it was really no different than room descriptions. I'm not really arguing one way or the other because I have no way of knowing what it would be like to implement in a system I haven't seen. I just wanted to share my personal experience with adding some basic color customization.

You still don't seem to get it. Yes, 90%+ MUD codebases (AberMUD derived) in use fall into the realm where implementing more than a very basic level of color customization is a lot of work. I think your notion that this makes them inherently bad codebases is somewhat flawed. I imagine that if given access to your code, I could find a number of features I consider trivial, which would be a lot of work for you to implement. That is often the case when something isn't designed into the system from the beginning.


Well said. I award you the gold star for Best Post in Thread.


I, too, like cake.

I don't like cake, and none of you will convince me that you should be eating it. >:)

I disagree, a sane code would separate how an object is displayed from how it is manipulated. It is a basic programming pattern.
The code displaying an object in any situation should be easy enough to isolate (thus color configuration should not mean changing code all over the place). Everything else is quite unsane and a nightmare to maintain because everytime you want to add a new action it means that you will have to go in many places to display this new action.