Lyanic's claim is that, given what we *know*, we can assume more MUDs are going to find this difficult than easy. Of course, that's not a fact, but rather an assumption, but one that I find safe to make given what I know.

Your position is to make it seem like we know nothing and should therefore assume nothing. You're also trying to make it sound like Lyanic said *all* MUDs would find it hard, so that providing even one use case to the contrary can topple his argument. That was the straw man, and I will call it out as many times as I see it. Stop doing it and I'll stop bringing it up–easy.

You can start debating by showing that:

1. Most MUDs are not Dikurivatives.
and / or
2. Most Dikurivative codebases already make implementation of this easy
and / or
3. Most MUD admins have already made such changes to their Dikurivative codebase as to make it easy to implement this exact feature.

If you can't supply evidence to back up either of these, then I'd say Lyanic's claim is very likely to be true, given that:

1. The *vast* majority of MUDs are recognizably Dikurivatives, and it is known that in that codebase comprehensive color customization is hard due to some very early choices. (plenty of evidence for both)
and
2. There are thousands of things to do on a game, and it's hard to believe that 50%+ admins began by rewriting the event output code. (just the fact there's no snippet for it is enough to convince me that the majority of Dikurivatives did not do such a rewrite)

There is no fallacy at play here. There is something called "experience". I have been around the MUD community for a long time. I know the demographic breakdown of MUD codebases in use. I know what those stock codebases look like. I know the approximate amount of time it would take me, a reasonably skilled programmer, to implement full/event based color customization in those codebases. I know that most MUD creators who start work on stock codebases are less skilled programmers than I am - I've had conversations with hundreds of them over the years, and I've read and replied to their pleas for help on the various MUD fora. I know that most MUD projects end up failing and being abandoned. I know that most running MUDs that started as stock codebases do not deviate significantly at the UI level, and something can be said for the underlying infrastructure, as well - simply logging on and observing is sufficient to tell.

Given all that I know, it's awfully presumptuous of you to state that I have no knowledge whatsoever. It also seems that I'm not talking about a small subset, rather a large one. There is one piece of my argument missing, though. Do I know that most creators of MUDs based on stock codebases HAVEN'T refactored their code to make it easier to add full/event based color customization? No. You're right, I don't know that. I am only assuming it. Still, if I were a gambling man, I'd be willing to bet my life, soul and unborn children that < 5% of them have.


That's rich, since I called you out for misusing "strawman" earlier in the thread. Since plamzi appears to be using it correctly, at least in this case (I'm too lazy to re-read plamziHaley Debate 2012), that makes twice that you've misapplied it. Perhaps you should spend some time on The Google.


Thanks for the assist and camaraderie. Sometimes it gets lonely on threads like these, where certain people, who shall remain nameless, seem willing to argue over something as simple as the definition of the word "and".

@plamzi: You're reusing the "if you can't demonstrate X to be false, then it must be true" fallacy. I'm not buying it. Like I pointed out, it's a ridiculous assumption to make that "most games I'm aware of are barely modified Dikurivitives, therefor most all MUDs are barely modified Dikutivitives".

Not only is it conceptually fallacious, but I find the premise hard to believe for many reasons: If you can make such assumptions, then I feel it's safe to make the following assumptions:

1) Most players dislike playing stock or close to stock Dikurivitives.
2) Most stock Dikurivitives therefor do not fare well.
3) Most admins tend not to keep their game active if nobody plays it.
4) Since nobody plays stock Dikurivitives, such games tend not to last very long.
5) Since there's nothing to do on a stock Dikurivitive with no players except to modify the codebase, such games must either not qualify as near-stock Dikutivitives any longer, or cease to exist altogether and must be left out of the equation.

Given these just-as-safe assumptions, I would make the argument that, no, 90% of active MUDs are not slightly modified Dikurivitives. They are either greatly modified Dikurivitives, or not Dikurivitives at all.

And, to steal a page from your playbook, "if you can't prove this wrong, then it must be right."

Have a great Easter!

I don't really care about the debate, however, most muds listed at TMC are not Dikurivatives.

Muds listed at TMC - 1097
diku - 484
not-diku - 613

Boom Shakalaka! :P

