Re: Got a License for That?

[Maxi Rose]

Why is it that MUDs have to make money? And why is it money is the only thing that drives innovation? Is money the best thing for driving innovation? Hands down yes. But why does money have to enter into the MU* picture?

If you've ever been to Darker Realms LP or any of the other heavily-modded MUDs out there, you'll see innovation and interest coded without money as the driving force. They didn't need it, and it's greedy to need it.

The original authors of LP, Aber, and other flavours coded their servers so people could have FUN. If they wanted money to be made off of them, they would be making the money, themselves. Why spend hours and hours, years possibly, even, to make something, only so that some lazy moron can make money off of your work by adding in a personally-written "theme" and not adding any real code to speak of? Or adding 165482th guild/clan to the list of already bloated guilds/clans out there.

The problem here in this article also, lies in that the author has conflicting interests. He works for a For-Pay MUD server, and is decrying free MUD servers. Gee. I wonder why that might be?

Even if MUD servers and devteams are poor at documenting any and everything about their source, at least you don't have to pay hard earned cash for a game built around the premise of:

Bob verbs adverbly at Mary.

For the same cost to join a Skotos game, I can play Ultima Online or EverQuest and get FULLY GRAPHICAL games with constantly-changing content, better mobs, more items, more interactive commands, and NO interference from game staff, no obvious favouritism, and THEY don't censor you if you have something less-than-stellar to say about their company or their adminning practices.

I'll do our friend, here, the service he could not be bothered to do, himself, in trying to downplay the competition. Here's links to several flavours of MUD and MUSH source code webpages. I just typed in "MUD source" into Google, and here are some links I got, in the order Google gave them to me:

Desolation of the Dragon MUD - Source
Overview of gnome-mud source package
About PerlMUD 3.0
SourceForge.net: Project Info - Koala Mud Server

But of course, our author, here, no doubt wants to only talk about "famous" codebases. So here are links to "famous" codebases and their source. I found them, again in Google, by typing, "diku source". Here they are in the order Google gave them to me:

The Mud Slide

Wow! That webpage, found on page one of Google, has ALL the major "famous" codebases! So much for not being able to find anything about these codebases very easily.

Shall we talk about the Tiny- flavour of codebases? I can easily dig up the source pages for TinyMUSH 3.x, TinyMUX, TinyMUCK, and PennMUSH. More obscure codebases can be found as well, but I don't dabble in them so haven't looked:

TinyMUSH 3: The Home Page
MUX 2.2 Main Page
FuzzBall Software
PennMUSH Home Page

Before anyone decides that MUD codebases are sliding into the ground or are impossible to find or ANYTHING is absolutely TRUE as written by a person with conflicting interests, do your homework. My digging took less than five minutes. It's like listening to movie critics, and how often has a movie critic been right for anything but an OBVIOUS Oscar-nomination movie that you could smell a mile away?

[Sentack]

I may be mistaken but I think actually the author was trying to make diffrent points then the ones you only picked up on. What I got from the article, and I must admit, from my own casual observation, I find to be true, Is the following. Most open source based MUD's have stoped evolveing lately. As a matter of fact, they seem to be quite stagnant universaly.

On top of that, you have lack of documentation, and in a lot of cases, I've seen that as well. Not to mention other odd little things like all but one of the built in mudlib's that come with the source to LDMUD don't actually WORK anylonger. One of them does and while it may be nice that one does, I really wish the other examples where more playable.

The thing is, and this is kind of true with a lot of OSS projects is that a lot of what your expecte to learn, is thru FAQ's, Trial and Error, and the Search Feature of every Forum and Newgroup available to the project. Rarely have I seen good honest basic docs for any of such projects that explain the basics to advance and remain up to date. It doesn't help that good docs are expensive to make and very boring. So few people really put the effort into it. And once a project gets of a specific size, things get forgotten, out of date and basicly ignored till the point that your only choices are just sludgeing it out on your own.

Combine with the fact that typicaly, most MUDS tend to thrive thru replication then inspriation you get a situation where you have a lot of projects that really look alike minus a few minor or major tweaks. But for a for pay company to really be successfull, THEY have to be inspirational to attract and keep customers. So thus, When a pricetag is involved, inspriation is what keeps you alive compared to the other guys.

It doesn't mean free muds can't be the hot beds of inspriation. It just makes it less likely once you take into consideration the greater whole.

