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: rom-admin@rom.org [mailto:rom-admin@rom.org] On Behalf Of Hiddukel
Sent: Tuesday, April 05, 2005 10:23 AM
To: rom@rom.org
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: rom-admin@rom.org [mailto:rom-admin@rom.org] On Behalf Of
Christopher
Bunting
Sent: Tuesday, April 05, 2005 9:57 AM
To: rom@rom.org
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
ROM@rom.org
Unsubscribe here ->>>
http://www.rom.org/cgi-bin/mailman/listinfo/rom
--
ROM mailing list
ROM@rom.org
Unsubscribe here ->>>
http://www.rom.org/cgi-bin/mailman/listinfo/rom