07 Jan, 2011, Crollster wrote in the 1st comment:
Votes: 0
Hi,

Have been reading these forums for quite a while, but have only just decided to register and post something. : :cyclops:

Anyway, most of the readers/posters in this forum are (or at least aspire to be) MUD coders, either having built a code-base from the ground-up or, more likely, have modified an existing code-base. Since MUDs are fairly mature (well into their 3rd decade), as far as software and online games go, I was wondering if perhaps we should start formalizing some of our design & coding decisions into MUD-oriented design patterns, which would not only help future developers, but also help cut down on some of the more frequent newbie questions (such as, "should I have 1 thread per connection," etc) that pop up on such forums like this (and hopefully prevent the (aptly named?) "Big ball of mud" anti-pattern that becomes common in some of the more ancient code-bases).

Anyone have a pattern they want to share to get us started?
07 Jan, 2011, Runter wrote in the 2nd comment:
Votes: 0
I'm not sure this is useful. I'm not sure it's useful because there's no singular answer on most of these topics. There's benefits and draw backs to design decisions. Common programming patterns are well documented. These can and should be used in software like mud codebases, but I don't see why they would have their own special patterns. In many cases this is just opinionated parsing of well established patterns for little benefit except maybe giving publicity to those patterns.

For example, in your original post you use the question of "should i have 1 thread per connection". Setting aside whether or not this is a pattern, it seems like you're talking about a FAQ.

If we're talking about common designs for these servers that's also not very useful. It's not useful because your post makes the assumption that because muds are 30 years old they're well designed and have had 30 years of thoughtful development. This is far from the truth in most of these old codebases. In fact, a lot of their practices should be discarded and some of the best higher order "patterns" aren't used at all.

I'm not trying to rain on your parade, but maybe you could clarify if I'm misinterpreting what you're asking for. Or tell me how I'm wrong.
07 Jan, 2011, Crollster wrote in the 3rd comment:
Votes: 0
Thanks for your reply, Runter.

Ok, I understand what you're saying, and some of what I'm talking about could be dealt with in a FAQ (afterall, if you think about it, design patterns can be considered to be little more than very well documented FAQs, since they are the condensed knowledge of engineers used over many software project iterations, working on similar issues).

You are, of course, correct in your assertion that much of what has been written over the past 30 yrs of MUDs should be thrown away - this could be said for much of the code written for internet based applications early in their life, but development is a learning process, and over time things get better.

While I agree that, where applicable, we should use the GoF patterns in object oriented development, there are cases where new patterns appear for specific application arenas - and I was wondering if MUDs *could* be one of these arenas.

The example I gave of threads & connections was one of the first mistakes I made when I first wrote a new code-base, and is something I see asked a few times a year on the various boards.

Now, I know how *I* dealt with this issue when my mistake was pointed out and after I was slapped about the face with it, but I have examined too few other code-bases to know if there is a preferred (or better) method used.
Pretty much by definition, if all/most current code-bases do something the same way, that could be classed as a pattern.

The motivation for this post came after I spent several months, on and off, looking for websites on MUD design, but not finding anything particularly useful (just the occasional forum post here and there). Rather than setting up a website detailing how *I* thought a MUD code-base should be designed (and getting flamed in the process), I thought I'd try and get some input from the community first (and get flamed in the process :wink:).
07 Jan, 2011, Runter wrote in the 4th comment:
Votes: 0
I'm not really flaming. I'm just challenging the need. I'm not sure muds are so ground breakingly different (or more difficult) than just about any other worth while program. In fact, I think the established patterns for general programming work very well in muds. And generally they aren't used. So that brings me to another point. If we talk about these de facto patterns in muds that exist out of virtue of a lot of people doing stuff the same way… I think that alone doesn't certify the "pattern" as a proper way to do things. I think a lot of the generic programming patterns go unused in most muds. There are a few that are good ideas that I can think of that muds generally use. So in the spirit of trying to be constructive to this thread I'll throw one out there. The prototype pattern.

Most muds use this pattern in one way or another. They prototype various game elements and hold them in memory. Usually instances are copys of this data or simply facades/proxies to it. Sometimes in muds (although more rare in other places) separate classes are used for prototypes and instances themselves. Although not necessarily.

