10 Jan, 2011, Runter wrote in the 21st comment:
Votes: 0
I'll go first. How do I install the copyover snippet?
10 Jan, 2011, JohnnyStarr wrote in the 22nd comment:
Votes: 0
I think the idea is great, but I don't see it working universally. The main issue is that some of
us are casual programmers. Others are: C.S. majors, professional developers, teenagers with too much time,
visionaries (with little to no programming experience), and some of us are just builders.

Design patterns are useful if the author understands how and when to use them. This requires more experience
than the typical aspiring MUD admin possesses to be successful in adhering to a design standard.

Most Diku-rivative code I've seen is horrible. Sadly, a lot of MUD coders have learned from these poorly written
servers. Once they get an opportunity to write one of their own, they have to spend a long time unlearning bad
habits.

That being said, with newer languages like Ruby, the danger of implementing poor design has been somewhat ameliorated.
11 Jan, 2011, Deimos wrote in the 23rd comment:
Votes: 0
David Haley said:
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.

I'm not going to play pedantic tennis with you over this, but suffice it to say that it satisfies every definition of "design pattern" that comes up on The Google. It's a generic, implementation-agnostic method for solving a common design problem within the context of MUD programming. If you don't consider it a design pattern because its scope is too narrow, then I'll point you here for further reading.

And yes, the virtual wilderness pattern is specific to MUDs and MUD-like games. No, "representations of spatial data" are not specific to MUDs or MUD-like games, but then, I never claimed that they were.
11 Jan, 2011, Deimos wrote in the 24th comment:
Votes: 0
plamzi said:
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

Given that the answer to almost all "should I" questions is "it depends," I would highly advise against posing questions in this format, lest the thread degenerate into ego-fueled, pseudo-intellectual sparring. Try more along the lines of "What are some common methods for handling connections and their respective advantages/disadvantages?"
11 Jan, 2011, Crollster wrote in the 25th comment:
Votes: 0
Ok, I've seen some good points made here, including some I had not considered myself, and it seems that people have expanded on where I had originally thought this thread would go - and that is certainly a pleasant surprise! :grinning:

For clarification: In my OP, I was looking for "new" patterns that applied to mud development (rather than asking what patterns were people using in their muds), but I was actually just looking to stir up a little bit of thought and discussion and hopefully get something useful (for both me and the community as a whole) at the end of it.

For me, a design patten is, as mentioned above, is about a common approach to a common problem (both in programming, and building aspects since our chosen hobby/passion/job encompasses both aspects) - but it is also provides us with language constructs to quickly and concisely convey a design. In this way both "array-based wilderness" and "random-room wilderness" could be 2 perfectly valid mud design patterns. They don't convey too much just from the name, and so would need to be more fully defined in order to be of use, but the principle is there.
11 Jan, 2011, David Haley wrote in the 26th comment:
Votes: 0
Deimos said:
David Haley said:
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.

I'm not going to play pedantic tennis with you over this, but suffice it to say that it satisfies every definition of "design pattern" that comes up on The Google. It's a generic, implementation-agnostic method for solving a common design problem within the context of MUD programming. If you don't consider it a design pattern because its scope is too narrow, then I'll point you here for further reading.

I would suggest this as the reference for what design patterns are in programming (your URL refers to it as well). The whole point of a design pattern is to specify an implementation schematic. A wilderness system can be implemented with any number of approaches, from straight arrays to hash tables to compressed pattern representation (or more fancy spatial-specific data structures). Therefore, a wilderness system is an idea or a feature, and not a programming design pattern. Your own link describes design patterns in this way [1], and not as general features, so I'm not sure why you thought it would be helpful to me in understanding your point.

[1] This is because it describes a pattern as a problem and a solution whereas "wilderness system" is merely a problem. It might be nice to discuss some particular implementation schematic for wilderness systems, sure, but that doesn't mean that wilderness systems (or combat systems or magic design or weapon design or ……) are programming design patterns.

It would be nice if we didn't snipe at each other about pedantry (especially if we engage in such 'pedantry' in the same breath); that is unnecessary and serves only to bring the discussion to a hostile and unpleasant place. This 'pedantry' happens to be the interesting part of the discussion because design patterns are not vague and hand-wavy. As Crollster mentioned in #25, the idea is to have a precise set of vocabulary with commonly understood definitions. If we start out with imprecision, it seems that the whole endeavor loses value.

