A "modern" MUD

[Blaidd]

Hello All,

I've been noticing lately while browsing the various MUD related forums that a lot of people have been complaining about existing MUD codebases being "so 1980s" or otherwise antiquated and how 90% of MUDs are built on exactly the same outdated principles. I see quite a few derogatory remarks directed towards these "traditional" (but I agree sadly archaic in some respects) games and the people who are still building off them by people who claim to be working on a "modern" game.

Now I've been hacking on the guts of some really bloated and ancient LP libs for about five years now and I see where people are coming from with this rant, but as someone who has recently embarked on the time honored journey of "I have all these great ideas from years of experimenting, hey guys let's go start our own game," I'm curious as to what features people here think is necessary to be considered a "modern" MUD or a "modern" codebase.

For a bit more background on my own project. I'm using LPC because it's home, I'm familiar with it, and I believe it's still a perfectly viable language (especially the DGD dialect which I'm using). I chose DGD because it has support for a lot of really nifty advanced features and I think it's extremely under used considering its potential. A really good mudlib or two would really help it out.

Ok, so what makes a codebase "modern" instead of "so 1980s"?

The first thing that comes to mind for me is a more modular, but much stricter object oriented design. Most of those old mudlibs (not sure about the C++ codebases, never really looked at the internals) are so bloated and confused that if you try to take anything out you'll break half-a-dozen other things. What I'm aiming for with my mudlib is a design modular enough (with a clearly defined API between objects) that anyone can write a "module" and drop it in on top of what's already there without breaking anything at all (assuming no logic errors in their code of course).

I'm building this sort of functionality in as I go, but it's already visible in the player account system. Don't like "Player Accounts"? Delete account.c, copy in a "player.c" file, update the config file that tells it where your player object is. Traditional character-only log in system. As long as every module defines the appropriate API functions it's basically drag and drop to modify anything. Don't like the standard class system, download a different one and drop it in.

Seems to work so far and I don't see why it wouldn't be possible to keep it up over the long haul.

Ok, so what makes a GAME modern instead of old school?

Grid based systems instead of rooms?
Non automated combat?
NPC AI?
Dynamic descriptions?

What exactly is this "modern" fuss about?

Thanks,

Blaidd

[shasarak]

[Blaidd]

[Nornagest]

I think C and its variants are still a good tool for the job, at least on large-scale projects. Big, long-running MUDs tend to get quite expensive in terms of machine resources; it'd probably take a couple of years for you to hit the wall in a large MUD written in, say, Python, but it'd happen eventually if the resource usage of my old MUD is anything to go by. C and most of its variants tend to be a little less greedy.

Recently I've been wondering how a MUD written in Lisp would do. The variant I've learned seems quite well-suited to the task, and it's a fairly efficient language; such a MUD would likely have longevity problems, though, as the language is neither easy nor (as) common (as C). No points for modernity, of course.

As far as the topic question is concerned, most of the archaism I see in contemporary MUDs relates to two major problems: software architecture and the player interface. You've already covered a lot of the problems with architecture, so I'll comment on the latter.

Diku-based MUDs in particular tend to have an awkward interface, with an obscure grammar that is effective once learned but not particularly intuitive. I think the MudOS-style natural language approach is better, but the existing implementations tend to be insufficiently sensitive to context and highly dependent on a robust set of verbs and object descriptors; I recall trying several variations on "put apple away" before hitting on the correct "put apple in backpack", for example.

As a final caveat, I suspect that much of the allegedly slow evolution of MUDs comes not from any lack of development but from slow or nonexistent adoption of "modern" code. The Phantasmal lib for DGD is a good example. While excellent in many ways, it's too modern for its own good; its design and libraries bear almost no relation to more common mudlibs, so its adoption has been slowed almost to nothing through sheer confusion.

[MikeRozak]

In my heretical opinion, the first thing that needs to change is that you need a custom (or powerful generic) client with:
- At least some graphics
- Sound
- Automap - Probably my biggest gripe about text MUDs.


Then, I'd recommend:
- More OO
- Better NLP
- Better AI
- Non-DIKU combat
- Etc.

[Blaidd]

[Spazmatic]

Guys, I think shasarak was kidding. Well, I think so, anyways.


As far as modernity, I don't think you should concern yourself with it over much. I think I've read many of the posts you tangentially mention - most of them aren't overly intelligent. You can leverage criticisms at almost any design choice, but "it's old" is not a valid criticism.

For example, there was a lass complaining about rent. I, personally, dislike rent and her point that rent was often used to save space is true. However, that does not make it a fundamentally bad design decision. It depends entirely on your goal. It may be that you want a fluid economy and you choose to create that limitation via rent (or, on some muds, wiping the player's entire inventory). Hey, design decision.

Now, there are places that legacy muds really lag behind reality - these areas are not game design issues (as those are almost entirely design decisions that have pro/con tradeoffs). You mentioned system architecture, and that's a big one. Utterly impoverished software design is a major hallmark of the worst legacy codebases. Also, in a similar vein, some older mu*'s offer poor database designs, etc. However, you seem to have this area well under control.

You also mention AI and what not (as do several other people) - this I also agree with. Again, not so much an issue of design decisions and gameplay as it is a technology issue. As an example, consider NLP (natural language processing). Modern NLP is terrible, this is fact. However, 15 years ago, NLP was even MORE terrible. Similar things can be said about many key areas in computer science. Modern AI systems can do some fairly impressive things. Modern data mining - even more impressive things. Those are definitely areas that have seen sufficient improvement that legacy codebases really suffer (if, of course, you want NPC AI).

HOWEVER, I think the one point that is most relevant to gameplay is the maturity of game development as a whole. Game design started as a very designer-oriented task. Many game designers focused more on what they and their team thought was "cool", rather than attempting to design games for their audience. Over time, as the gaming industry grew and matured, things shifted (in general) towards consumer oriented design.

If you are looking to create a game with general appeal, I think that's the biggest lesson to be learned from "modernity".

(I think I left myself open to some very harsh criticisms. Oops.)

[Blaidd]

Spazmatic,

That's exactly the sort of analysis I was looking for and our thoughts on the subject seem to pretty well follow the same lines.

I hadn't thought about it quite that way, but you are right that most of the problems in the old codebases are either design issues, or issues of the advanced algorithms just not being available (or at least well known) at the time.

So it seems that the general idea would be to study the design techniques and algorithms used in non-MUD games. Which is basically what I've been doing.

Blaidd

[Nornagest]

It's quite true that game design has shifted from a designer focus to a market focus. This shift has brought us, in my time as a gamer, from Monkey Island to BloodRayne; I leave it as an exercise to the reader to figure out which made for more memorable gameplay.

I believe that trying to create a MUD with mass appeal is itself a mistake. The medium has a significant disadvantage compared to large-budget MMOs (its most direct competitors) when it comes to crowd-pleasing; however, it has a significant advantage in terms of total creative ability, from the sheer number of active development teams if nothing else. This suggests to me that the better approach is for each team to design what they think is cool or makes for an enjoyable game, rather than what they think the market wants, and let Darwin sort out the losers.

This is not to say that mainstream gaming has nothing to teach us, merely that the design model that works for mainstream design houses (relatively few, high-budget, publisher-driven) don't necessarily work for MUD design teams (relatively many, low- or micro-budget, user-driven). We might be better off looking at the design techniques that have been successful in the mod community attached to mainstream gaming, and particularly in add-ons for successful commercial RPGs like Neverwinter Nights*.

On the other hand, Medievia's still popular.

*I have little personal experience with the NWN mod community, but this seems to make sense.

[MikeRozak]

While I agree that trying to produce a World of Warcraft (clone) with a few people is silly, and that niche virtual worlds (MUDs and indie MMORPGs) should probably be completely different experiences, I'd argue that stealing a few ideas (like ease-of-use and limited eye candy) might be able to attract signficantly more players for relatively little effort.

Discalimer: As I've posted before, that's exactly what I'm working on. See http://www.mxac.com.au/mif.

You might also look at browser games like Adventuer Quest, http://www.battleon.com/. There are 6631 players online as I write this. Underneath what little eye candy they have is a very simplistic MUD, so simple that players can't even interact with one another.

[Spazmatic]

[Nornagest]

At the risk of derailing this thread...

I think "a cool idea", "a good game", and "a popular game" all imply some player appeal; the distinction is mainly one of how, not whether, you're trying to attract your target audience. If you're trying to explore a cool concept, for example, you're effectively targeting your game towards anyone that shares your enthusiasm. With half a billion people on the Internet, it's reasonable to assume that such an audience exists.

"Good" and "popular" are a little trickier, and they're both going to appeal to a fairly wide set of players within your chosen niche. The two are arguably distinguished by the fact that players may not enjoy features in practice which they find attractive on paper, and may enjoy features they don't; hence, one game may seek to maximize user loyalty by using features that play well in the long term, while another may seek to attract new users by using features that look good in the short term. They overlap precisely to the extent that players know what they like - assuming, of course, that the popular MUD tactic of "baldly lying about your features" hasn't been adopted.

I suspect the market-oriented trend that the gaming industry currently seems to be undergoing constitutes a shift in focus from retention to attraction. This makes good business sense for single-player games and any commercial game that offers free multiplayer features, since the publishers of such games get paid once at purchase time. It doesn't make good business sense for an MMO or MUD using the subscription model, although much of the MMO subgenre doesn't seem to have realized it yet, and it doesn't make sense for a free MUD, whose stock in trade is essentially user loyalty (in the form of donations and free publicity). Plus, as I mentioned in an earlier post, MUDs just don't have the resources to pursue many aspects of an effective attraction strategy.

Of course, we can still learn from the mainstream; we should just keep the differing business models, and hence different goals, of the mediums in mind. And gameplay's always important, as long as what you're making can fairly be classified as a game (and not, say, a simulation or code sandbox).

Finally, it's true that my Monkey Island/BloodRayne example was misleading. In retrospect, I should probably have picked a less obviously lame recent production, but it's late and I haven't had my coffee.

[shasarak]

[Spazmatic]