Overall, the auther has a point, OSS muds are in a lull when it comes to code and docs. They haven't even touched recent concepts, many just still do things the same old way, many are still much more diverse and enhanced then the new MMOG's are, but that's changeing with time as the big developers are pumping in more time, effort and funds into bigger, better, more creative works.

All in all, OSS MUD's are sliping behind the curve, but do they need to stay above the curve? Maybe not. People still love em, people still play em. Angband hasn't changed much over the years. Today you hae Diablo, a bigger rendition of the game, but that doesn't mean Angband should change to match the times that drasticly. It's still just as fun now, as it is then, and it does what it does well.

Sentack

[Lee]

I think, Maxi Rose, that you are missing the relevant points of the article and inserting some of your own.

One of the main points of the article was that the technology behind free mud codebases is years behind the curve compared to todays commercial engines. And that when the occasional advancement is made it gets 'lost'. Word often never gets out about its existence. Even if the source code is published it never makes into some central distribution for that codebase. This is not in anyway saying 'all free muds suck' or anything equivalent.

Technology/architecture affects a MUD by dictating how easy or hard it is for the game desinger(s) to implement thier ideas. Obviously many free muds are fun and full of good ideas. But I bet you the coders had to work much harder to implement those ideas than they would have using a more advanced engine.

I could bitch all day about how hard it is to write a minesweeper game in C using notepad. Or I could use an IDE specifically made for writing C code to make minesweeper and have a much easier time of it. Either way I get my minesweeper game, but I would be well within my right to say how problematic it is to write C code in notepad.

Relax, take a hot bath, and read the article again with a different perspective.

[Maxi Rose]

I can see what you're saying, Sentack. It makes perfect sense. Maybe I misinterpreted what he said a little.

I still stand by my view that if you want lots of people to PAY for a MU*, you need to provide a LOT more than:

Bob verbs adverbly at Mary.

I've played Castle Marrach. It provides me less features than many, if not most FREE MU*s. As well, most free MU*s don't rely on subjective staff for character advancement. Free MUDs have mobs you can fight to gain money and XP which goes up based on how much effort you put into killing the mobs. You level up regardless of whether staff thinks you're their best friend or not.

Even most MUSHes, which have no coded mobs, allow your fellow players to rank you for quality, handing out XP points when you earn them.

Now to address the main issues I only partially touched on, or may have incorrectly noticed:

MUDs are more static these days simply because yes, when you're not being paid, it's hard to be as motivated. As well, people horde code. They code something cool, they do not share.

I code for the Pueblo MU* client, and any code I make, I offer up freely to help further the Pueblo community. Unfortunately, not everyone feels the same way. A lot of times, games want to seem "cooler" than their competition, and the one way they feel they can do that is by having cooler code, unlike anyone else's. This hording may be innovation, but it's still hording, and that leads to stagnation, despite the cool code. Look at the semi-famous MUSH variant called RhostMUSH .

Here's their "license agreement" of sorts, for allowing other people to use the code. See how wonderfully stifling this all is.

http://rhost.mybis.com/availability.html

Especially look at this passage:

3. We would greatly prefer that no one rape our mush for ideas in other servers. And if you do get an idea from our server, please put a credit down that you got it from us. You don't have to ask us permission for ideas, but we would appreciate it and it does show some deal of tact. Please make a generic credit to 'RhostMUSH'.

Apparently, we're not allowed to be inspired by their work unless we duly notate this in our code or credits. As well, inspiration is considered "rape". And the main coder, a guy called Ashen-Shugar, raves on and on about how great his server base is and how others either suck or are full of bugs. If his server is so great, why doesn't he share?

If Ashen-Shugar charged people for access to his games or to the code, would this cause greater innovation? Only for those people with no interest in game creation. Creators are stifled by For-Pay schemes because it prohibits them working with existing code to improve it. Instead, they have to reinvent the wheel just to be able to improve on it, and many people just don't have that kind of patience. This is why we have so few games of that sort out there that succeed, and they're mostly backed by major corporations.

Those with money, or backing to GET money, create the new, innovative games. I have great ideas, so I think, but not the coding experience in C++ to be able to implement them, or connections within EA or Sony to get someone else to make my ideas a reality. As such, my ideas don't happen in C++-based languages. I code rather well in TinyMUSH, however, and with the Pueblo client, and because both give me free access, I can make my "great" ideas a reality in those code bases. Their being free and already well-coded allows me to build upon them and make new things and new ideas. I don't have to start from scratch.