a = Actor.new(:dogs) 
b, c = a.dup, a.dup
b.name, c.name = "fido A", "fido B"


Oh, and I really think the threads example is just new programmers not understanding how the fundamentals of a large program work. The outside appearance of total concurrency makes them consider ways of achieving that when it's unrealistic and dirty to push scheduling to the VM or OS to achieve it. Similar questions seem to come up on other forums I frequent about developing graphical games in regards to the event based programming.
07 Jan, 2011, KaVir wrote in the 5th comment:
Votes: 0
Runter said:
I'm not sure this is useful. I'm not sure it's useful because there's no singular answer on most of these topics. There's benefits and draw backs to design decisions. Common programming patterns are well documented. These can and should be used in software like mud codebases, but I don't see why they would have their own special patterns. In many cases this is just opinionated parsing of well established patterns for little benefit except maybe giving publicity to those patterns.

I agree to some extent…but I also think there could be some value in describing common approaches to certain mud design issues, even if these approaches utilise established patterns.

An obvious example would be modelling a game world. How does a room-based system typically work? What about a coordinate-based system? What about hybrids? What different approaches are there for designing wilderness systems, exits, OLC, dynamic room descriptions, weather systems, etc, etc?

It'd also be interesting to see a break-down of different combat systems - how does the standard Diku model really work? How does that differ from LPmud? What variations of balance-based combat exist? What different approaches have proven effective for automated and non-automated combat?

A lot of time and effort has gone into different areas of mud design, and people do keep reinventing them - it'd be interesting to see them all documented.
08 Jan, 2011, Mudder wrote in the 6th comment:
Votes: 0
I would use something like this. I'd also help out where I could. :cool:
08 Jan, 2011, Scandum wrote in the 7th comment:
Votes: 0
Mudpedia could be used if some kind of categorization and classification effort was undertaken first so people don't randomly start mucking around.

I worked on a list of notable features a while ago, but it's far from complete.

http://www.mudpedia.org/wiki/Comparison_...
08 Jan, 2011, David Haley wrote in the 8th comment:
Votes: 0
This has nothing to do with features; this has to do with how code is organized.

It would be nice to have high-level descriptions of what makes Dikurivatives and LPmuds different, for example, from an architectural standpoint (the notion of precompiled code vs. a runtime environment with a driver).

Questions of game design patterns are interesting but I think a separate issue.

I agree with Runter though in that there really aren't that many, if indeed any, MUD-specific patterns. Most codebases would benefit immensely from applying standard design patterns or knowledge. In relatively few real-world servers do you want one thread per connection, for example: this is not a MUD-specific mistake.

So concretely what would the next step be? Are you volunteering, Crollster? :smile:
09 Jan, 2011, Deimos wrote in the 9th comment:
Votes: 0
One of the more useful patterns I've seen brought over to MUD development is the Observer pattern for event-handling. Of course, this may be a bad example, as I'm somewhat confused about whether you were asking for established design patterns that tend to be used in MUDs, or design patterns which were created for and specific to MUDs (the aforementioned Observer pattern obviously being an example of the former, not the latter).

If you're looking for MUD-specific patterns, one good example might be the virtual wilderness concept. As far as I know, this problem is specific to MUDs (or, at least, MUD-like games), as are the different solutions created for it. My favorite pattern is the one presented by KaVir, though I can't seem to locate the thread on these forums. Maybe you'll have better luck.
09 Jan, 2011, Runter wrote in the 10th comment:
Votes: 0
I thought we are talking about actual implementation patterns. Not exposed concepts. For example, the room based and coordinate based systems may be implemented differently than you'd expect. There's no reason a "room based" system couldn't use the exact same underlying implementation that a coordinate based system does.

