11 Aug, 2010, Valcados wrote in the 1st comment:
Votes: 0
I've been thinking lately about ways MUD technology can be pulled closer to the 21st century. One thing would be to allow MUDs to use databases. Do any major codebases already do this?

In any discussion of MUD technology, the main question should be what's visible to the players. Performance pro's and con's of databases vanish on a sufficiently powerful server (or sufficiently small MUD i.e. every non-MMORPG MUD in existence), the players themselves wouldn't be able to tell whether the MUD used a database or a filesystem, so from this perspective, it's all academic. BUT… A big advantage of databases is they allow the MUD to talk more easily with more modern systems.

EXAMPLE: MUD helpfile wiki's

Wikimedia stores pages in a database. In principle, the MUD can log into this database and make queries. This creates the possibility of letting players edit helpfiles through a wiki on your mud's webpage. The MUD would periodically query the database for changes, and update the in-universe helpfiles accordingly.

2nd EXAMPLE: Forums

How many times have you joined a MUD… rolled a character… then gone to the forums… and discovered that they require a whole separate registration process? And besides the inconvenience and unprofessionalness of this, there's nothing stopping someone from registering your character on the forums if you haven't already. But the major forum systems store their users in… a database! And in principle, the MUD can connect to this database and perform queries. It wouldn't even be all that difficult, for example, to set it up so players are automatically registered at the forum when they join the MUD. For that matter, it wouldn't be difficult to have in-MUD bulletin boards get copied to the website forums– you could even let people subscribe to their clan noteboards' RSS feeds!

This example combines with the previous example: you could have players auto-registered on your wiki on creation. This would eliminate most problems with wiki abuse: if somebody starts vandalizing the helpfiles, send their character to Hell.

You can easily think of more advanced examples. In theory the whole MUD could be put in a database, allowing all kinds of beautiful features on the website. Have your players' bios, pkill histories, descriptions, etc. online…

I'm seriously thinking about implementing the first example (wiki helpfiles) and making snippets of it for various major codebases. Once the foundations were done for one codebase, it would be straightforward to port them to any other codebase written in the same language. Of course, the more ambitious the project (wiki helpfiles is about the lower limit of ambition), the more work required to port the snippet to more codebases. It's a dilemma. For example, should I build in auto-registration on the wiki to the snippet? But then I wouldn't be able to port the snippet to as many codebases…

Anyway, I wanted to hear what all the great coders and designers here think :)
11 Aug, 2010, Kline wrote in the 2nd comment:
Votes: 0
I have my ancient Godwars running on a MySQL backend (for parts) as nothing but a learning experience for myself. Help files, change logs, a live chat/action history, and part (not all) of player files are stored there. One of the greatest benefits I immediately realized was being able to more easily compare or perform actions on players while they are offline. Letting people set bounties, compare records, etc. I've wanted to move the entire game into the DB but just haven't had the drive to do it as the game has 0-1 players weekly and I've got other more exciting projects at this point. It has a lot of room for improvement in how I did things, but it works, and was a good proof of concept to teach myself something.
11 Aug, 2010, Tyche wrote in the 3rd comment:
Votes: 0
Muds have been utilizing databases and acting as web and gopher servers since before 1994.

If you want a mud that runs on a database that implements an embedded object-oriented language that features dynamic run-time inheritance and also acts as a web server serving up rooms and allowing navigation, note-boards access, help files, it's own code and objects see…
[link=file]727[/link]

Some of the LPMuds integrate SQL databases and HTTP servers. In particular…
[link=file]1169[/link]

Most modern Mushes integrate SQL backends as well like…
[link=file]759[/link]

One of the interesting things is that in the distant past muds have been on the cutting edge of technology…sometimes even ahead of it.
For instance this one released in 1993 also features a language that uses run-time dynamic inheritance that's its own object database query language. I did research on this about 10 years ago and only found a total of one contemporary paper even proposing this notion of an OODBMS in the IBM archives, let alone implementing it. Not only that but you can set up multiple mud servers and walk your character around interacting with rooms and objects residing on multiple servers. Distributed mudding.
[link=file]711[/link]
11 Aug, 2010, Valcados wrote in the 4th comment:
Votes: 0
Tyche said:
Muds have been utilizing databases and acting as web and gopher servers since before 1994.