To address Lee, Castle Marrach is a "commercial engine". Please tell me how "advanced" `Bob verbs adverbly at Mary.' is. I seem to not understand the meaning of "advanced". Maybe this is some sort of Invader Zim reference?

[nigel_ht]

Why is it that MUDs have to make money? And why is it money is the only thing that drives innovation? Is money the best thing for driving innovation? Hands down yes. But why does money have to enter into the MU* picture?

Eh, I prefer a license that will allow me to recoup my recurring expenses at a minimum. That's ignoring the time required to actually code the content for a mud.

Which is the hard part IMHO. The engine is the prerequisite but the heart is the content.

You support the author's assertion that mud code bases are stagnating because they aren't cross-pollinating and the "coolest" code is being kept internal to a particular mush rather than making it back to the wider community.

As far as Skotos and cost Marrach isn't the only mud on skotos, there is The Eternal City (which sounds more like your cup of tea). Plus you get M59 and Underlight in the package along with a couple other games outside the RP arena (like turn based strat, etc).

My biggest complaint with the author is I'm waiting for some meat. So far this stuff is pretty fluffy...I want to know the pros and cons of the various code bases. Heck, a table of what language they are written in would be a good start.

I also want to know what core functionality is the difficult part in writing a mud server.

Bob verbs adverbly at Mary is only one portion of the codebase. There has to be more to it than that...but looking at the few code bases I've seen gives me a headache. Both the code and the content creation mechanisms seem to me to be arcane, or more accurately obsolete.

Heck, is there a modern mud codebase written in C++/STL (or Java) using mySql as the persistence layer?

I'm guessing that many of the coders who might have coded a new codebase are working on graphical mud codebases instead. Its a heck of a lot cooler...

Nigel

[angelbob]

A minor correction...

The problem here in this article also, lies in that the author has conflicting interests. He works for a For-Pay MUD server, and is decrying free MUD servers. Gee. I wonder why that might be?

I'm the author. I don't work for Skotos. I get paid nothing for these articles. I'm paid for programming, but that's a different company (NVidia) for unrelated work (graphics drivers).

I have a codebase I wrote, called Phantasmal. It's public domain, and I make no money off it. You can find it on SourceForge. I've written a lot of LPC documentation, which I give away free, and license as public domain.

So actually, no, I don't consider this a conflict of interests. You're welcome to differ, but asserting that I work for Skotos is simply incorrect.

[angelbob]

Why is it that MUDs have to make money? And why is it money is the only thing that drives innovation?

Time, not money, drives innovation. And money buys time.

don't have to pay hard earned cash for a game built around the premise of: 'Bob verbs adverbly at Mary'

That's like saying you should pay hard-earned money for a game like Baldur's Gate which is based around the premise of "move your mouse around a bit and hit the buttons." You're confusing the UI with the game. Unless you mean that nobody should ever pay for a social game since that's only communication with other people, and nobody should pay for that.

The phone company and your ISP would beg to differ on that point, though.

For the same cost to join a Skotos game, I can play Ultima Online or EverQuest and get FULLY GRAPHICAL games with constantly-changing content, better mobs, ...

Griefers, fewer staffers, less continuity... You're welcome to say that EverQuest works better for you, and that's fine. Saying it works better for everybody is just silly.

NO interference from game staff,

You consider this a feature? I'd call it a bug.

no obvious favouritism, and THEY don't censor you if you have something less-than-stellar to say about their company or their adminning practices.

It's possible Skotos does this, but I've never caught them at it.

[angelbob]

To address Lee, Castle Marrach is a "commercial engine". Please tell me how "advanced" `Bob verbs adverbly at Mary.' is. I seem to not understand the meaning of "advanced". Maybe this is some sort of Invader Zim reference?

Heh. By 'advanced', they're referring to several things. You're right, adverbs aren't enough to warrant that by themselves.

Castle Marrach has a software architecture that is essentially zero downtime. That's not to say the servers are perfect, but the software layer makes it possible to keep stuff persistently forever, to a level that's not possible in, say, EverQuest. If you do a web search on "DGD mud" you'll find some sites (mine, for instance) that explain this in more detail.

CM also includes the whole "prox" system, which may not be rocket science but I can't name a free MUD that has anything similar. Also, there are details -- there are a few free MUDs that allow them, such as my own, but they're not at all common.

