[Parhelion]

Want to start off by thanking Soludra for that link. I'll be taking a good look at it after I finish writing this post.

There's definitely different things to consider here. "Design" can be applied to administrative policy, public relations and marketing, code, or theme. I think that the ability to evolve itself IS a design issue -- if you build a game that is stiff and unchangeable from the start, you'll be shooting yourself in the foot.

This is one of the many problems with my afore-mentioned favorite MUD: administrative policies have kept the game from evolving past the point of its original concept from 12 years back; new mechanics or ideas could not be fully explored, while old ones could not be updated or revised. A growing political chasm in the staff has led to a great deal of problems, because there was no infrastructure in place to deal with these types of social issues.

Normally, I would not put "policy" and social issues under the category of "design" -- but seeing as how most MUDs are volunteer-run and there is so much disagreement over the legal rights of MUD owners and their games, I consider this a downright critical installation from the very beginning.

The game's inability to evolve could also be attributed to poor code design. While there are some innovative or creative solutions to problems to be found within the MUD's codebase, the overall "flow" is confusing and difficult to work with. Many of the features which needed to be expanded could not be, due to the depth with which they were programmed into the core of the game, while less obvious problems showed up in the way that files were traditionally inherited to create objects in the game.

(( For example, every time I decide to create something that has one additional/unique feature to it, like a pendant with a readable inscription as opposed to just a pendant, I needed to create a whole new base object first, and then create the pendant and have it inherit the new base object. What results is directories full of near-identical base objects that might inherit one or more OTHER near-identical base objects found in other directories, which, in turn, may or may not inherit more base objects. ))

I kind of think this can be applied to the way codebases are designed, too. Not that there are lots of those being cranked out now-a-days anyhow; my romp with MudOS/Lima left me first mezmorized that it worked so nicely out of the box and then stunned when I discovered 26-objects-deep inherit chains from hell. This is, of course, JUST an example, since I am not familiar enough with programming to have explored other options.