Transactions.

Transactions are a good way to prevent data corruption due to a failure in the middle of an operation. Another safeguard against bad data is foreign keys. If you know, for example, that your room terrain types can only be ROAD, WATER, GRASS, HILL, or FOREST, you can make a table of terrain types which your room table references as a constraint. So any attempt to modify or insert a record with some value NOT in the terrain type table will be rejected by the database itself.

By using foreign keys wherever you have fixed sets of possible values, you can help protect against buffer overflows and other in-memory corruption that doesn't always trigger a crash, but can screw up values that a plain file system will happily write out and read back in again. Even if you check and discard invalid values when reading, once it's been written the actual correct data is already lost.

But easily recoverable as backing up/comparing plain text file is really easy and do not need any real skills (and wont take more than 4 or 5 mins when using any source control program, all that for a scenario that is unlikely to happen anyway (I only had one memory corruption that led to wrong files in…many years). I only question the validity of putting 400hours to retrofit a diku. 400hours is a lot of time, that needs to be compared to 400hours to move your codebase to one that already use a database (and that is probably way more modern, and not using the stupid diku license as well).

You don't necessarily know. Look up signal handlers for seg faults, for example. (And also, look up how often people are told to *not* use them, even on this forum.)

Even if you did know, what would you do? The point is that when your program is so screwed up you're crashing, the probability of your data being garbage is much higher than when everything is normal.

And, of course, as Kiasyn pointed out, transactions help avoid saving corrupted data.


400 hours is a lot of time, but moving to a whole new codebase is a lot more work than 400 hours.

I love my good old CircleMUD. Played it in college and wanted to revive it, not to build a game from scratch. For all I know, the soul of the game is somewhere in the codebase. Dozens of people have invested hundreds of hours into the game and keeping their legacy is part of the project (I'm sure other MUDs are in the same position). And after the initial investment, there's no telling how many hours the db will save me, and how many solo projects it will make possible.

Regarding data corruption:
If you think restoring flat file backups is easy, then restoring database table backups is easier. I could "call RestoreBackup('Tuesday')" but I've never needed to do it on a global scale. Occasionally, I get power surges and was once forced to roll back the player object saves table to earlier in the day. But that's about it.

Well considering all you are saying I doubt your work can be used in other Circle/Diku or am I mistaken ?
I am guessing from what you are saying that as soon you update the database the game is changed, meaning you do not load everything at once in memory like common Diku does.


Different, I use CVS, so recovering any files is as easy as override/update from any version I want. I lose consistency (changing some item stats wont change it everywhere, but I do not want this behaviour anyway)

Most of the schema and a lot of the interface code can be re-used and I was thinking of packaging those up soon to put in the repository. Depending on how far your codebase is from Circle/Diku, you would have to modify accordingly, but it will take you a few dozen hours to do that vs. what I had to do.



No, I'm not there yet. Some stuff like the help files is read from the db everytime it's used, so updating in the db is all you need to do (I do that in a browser). Some stuff, like the main quest table, is indexed by the game for fast access but can be re-indexed without a reboot. Most of the world is currently being loaded only at boot time and I'll add live refresh options to it depending on how often I need to tweak it without a boot. As it is, I reboot at least once every 48 hrs. due to other code additions so I don't hold uptime sacred…

And as for the hot boot option, there are a number of complications with it for my game. I've never used it successfully on the production server even though I've loaded it with all kinds of safety checks. I'm not crazy about players losing pets, or ending up facing a boss who is suddenly again at full health, or losing keys to a zone they've spent hours collecting, or seeing a roaming mobile disappear… I'd much rather schedule a reboot.

yes.

Oh very nice then. I thought you would have gone all the way already making it too hard to use for someone who is stuck with olc.

I think you completely missed the point, but whatever. If you're not going to be convinced that using a database is a good thing here you'll never be convinced. Your proposed solution is such an OS dependent hack that I don't even want to entertainment it.

I just worry that readers on the fence might not understand how you could so easily hand wave this away. For those readers I say this: Do be very careful about advice you get on a hobbyist site devoted to practices that were appropriate in 1980. Being a hobbyist doesn't mean you have to do things poorly. And fwiw, doing things right usually is just easier in the long run.

MUDs were appropriate in 1980.

Actually, I have OLC save to SQL funcs to share, too. The long-term plan is to build new zones using a web UI but OLC will always be very useful for in-game tweaks. Give me a few days and I'll post all I've got.

It's almost like you're trying to make a point, but just not quite getting there. So I'll wait til you actually make one to reply.

I think that "You don't need X, just use bash and grep" is my new thing I'll say.

And I think you missed mine. I am all in for using database over flat files. But you always have to pounder time put in migrating a flat file system to a database one.
If you stay at a hobbyist level, it may not worth it. A database is better for sure and I never said the contrary.
And as you said 'a database is better in the long run' long run is the keyword. 400 hours is alot of time, and to recoup them you will need to make an extensive use of your database.
It is like the time you would need to learn how to use awk/sed/bash compared than limit yourself to the tools provided by notepad++ to search/replace etc.
Let say you have one nail to plant and no hammer but a rock.
You could drive to the store get a hammer come back.
Using a rock you could have done it before you even started your engine.
All this depends on how frequent you have a nail to plant.
This is a better advice than 'you always have to get a hammer because it is a better tool for the job'. Yes it is…but no it is not always the best solution either. Especially in IT.

You can even check some of my post where I advocate the use of a database to someone instead of using flatfiles…on a NEW project.

World persistence…

Standalone Relational Database Y/N?
Maybe.
It'd be a step back to the 80's, if your mud server already implements an object-oriented database.
A step forward if you're using a typical Diku.
MySQL will frequently corrupt databases in power outages, if you're using MyISAM as the back end.
That's the penalty you pay for speed, poor ACID.
Why not use something more reliable like SQLite, DB2 or Postgres?

Because speed is important, a UPS is $40, and having full-blown features, an API for every language, and nice clients for every OS is sweet.

I prefer postgres of those three options, actually.

Better to use the one that already runs. It is not like the function a mud needs would not be available on any modern DB. I have a phbb forum backed up by mysql so I would use mysql.
would it be something else it is not that hard to modify change of db driver.