However, most of what you're paying for in Marrach isn't any of that. It's staffer time and builder time. Since you seem to dislike what they build and resent time staffers spend on you, perhaps you shouldn't subscribe to Skotos' service. People who actively dislike customer service certainly shouldn't be forced to pay for more of it. Go somewhere that they'll ignore you :-)

[angelbob]

My biggest complaint with the author is I'm waiting for some meat. So far this stuff is pretty fluffy...I want to know the pros and cons of the various code bases. Heck, a table of what language they are written in would be a good start.

Unfortunately, a lot of the meat you want would require a lot more total writing than you're going to get in a biweekly article. What I mean is, it takes many pages to dissect this stuff, and even, say, a decent comparison of parsers between three or four MUD codebases is longer than one of these articles.

On the one hand, that means I have material for, like, forever since I can just go analyze particular features of particular codebases. On the other hand, it means you won't get a ten-page summary that tells you everything you want to know about all the codebases.

I also want to know what core functionality is the difficult part in writing a mud server.

Almost none of it. No single part is surpassingly difficult. However, there are many individual parts and they need to be coordinated with one another. The problem isn't the difficulty of the parts, it's the size of the whole.

but looking at the few code bases I've seen gives me a headache. Both the code and the content creation mechanisms seem to me to be arcane, or more accurately obsolete.

"Obsolete" implies that there's something newer and better out there. What are you thinking of?

The code is somewhat arcane, but mostly it's built by too many different people, and too few of them knew what they were doing. Codebases that were built by a smaller team tend to be better about this, but those aren't the big popular ones.

The building mechanisms are *very* arcane, and that's actually where Skotos is doing much, much better than the free MUDs. Their work, though, isn't free, so you don't see it adopted by the free MUDs. Go fig.

The problem is that building over a text/telnet interface is *hard*. It's hard to come up with a good interface, and almost all existing ones suck. However, if you don't build over a text/telnet interface then you have to build your own client and you're suddenly not platform-independent any more. Java takes you partway there. That's what Skotos uses, and what ScryMUD used for its Hegemon client. However, it's not really all there yet, which is why older Linux distribs won't play Skotos games properly (nor run Hegemon, frequently).

Heck, is there a modern mud codebase written in C++/STL (or Java) using mySql as the persistence layer?

Ah, by "obsolete" you mean "not using your favorite platform". STL and C++ aren't cure-alls. In fact, they tend to make things worse if the programmers involved aren't very skilled, and most MUD programmers aren't. I'm a fan of DGD, which replaces both C++ and mySql in your example.

But yes, there are codebases written in C++ and mySql. I have yet to see one that isn't buggy, glitchy and severely incomplete, and I have yet to see one that has been adopted for anything large by anybody but the author.

I'm guessing that many of the coders who might have coded a new codebase are working on graphical mud codebases instead. Its a heck of a lot cooler...

Yeah. Those never get anywhere either, but for slightly different reasons.

[Lee]

Originally posted by nigel_ht
Heck, is there a modern mud codebase written in C++/STL (or Java) using mySql as the persistence layer?

A codebase should judged based on the tools the programmers used to implement it. I could write an awesome codebase in C or an awful one in C++/STL (or Java) using mySql as the persistence layer.

One should decide what features makes a codebase advanced and then pick the tools that best suit the task. It's dangerous to do it the other way around. You could easily end up thinking 'inside the box'.

Personally, I value flexibility and the ability for non-programmers to create the game they want with as little programmer involvement possible. Us coders are slow .

And now that I have a goal, I can pick the tools that work the best.

Lee

[nigel_ht]

Originally posted by angelbob
My biggest complaint with the author is I'm waiting for some meat. So far this stuff is pretty fluffy...I want to know the pros and cons of the various code bases. Heck, a table of what language they are written in would be a good start.

Unfortunately, a lot of the meat you want would require a lot more total writing than you're going to get in a biweekly article. What I mean is, it takes many pages to dissect this stuff, and even, say, a decent comparison of parsers between three or four MUD codebases is longer than one of these articles.

No, I don't expect 10 pages...at least not at once. I view these articles in terms of a complete series...though generally its because I start them a year in.

But you're now on page 3...I'm hoping for more geeky details in the coming pages. Three pages of motherhood is cool but IMHO soon there should be one page that is a summary of the state of muddom...at least from the 10,000 ft level rather than the 30,000 ft level.

