Flutterby™! : WikiMUD

Next unread comment / Catchup all unread comments User Account Info | Logout | XML/Pilot/etc versions | Long version (with comments) | Weblog archives | Site Map | | Browse Topics

WikiMUD

2004-10-21 02:05:06.803022+00 by Dan Lyke 10 comments

If you need a little mind-stretching this evening, how about thinking about a WikiMUD?

[ related topics: Interactive Drama Content Management ]

comments in ascending chronological order (reverse):

#Comment Re: made: 2004-10-21 23:37:22.127311+00 by: spc476

Thanks, but after reading that, my brain hurts.

#Comment Re: made: 2004-10-22 18:27:01.915765+00 by: TC

some very interesting ideas/concepts but so is a suspention bridge made out of glass(think of the view) but both seem about as fragile...

#Comment Re: made: 2004-10-22 22:29:56.713612+00 by: spc476

What's fragile about the idea (the WikiMUD, not the glass suspention bridge)? Chaotic, I'll give you that, but fragile? Unless you mean fragile in the sense of unexpected behavior and possible bugs (not in the core engine, but in the code people write to manage objects).

#Comment Re: made: 2004-10-23 13:22:41.795804+00 by: polly

sometimes, while reading this *stuff*, i wonder where you guys come up with these ideas? it does hurt the brain to try and follow the wikiMUD, i loved the idea of anyone being able to interact with the program, but when he started explaining how it worked, it got complicated....BUT i persevered and read the whole thing!

now i've got to go find some aspirin.

#Comment Re: made: 2004-10-23 20:53:21.573362+00 by: spc476

In this case, it was when I was half asleep. Fortunately, I remembered enough to write about it the next day.

#Comment Re: made: 2004-10-25 15:26:35.300924+00 by: flushy

I actually understood what he was talking about it. I've played muds for too many years.

The problem with a wiki-mud would be the asshole ratio. There are far too many assholes out there than good players. Thus, you'd log in one day, and find the entire world deleted and replaced with BevisHead's Land O' Ultimate Destruction!

#Comment Re: made: 2004-10-25 16:19:23.85301+00 by: Dan Lyke

What got me interested in MUD/MUSHes in the first place was the reconfigurability, but the ones I saw always had some mechanisms for security and ownership. One of the arguments used about Wikis is that damage gets repaired quickly, I wonder if perhaps the thing to take away from that is to build in a simple "undo", or find other social ways to keep the assholes uninterested.

#Comment Re: made: 2004-10-25 18:06:24.084138+00 by: Mars Saxman

I suppose this is to be expected from a programmer, but it seemed to me that the meat of the article was in the sub-page, "Rambling about programming":

But what if both nouns and verbs are significantly large? What if you have a hundred different data types and a hundred different actions that can be applied? (One hundred of each ever after you tried reducing the number of both?)

This is a really interesting question. At least, interesting enough to me that I worked on designing a language designed to answer it back in the early '90s. I'm a little disappointed by the "throw lots of developers at the problem" answer, because it doesn't move us beyond the current state of the art. This problem is begging for automation: we need some new level of abstraction that describes possible actions in a way that can be somehow expanded to cover all the different possible datatypes.

I've never actually played a MUD, but it seems that a MUD-world must be similar to the sort of giant, sprawling, continuously maintained programming project I was trying to support with my "Sierra"-language project. Flexibility is the big problem in software engineering: it's easy to design a program that works; what's hard is to design a program that works and will keep working under new and unexpected circumstances, or to design components of a program that will keep working when the rest of the program has been replaced. Both of the big revolutions in programming abstraction levels have involved mechanisms for increasing flexibility: first there was structured programming, which broke programs up into supposedly self-contained units that talked to each other via parameter lists and return values; then object-oriented programming, which grouped programs around the datatypes they affected and introduced the notion of polymorphism.

I would argue that C++ templates and generics-based programming represents as large a climb up the ladder of abstraction as OOP itself did, since it allows you to write code in terms of a generic algorithm which may be applied to any datatype capable of performing the actions required. And now we're getting closer to something that might be able to support a MUD.

So it seems to me that the way to develop a MUD with a hundred types of objects and a hundred different actions to perform on them is to develop a language which allows you to describe an action in terms of the attributes of the objects it can apply to and the sub-actions of which it is composed. Imagine the concepts of inheritance, composition, and interface implementation applied to methods instead of classes. Polymorphic methods, perhaps.

-Mars

#Comment Re: made: 2004-10-25 19:50:10.412876+00 by: aiworks [edit history]

Assuming that there's some commonality between nouns/verbs, this is part of the design goal of Aspect Oriented Programming. None of (what I would consider) reference implementations are anything I'd actually want to throw at a problem, but it's good to see bigger ideas out there.

Some AOP links: http://eclipse.org/aspectj/

http://www.onjava.com/pub/a/onjava/2004/01/14/aop.html

#Comment Re: made: 2004-10-26 01:31:58.045116+00 by: flushy

On several of the muds I was on, I always wondered why a transactional database wasn't used. Not just for the data types, but the world state as well. You're talking some serious memory, but the benifits would be huge.

I don't understand why we always have to do things in code, when we can design the datatypes/database to accomplish most of the manipulation. I guess that is where the wikimud would be headed - a database driven world. The language you would use to describe the world would need to be something akin to Ocaml - something that is very functional that could be natively compiled. An interrpreted language just isn't fast enough to handle the interactivity of a mud.