Ohai, you must be new to MUDs. You seem to be painfully unaware of the fact that 90%+ MUDs in existence are derived from AberMUD (Diku, LP and Tiny families). Are you also unaware that we're talking about 20+ year old code? The idea of design patterns in software engineering was a brand new, and not widely accepted/adopted thing at that time. Also, the vast majority of people who have contributed to the codebases over the past 20+ years were hobbyists with little to no background in software engineering, anyway. You really have to consider the historical context and the average use cases of what you're talking about.

None of those are derived from AberMud. The only AberMud derivatives that I am aware of are Dirt, iDirt, pDirt, cDirt, Dyrt and FreeDirt. DikuMud, LPMud and TinyMud were all original and do not
share any code with AberMuds.

But, to your point, yes it's certainly true that all of the above originally contained some pretty poor code. Most were written by computer science students and most of them went to become professional developers. I don't doubt that they cringe at a lot of their old code.

You'll never hold players with cake. Most players prefer pie and will be upset if it's not offered. >:->

You can't make everyone happy. Therefore, cake will have to suffice.

You're technically correctly. They don't share code (questionable, some people suggest there are some small pieces that were shared) with AberMUD, but they are conceptually derived from/were based on AberMUD. Design concepts are really what we're talking about here, anyway. I was just starting at the beginning (more or less).


I've always cringed at the code I've written that is more than about 2 years old. It's a constant cycle of rewriting my old code, utilizing newer/better methods of doing things.

I'm fairly familiar with the Diku family code, and disagree with the premise that it would be difficult or time consuming to add basic color customization to it. Maybe 2 hours, tops.

As for cake/pie, everyone knows cheesecake is the best.

I'm a fan of cheesecake myself. It's a pie called cake!

Like color, the dessert issue is black and white. There's no need to muddy the discussion with shades of gray like cheesecake.
Cheesecake is in reality cheesepie! There's nothing at all cakeish about it, despite the name. ;-)

Emphasis mine.

I don't think anyone is disagreeing that basic color customization would be that big of a deal. At this point, I think the talk of color customization has moved beyond just basic (maybe not the exhaustive level that has been mentioned previous), and is where we are when discussing that customizing the ability to highlight various events in combat, change an overall color scheme, and account for different variables within room descriptions and titles, etc. is where we run into an issue.

The example Chris Bailey provided would be what I would call basic color customization, and I agree -that level- wouldn't be that big of a deal. It's going beyond that where we have an issue.

Many muds already use colour codes like #r for red, #b for blue, etc. The two ASCII characters are then either stripped out, or replaced with the appropriate ANSI escape code, depending on whether or not the user has colour enabled. If you support xterm 256 colours then you've probably got an additional check for those as well.

DikuMUD also uses similar codes in its act() function, for example $n is replaced with the character's name, $N with the target's name, and so on. These aren't (normally) used for colour, but the underlying concept (from a coding perspective) is exactly the same - text replacement tailored to the viewer.

There's no reason why you couldn't lift that functionality from act() and drop it into the colour code, so that #n would be replaced with the character's name, and so on. Most DikuMUDs also have a 'title' command; copy and paste that, and you've got yourself a basic command for configuring strings. Then you just need to add a new string for each configurable colour.

So actually implementing custom colour can be done mostly through cut and paste. The more challenging issue, as Hades_Kane mentioned, is deciding how to use it - but that's really a design issue, and is going to come down to personal preference.

What I personally find interesting is that the code for colour customisation could also be used for simple dynamic descriptions. That's something I'd really like to see more of; I don't feel that static descriptions are the best choice for interactive games like muds.

I am in the mud world since 1998 so yep pretty new, but before adding anything to the mess the code was in, I factored code so it reflected sane programming pattern. Yep it took some time and I do not consider the work over by far. But this is one of the first thing I did.

It's commendable that you did that, but you can't assume everyone else did the same. In fact, it's probably a safer assumption that no one else did (small enough number of people to round it down to 0%). That's the whole point in this conversation - it's not about your code. It's about the code that 90%+ people have to work with. If you're adding the extra step that they completely refactor it to reflect "sane programming patterns", in order to more easily add color customization, then you're just making my point for me. For most use cases, adding more than very basic color customization is going to take more time and effort than it is worth.

s/For most use cases/For my particular use case/

Fixed it for you! No payment required, but cheesecake definitely appreciated!

I can only assume that was directed at me, since you're using my terminology. I never said it was applicable for my use case, though. I said "most use cases", and that's precisely what I meant. You really should stop making all those baseless assumptions.

Sorry, I was just trying to help you out of an impending argument by generalization fallacy. You know, where one claims something is true "in most cases", despite having no knowledge whatsoever of those cases, but rather, only a small subset of them.

My fault for making the baseless assumption that you had any cheesecake to begin with…

Deimos, there's nothing baseless about Lyanic's assumption and any look at a breakdown of codebase popularity can demonstrate that. Can you supply evidence that most active MUDs today are *not* Dikurivatives? If not, then Lyanic's claim is very valid.

Or supply evidence that of the many Dikurivatives, that most of the have taken Rarva's step of making the code sane before adding anything else to it?

We might be operating off of assumptions, but baseless they are not.

Just moving forward from stock Diku based, I think there is agreement that the code isn't sane.

Of the many, many MUDs out there, through both personal experience and general community perception, there is a large percentage, if not outright majoirty, of Diku based MUDs that have done little beyond cosmetic/superficial code changes and additions to areas. It stands to reason that if this the extent that many MUDs have taken their code, that they lacked the knowledge, drive, or desire to make their code sane.

Even of the MUDs that have made something very different and unique from the base they started (I am an example of this), many are simply hobbyists without any sort of professional programming experience and training (and I'm sure many, like myself, learned how to "code" by trial and error in the codebase, establishing our coding habits and knowledge based on the codebase we were working on). For many of those types (myself included), the idea of reworking a ton of the code that was there to follow more sane programming habits and patterns would have been one of the last things we have thought of.

Like many, as I've learned more and more, I'll go back over old code and redo it when necessary (usually when I need to change something and condensing the code into one spot for ease of ever having to do it again). I consider myself more of a ROM Hacker than a coder of any sort, to be completely honest, and I would be willing to wager that the way I came about being the "Coder" on my game is fairly typical of how it works out in the MUD community.

So no, while we are assuming, I think there is plenty of evidence to support it and not make them just baseless.

@plamzi: That's another common fallacy (though the name escapes me). Basically you're saying "if you can't prove X wrong, then X must be right." Which is, of course, nonsense.

@Hades: Even if I were to grant you that "most MUDs are Dikurivitives," you still can't make the claim that all, or even most, of them have code that's even still similar to that which existed in the original base. Doing so is still an argument by generalization fallacy; you're attempting to say "because I've seen or heard of X, Y, and Z MUDs that were only very slightly modified, it must also be true that most other Dikurivitives are only slightly modified." Which, again, is obviously nonsense. Your hypothesis may be correct (though we can't know one way or the other), but I find the premise that "my idea seems to make sense, so it therefor must be true" to be inherently flawed.

Let's back up a bit. Lyanic's claim was not baseless. There's empirical evidence that seems to support it. His claim was also far more modest than what you're building here, which is a straw man.

You sure seem to like to misuse the straw man accusation. First with David, and now me? :-p Suggest you spend some time on The Google.

You also somehow managed to reply to me without actually addressing anything I said. I've no idea how to combat this new debate strategy, except to say, "okay?"