Then detailed commentary on specific implementations and features as you mentioned.

I also want to know what core functionality is the difficult part in writing a mud server.

Almost none of it. No single part is surpassingly difficult. However, there are many individual parts and they need to be coordinated with one another. The problem isn't the difficulty of the parts, it's the size of the whole.

About what I expected.

but looking at the few code bases I've seen gives me a headache. Both the code and the content creation mechanisms seem to me to be arcane, or more accurately obsolete.

"Obsolete" implies that there's something newer and better out there. What are you thinking of?

I mean that some of the core concepts were pretty advanced...for the early 80s. Its 20 years later and I get the impression that we're still using the architechtures built back then.

The code is somewhat arcane, but mostly it's built by too many different people, and too few of them knew what they were doing. Codebases that were built by a smaller team tend to be better about this, but those aren't the big popular ones.

After a certain point software gets too creaky to be able to change (I guess kind of like people). Too much coupling between modules, too much dead code everyone is afraid to delete, etc.

However, if you don't build over a text/telnet interface then you have to build your own client and you're suddenly not platform-independent any more. Java takes you partway there. That's what Skotos uses, and what ScryMUD used for its Hegemon client. However, it's not really all there yet, which is why older Linux distribs won't play Skotos games properly (nor run Hegemon, frequently).

Java is probably not the right answer for the builder interface. I was thinking more along the lines of blog programs like movable type. While I'm not a PhP coder, I would think that this would be a way to go...assuming that the backend was something reasonably clean...like a RDBMS.

Were I a game developer for Skotos I dunno how much I care if a game like Hegemon plays poorly or even not at all for folks that are running an old JVM. The performance differences between Java 1.4 and the old 1.1.8 on the old distros far outweighs the penalty of not having my game run on someones old slackware distro on a 386 box.

Heck, is there a modern mud codebase written in C++/STL (or Java) using mySql as the persistence layer?

Ah, by "obsolete" you mean "not using your favorite platform". STL and C++ aren't cure-alls. In fact, they tend to make things worse if the programmers involved aren't very skilled, and most MUD programmers aren't. I'm a fan of DGD, which replaces both C++ and mySql in your example.

Not "my favorite platform" but languages that support modern architectures without a lot of workarounds.

Of course modern languages are not cure-alls but they do support modern development paradigms at the code level better than C does. Having done OO C, its a PITA.

And there are tons of books on Java/C++ development as well as for MySQL. How many for DGD? I dunno if its in the old Andrew Busey book...or if that thing is still even in print.

At the content creation level, it should be all transparent anyway.

But yes, there are codebases written in C++ and mySql. I have yet to see one that isn't buggy, glitchy and severely incomplete, and I have yet to see one that has been adopted for anything large by anybody but the author.

Most open source ends up this way. The huge success stories like linux, apache, etc are surrounded by a sea of opensource projects that consist of 3 guys and a page on SourceForge.

These likely have not had the chance to gain critical mass because they are written by programmers for programmers and haven't put in clean interfaces for content creation by non-programmers.

Some features, like guild support, etc will need to be done by programmers that understand code. But for the most part the heavy lifting in MUDs appear to me to be the content creators that bring a MUD to life.

Besides, the original codebases were buggy, glitchy and severely incomplete when they were first written. The counter argument is today they are bloated, outdated and hard to change.

You can't decry that these codebases are slow to change without also acknowledging that old codebases are intrinsicly hard to change if for no other reason of their age and the entropy caused by too many hacks on the original framework.

I'm guessing that many of the coders who might have coded a new codebase are working on graphical mud codebases instead. Its a heck of a lot cooler...

Yeah. Those never get anywhere either, but for slightly different reasons. [/b]

Well, I suspect that the original authors of the current codebases would likely have started one of those projects rather than joined in maintaining creaky old codebases.

And I doubt they'd not choosen the architectures you see today. Code interpreters were kinda cool/state of the art in the 80s...folks wanted to write one just to learn how. Today, I think that folks want to write something else just to learn how.

That sure isn't the case today.

Nigel

[nigel_ht]

You know what I'm looking for? I dug out my old Secrets of the MUD Wizards book by Andrew Busey and in the back is an appendix that lists the available servers circa 1995.

I'd like to see one for 2004.

Here's what it says about DGD