Deimos said:
And yes, the virtual wilderness pattern is specific to MUDs and MUD-like games. No, "representations of spatial data" are not specific to MUDs or MUD-like games, but then, I never claimed that they were.

Ah, but a wilderness system is a spatial data representation problem, ne? It's a map of things in locations. If spatial representation is not specific to MUDs, then wilderness systems are not either. :smile:

I'm not sure what value we have in laying full claim to some concept as being zomg it's OUR PROBLEM NOT THEIRS. It's a common problem; isn't that enough? This is a serious and earnest question: why is there such value in a problem being completely specific? It could still be useful to have a repository of pointers to solutions to common problems that come up in MUDs, even if those solutions could have been found elsewhere.

Deimos said:
Given that the answer to almost all "should I" questions is "it depends," I would highly advise against posing questions in this format, lest the thread degenerate into ego-fueled, pseudo-intellectual sparring. Try more along the lines of "What are some common methods for handling connections and their respective advantages/disadvantages?"

The answer is indeed almost always that it depends. But you often also find cases where in, say, 90% of the cases a given answer is more appropriate than another; in that case it is not unreasonable to give a general answer and add a caveat that in special circumstances a different solution is more appropriate.
11 Jan, 2011, Runter wrote in the 27th comment:
Votes: 0
Yeah, I'd have to agree with David in regards to problem vs solution. In my view, the problem is here is looking at it like a pattern is the problem itself and now let's list the solution to the pattern. Sure, it may be a pattern. It might be a pattern in terms of what is commonly used in mud-likes. But it's running the weight of a term with very established meaning in design pattern in regards to programming. There's multiple books that are required reading around the country on the topic at many schools. So my advice would be if we're really just wanting a FAQ or list of common features in muds then do that. Imho, identifying the problems is much less interesting than actually identifying design patterns in mudding that can be applied to various problems.
11 Jan, 2011, Deimos wrote in the 28th comment:
Votes: 0
A virtual wilderness is both a problem and a solution. You can create a MUD with a wilderness system that is not virtual at all. You can instantiate every single room if you like. If you have a moderately large world, I'm sure you'll run into the problem of your game being very inefficient as a result. How do you solve this problem? By virtualizing your wilderness. Your implementation may differ from others', but that's to be expected, as virtual wilderness is merely a pattern, not an implementation. There is a big difference between a solution and an implementation of that solution, David. While virtual wilderness is a solution, it is not an implementation. And, as such, it's not very interesting to talk about, which is why I cited KaVir's method in my original post as an example of an implementation of that solution which I found very interesting.
11 Jan, 2011, Runter wrote in the 29th comment:
Votes: 0
It seems like we're not making any progress here at all when we can't even agree that a wilderness isn't a blueprint for how to make a wilderness. Even when you add the caveat of "virtual." It's a difference without distinction to the end user. And it's a fancy way of talking about how to compress/share data without talking about the actual patterns used to do it. It's no more useful than just the wilderness term unqualified. And it'd be similar if I said, no, it's not a virtual wilderness–It's a compressed wilderness. It's a big wilderness. To that end, I think it's a little funny to even use the term wilderness like it's the defacto standard for discussing "big worlds." It's a term come to fame perhaps in the mudding community, but even that isn't a mud specific concept. Look at any MMORPG with big world models. P.s. I don't recommend "big world model" as your pattern either. Not even "virtual big world model."

Just to be clear, I agree that it's a pattern in the sense that some muds do it and some don't. But this doesn't seem like the definition you're applying here.
11 Jan, 2011, David Haley wrote in the 30th comment:
Votes: 0
I don't consider it a "solution" when you don't actually have a schematic to follow to, ah, solve the problem. If I say: "use a hash table to store rooms", then that is a useful solution. If I say: "oh just use an array", then that's a solution (although not a good one). But if I say: "oh use a virtual wilderness system", that is not terribly helpful. What does that mean? What implications does it have on performance? What are some algorithmic properties we can expect?