Fact = truth
Truth = fact

When did we go from debating whether something is a -baseless- assumption to whether something is fact? We never made that assertion.

The entire time, no one has said that it is undeniably true or fact that most MUDs haven't taken the time redo their output to where adding in full or very detailed color customization would be easy. The entire time, we have maintained that we are making well informed -assumptions-. The "other side" was calling them baseless assumptions, and we have provided ample evidence to show that the assumption isn't baseless, but rather, is well founded.




I couldn't remember who it was that used to post the stats of the various codebase break downs, but I was going to ask whoever it was if they wouldn't mind outlining that as to erase any question of the percentages of diku based. Thanks!




It's been my experience that the further from stock someone ventures from their game, the more they stand to alienate people looking for a "familiar" experience. A good bit of players seem to be basically searching for a game that reminds them of their "first" or "favorite" MUD (in fact, some comments in this thread have supported people get used to a particular color scheme and want that to carry over to other games). When someone attaches to a particular codebase, it seems it's those features, that play style, even in many instances those areas they are looking for when they go from one game to another. The more you change from stock, the higher a learning curve there is, and many players just want to be able to jump right into something without spending however much time it takes to learn a new system, particularly when many times their expectations of going from one game of a particular codebase to another is that they've already learned the basics of how the system works.

I've also noticed in many games that I've tried out is that the ones that feel the most like stock tend to be the most popular ones. As someone who has deviated far from stock, it's honestly a bit frustrating to see, actually, but I digress.

My personal experience thus contradicts the foundation of your assumptions. Likewise, I've spent 5+ years with near constant development on a game "nobody plays" (it comes and goes, but not being officially open yet, we've yet to nail down a core and consistent playerbase) and numerous other MUDs go through the same process of years of development before establishing players. Further, as someone who has spent substantial time developing my game, refiguring output has not been something that has come to mind nor been something I would have considered a priority in order to make something like color customization easier. In fact, the -more- time I've spent developing my codebase, the -more- difficult or time consuming it would prove to try to add such customization.

Basically, making the changes necessary to make detailed color customization an easy task would have to have come -early- in the development of any Diku derived codebase if that, in of itself, were to be a less difficult task as well.

Even if we take out the assumption that a good chunk of MUDs out there are mostly stock games and likely haven't taken the time to modify their games (despite the fact that I don't buy that they aren't), there's still the founded assumption that a majority of MUDs out there aren't professional programmers or game designers, that hobby of MUDing is driven by hobbyists, it easily stands to reason that these hobbyists who booted up a stock Dikurative long ago and began making changes to their games that later became your #5, they lacked the knowledge, foresight or skill to have considered rewriting their output or event handlers at an early stage.

The things you guys are talking about with regards to rewriting the way all of that works is really expecting a bit too much out of a bunch of hobbyists. Sure, many of you here -may- have done this, but you must also consider that this forum is largely frequented by the elite of the MUD community, which makes it a great resource for those just starting out, or the "rom hackers" such as myself when we run into an issue we can't figure out. I hold my own with anything I feel needs done on my MUD, but I couldn't even really pretend to hold a candle to some of you guys when it comes to programming knowledge. I'd wager I'd qualify as the "average" MUD "developer" when it comes to an overall view of the community as a whole.

I just don't understand what is so hard to buy about the assumption that a good chunk of the MUDs out there don't have "sane" code that would allow for detailed color customization to be a trivial thing to add.

Do you honestly believe that it would be a trivial thing to do for the majority of MUDs out there, or are you just trying to win an argument?

I do honestly believe it wouldn't be very difficult for most MUDS. I have very limited experience with Dikurivatives but can't recall anything that would make it overly complicated. I can think of some things that would make it time consuming though. Maybe it is time to go ahead and make a snippet.

Like Chris, I also honestly believe it's a pretty easy thing to do. We already agreed upon the fact that basic color customization is near trivial to add to pretty much any game. Some of you argue that "full" customization would be tedious in most games, but I completely disagree with both the premise that you or anyone here is familiar enough with most games to make such a claim (for all we know, most games don't make much use of color, so "full" customization would be virtually the same as "basic" customization), as well as the assumptions that 1) most games are Dikurivatives, and 2) being a Dikurivative would make an appreciable difference in implementation time.

