Christopher Bunting wrote:
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
I see what your talking about, and I don't see why sticking things like
spells, skills, fight code etc into SQL *IS* a
good idea. Things like the Ban list, Messageboards, Playerfiles (I have
to say this here, I saw a snip somewhere
where it put all the pfiles into SQL and read them from there, this is a
dumb idea, why not read the sql data then
load it into memory?) Areas, and specificly helpfiles being stuck into
SQL, but everything else?
Lets face it, (using the skills loaded from a file thingy) Its pretty
stupid to have to A) code the skill, B) increment the
MAX_SKILLS, then C) load the mud up, add it through an annoying command
just to be able to use it. Youve already
done A and B, C should just be as easy, open up const.c,
copy/paste/edit. These sorts of things shouldnt be
done in SQL, theres just no reason. Can you pull up Min/Max Damages from
SQL? No, thats in the code, can you
pull up what effect and duration a specific spell does? No. Then theres
no reason to add it to SQL. Infact IMHO
adding SQL to a rom based mud haphazardly is just flat out stupid. You
end up hammering the SQL server
instead of quickly reading it from memory. (flush_connections anyone?)
There are only a few things I belive should be put into SQL for purposes
of exporting it to a webpage, which
really is the only place you need the data elsewhere.
* Help files: Simple, add a search function for helps, link various
parts of your page to the helps wiki style
* Ban List: Its nice to have the Ban list in SQL, you can post it up
on your website, people can petition a siteban for example
* Area files: While adding new areas isnt easier, it just allows you to
create say a 'virtual' tour on your website. This can also be achived by
dumping the files to sql instead of reading directly from it, also
saving on SQL queries.
Possible HTML based Area editor? Have builders directly upload a
finished non-your-mud area into sql? hmm
* Messageboards: Link your ingame notes to a e107/NukePHP Fourm. Cool eh?
* Playerfiles: Easy way to keep track of top10 lists, 'finger' commands
(from ingame and webpage)
* Chat Commands: To view history ingame/on a webpage (Chat history
webpages are cool ;)
Seriously, do you need anything else in SQL? Even Area files is a tad
over the top. Unless the Data changes alot,
(not constantly like Player data, note i said playerfiles, not
playerdata) like messages, ban lists, helpfiles, Why not
just write a function to create a Static HTML page with the information?
To finish, sticking everything into SQL is not a good idea, sticking
things that could be useful in other places like say
websites is. Just a word of advice. Besides, What about Security? =)
-Thri
