Alrighty, first off, lo all. :)

Secondly, I'm writing a codebase from scratch and I'm presently working on the OLC system and I've got two ideas for saving the data.

First: Each area gets it's own file, much like ROM does. All data is stored there for rooms, objs, mobs, etc.

Second: Each Obj/Mob/Room gets printed to a file like <vnum>.obj, <vnum>.mob, etc and sorted into the mob/obj/room directories.

Which way do you feel is better? There are bonuses to both.

-Aidan

Well, with the first option you might end up with a bunch of files. But with the second one you will end up with three very huge files…

Do you plan on editing any of them offline ever? It is much easier to open the smaller files then it will be to open the larger ones…

If you have mutliple builders building at one time how is it going to save the file? If all the mobs are in one file will it not over write whats there? And what if they both happen to save at the same time?

Maybe I am not understanding it right… for the second option you are saying that all that mobs will be in one file, correct? Or that each mob will be in a file of its own titled with is vnum? Wait that just does not sound right… must be the first thing I said… *shrug*

Ok, the first is how stock normaly does it, each area has all its on data.
The second one is saving each vnum seperate into its own file and if its a .obj or .mob or .room.

I would go with all the area info in a single file. Doing it the second way would make way to many files and would mean if you edited it offline it would be annoying if you had to edit each file.

Well, the thing is this. You won't have to do offline editing. The mud would handle everything in game. Each obj/mob/room would get it's own file and they would be sorted into directories to keep them together.

-Aidan

Well option 3 then.

require 'gdbm'

def save_rooms
  db = GDBM.open("myrooms.db", 0622)
  for room in $room_list
    db[room.vnum] = room
  end
  db.close
end

def load_rooms
  db = GDBM.open("myrooms.db", 0622)
  while room = db.next
    $room_list << room
  end
  db.close
end

Simple. Fast. No parsing. No formatting.
No Headaches.
Xlate to favorite language.
More fun after done. ;-P

Can you explain what you mean Tyche? I don't mean to sound like an idiot, though I know I am, ;) I am not familiar with the gdbm.

-Aidan

I'm not familiar with gdmb either, but I certainly wouldn't go with saving each room, object, & mob to it's own file, even in a small world of 5-8k rooms you could easily end up with literally tens of thousands of little files each taking up a full 1k+ of disk space and if you ever decided to try to do any offline editing, it could be a night mare to identify which files you're actually after.

Interesting Tyche, is that Ruby?

Not really familiar with gdbm, but after a quick look, it appears that it simply stores name/value pairs in the file. Might save a few lines of code, but I don't see any major advantages to it for a mud's database.

As for the original question… what're your reasons for considering these 2 options.

A single area file would be my preference, or a split area file… with <area>.mob <area>.obj <area>.room… I've worked on some circles that use this organization.
This gives you fairly low overhead and keeps the information organized in an easy to work with manner.

If every single room, obj, or mob has it's own file, then you'll get extra overhead during read/write time (managing upwards of 150 times as many files as a single area file would)

Each file also has it's own disk-space overhead, which would increase how much space your game uses. Unless you absolutely need to access each mob, room, item file individually, I'd avoid this.

With a single file for all rooms, objs, or mobs… you run into the opposite problem… needing to read the entire contents, or write the entire contents… (although this can be avoided with some indexing and fseek… assuming you organize the contents).

Anyway, just a few options, I'd say it really depends on what you need, but given flexible requirements, go with a single file for each area… it's a very good middle-ground.

gdbm is gnu's version of a hash database. There's also Berkeley DB (aka bdbm), dbm, ndbm, sdbm, tdbm and quite a few others. More than likely you've already got one or more of them already installed if you are running a unix. The advantage is speed, stability and simplicity.

$ man gdbm

It was never my intention to write everything to a single file. Someone misunderstood my earlier question apparently, no worries though. :)

Tyche, thanks for the help. I will take a look at that and see what I can figure out. I think though that the suggestion of writing a .obj, .room, .mob file for each area is the best solution.

While a lot of my work is certainly influenced by ROM, I'm trying to make it original and efficient at the same time, which is why I'm asking questions. :) Though that is certainly the best way to learn.

-Aidan

That does seem like a nice happy compromise, at least that way you're only breaking each area into three files, one each for mobs/objects/rooms, rather than one file for each mob/object/room mud-wide.

Yeah, I thought that might be the case.

Hello,
There is a codebase called NakedMud, A modified version of SocketMud that was written from scratch some time ago. NakedMud has OLC already written for it and it already saves and loads areas. I think the saving and loading is a bit simular to Diku's style instead of Merc or Rom. It may give you some ideas to check out the codebase though. I think it's written in C.

Chris

cbhunting,

Thanks for the suggestion. I already looked at NakedMud and decided not to use it. I specificially don't want to do things in the way that Diku does and I want to custom write my own OLC so that it's idiot-proof.

Thanks
Aidan

Good luck with making it idiot proof.. I've met a few idiots who could screw up pretty much anything. :wink:

:D

Idiots. The perfect code-testers.

Personally I've started using SQLite3 as a backend. I can't compare it to those other database softwares mentioned, since I haven't tried them. But I think using an embedded database instead of custom fileformats is generally a good idea. SQLite3 already have all the features you'd ever want for a mud (more or less). I find myself spending more time on the really interesting bits, since sqlite can take care of the dirty work for me, especially handle errors that might happen upon reading and writing data. Rollback is a nice feature that I gladly let sqlite deal with instead of coding it myself.

I'm no fan of using anyform of SQL, but, i have to admit, that lately, sql databases have been looking better and better, faster loading/saving than a flatfile, and as i've heard, they eat up a whole hell of allot HD space then a large flatfile would, so yeah, i'm personaly debating this fact myself.

Not to mention that it just seems like a generaly good idea, and safer then the old flat-file way of doing things.

In my experience, SQL databases use less disk space for data than most flat file systems I've seen. Except those which use binary output or have a hard format.

Although indexes can quickly use more disk space than the data does. The biggest issue I've found with traditional sql databases is latency. Haven't used an embedded database so I can't say for certain, but I doubt its a problem.

Justice, Me and Davion have experimented with SQL in our joint scratch MUD, and I use MySQL in my MUD for race storage.

In the Scratch Base, we used it for rooms, mobs, and objs. Made a table for rooms, a table for exit, a table for mobs, and a table for objects.

it works very efficently i like it much better then flat files, as i eventualy plan on making a php based OLC as well. It very quick, and you cant realy fuck it up and cuase crashes unless mysql closes, unlike flat files, you get an EOF and yer screwed.

Jus some of my input