The only thing that I can think of that would significantly increase the time it took to implement "full" customization is the amount of elements being made customizable. Which, incidentally, has absolutely nothing to do with Diku, and is something no one here could even venture to take a stab at guessing an average for "most games."

In the last half hour or so I added back in color customization for friendly players, grouped players, enemy players, and added friendly ships, enemy ships, currently targeted players, currently targeted ships, friendly npcs, neutral npcs, and hostile npcs. When does it become more than basic customization? Is it based on the number of elements that can be customized?

That's just it. The argument has never been that it would be "difficult" in terms of complex algorithms or tough design decisions. It's simply that it would be a time consuming and rather tedious process, one which is likely not worth the effort versus its perceived value to the subset of users who would consider it a must have feature.


I don't think it's something you can really write a "snippet" for. The problem, to use Dikurivatives as the example case, is that the color usage is scattered everywhere throughout the code and there's no clear indicator of which message output is of which type. Most of them use a mapping from the raw ANSI to something like #r, ~red, #[red], etc to indicate red (and likewise for other colors). So, it's easy to remap color1 -> color2. And if all you cared about were a couple message types, let's say chats and room names, you could easily find those spots in the code and insert a configuration variable check to modify the color. The problem comes in when you want to allow customized color for a large number of message types (parries, dodges, trips, disarms, room names, room descriptions, directions, chats, NPCs, objects, etc….I could make the list as arbitrarily long as I wanted by adjusting the scope/resolution). In that case, you're stuck tracking down where all these individual events occur and inserting the appropriate check. It's either that, or refactor the code to make the task easier. Do I even have to explain why that is time consuming?


See above.

I posted the full stats over on the Chat forum.

@Lycanic: I'd like to know what time consuming is, exactly, because nothing you described should be that time consuming IMO. A simple grep for the output string and a minor change, and that element is now customizable. 1-2 mins tops.

You also have to consider that no player is going to want more than a dozen or two colors to customize, so you're not making a new option for each colored element. You'll likely want to have categories - some broad, some narrow. Allowing things like "setcolor left_border_of_box_around_who_output cyan" would be ridiculous. Instead, you'll want maybe a "borders" option which applies to all borders. But, you don't have to make all borders customizable at one time if you think the time investment isn't worth it. Just do a couple, and then others in the future as requested by your players, or whenever you get bored.

Indeed, that's common observation among developers who have run their own muds for a few years (Bartle also wrote a related article about the subject). There have been a number of discussions about innovation vs familiarity, and it's been noted on a few occasions that the most successful muds are those that stick with established/stock gameplay, give it a good polish, and add some new content.

I always enjoyed the way ROM played, and I was initially very hesitant to venture too far from that feel as a developer, particularly with the combat. Odd that my first ROM MUD I played was probably my 4th or 5th major MUD I played, with Gemstone III my first and a Nightmare LP MUD my second… So ROM just really struck the right chord with me I suppose. Several years ago when Midboss was doing a lot of developing on End of Time, his philosophy on pretty much any MUD he worked on (almost exclusively ROM) was to rip out as much of the stock systems as possible and rework from the ground up. Coming from opposite ends on how we looked at things, I think that worked rather well to meet in the middle. He certainly pushed me outside of my traditional comfort zones with many systems, and once we reached a point where the game has very much its own feel, I've become much more interested in developing "End of Time" as its own game rather than trying to maintain any certain type of feel. We have pretty good newbie retention, so I think we've struck a pretty good balance.


As far as the other stuff in the thread goes, I think we just may have to agree to disagree. Regardless of the speculation on what it would take with other games, we know our games pretty well and have a pretty good idea of work vs. worth, and for some of us, it isn't worth it at this stage.

Can't argue with that. Adding it was a fun diversion for me, it let me think about my space system and make some actual decisions.

If you don't understand it at this point, you're never going to. I'm done trying to explain it to you.

P.S. You're still spelling my name wrong. I'm now taking it as intentional and insulting.

People can't always agree. How noble of you to end the debate in a respectable manner.

Lionic is right.

One more….

200!

This officially reached ridiculous :p