"Written by Felix Croes. A reimplementation from scratch of the LPMUD server. It is disk based, and thus uses less memory. Its also smaller and lacks many of the features of the other LPMUD servers, though it is capable of simulating most of those features in LPC. Many DGDs are capable of simulating a LP, but there are several MUDs that now use DGD to simulate a MOO variant. The name stands for Dworkin's Generic Driver. Stable. Has been ported to Atari ST and Commodore Amiga."

Now granted, there isn't a publisher handing you cash for such a list but hey, I'll buy you a beer.

Nigel

[angelbob]

Originally posted by Maxi Rose
I'll do our friend, here, the service he could not be bothered to do, himself, in trying to downplay the competition.

Actually, I didn't say no codebases could be found, I said that there were a number of major ones that couldn't. For instance, my prime example was PernMUSH, which wasn't on your list and you downplayed by default as "you don't dabble in it so you didn't try to find it."

I didn't say that, say, CircleMUD couldn't be found. In fact, I specifically mentioned that *they* even had a decent web page. Anyway, let me hit your actual links that you mentioned one by one.

Desolation of the Dragon MUD - Source

This is a minor variant on SMAUG with a couple of things tacked on. SMAUG is also easy to find. So are fifty other bastardized versions of SMAUG, none of which add anything real. There are probably decent ones buried in the mess, but I couldn't tell you which.

Overview of gnome-mud source package

Did you look at this, or just post the link? There's not really anything here, other than "maybe some day".

About PerlMUD 3.0

Ditto. Check the source. Nobody sane would actually run this MUD, though it does a couple of cute things as far as using Perl for features.

It is, like the above, more a fun thought exercise than, y'know, a server you'd look for specifically.

But you're right -- Google dutifully returns it.

SourceForge.net: Project Info - Koala Mud Server

Again, did you check these guys out, or just post the link? Note the entire documentation section is "under construction"? And that the whole MUD is alpha? And that they haven't updated since November 2002?

But of course, our author, here, no doubt wants to only talk about "famous" codebases. So here are links to "famous" codebases and their source. I found them, again in Google, by typing, "diku source". Here they are in the order Google gave them to me:

The Mud Slide

Wow! That webpage, found on page one of Google, has ALL the major "famous" codebases! So much for not being able to find anything about these codebases very easily.

Actually, it contains a couple of Diku and a couple of LPC. Specifically, for Diku it contains Circle, Merc and GodWars (which isn't really Diku, but anyway). It didn't contain ROM, SMAUG or any of the other common Diku variants.

For LPC, it contained an old link to MudOS, and even older link to MudOS, an even-older-yet version of LPMUD, one Lima and one Merentha. It contained nothing about CDLib, LDMUD, DGD, DiscWorld, various Nightmare-descendants...

So I'd say within just Diku- and LPC-descended MUDs, my point about there being no good single site summarizing the codebases (I think that's from a previous article) is absolutely correct, and you've just proven it.

Since that page contained no MUSHes, MUCKs, MOOs, etc, you've proven it even further in that direction. Thanks.

Shall we talk about the Tiny- flavour of codebases? I can easily dig up the source pages for TinyMUSH 3.x, TinyMUX, TinyMUCK, and PennMUSH. More obscure codebases can be found as well, but I don't dabble in them so haven't looked:

"Don't dabble in them so haven't looked." Good to know.

I don't know the MUSH codebases as well, so I won't go through a rebuttal like the one above. Perhaps you're right, and only the one specific codebase I was looking for was unavabilable and unmentioned, and unlike the entire rest of the MUD community, this part is clearly documented and easily available. I'll remember that next time I'm trying to find documentation on MUSH scripting languages.

Before anyone decides that MUD codebases are sliding into the ground or are impossible to find or ANYTHING is absolutely TRUE as written by a person with conflicting interests, do your homework.

What she said. But please, do more of it than she did.

My digging took less than five minutes.

Yes. Do more than five minutes of digging.

[angelbob]

Originally posted by nigel_ht
I mean that some of the core concepts were pretty advanced...for the early 80s. Its 20 years later and I get the impression that we're still using the architechtures built back then.

Sort of. Bear in mind that, for instance, nobody has come up with a better shortest path algorithm than Dijkstra for most cases, and that Euclid is still a standard source for Geometry. Some stuff just doesn't change much in 20 years.