If you want a mud that runs on a database that implements an embedded object-oriented language that features dynamic run-time inheritance and also acts as a web server serving up rooms and allowing navigation, note-boards access, help files, it's own code and objects see…
[link=file]727[/link]


Am I reading you right: the web server serves up rooms? As in, you can walk around the game universe through HTTP?

I tried to find more on this. The codebase seems abandoned. I was able to find one MUD online running this code, but it was closed to new players and appeared to be run through a standard telnet connection with no special HTTP support. Are there any working examples of the features you just listed? Thanks :)
11 Aug, 2010, Tyche wrote in the 5th comment:
Votes: 0
Valcados said:
Am I reading you right: the web server serves up rooms? As in, you can walk around the game universe through HTTP?

I tried to find more on this. The codebase seems abandoned. I was able to find one MUD online running this code, but it was closed to new players and appeared to be run through a standard telnet connection with no special HTTP support. Are there any working examples of the features you just listed? Thanks :)


Yes, you can browse the rooms, traverse the exits, examine extra descriptions, examine objects and players by clicking on links. That much is the default library, ColdCore. If you want to do more, I expect you'd write more ColdC code. A commercial mud uses the engine, The Eternal City, but they either aren't using $web_daemon in their lib or perhaps don't expose it to the public.

The easiest way to see it is to download it, build it, get the ColdCore lib, compile it and run it. Then look in your browser at http://localhost:1180. The last time I compiled it was 2005, so it's certainly possible there's some bit-rot with newer compilers like gcc 4.x. Actually there's an easier way if you are running windows. Just get the two binaries at http://cold.xidus.net/ and then get the ColdCore lib.

The last maintainer was Bruce Mitchener who is/was one of the admins of TheEternalCity. The last release I am aware of was in 2006. Maybe it wasn't abandoned, but rather finished. ;-)
11 Aug, 2010, Tyche wrote in the 6th comment:
Votes: 0
I found another example from Moo Canada.
The MOO serves up pages at http://www.moo.ca/home where users can create their own personal pages.
It also runs a gopher server at gopher://moo.ca/ where you can browse all the MOO objects and code.
You need to use Firefox for the latter link as Internet Explorer no longer supports it.
And you'll probably have to paste it in as it doesn't look like this forum software recognizes it as a link either.
11 Aug, 2010, KaVir wrote in the 7th comment:
Votes: 0
Valcados said:
You can easily think of more advanced examples. In theory the whole MUD could be put in a database, allowing all kinds of beautiful features on the website. Have your players' bios, pkill histories, descriptions, etc. online…

I already do that with flat files - eg here, here and here. The mud generates the webpages on the fly, so it doesn't really matter what sort of database I use.
11 Aug, 2010, donky wrote in the 8th comment:
Votes: 0
Tyche said:
I found another example from Moo Canada.
The MOO serves up pages at http://www.moo.ca/home where users can create their own personal pages.
It also runs a gopher server at gopher://moo.ca/ where you can browse all the MOO objects and code.
You need to use Firefox for the latter link as Internet Explorer no longer supports it.
And you'll probably have to paste it in as it doesn't look like this forum software recognizes it as a link either.

Thanks for the very interesting posts. :smile:

The cost and unknown benefit of trying these old semi-abandoned code bases (ignoring the examples you gave which can merely use a database on the backend) is prohibitive to finding out that they were so outside the box that has become the standard.
11 Aug, 2010, Valcados wrote in the 9th comment:
Votes: 0
Astonishing. Why isn't this sort of thing present in modern muds? (Kudos to KaVir for at least having a "read-only" version)

(At this point, I should toot my own horn and throw in a link to the Aethar Snapshot, which is a frozen navigable online SMAUG world, a first step I took toward exploring this kind of stuff. Of course this is different since the world is frozen in time. For many years, a non-frozen equivalent would be impossible in HTTP. But now, there is Ajax…)

So how many of you would be interested in adding a wiki for your mud's helpfiles, assuming a snippet existed for that?
11 Aug, 2010, Tyche wrote in the 10th comment:
Votes: 0
donky said:
The cost and unknown benefit of trying these old semi-abandoned code bases (ignoring the examples you gave which can merely use a database on the backend) is prohibitive to finding out that they were so outside the box that has become the standard.