edit: Also, I can go down the list naming every programming pattern that's common out there and they'd probably be useful in muds. So I'd like to see some examples of patterns (for implementations) that aren't used in other places than muds.
10 Jan, 2011, David Haley wrote in the 11th comment:
Votes: 0
A "virtual wilderness" is not a design pattern, nor is it specific to MUDs. In fact, representation of spatial data is a fairly standard problem. The implementation you choose to use will depend highly on what your stored data looks like; KaVir's approach might be highly appropriate in one circumstance and highly inappropriate in another. Examples of parameters are how sparse your data is, how much is "interesting" vs. how much is compressible filler, how much data a given player accesses at once, how much data all players are accessing at the same time, etc.
10 Jan, 2011, KaVir wrote in the 12th comment:
Votes: 0
Deimos said:
One of the more useful patterns I've seen brought over to MUD development is the Observer pattern for event-handling. Of course, this may be a bad example, as I'm somewhat confused about whether you were asking for established design patterns that tend to be used in MUDs, or design patterns which were created for and specific to MUDs (the aforementioned Observer pattern obviously being an example of the former, not the latter).

If we view a design pattern as a general solution to a commonly occurring design problem, then it's certainly possible to come up with a list of problems frequently faced during mud design - and common solutions to those problems. Whether those solutions are unique to muds or not doesn't matter, the important thing is that they provide a tested, proven paradigm that can speed up mud development.

Deimos said:
If you're looking for MUD-specific patterns, one good example might be the virtual wilderness concept. As far as I know, this problem is specific to MUDs (or, at least, MUD-like games), as are the different solutions created for it.

Rather than getting sidetracked with definitions of "design pattern", or arguments about whether or not a particular solution could also be used for something other than a mud, I'm going to stick with the actual subject at hand. I really hope others can try to do the same, as it would be a shame to see this thread derailed when the subject itself has the potential to be of real interest from a mud design and development perspective (please note that this isn't directed at you, Deimos, it's just a general comment).

A number of mud developers have implemented (or wish to implement) a wilderness system. There are of course multiple solutions to this problem, depending on what exactly you're trying to do, but most implementations seem to follow the same approximate approach. Is it possible to produce a tested, proven paradigm that could be followed by those wishing to implement a wilderness system? Yes, it is. Would this be useful for mud developers? I believe it could be.

You could also try taking a look through mud snippets and see which ones are popular. What about something like Lope's Colour snippet, for example? I never used it myself, yet my solution ended up working in a similar way - and I've seen others independently follow the same sort of approach as well. Would it have saved us time if this had been written up as a general solution? Perhaps - but even if not, it would at least have provided a consistent solution for the players (eg rather than having "#r", "^r" or "{r" for red, depending on the mud).

What about something like the low level communication of a mud - the basic socket handling that's common to almost every mud. Would a carefully described solution be useful for someone who wished to develop a mud from scratch? Yes I think so - I know I'd have appreciated it when I created my 16K entry. There is plenty of documentation on sockets, but it would have been really helpful to have some specific notes on how to use them for a mud.

What about help file systems? I've seen articles discussing these, listing problems, suggesting improvements. I've seen seem some muds attempt to make their help file systems more user-friendly, and they usually end up independently adding the same enhancements - indexing, soundex, etc. Couldn't these enhancements all be written up as part of a general solution?

What about dynamic descriptions? Or generated descriptions? This subject always seems to surface every couple of years, with new muds having a go at it. There are some snippets of course, but snippets are language-specific. Would a general design solution be useful?

How about combat systems? Combat plays a central part of most muds, and most muds try to stand out from the competition, so it's an area where many developers try to add something unique - yet when you look past the cosmetics and the extras, at the underlying design itself, there are no more than a handful of common solutions used by existing muds. Now one could argue that anyone designing a combat system would probably already know how combat works, but would they be familiar with all of the common solutions? Would someone from a Diku background be aware of how a balance/affliction combat system worked, for example? Combat is one of my favourite mud-related subjects, and I eagerly explore any new approaches I find, but there are still some muds that I've only read about second-hand. I would personally love to see a set of general design solutions for each common style of combat system.

Would these solutions be defined as "design patterns", or be unique to muds? It doesn't matter, that's a red herring - an irrelevant argument that distracts from an otherwise interesting and constructive thread. The question we should be asking is: Would these solutions be useful for mud developers?