You're right that few MUDs use heavily multithreaded and semaphore'd servers, but I'd argue that that's because such monstrosities are really awful to maintain. Most of the 'new' architectures I've seen put forward since, oh, maybe '85 are just not worth the effort for large-scale projects. If there's anything specific you're longing to see, somebody's probably done it in a MUD and it's probably gotten nowhere, but I'd be curious what.

Java is probably not the right answer for the builder interface. I was thinking more along the lines of blog programs like movable type. While I'm not a PhP coder, I would think that this would be a way to go...assuming that the backend was something reasonably clean...like a RDBMS.

The problem with a web interface is that you can either do it as plain HTML/Javascript, which makes for *really* ugly interfaces, or use Java, which you've just said (and I agree) isn't the answer. Server-side scripting languages like PHP have to turn into HTML (and/or Javascript and/or ActiveX and/or whatever) eventually, no matter how cool they are. They just don't make it to the end user.

Were I a game developer for Skotos I dunno how much I care if a game like Hegemon plays poorly or even not at all for folks that are running an old JVM.

I wasn't referring to the game Hegemon. There's a builder client called Hegemon for ScryMUD that automates a lot of the grunt work in the builder commands.

Not "my favorite platform" but languages that support modern architectures without a lot of workarounds.

Are you talking about exceptions here, or what? What do you mean by "modern architectures"? C++ doesn't exactly have the cleanest support for exceptions either, and some of its OO support is awful, and always has been.

And there are tons of books on Java/C++ development as well as for MySQL. How many for DGD?

Not a one that I didn't write or rewrite, so you're correct here. However, books or not, I'm still not convinced that C++ is good for a large multiperson project. Yes, your C++ code may be good, but the word "abusable" is relevant when you may have tens or hundreds of collaborators over the years (think MUD, ROM, Smaug, Diku, etc).

Most open source ends up this way. The huge success stories like linux, apache, etc are surrounded by a sea of opensource projects that consist of 3 guys and a page on SourceForge.

Sure. And you're right, that's not proof that it doesn't work. However, if you ask "why not use those", I still get to say "because there aren't yet any real success stories like that."

These likely have not had the chance to gain critical mass because they are written by programmers for programmers and haven't put in clean interfaces for content creation by non-programmers.

How is this different from MUDs in other languages and on other platforms?

You can't decry that these codebases are slow to change without also acknowledging that old codebases are intrinsicly hard to change if for no other reason of their age and the entropy caused by too many hacks on the original framework.

It's true. When we see a new codebase done from scratch that *isn't*, I'll consider changing my tune.

Well, I suspect that the original authors of the current codebases would likely have started one of those projects rather than joined in maintaining creaky old codebases.

Sadly, yes. One more reason we're not seeing more progress.

And I doubt they'd not choosen the architectures you see today. Code interpreters were kinda cool/state of the art in the 80s...folks wanted to write one just to learn how. Today, I think that folks want to write something else just to learn how.

Not sure what you mean by this.

[nigel_ht]

Originally posted by angelbob
You're right that few MUDs use heavily multithreaded and semaphore'd servers, but I'd argue that that's because such monstrosities are really awful to maintain. Most of the 'new' architectures I've seen put forward since, oh, maybe '85 are just not worth the effort for large-scale projects. If there's anything specific you're longing to see, somebody's probably done it in a MUD and it's probably gotten nowhere, but I'd be curious what.

Eh, your classic N-tier architecture as far as architecture goes. I'd guess the web based muds will follow the typical enterprise web architectures.

If the netcode isn't multi-threaded I'd be moderately surprised as that seems to be a common text book implementation though I suppose that you could just loop through your sockets.

But I include other things I kind of lump into architectures that aren't "architecture" per se but rather the framework for design. For example, its hard to implement many of the design patterns without using an OO language.

Which architectures do you feel aren't worth the effort? I would guess that most are derived from large projects in other problem domains.

I'm not certain that MUDs cross over into the "large scale projects" arena anyway.

The problem with a web interface is that you can either do it as plain HTML/Javascript, which makes for *really* ugly interfaces, or use Java, which you've just said (and I agree) isn't the answer. Server-side scripting languages like PHP have to turn into HTML (and/or Javascript and/or ActiveX and/or whatever) eventually, no matter how cool they are. They just don't make it to the end user.

I think some of the blog interfaces are reasonably well laid out and professional looking. You need to apply text descriptions to objects, set values and link objects for the most common content creation activities.

How much uglier than the text interfaces can you get? @whatsits foo=bar isn't ugly?

