Database driven Mud

[Raiwen]

I posted a portion of this in another topic as a reply, but I felt it should go here if I really wanted a discussion about it.

I had an idea awhile back, but I dunno if this has ever been attempted. A Mud is made up of a data and code designed to interprete the data. How feasible would it be to have the data SQL driven?

Now, I'm going blind here. I have no way of knowing how Sojourn3 is built. But I do know that in the base Diku mud, the mud files are mostly text based. The player file is usually binary data, but it's still a flat file.

I could see issues of updating these databases in a multi-process environment. You have file locking issues for binary files, and in text files you have different line lengths which could effect an in memory index, and most the default mud files were multi-lined records, etc. This would make it horribly difficult to update text files on the fly.

However in a SQL based database (or anytype of database, c-tree, binary tree, whatever), you'd would have built in consistancy mechanisms, the ability to update tables on the fly (as long as you had code and human-based policies to deal with dumb changes - such as removing a room which a player was already in). You could add items to the mud on the fly. Add monsters to the mud, then to permently pop on a zone. You could add new rooms, and even zones.

Like I said, I'm a bit unfamiliar with how Sojourn3 is setup, so it's probably already been thought about. I would assume the mud uses a fair chunk of shared memory for all the mud file data so all the different processes could access the same data. Probably multiple threads in each process, so that each user doesn't have to be a process or each mob for that matter. Going to a SQL based solution may mean multiple hits to the database server for each request which would mean thousands of transactions - so you could cache the requests in the shared data.

I dunno, I'm rambling in half thoughts. I have no idea how feasible it would be.

[Elseenas]

While I like this idea, I can see a few issues:

1) The MUD would have to be designed from the ground up to support this paradigm.

2) A huge number of possiabilities and rooms would have to be designed for every zone.

2a) This would make zone design difficult at best with a requirement of programming knowledge and fairly large number of additional flags (e.g., "burnable")

3) This would be extremely slow for several tasks

4)The advantages to this far outweigh, from my experience, the difficulty in implimenting it (at least using SQL for something like this).

Keeping things in tables or trees is fairly easy and fast, but wouldn't serve much purpose, particularly in a situation like this where pointer referances make more sense.

The idea is decent, but the devil is in the details and implementation would require a complete rewrite of the MUD core engine.

------------------

Elseenas of No House Worth Mentioning

[Kyos]

Hmm...

I don't see the use of it really.

You can still add items on the fly or zones,
or mobiles etc with the OLC.

Create a new zone -> blabla new 354
makes a new zone nr 354 etc.

Shrug.

[Elseenas]

Number 4 needs to be reversed (reasons not to be programming and surfing at the same time)

[Elseenas]

I don't believe OLC is loaded on the mainmud, just the testmud.

------------------

Elseenas of No House Worth Mentioning

[Selias]

Your post made a little bit of sense to me Raiwen, but I'm just curious as to how the mud is currently written?

Also, can anyone tell me how to load a mud onto a unix machine? I think it's rather complicated, but I have no idea where to start.

sel
blurr@udel.edu

[Elseenas]

Selias:

Depends on the MUD (not very useful, I know, but true). It isn't particularly complicated so long as you have the authority to run a networking client on that server.