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.
I don't believe any of the SQL advocates have said trying to run everything out of SQL. If you recall, I specifically mentioned caching in my post, and it's incredibly important. You certainly don't read everything from a file do you? On load up, sure, but everytime you want to spawn a new mob, do you read it from the file again? No, you read it from a "cached" version of the loaded mob in memory. Using SQL is no different. You need to make an informed decision on what should be loaded from the DB and what should come from cache. > 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.. The other route doesn't have to be an extreme. You drew two lines in the sand, on one end there was current ROM, the other was completely SQL backed. It is possible, and probably benefitial to find a middle ground in there. This is not a black and white issue. SQL is a tool, not a bandaid. If you don't design your database properly for the task at hand, then yes, it's going to run poorly. > 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. And the people that aren't knowledgeable aren't chiming in on this thread. Those of us who do database programming for a living are. And even so, I encourage you to take everything said on these forums with a grain of salt. If you don't feel that SQL is the tool for your mud, don't use it. > 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.. There is no reason you have to make 75 times more queries. You can cache a room description and only have to pull it up when there is a cache miss or the cache is stale. You also have indexes to help you find the necessary data quickly. If you are making 75 times more queries, you are missing the point. >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. Again, if you are doing one for one queries per command of the player, then the fault is with your design, not with SQL. Let me rehash my analogy of querying the file system everytime someone casts a spell. You don't do it now, why would we? >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. Yah, the scripting engines allow rapid content development for quests and in game events. They have nothing to do with trimming down the number of database hits. Whether you've got an interpreted script or a compiled function, both can hit the database or not, as appropriate. > 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, So you have to recompile and reboot your application whenever you need that 6th extra section. I'd prefer my app not to go down. And a race is nothing more than data. There is no reason it needs to be compiled in with the code. The only reason ROM does it is because that is how you create static arrays at compile time in C. Otherwise there'd have to be a dynamic collection loaded during bootup to find the races. > But overall, I still have yet to see any valid reason to waste extra > resources just to use sql. I'm gonna say it again, since you somehow missed the point. The wasted extra resources you have mentioned when using sql can all be attributed to a design that doesn't fit the application domain. >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. Sure it can. Any interpreted language is capable of doing it. You could use C# and reflection, for instance. Although I'd be hard pressed to think of a reason why anyone would want to implement the code for fight.c inside 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? Didn't you tell us you rewrote ROM in something other than C? How much coding was that? In the time it took you to do that, you could have just as easily ported ROM to use a DB store. > 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.. Everquest and World of Warcraft, to name two of the most popular. Granted WoW is struggling with the load right now, but that could have something to do with the 1.5 million active accounts hitting their servers every month :) > 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. You are missing the trees for the forest. Why is a mud any different than any other database backed application? In the end, it's just data and queries, and the database doesn't care if it's giving out a room description or telling a customer what's in their online shopping cart. As long as you design your database and application with the load and particular challenges of your app domain in mind, then it's going to work out.