I've never heard anyone disagree with the idea of writing up specifications for mud protocols, like MXP, MSP, MSDP, etc. And having these specifications definitely makes them easier to implement, even though they're not the only solutions to any particular design problem. I believe the same would be true for other areas of mud development, and that a set of general solutions to commonly occurring mud design problems could prove both interesting and useful.
10 Jan, 2011, Runter wrote in the 13th comment:
Votes: 0
It isn't a red herring to point out that something isn't a programming pattern. It's not just a loaded word. It's got long established meaning in the programming world. I think it's important to make the distinction between the vehicle you use and the destination you're getting to. They're not both the same thing. In the wilderness example what is exposed to the players may be a pattern of some kind, but it's not a programming pattern. No more than "ANSI color enabled" is a programming pattern. No more than a snippet of code for a specific feature is a programming pattern. If we are just talking about classifications, then sure. But that's far less useful to developing features than talking about actual programming patterns. I welcome an actual discussion on this topic. I just think it's important to be clear about what we're talking about here.

And to be clear, domain-specific patterns are also well established. They also don't include the sorts of definitions we're talking about here. So I'd like to actually see what unique patterns we use here (if any) on the underlying data. Otherwise we can just list common features and the already established patterns useful to them.
10 Jan, 2011, KaVir wrote in the 14th comment:
Votes: 0
Runter said:
It isn't a red herring to point out that something isn't a programming pattern.

It is when nobody else has even mentioned the term. Either way, you've expressed your views, and whether one disagrees with the OP's terminology or not it's fairly clear what he meant, so let's see if we can turn this thread into something useful. Call them "mud patterns" if you prefer, or PGSTCMPs (Proven Generic Solutions To Common Mud Problems), or whatever you like. Or just avoid naming them at all if you like. I don't really care what you call it, it's the concept itself that interests me.

Runter said:
I welcome an actual discussion on this topic.

Then how about sharing your views on some of the solutions to mud design problems that have been discussed? Do you feel these would be good candidates for clarification and documentation? What aspects of mud design have you seen independently reinvented? Did you ever develop something mud-related only to later discover that someone else had already done it the same way?
10 Jan, 2011, Runter wrote in the 15th comment:
Votes: 0
It's not just a naming issue. If you had read/quoted/whatever you do with full text on these forums you had seen my actual point. Whether you call it a design pattern or a programming pattern, when you couple it with talking about established programming patterns (as has been certainly mentioned on this thread a few times by multiple people including the OP), you're talking about programming patterns. If my two short paragraphs were tldr then just let me know in the established protocol. We don't need any more actual red herrings.

Quote
Then how about sharing your views on some of the solutions to mud design problems that have been discussed? Do you feel these would be good candidates for clarification and documentation? What aspects of mud design have you seen independently reinvented? Did you ever develop something mud-related only to later discover that someone else had already done it the same way?


Most commonly I've developed things to find later there were generic programming patterns that fit it perfectly without knowing because people usually describe these things on forums without discussing the actual established, proven design pattern underneath the implementations. Which we seem to want to do again, for some reason.
10 Jan, 2011, KaVir wrote in the 16th comment:
Votes: 0
Runter said:
Most commonly I've developed things to find later there were generic programming patterns that fit it perfectly without knowing because people usually describe these things on forums without discussing the actual established, proven design pattern underneath the implementations.

Which things did you develop, and which patterns did you later discover would have provided you with a better solution? I use some design patterns out of habit, but I find they cover much simpler concepts than most mud features, and I tend to view them as more of a general skillset for software design and development.

Within the context of this thread, I think it would be more interesting to discuss particular features and problems directly related to mud design. For example I'm not so interested in discussing how a quest system could be implemented using the singleton pattern, using the iterator pattern to sequentially access individual quests, etc - that's common programming knowledge, anyone developing a mud should already know that sort of thing, and if they don't there are plenty of books and other forms of documentation that already cover it.

Instead I think it would be much more interesting to discuss common solutions to (in relation to the above example) quest systems that have been tested and proven to work. In other words, we don't worry about common solutions to general programming problems, but instead focus on common solutions to mud-specific problems.

