On Sat, 2005-04-09 at 03:13 -0400, Christopher Bunting wrote: > So to get to the point, I've seen allot of people saying what can and > can't be done. And my first question is, Have you actually tried to > use mysql for everything within Rom? It can be done with php and > mysql, No doubt. But just to say it can be done in Rom, or any general > diku deriv is a whole nother ball game. To get Rom to load everything, > I mean areas, datafiles, player files, spells, skills, objects, > mobiles, resets, and a spare db table to hold temp values for corpses, > repops and other misc things, You are moreless talking about rewriting > 90% of rom as it stands. Just so we are clear, Everything loaded to > db.. Leaving you with only .c/.h source files and a .sql db. > The whole reason this all originates is because the standard diku > derived mud loads everything into memory to be referenced/manipulated. > (Unlike LPC) It's easy, fast, and it works.. But to go the only other > route, would mean that you use a database, or plain c and simple > generic IO functions to read and write to a text db.. The latter has > been proven to smoke sql..
There is a difference between using a DB to store the info and using a DB to store everything. Also just because mysql is one of the more popular choices it is not by far the only one. Where has this been proven? How is a mud's memory references any different loaded from a DB vs loaded from flatfiles? It comes down to how the DB is used - you don't have to use the DB to replace the temp contents that are stored in memory, and IMO shouldn't unless you have a real need for it (well for rooms, objs, etc) stuff that is rarely used (lots of helpfiles) can be straight queries off a cache, tho you don't get much memory savings unless your mud has a substantial amount of helpfiles - and they get checked often (ie not motd, greeting, etc) > But that still leaves various issues in regards to SQL or MySQL.. I > simply do not think that most people are knowledgable enough of C and > SQL/MYSQL in general to be able to overcome the various issues.. Most > wouldn't even know where to begin trying to load resets, mobs, objects > which are dynamic data to an area and/or room that are dynamic as > well. Then let them try keeping a corpse on a timer show for X amount > of minutes in a dynamicly generated area/room when the players walk > in. That's probably why most don't use it then, it's not for everyone, if you are comfortable with it, then use it, if not don't. If people don't have the knowledge to do it, they will either not do it or will learn as they go - did you just magically download rom and go hey I'll write this in D? No, because at the time D didn't exist, thus you had to learn it. Learning by on-hands experience is good - it's a good learning step. > But the problem I see is that everyone talks about how easy it is.. > But the fact is, it's not easy. You are also talking about each player > making 75 times more queries to the db than a standard user browsing a > web site.. Can you imagine all of Aardwolf's players casting spells > throughout the day.. Prolly hundreds of thousands of spells each day. > Now think of that many db quries along with rooms, objects, mobs, > spells, skills and everything else being queried from a DB. There's a > reason why scripting engines are common in games like FarCry, > EveryQuest and Baldur's Gate but database usage is not...However, A > mud processes 50% more requests per user than any 3D MMORPG that I've > ever seen. While not easy, it's also not hard - basically all you are doing is replacing the file IO operations. Lots of the muds don't do things themselves every time and I'm sure soon as someone came out with a snippet for DB backed pfiles lots would use it because it was done for them. The only way you are making 75x more queries is by design flaw, you don't do 75x file operations, you could, but you don't. This still treads on what exactly you are using the DB for, most seem to use it for storage and few online things (finger, top 25 lists, notes, helps, etc) While you could replace most of the big lists and internal structures with just DB, it imo is a poor design choice, it's not needed. What does scripting have to do with DBs? > I honestly, in my experience still can not see where the end result > would be useful for such a thing.. To simply claim that it makes > adding extra data to areas easier is a bit... well, thats the same > reason why you can open db.c and insert, load_mod_area and add the bit > of code to load your cool new stuff. Then use save_mod_area to save > your cool stuff for the next reboot. > I've said to many people who asked me for ideas before to plan for > further expansion. Even if you only plan on using 4 races/classes. Add > 5 extra spots to each table along with adding 5 to skills and spells. > Add 5 extra sections to the area files if you think you're going to > expand that much later on.. After all, Mud Development needs to be > planned out, and have a foundation just like anything else being > developed. MMORPGS don't just pop up. They are planned, schetched on > paper, it's a long drawn out boring process, In the end it's easier to modify the data in a DB versus flattext. Say you add/remove some fields to rooms, mobs and objects [and you don't have OLC], and need to update your area files to use the new field. Firstly you are probably using some kind of versioning or you have to edit every single file, you create the needed code to check for this new version and read/ignore the extra fields, now you want all your old area files to also use this, that's alot of work to update it - in a DB setting you can add/remove them from all the records at once in a few seconds. > But overall, I still have yet to see any valid reason to waste extra > resources just to use sql. Using sql doesn't make writing spells or > the overall development of the mud engine itself any easier.. Fight.c > can't be stuck in sql. So as a mud coder, you still have to do a fair > share of coding, so why is a few modifications (5 minutes of work) to > add new area/mob/obj data or room features so hard? There is no waste if the outcome is what you desired, we're not paid for this, we do this for our own enjoyment and hopefully other's as well. Why bother 'wasting extra resources' for anything download a codebase and use others areas. If you had a nice scripting engine you could perhaps do spells and skills in the script and dynamically load them from DB/files whatever, however it's not a huge benefit - other than that I see no reason for spells to be in a DB. > I've searched the web high and low and I still, have yet to find any > MMORPG or Mud that uses sql as a back end.. I see tons that are in > development but none that I can find running with players.. I'm sure there are some out there, I can name Everquest and World of Warcraft that use DBs right now, MUDs not so much, lots based off mysql stuff but again not all that popular - now that doesn't mean much, except that thier builders or coders for whatever reason didn't make the mud 'fun' to the masses, I highly doubt that it's the DB that caused that. Does it matter if others are doing it or not? You may well be the only D based mud, will others care about that when deciding to use D or not? (Example: Hmm I want to write a mud in D but I see no stable mass populated muds written in it - that's not gonna stop anyone) > This is by no means to start a flamewar nor am I saying that using a > DB simply can't be done.. But I'd like to learn more about this > myself, see some examples and find some Production Muds w/ 100+ active > players, who are actively using this concept.. If there is proof that > it is proven and working, then I may look into it more myself. I'm > always willing to do or try something new. But at this time, I see > nothing other than a bunch of hearsay on every mud related forum I > come across. If you are willing to try it new, start small do something simple first, perhaps loading the banlist from a DB versus ban.txt, storing helps in the DB, and work towards your final goal whatever that may be. My ideas on using DBs in muds: I don't plan on replacing everything with DB queries, I just plan on removing the need of flatfiles. DB is used for loading and external editing of content (chars, rooms, areas, objs, helps, bans, notes etc) Ideally once done you have the executable and logfiles, everything else is stored in the DB, however it's still primarily modified in memory, while allowing for limited persistence [PC corpses, certain items etc] overall not too much different from how a normal mud does stuff. -- Chad Ziccardi [EMAIL PROTECTED]