When we talk about design patterns and say things like "use an observer pattern", that has pretty clear consequences on what is being implemented. You must have things that observe and things that are observed (not necessarily disjoint sets) and you must have relationships between them to establish direction of observation. Whether you use a linked list of observers or a map from observer to observed is a detail of the implementation, yes, but a solution schematic has been proscribed. Algorithmic properties can be discussed with respect to the number of operations associated with changing state, e.g., you have to ping all observers that an observed's state has changed.

As such, I'm not sure what you think it is useful to talk about. If something is a problem and a solution (a contradiction in terms, IMO, but ok) then it's not a general pattern. I think you might have made a typo because your last sentence seems to contradict itself (paraphrasing: "it's not interesting to talk about, which is why I talked about it").

Perhaps I might rephrase it this way:
The problem: I have a lot of rooms, most of which are unoccupied or otherwise uninteresting. How do I avoid having them all in memory?
The solution: Only instantiate rooms that are interesting (for some appropriate definition of interesting, e.g., occupied by a character).

Of course, this solution is trivial (in the mathematical sense) and therefore not terribly interesting. The question begs the answer. How do I not keep them all in memory? By not keeping them in memory. That's tautological. So, ok, what are we actually doing? This is when you get to far more interesting data structures for storing sparse data. Are we compressing them? Are we only storing a subset? Are we using a very clever data structure for spatial organization? Etc.

Basically, virtual wilderness is a data structure problem – again, a problem of spatial representation, or, as Runter put it well I think, of "big world" representation – not a general pattern of design. (Perhaps the data structures are design patterns; indeed it is very common to use a hash table instead of an array when your data is sparse and cannot be indexed directly.)

So what are we trying to talk about? Are we actually looking for design patterns in the conventional sense of the term? (E.g., the Gang of Four's book that I referenced.) Are we looking for common implementations (down to the data structure level) to problems that occur in MUDs? Are we talking about things that users see, or that are purely programmatic? Are we talking about how to set up the game model for builders?

I don't think we're talking about what some MUDs do and others don't. I guess we could talk about that but that seems like a feature comparison project, not an interesting source of information for developers who want to produce code (or world content or whatever).
11 Jan, 2011, Deimos wrote in the 31st comment:
Votes: 0
As I mentioned in my last post, the interesting thing to talk about is the implementation of a pattern. I'll leave it up to you and Runter to discuss what is or isn't classified as a pattern, as it's already boring me.
11 Jan, 2011, David Haley wrote in the 32nd comment:
Votes: 0
I guess your earlier post was unclear. You mentioned the virtual wilderness concept as an interesting thing to talk about, and gave an example. Now you're saying you're only interested in that implementation, and not the concept. OK, that's fine, but at least you might see now why there was confusion.
11 Jan, 2011, Runter wrote in the 33rd comment:
Votes: 0
I'll go back to one of my previous examples. Is color enabled server a programming pattern? What about virtual color enabled? It may be a pattern in the most broad sense of the word, certainly. But that's not really apples and oranges from what we seem to be talking about here. If this thread has any chance for usefulness we need to know what people really think we should be talking about. My vote isn't another features list of mud servers.
11 Jan, 2011, David Haley wrote in the 34th comment:
Votes: 0
I meant to address that but forgot to, thanks Runter. Deimos, the idea isn't to have some random "academic" conversation about what is and isn't a pattern. The idea is to figure out what exactly the goal here is. If you personally only want to talk about a specific implementation of a feature, that's fine. What about other people? I don't think that's what the OP had in mind, for whatever that is worth.
11 Jan, 2011, Deimos wrote in the 35th comment:
Votes: 0

Nope, sorry.
12 Jan, 2011, Chris Bailey wrote in the 36th comment:
Votes: 0
Is that a gigantic straw man? =)
12 Jan, 2011, David Haley wrote in the 37th comment:
Votes: 0
I'm glad to see your contribution to polite and civil discourse, Deimos. Please share further insight with us so that we may all learn and enjoy an interesting discussion. If you actually cared about not being just an ass about this, you could perhaps explain what exactly you object to in what I said. Or not – you've demonstrated fairly well I suppose that you're not interested in a civil discussion. I don't know what you're talking about but given your ridiculous attitude I'm not sure I really care anymore. :thinking:
20.0/37