Here here! I started incorporating sql into my mud about 6-8 months ago, and it was for the sole reason of being able to query aspects of my pfiles without the expense of looping through a directory structure and reading every single pfile for the query text... the database design not only sped up my queries, but also massively simplified the code involved from when I was using the flat file structure... I actually had to start w/ notes and a couple other things before I worked up the guts to convert the pfiles over, and it did take a little training to get myself thinking in db mode, I kept wanting to be able to make like a sub-table within a table, the way you can nest structures in C, and I had to learn how to normalize all of my data, which is now no problem at all... I still haven't converted area files over to it, but I do plan on it... also, you just don't realize how much functionality a db can add to your mud until you actually start implementing it... you can share the exact same sets of data between the telnet and an http interface, allowing real-time viewing of game and player data, without having to set up something to dump that info to an html file from within the source... you can set up a web-based OLC interface for your builders... for mine, I even overcame one obstable of guild ranks, trying to set the MAX_RANK value to something that wasn't limiting to some guilds that may have more ranks, and didn't make me struggle to invent ranks in guilds w/ lesser amounts (i.e. setting MAX_RANK to say, 8, and having to limit myself on a militaristic guild that may have a whole slew of ranks, but having to force myself to come up w/ 8 ranks for a guild that may only have 3 or 4)... I also couldn't allow for different types of rank 'trees' within the guild, say, joining a militaristic guild but going in for intelligence, or as a cook or a tailor, and not a soldier... the database format allowed me to dynamically add and remove different trees of rank, and size all of them to exactly how big or small I wanted them to be, without having to match them in another guild to fill array slots...
Richard Lindsey -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiddukel Sent: Tuesday, April 05, 2005 10:23 AM To: [email protected] Subject: RE: Advanced Topic - Doing it differently. I apologize for the length of this message and this will be the last from me on this thread as no one else on the list seems to be interested in this subject -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Bunting Sent: Tuesday, April 05, 2005 9:57 AM To: [email protected] Subject: Re: Advanced Topic - Doing it differently. > How so? Is this based on knowledge? Know anything about coroutines? >Did you know that they are faster than processes and threading? Did >you know that they also lessen the resource usage because coroutines >don't access the OS kernal whatsoever? Did you know that it was first >done on Linux but is also cross platform capable? Muds of old didn't use coroutines either so as I said your argument of you don't need this stuff because old muds didn't have them and they ran fine is not valid on this point either. > I've never seen a mud with 1000's of live, in use profiles... You've never seen mine, I'm not saying that there are 1000's of people logged on at one time, but there are literally 1000's of pfiles that at the very least get used once a week and therefore are considered "in use". > Sorry to tell you but rom won't load them whether you use a database > or not. A database with that many would make the mud so unplayable it > would be useless. Sorry to tell you but it will and does load 400,000+ rooms willingly and with no adverse affect (besides the fact it takes up huge amounts of memory but memory is cheap). You obviously have to change other things about rom to make this totally playable, things that I have changed but are beyond the scope of this particular thread. >I hope that all of your decisions are not based on "Could be" events >in the future.. I'm trying to plan for future expansion as well but I >am at least trying to do it based on logical facts and not some "would >be" examples.. As I said before, I see a logical solution for >everything than can be mentioned.. It comes from years of research and >learning.. I guess that's why I've learned to get around many of the >problems associated with the standard codebase simply because I needed >to do so.. Not because I thought I had too.. If you yourself don't need an sql backend or threads or coroutines or any of the newer technology that muds are migrating to today that's fine, but my decisions to use them are not based so much on the future as they are solving problems that I have had in the past and continue to have today. My mud does have over 400,000 rooms, a lot of those are wilderness granted but still stored in the areas and rooms databases and still loaded into memory 100% of the time and still occasionally need to be saved or searched through. So just because you've never seen it or for some reason believe that a modified version of rom "won't load" this many rooms doesn't mean it actually won't, hence why I said try it and you may start to understand my personal decision to use an sql database and threads. As for the years of research and learning that you keep trying to throw in people's faces, I'll answer to that only because you keep bringing it up. I'm no spring chicken, I have my BS in computer programming and have been working with C since 1994 and countless other languages before then, some you may have never even heard of. I'll admit I've only been working with muds since 1998 or so but to tell you the truth anything written before then doesn't interest me because I'm not writing a nostalgic mud of old, I'm pressing the limits in proof of concept muds that with time could compete with mmorpg's, but that is not my goal. My goal is nothing more than to realize my vision of a mud with a world that you couldn't possibly explore all of in a years time. I'm not hoping for thousands of simultaneous logins, but if it gets to that point I won't complain, I'll simply start working on linking servers together to handle the load. >I'm not knocking you for your examples.. But you are a bit off on many >of your interpretations of C.. I'm also not interpreting C ... what I said about the language of C is valid, it is not a scripting language, yes you can add scripting languages to it or build a C style scripting language for your mud and I have no doubts if you really wanted to you could add a php enabled web server straight to your mud, but when some immortal searches through all your area files with no database or even threading on your mud it will lag all the players. I'm certainly not saying there is not other ways to handle the problems I've dealt with myself using sql and threads, but they are problems none the less that were not in "general muds of the mid 90's" and need to be dealt with in some fashion that wasn't used on those muds of the mid 90's. All I'm trying to say is just because you or someone else doesn't "need" a particular technology doesn't make it wrong to use it if it does solve the problem in a fashion that does not make the mud unplayable. I didn't simply jump on the sql bandwagon, I tried other options and none were right for me and my mud so I eventually arrived at using sql and threads. Nobody is asking you to use them, but it's also not your place to say that the mud community as a whole is wasting their time with it simply because you had an idea for a mud client that you thought someone should have already developed. >Chris -- ROM mailing list [email protected] Unsubscribe here ->>> http://www.rom.org/cgi-bin/mailman/listinfo/rom
