Hello All, In regards to the reply that MrPotatoHead submitted, I thought I'd start a new thread and try to get things going correctly instead of adding on to the old burnt out thread.
Before I go any futher, I'm going to say that most of this post is my thoughts and opinions, However, I also have years of experience with php/mysql.. 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.. >> Personal Note: Since I'm a big fan of TADS, HUGO, IF Adventures and so forth. Including LPC, I'd prefer using C/IO to read and write from text files..over SQL. It has worked for many, many years.. Discworld and tons of others are perfect examples. 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. We are not talking about building a commercial CMS system built in PHP/MYSQL. These alone have to be designed in a fashion to output the needed data with the least amount of db queries to keep away from the undisputed killer called lag. Unless you are using more than one server to balance the load like sourceforge and so forth.. I still have yet to see a plain text mud that big using more than one entire server either. 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. 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, 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? 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.. 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 know of or think otherwise, I'd be glad to hear it. Chris