I really don't know what "abandoned" means. I suspect in this day and age of instant gratification, it means you don't get an email within 24 hours solving your problem. Or maybe it means the author(s) stopped writing code for you?
I myself have released updated versions and Windows ports of CoolMud, Genesis, TinyMud, DikuMud, Smug, PernMush, TinyMuck, LPMud and UnterMud in the last five years.
I worked on the Genesis/ColdC project and CoolMud was the basis for the first mud server I wrote so I could probably answer questions.
There are far more knowledgeable people still around to answer questions on Mushes, Mucks, MOOs and LPs.
11 Aug, 2010, Tyche wrote in the 11th comment:
Votes: 0
Valcados said:
Astonishing. Why isn't this sort of thing present in modern muds?


Err.. it is. Unless by modern muds you mean crusty old Diku retreads. ;-P

But even among them, RoT, a RoM derivative in the repo here has had a webserver in it since around 1999.
11 Aug, 2010, KaVir wrote in the 12th comment:
Votes: 0
Valcados said:
(Kudos to KaVir for at least having a "read-only" version)

Actually I did partially add a login option - I removed it for now as I had some security concerns with my implementation, and I've been sidetracked with a lot of other things recently, but at some point I'll reactivate it and finish it off.

I posted some of my ideas for the MWI (Mud..., if you're interested.

Valcados said:
So how many of you would be interested in adding a wiki for your mud's helpfiles, assuming a snippet existed for that?

I display help files as well. The problem is that many of my help files are dynamic, customised to each player, and that doesn't really translate very well to a webpage unless the viewer first logs on.
11 Aug, 2010, Koron wrote in the 13th comment:
Votes: 0
Valcados said:
So how many of you would be interested in adding a wiki for your mud's helpfiles, assuming a snippet existed for that?

I would definitely be willing to make this happen, but I would never rely solely on a wiki style help system. I love players for their ability to keep up with the files when I've forgotten about them, but they do like to get stuff wrong occasionally.
11 Aug, 2010, quixadhal wrote in the 14th comment:
Votes: 0
Part of the trick with adding SQL support to an existing MUD is simply designing the schema and having to deal with the fact that C is a terrible language to use. I say that because you can't distinguish an integer value of 0, from a NULL column, without having a second indicator column (generated by your API) to check for NULL.

There are two ways to deal with moving your game data into an SQL backend. One is to do it via objects (OODMBS), and while that works just fine, you don't gain most of the power that typically gets people thinking about SQL in the first place. Namely, you serialize game objects and stuff them into tables. All that really gains you is (potentially) faster load times and simpler load/save code.

The other way to go about it is to actually define a full schema with relational integrity for all your game objects. The advantages are you can do pretty complex queries to data mine (very handy for balancing your game), and you can remove quite a bit of error checking from your driver since the database itself will ensure values are in bounds. The bad part is, this is a fair bit of work and may require a re-think on how some of your data structures currently fit together.

As far as documentation… that's much simpler, and probably a very good place to start. I assume by "snippet", you mean a limited web browser implemented inside your MUD, so all your documentation is in the wiki and people in game and browsing from the web see the same data?
11 Aug, 2010, David Haley wrote in the 15th comment:
Votes: 0
Note that a lot of the stuff you talked about can be accomplished without using MUD databases at all. Nothing prevents you from having the MUD poke the forum's database on character creation, for example; you don't need an integrated database for both.
12 Aug, 2010, donky wrote in the 16th comment:
Votes: 0
Tyche said:
I really don't know what "abandoned" means. I suspect in this day and age of instant gratification, it means you don't get an email within 24 hours solving your problem. Or maybe it means the author(s) stopped writing code for you?
I myself have released updated versions and Windows ports of CoolMud, Genesis, TinyMud, DikuMud, Smug, PernMush, TinyMuck, LPMud and UnterMud in the last five years.
I worked on the Genesis/ColdC project and CoolMud was the basis for the first mud server I wrote so I could probably answer questions.
There are far more knowledgeable people still around to answer questions on Mushes, Mucks, MOOs and LPs.

I meant as in I never hear about anyone actually using half these older things you mentioned. Not that they are not maintained in some way, or that anyone is not willing to help should there be a request.
0.0/16