[MUD-Dev] Forks or Frameworks?

[Thomas]

<EdNote: New text moved below quote and quote trimmed>

> -----Original Message-----
> From:	Gavin Doughtie [SMTP:gavin at idealab.com]
> Sent:	Monday, December 18, 2000 8:14 PM
> To:	mud-dev at kanga.nu
> Subject:	[MUD-Dev] Forks or Frameworks?
...
> Are there projects afoot to provide a generic framework that can be
> revised independently of the content? I'm thinking specifically of a
> "D-Free" shared engine. The Worldforge project is the only sizeable
> one I've seen so far.

One should always design his or her programs to be as versatile as is
reasonably (within temporal/financial constraints) possible; this is
one of the precepts of good software engineering, since it facilitates
code reuse and actually decreases errors because it requires a more
logical abstraction.

The average MUD eschews this practice because its coding staff
consists of amateur programmers, who generally have little formal
training and therefore have little appreciation for proper design
techniques -- they program for the moment, with an eye toward
implementing the very next feature, while having little regard for how
future changes might rely on concepts exposed within their individual
contributions.  Additionally, many of the traditional C -oriented MUD
codebases (DIKU, Circle) do not easily accomodate major change; their
functional (as opposed to object-oriented) approach and infestation of
preprocessor directives (they nearly create another language through
these directives -- horrible, HORRIBLE technique) combine to create a
snarled mass of if-then spaghetti code, to the point that a programmer
would find it much easier to just toss another strand in the bowl
rather than try to isolate common sections and reorganize.

When one considers the frequency of modification that MUDs tend to
undergo (some MUDs are always adding new code), I'd say it's not only
advisable to design a flexible MUD framework that employs proper data
encapsulation, I'd say it's REQUIRED -- that is, unless you want your
game to crash unpredictably when you add a new feature, possibly
trashing your hard drive in the process and subjecting you to hours
(or days) of downtime while you traverse thickets of pointers and step
through hundreds of if-then constructs, every once in awhile looking
back at the list of preprocessor definitions to ascertain whether a
particular command is really doing what you thought it was. Many MUDs,
unfortunately, seem to consider frequent crashing due to shoddy code
an inescapable part of the endeavor.
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev