Oooh, look what he's done. Tsk, Tsk, you're waking up he dinosaurs,
Chrissy..
On Sat, 9 Apr 2005, Christopher Bunting wrote:
> 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..
Unless your name is in the PHP (or MySQL) credits, "years of experience"
doesn't count in my book. How's that for arrogance?
> 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
Yes. It's pointless, as Bobby/Chil already pointed out.
> 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.
Why dredge the poor old ROM code into something like this - when it, by
design, wasn't intended for such a purpose.
What is it with you people, who insist on spending obscene amounts of
code/time trying to turn ROM into something that it never can - or should
- be? If you're going to spend more than a couple years on it, you might
as well start from scratch, and design the game to your criteria right off
the bat...
That was my lesson #68765. I've (re-)written my game twice from scratch
since then - once in C, and once in python (better RAD environment) - so
far, I'm thoroughly enjoying the python version, including it's multiple
dispatch, and usage of multiplexing lists...
> 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
You're making a huge (and, probably largely incorrect) assumption with
this statement. On the other hand, those of us who are knowledgeable
enough to do it, aren't stupid enough to do it.
> 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.
Look up "events" and "callback functions"
> 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.
There's a reason for it. Ahem. Because it's a dumb idea. (See a trend
here, yet?)
Let me regurgitate what Bobby quoted:
> But the problem I see is that everyone talks about how easy it is..
> But the fact is, it's not easy.
> 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..
You need to look better - there's a few, but the only name that I remember
off-hand, is Moebius. It's written entirely in python, and 100% backed (in
realtime) by MySQL. That should fulfill your criteria, no?
.. and then there was our prototype that used PostgreSQL's LISTEN/NOTIFY
SQL syntax for message passing - it didn't even have a "client" per se -
and definitely no server (outside of the database) - all the communication
between end-users happened through the database, and the client was merely
a shell script wrapper...
- d.
--
Dominic J. Eidson
"Baruk Khazad! Khazad ai-menu!" - Gimli
-------------------------------------------------------------------------------
http://www.the-infinite.org/