You want to learn how to use an abstract factory pattern or a scheduler pattern? Pick up a book, there are plenty of them out there. But you want to create a combat system or a magic system for your mud? Not so easy to find the information you want without trawling through code or extensively playing other muds - even though there are several well-established solutions that have been tested and proven to work well, nobody seems to have documented them. It'd be nice if they did.
10 Jan, 2011, Runter wrote in the 17th comment:
Votes: 0
Quote
You want to learn how to use an abstract factory pattern or a scheduler pattern? Pick up a book, there are plenty of them out there. But you want to create a combat system or a magic system for your mud? Not so easy to find the information you want without trawling through code or extensively playing other muds - even though there are several well-established solutions that have been tested and proven to work well, nobody seems to have documented them. It'd be nice if they did.


Those patterns which you seem to dismiss aren't inferior to some abstract design, regardless of how conveniently chosen your two examples were there. How about a flyweight pattern wilderness? How about facades or decorators or just simple proxies for your game-object (npcs, items, whatevs) instancing? How about a reactor pattern for various service requests? These patterns appear throughout computer science. If you're not using them in a large but simple program like a mud. You May Be Doing It Wrong™. This is the type of discussion I think forums like this should have in regards to implementing features, but this seems a farcry from discussing in the abstract what is exposed to the player instead of the actual structures the muds themselves are built upon.
10 Jan, 2011, KaVir wrote in the 18th comment:
Votes: 0
Runter said:
How about a flyweight pattern wilderness? How about facades or decorators or just simple proxies for your game-object (npcs, items, whatevs) instancing? How about a reactor pattern for various service requests?

Well the flyweight pattern itself would just cover the data storage (my wilderness "terrain template" approach could be considered flyweight), while the facades would be more of an interface (a bit like the way I handle my Thing/Brain approach), etc - for a mud feature you'd really need to flesh the concept out a bit more for it to be useful.

But other than that, sure, I think there's value in listing any general solution (to a commonly occurring mud design problem) that's been tested and proven. Such information isn't just interesting to new mud developers (who'll be able to see what tried-and-true approaches have proven effective in the past) but also to veteran mud developers who may be interested in seeing what alternatives their peers are using.

Runter said:
These patterns appear throughout computer science.

Sure, but let's focus on the mud angle - as I said before, there's already plenty of books and documentation covering general use, and most mud developers should have some understanding of patterns anyway. I guess it might be of academic interest to list how different design pattern can be used to help create existing mud features, but assuming the reader knows what design patterns are (or is willing to spend a couple of minutes looking them up), simply listing "a flyweight pattern wilderness" isn't really any more enlightening than "an array-based wilderness". If someone is planning to create a wilderness system, they're going to need to know more than just how to store the data.
10 Jan, 2011, David Haley wrote in the 19th comment:
Votes: 0
KaVir said:
it's fairly clear what he meant

I don't think it's clear at all what was meant, because clearly you have interpreted it rather differently from Runter and myself (and others). So instead of speculating, I propose that we simply wait for clarification. (That said, a discussion can be interesting/useful regardless of whether or not the OP actually intended it to go some way or another.)
10 Jan, 2011, plamzi wrote in the 20th comment:
Votes: 0
Crollster said:
…help future developers, but also help cut down on some of the more frequent newbie questions (such as, "should I have 1 thread per connection," etc) that pop up on such forums like this (and hopefully prevent the (aptly named?) "Big ball of mud" anti-pattern that becomes common in some of the more ancient code-bases).

Anyone have a pattern they want to share to get us started?


Judging from the discussion so far, I think a good way to focus this thread is for a specific question, such as "Should I have 1 thread per connection?", to be asked and answered in turn. A lot of people here are quite used to answering such questions periodically, so they can do the pretend-asking. And it may help to answer them all in one place, pre-emptively, which is I think what the OP suggests.

There's nothing wrong with ending up with yet another FAQ. I think it would be a lot more helpful to new coders than an abstract discussion on programming methods, which would be difficult for them to anchor into their own limited experience, and which may only end up being useful to a very limited number of folks who start out writing their own codebase.

Given that the vast majority of new coders begin with questions about codebase selection (as opposed to questions about basic game design), maybe a set of questions is in order such as: "What's a good codebase that lends itself to [a roomless world | an RPI environment | smart mob AI | instanced zones] and why?"
0.0/37