Re: Circle 4.x wish list

From: Mysidia (
Date: 11/24/02

On Tue, Nov 19, 2002 at 11:03:25PM -0600, Ronald Fenner wrote:
> On Tuesday, November 19, 2002, at 10:29  PM, Tseran wrote:

Here's a question:

Would circle 4.x be just an add-on for circle 3.x still based
on Diku code, or would it be a complete rewrite?

I tend to think the Diku code is old and crufty, and that it ought to be
replaced with something new and shiny, redesigned "the right way" (tm)
from the ground up: with no evil obj_file_elems, data_block_type_ds,
char_file_us, or even world[]/obj_index[]/... arrays of aggregate
rooms/objects (with each index one room/obj)..

I can't even begin to count those sorts of basic elements that make the
system harder to expand or change at a fundamental level, though
some snippets have managed to get around inherent difficulties
and still expand the system usefully in a significant way
(ie: Oasis/Genolc, dg scripts).

Perhaps there are some circle@ people who could help out
with such a large undertaking as a rewrite? :)

In terms of the MySQL thing... i'm not sure MySQL is a good choice
for a mud: you need data integrity and speed on updates, IMO you
need full transactions and row-level locking: atomic operations don't cut
it here, for something this intensive and complex. I think maybe you
need something more like PostgreSQL if you want to use a RDBMS, but
i'm not convinced that's the right thing.

After all, if a mud uses an external DB like a SQL one, it _should_ use
that DB to store its persistent state too (ie: player data, object data,
world data, world state [ie: which mobs are still alive, what objects
are on the ground in various rooms, etc]), and use of the DB, should for
example eliminate the need for a player 'save' command or even an olc
zonesave command, and eliminate the need for automatic zone resets
on bootup (since 'world state' can be saved).

What kind of database system a mud should use is a complex question,
and I won't presume to have the right answer: I don't know what is best,
but I am about 90% certain that MySQL is a bad choice for this, since
in terms of reliability and speed, it declines somewhat when tasked
to much beyond simple applications like spewing dynamic web content:
the more often existing data changes, and the more concurrency the
system needs, the worse a choice MySQL is.


   | FAQ: |
   | Archives: |
   | Newbie List:   |

This archive was generated by hypermail 2b30 : 06/25/03 PDT