LPMuds vs Diku muds

 

I’d like to expand a little on the Diku side to [Tim Hollebeek’s] excellent reply on the differences between Diku-derived muds and LPMuds.

Whereas the great strength of LPMuds is the fact that they are so flexible and programmable, the great strength of Diku derived muds is that they are not. The more complex the system required to build or to get the game running, the less likely that said system will ever be successfully set up. This is why the template approach of Diku style muds proved so popular. They are very easy to set up, al the databases even among the different code bases are remarkably similar (i.e. converting areas between stock Diku, Merc, Circle, etc, is remarkably easy, if indeed any conversion is necessary) and hence large muds can be opened from scratch by spending a few hours with FTP.

This is also the great weakness of Diku of course–they are fill-in-the-blank muds.

LPs have the opposite problem. To make a unique LP implies a certain level of ability at coding in LPC, which is, to be honest, as rare as the certain amount of ability required to code in C on a Diku. The result is that most LPMuds take a standard mudlib off the shelf, and run with it, in effect ACTING as template-based muds even though they have a wonderful and powerful architecture underneath.

I don’t think there is any question that LP is far more powerful than Diku-derived code bases. You could write a fully-Diku-compatible mud in LP, and make it better. But Dikus will not go away because they are much, much, much easier to use for the most part. (Yes, a well-designed mudlib can be easier to use as a Diku, I know… my point is that the work required to get it to that point is not generally done).

The trend among Dikus that Tim mentioned, regarding adding scripting and so on, isn’t exactly new, of course, but it has taken a surprising amount of time to catch on. But scripting alone isn’t the real design issue. The name of the game in Dikus really has to be making the templates they load more flexible yet backwards compatible. Adding new sections to the template that are optional but permit greater detailing, customization, etc. Permitting each builder to find their own level…

LP is a better system. But I prefer to do my work on Dikus. 🙂

  3 Responses to “LPMuds vs Diku muds”

  1. […] was really easy. On MOOs and LPMuds, you had a lower barrier for adding features, but you also had a higher barrier for “just making content.” Most Dikus could, with minor text editing, share their zone files, […]

  2. […] was really easy. On MOOs and LPMuds, you had a lower barrier for adding features, but you also had a higher barrier for “just making content.” Most Dikus could, with minor text editing, share their zone files, […]

  3. […] On MOOs and LPMuds, you had a decrease barrier for including options, however you additionally had the next barrier for “simply making content material.” Most Dikus may, with minor textual content enhancing, […]