Heck, I've helped write web based Network Element management systems for telecom. These things describe the state of fibers pairs and matrix switches as well as setting up complex protection schemes to handle failover cases.

You can make them pretty. You also can make them moderately efficient although a scripting language is more useful for bulk setting of parameters.

I wasn't referring to the game Hegemon. There's a builder client called Hegemon for ScryMUD that automates a lot of the grunt work in the builder commands.

Either way. Telling builders to get something a little more recent isn't a huge heartache IMHO. You can run the latest distros on something as wimpy as a PII 300Mhz. Its slow but it works as long as you have the memory. That kind of rig should run you all of $50 on EBay.

Are you talking about exceptions here, or what? What do you mean by "modern architectures"? C++ doesn't exactly have the cleanest support for exceptions either, and some of its OO support is awful, and always has been.

Better OO support than C. Exceptions do suck in C++...in as much as they are slow. But with smart pointers and container classes C++ is a much more friendly coding environment than C is in terms of not shooting yourself in the foot as well as coming with some useful constructs out of the box. You also tend to get away from things like pointer arithmetic and other efficient but often buggy methods of doing things. I guess those aren't in LPC either but I dunno.

Plus C++ and Java tool support is much better than C.

It's not 1995 where memory, disk or processor power is a major issue.

Looking back on some of the concerns/requirements is humorous. "Runs best with a 1 MB ram disk! Requires 640K!"

Hokay. What do I do with the rest of my Gig of RAM?

Not a one that I didn't write or rewrite, so you're correct here. However, books or not, I'm still not convinced that C++ is good for a large multiperson project. Yes, your C++ code may be good, but the word "abusable" is relevant when you may have tens or hundreds of collaborators over the years (think MUD, ROM, Smaug, Diku, etc).

Well there are a lot of C afficionados, especially in kernel code development but I think that C++ has sufficient history that folks that are not convinced that C++ is good for "large multiperson projects" is ignoring a good decade worth of projects in the software industry as a whole and even within just open source projects...if I recall correctly Mozilla is at least partially written in C++. Parts of Apache are (tho' the core is C).

Sure. And you're right, that's not proof that it doesn't work. However, if you ask "why not use those", I still get to say "because there aren't yet any real success stories like that."

And in 1995 DGD was still considered a newcomer lacking features present in other LPC codebases. /shrug

How is this different from MUDs in other languages and on other platforms?

I dunno that it is different. Though I suppose in 1995 it would have been hard to predict which of the rewrites and new codebases would still be around in 2004.

It's true. When we see a new codebase done from scratch that *isn't*, I'll consider changing my tune.

That isn't what? Creaky with age? By definition, new codebases are just that...new. Lacking features but with a cleaner structure and easier to extend and maintain if for no other reasons than fewer hands have touched them.

Tack on 10 years and I'm sure they'll be messy too.

Sadly, yes. One more reason we're not seeing more progress.

Er, I dunno why you'd think this is a negative. Were it not for Felix Croes deciding to recode LPC from scratch you wouldn't have DGD. I dunno why...licence, code sucked, he was bored but whatever, all codebases started somewhere by someone who wasn't happy with the status quo.

I suspect that hot coders will almost always prefer to choose to build new over maintaining old. That's not to say they wont use libraries, reuse concepts or even older code but I think most prefer to control their own destiny.

Where would we be if Linus decided that FreeBSD would do what he wanted and joined some BSD team?

Not sure what you mean by this.

I mean in the late 80s and early 90s writing your own language (LPC, MUF, U, whatever they called the language in MOO) was "cool" among CS folks. Language writers were "uber" and the industry young enough that there were a plethora of new languages in development and contention.

Saying you wrote a new language from scratch was even a plus on your resume...even if folks rarely did that in the real world.

Today, I'd guess that the first thought of a hot spit coder in college wouldn't be "gee, I could write my own language and parser and that would be the core of my codebase! WOOT!".

Assuming that MUDs are even on their radar (which I think unlikely), I'd have to guess some sort of XML whoosits sitting atop Apache and Xerces or maybe Java and JAXB connecting to postgres or something.

Content builders would export their work in XML to be sucked in by the engine and stored in the DB.

Well, anyways, just my opinion. I'm certainly no expert on MUDs and I eagerly await your following articles.

And um, yeah, I think that if I had a lot of time on my hands I could write a killer new MUD codebase. If there is a coder out there that doesn't think that...well...

Nigel