Advances to MUD's
Chris Mellish
I'm in the middle of coding a new mud from scratch, after a 4 year break
from mudding in general. Perhaps I should have learnt my lesson before and
stayed away from the hell hole that running a mud can be. But I'm young
and foolish, and a sucker for punishment.
What I'm really asking, is what should be done differently in muds? Back
in the olden days we experimented with level less muds (after thinking it
worked really rather well on the original God Wars), and with different
combat models, and all the other fancy gismos like changing the ability
scores and proficiency systems. What is done differently these days? What
is new?
Coding from scratch has already given me the chance to change the structure
of the mud allowing for things to be done differently. And I have a whole
bag full of ideas and variations on old themes.
Regards,
Chris
Once known as Myurr, long long ago on a mud called Dark Heart.
Shihan
> Regards,
Interesting one!
My mud currently is level based but with many changes over the last year
have been adding skill levels behind the scenes. Things change all the
time and that can be just inside a single mud.
The way I would *now* approach it is to work out a honking good storyline
first. Work out the major twists and turns you intend, and what concepts
would be required to support and make the story happen. Build on this until
you can 'see' your world in your head and its day to day unfolding.
At that point, knowing what you need to achieve, then create the engine
that can make it happen as fully as possible. I don't really think you
can sensibly specify engine features and function until you are fully
aware of what it will be used for.
All non admin code changes on my mud are now driven purely by the storyline.
There is simply no point in wasting effort on whizzbang features if they
will not be used.
I guess the bottom line is to develop whatever works for you and makes you
happy.
Regards
Andy
--
----- ~~~~~ ====== ~~~~~ -----
Lands of Stone UK based Mordor variant
http://www.landsofstone.org/ telnet://mud.landsofstone.org:4801
Enjoy! (Remove .invalid from address when emailing replies)
Leave me alone
"Chris Mellish" <ch...@bluehalomedia.com> wrote in message
news:a67lp0$pt1$1...@newsg2.svr.pol.co.uk...
Well my personal drive is to make as much of the mud as i possibly can able
to be configured online. Everything from commands, socials, helpfiles,
spells, skills, combat rules, timing rules, everything. I like to
experiement a lot with new ways to do things, and the incessant
reboots/copyovers get rather annoying, so having it not compiled just makes
it easier on me:). Other than that i would say that the current trend is to
try out different and radical ideas, such as KaVirs area builders, more
complex mob progs, different themes, etc
Matt Graham
The question is so huge. I think we'll be able to help you a lot
better if you narrow the focus to questions about individual issues.
One structural thing that I think is good, is to put all the data into
a SQL DB. I think that would increase the flexibility and stability of
the mud a lot. Allow you to do cool things like have your php or perl
scripts easily connect directly in to the mud data for building and
reporting mud stats and stuff.
> changing the ability
> scores and proficiency systems.
I'd like to see something where your skills get worse if you don't use
them for a long time.
> What is done differently these days? What is new?
I don't mud on a lot of different places but it seems like things are
pretty much the same as they used to be. Must muds are just downloaded
off game.org and then people tweak them from there.
Matt
Laurent Oget
> Chris Mellish <ch...@bluehalomedia.com> wrote in message news:<a67lp0$pt1$1...@newsg2.svr.pol.co.uk>...
>
> > What I'm really asking, is what should be done differently in muds?
>
> The question is so huge. I think we'll be able to help you a lot
> better if you narrow the focus to questions about individual issues.
> One structural thing that I think is good, is to put all the data into
> a SQL DB. I think that would increase the flexibility and stability of
> the mud a lot. Allow you to do cool things like have your php or perl
> scripts easily connect directly in to the mud data for building and
> reporting mud stats and stuff.
>
I have been thinking about that. Even though i am more a MOO persone than
a MUD person. Do you know if anybody is working on that (putting a MUD
database in an actual SGBD) ?
--
Laurent Oget, Ph.D. lau...@oget.net http://oget.net
Senior Engineer Zvolve Systems Inc http://zvolve.com
Chercheur Associé Liafa http://liafa.jussieu.fr
Alan Schwartz
>mdgr...@analysts.com (Matt Graham) writes:
>
>> Chris Mellish <ch...@bluehalomedia.com> wrote in message
>news:<a67lp0$pt1$1...@newsg2.svr.pol.co.uk>...
>>
>> > What I'm really asking, is what should be done differently in muds?
>>
>> The question is so huge. I think we'll be able to help you a lot
>> better if you narrow the focus to questions about individual issues.
>> One structural thing that I think is good, is to put all the data into
>> a SQL DB. I think that would increase the flexibility and stability of
>> the mud a lot. Allow you to do cool things like have your php or perl
>> scripts easily connect directly in to the mud data for building and
>> reporting mud stats and stuff.
>>
>
>I have been thinking about that. Even though i am more a MOO persone than
>a MUD person. Do you know if anybody is working on that (putting a MUD
>database in an actual SGBD) ?
FWIW, although I don't see a great deal of benefit in putting the core
mud database into an SQL db, I am increasingly enjoying having
my mud connected to an SQL backend so that large chunks of text
mud data (e.g. player journals) can be stored in the SQL db
and retrieved/edited/etc. through the web as well as in the mud.
I'm using PennMUSH with the user-contribute mysql patch (that links
it with the mysql libs and provides some mushcode for running sql queries).
- Alan
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Javelin@M*U*S*H (mush.pennmush.org 4201) | Alan Schwartz
Paul@DuneMUSH | dune...@pennmush.org
Javelin@Belgariad, and elsewhere | PennMUSH Server Maintainer
=-------------------------------------------------------------------------=
PennMUSH God's Guide: http://www.pennmush.org/~alansz/guide.html
PennMUSH Source: ftp://ftp.pennmush.org/pub/PennMUSH/Source
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Matt Graham
> I have been thinking about that. Even though i am more a MOO persone than
> a MUD person. Do you know if anybody is working on that (putting a MUD
> database in an actual SGBD) ?
woah, nearly lost me with that SGBD thing. Might want to include an
english tranlation of that in the future. (or maybe I'm the only one
who'd never seen it before)
I've been writing and I just recently finished getting a MySQL
database setup and configured. Not a functional mud or database yet,
but I'm planning to put all the data (zones, player data, everything
else) into the MySQL db.
couple things I plan to use the DBMS for:
- Player creation will be done through the web server (apache,php),
letting players pick selections from drop lists and such. Once they
create the player, they'll log in through telnet and everything will
be set up, they just start playing.
- Zone building will be done through the web server too. Changes can
be made directly to the data, no FTPing files or anything, never have
to worry about data coming through in the wrong format. I don't really
have experience with MUD building as I've never done any, so I'm not
really familiar with how this stuff is done currently.
- Dynamic WHO list on the web, letting people hit the webpage and see
who's online. Maybe even let people send messages from the internet
directly to players in the mud.
- Maybe put world maps online. Dunno how this would work, I'm not
actually planning this, but it might be cool if someone figured a good
way to do it.
Matt
Laurent Oget
> Laurent Oget <lo...@zvolve.com> writes:
> >mdgr...@analysts.com (Matt Graham) writes:
> >
> >> Chris Mellish <ch...@bluehalomedia.com> wrote in message
> >news:<a67lp0$pt1$1...@newsg2.svr.pol.co.uk>...
> >>
> >
> >I have been thinking about that. Even though i am more a MOO persone than
> >a MUD person. Do you know if anybody is working on that (putting a MUD
> >database in an actual SGBD) ?
>
> FWIW, although I don't see a great deal of benefit in putting the core
> mud database into an SQL db, I am increasingly enjoying having
> my mud connected to an SQL backend so that large chunks of text
> mud data (e.g. player journals) can be stored in the SQL db
> and retrieved/edited/etc. through the web as well as in the mud.
>
> I'm using PennMUSH with the user-contribute mysql patch (that links
> it with the mysql libs and provides some mushcode for running sql queries).
>
> - Alan
>
MOOs can store texts in files with the FUP patch and it is very handy indeed.
SQL based MOOs would enable muds to be several orders of magnitude
bigger. This is necessary if you want to embed knowledge databases in
your moo to experiment with AI agents.
OTOH the price of RAM being what it is the limiting factor is pretty much
2G, which you would have to work a lot to fill.
Laurent Oget
> Laurent Oget <lo...@zvolve.com> wrote in message news:<7lu1rq8...@zvolve.com>...
> woah, nearly lost me with that SGBD thing. Might want to include an
> english tranlation of that in the future. (or maybe I'm the only one
> who'd never seen it before)
>
oops..i meant DBMS....
> I've been writing and I just recently finished getting a MySQL
> database setup and configured. Not a functional mud or database yet,
> but I'm planning to put all the data (zones, player data, everything
> else) into the MySQL db.
>
[...all kinds of good ideas]
> Matt
do you plan to open source that?
L
Jon A. Lambert
> ala...@tala.mede.uic.edu (Alan Schwartz) writes:
>
> > Laurent Oget <lo...@zvolve.com> writes:
> > >mdgr...@analysts.com (Matt Graham) writes:
> > >
> > >> Chris Mellish <ch...@bluehalomedia.com> wrote in message
> > >news:<a67lp0$pt1$1...@newsg2.svr.pol.co.uk>...
> > >>
> > >
> > >I have been thinking about that. Even though i am more a MOO persone than
> > >a MUD person. Do you know if anybody is working on that (putting a MUD
> > >database in an actual SGBD) ?
> >
> > FWIW, although I don't see a great deal of benefit in putting the core
> > mud database into an SQL db, I am increasingly enjoying having
> > my mud connected to an SQL backend so that large chunks of text
> > mud data (e.g. player journals) can be stored in the SQL db
> > and retrieved/edited/etc. through the web as well as in the mud.
> >
> > I'm using PennMUSH with the user-contribute mysql patch (that links
> > it with the mysql libs and provides some mushcode for running sql queries).
> >
> > - Alan
> >
>
> MOOs can store texts in files with the FUP patch and it is very handy indeed.
>
> SQL based MOOs would enable muds to be several orders of magnitude
> bigger. This is necessary if you want to embed knowledge databases in
> your moo to experiment with AI agents.
>
> OTOH the price of RAM being what it is the limiting factor is pretty much
> 2G, which you would have to work a lot to fill.
>
I'm not sure what the limiting factor is in MOO since I haven't played
with it in a long time. I do know that related servers like Cool and
Cold use disk caching and can support more objects than they can load
into memory. And their is a Cold server out there running a billion(?)
objects or something really enormous like that.
A particular problem with RDBMSs is that they are designed to support
a static schema. Also they are better suited to modeling data based
on aggregation and relation. Another problem is the notion that
the relational model supports parents knowing their children but not
children knowing their parents. (The foreign key business :-P)
OTOH, ODBMSs support inheritance better and the traditional object
model where children know their parents. Yet still most ODBMSs I've
seen best support static schema. Both RDMSs and ODBMSs, at least
most of them today, support runtime alteration of schema although it
is at a big cost to performance. Try ALTER sometime on a big
table.
The problem here with MOO and it's relatives is that objects have
a dynamic runtime definition. Attributes can be changed on the fly
and endless new "classes" of objects and their descendents can also
be created at runtime. How to map that into an RDBMSs?
Well most experiments I've seen have simply mapped ObjIds and their
associated blobs of data into the RDBMS. Simply a glorified DBM
that performs slower than DBM. There aren't any SQL benefits to
this as the data is just as opaque and inaccessible as before. The
other solution that I've played with is to design and store an object
catalog, that is the mapping of the object model itself, into an
RDBMS and then use that catalog to decide which tables to store and
find the data with any given object. This requires a number of
complex joins, and is a horribly awful performer.
The static schema of RBMSs is ideal for server designs similar to
Dikus where objects always have a fixed representation at runtime.
XML also suits them well for storage of their templates (maybe even
better!).
The ultimate solution to the "database" problem with MOO and its
relatives is to design a custom database that implements the
object model of MOO (or whichever) along with a powerful query
language (MOO-QL?). :-P
Alan is right. There are a whole lot of things you can do with
SQL databases for specific types of information that is well-defined,
like web pages, help files, note boards, etc. But I can see little
benefit trying to map MOO objects (the core library itself) which
are mutable and morphable at runtime into an RDBMS.
--
--* Jon A. Lambert - TychoMUD Email:jlsy...@NOSPAM.ix.netcom.com *--
--* Mud Server Developer's Page <http://tychomud.home.netcom.com> *--
--* If I had known it was harmless, I would have killed it myself.*--
mme...@steinbeck.ucs.indiana.edu
Jon A. Lambert <jlsy...@NOSPAM.ix.netcom.com> wrote:
>
>The static schema of RBMSs is ideal for server designs similar to
>Dikus where objects always have a fixed representation at runtime.
>XML also suits them well for storage of their templates (maybe even
>better!).
>
>The ultimate solution to the "database" problem with MOO and its
>relatives is to design a custom database that implements the
>object model of MOO (or whichever) along with a powerful query
>language (MOO-QL?). :-P
>
>Alan is right. There are a whole lot of things you can do with
>SQL databases for specific types of information that is well-defined,
>like web pages, help files, note boards, etc. But I can see little
>benefit trying to map MOO objects (the core library itself) which
>are mutable and morphable at runtime into an RDBMS.
I agree with what you've said here and just wanted to add a bit of
commentary. I'm currently involved with a project to develop a
Java-based MUD server that's basically somewhere in between a Diku
derivative and a MOO. For most of the reasons discussed, we aren't
going to use a RDBMS as a backend, but we do plan on using XML for
external storage.
When an object is needed by the system, it first checks its in-memory
cache. If it's not there, it checks the BerkeleyDB file of serialized
objects to see if it's been used during this run and has simply been
swapped out. If it's not there, it'll go ahead and parse the XML,
create the object, and put it in the cache.
There are a few parts of this scheme that we haven't defined yet, of
which the biggest is what to do about our message database. The code
does not contain any English string literals; every message is
external to the codebase itself. Sure, this is traditional
internationalization support... but we want to use it to enable NPCs
to speak in race languages with only trivial additional code support
needed. There might be an English DB, an Elvish DB, etc.
(Y'know, I guess this qualifies as an entry for the "Who's writing a
MUD from sscratch?" thread. Well, um, I guess we are. The only
external library other than the Java API that's involved so far is
Xerces.)
--Mark
--
Mark Meiss (mme...@indiana.edu) 812/855-1878 / Disciple of Loki and
http://steinbeck.uits.indiana.edu/~mmeiss/ / Fomenter of Entropy
Researcher, Advanced Network Management Lab /-----------------------------
Wanna-be Author of Novels and Short Fiction / What fools these normals be.
Laurent Oget
> In article <a6ivc7$1fg$1...@slb4.atl.mindspring.net>,
> Jon A. Lambert <jlsy...@NOSPAM.ix.netcom.com> wrote:
> >
> >The static schema of RBMSs is ideal for server designs similar to
> >Dikus where objects always have a fixed representation at runtime.
> >XML also suits them well for storage of their templates (maybe even
> >better!).
> >
> >The ultimate solution to the "database" problem with MOO and its
> >relatives is to design a custom database that implements the
> >object model of MOO (or whichever) along with a powerful query
> >language (MOO-QL?). :-P
> >
> >Alan is right. There are a whole lot of things you can do with
> >SQL databases for specific types of information that is well-defined,
> >like web pages, help files, note boards, etc. But I can see little
> >benefit trying to map MOO objects (the core library itself) which
> >are mutable and morphable at runtime into an RDBMS.
>
> I agree with what you've said here and just wanted to add a bit of
> commentary. I'm currently involved with a project to develop a
> Java-based MUD server that's basically somewhere in between a Diku
> derivative and a MOO. For most of the reasons discussed, we aren't
> going to use a RDBMS as a backend, but we do plan on using XML for
> external storage.
>
what exactly does xml bring you that an RDBM would not?
>
> (Y'know, I guess this qualifies as an entry for the "Who's writing a
> MUD from sscratch?" thread. Well, um, I guess we are. The only
> external library other than the Java API that's involved so far is
> Xerces.)
>
> --Mark
>
> --
> Mark Meiss (mme...@indiana.edu) 812/855-1878 / Disciple of Loki and
> http://steinbeck.uits.indiana.edu/~mmeiss/ / Fomenter of Entropy
> Researcher, Advanced Network Management Lab /-----------------------------
> Wanna-be Author of Novels and Short Fiction / What fools these normals be.
--
Laurent Oget
> >
> >The ultimate solution to the "database" problem with MOO and its
> >relatives is to design a custom database that implements the
> >object model of MOO (or whichever) along with a powerful query
> >language (MOO-QL?). :-P
> >
I strongly believe this can be built onto SQL.
But then i di dnot do the work to expose why
I am.
Sue me.
If days were longer...
>
> I agree with what you've said here and just wanted to add a bit of
> commentary. I'm currently involved with a project to develop a
> Java-based MUD server that's basically somewhere in between a Diku
> derivative and a MOO. For most of the reasons discussed, we aren't
> going to use a RDBMS as a backend, but we do plan on using XML for
> external storage.
>
a link to this project maybe?
> http://steinbeck.uits.indiana.edu/~mmeiss/ / Fomenter of Entropy
i can't get to it..unknown DNS....
mme...@steinbeck.ucs.indiana.edu
>mme...@steinbeck.ucs.indiana.edu writes:
>
>> In article <a6ivc7$1fg$1...@slb4.atl.mindspring.net>,
>> Jon A. Lambert <jlsy...@NOSPAM.ix.netcom.com> wrote:
>>
>> I agree with what you've said here and just wanted to add a bit of
>> commentary. I'm currently involved with a project to develop a
>> Java-based MUD server that's basically somewhere in between a Diku
>> derivative and a MOO. For most of the reasons discussed, we aren't
>> going to use a RDBMS as a backend, but we do plan on using XML for
>> external storage.
>
>what exactly does xml bring you that an RDBM would not?
Mostly, the use of text and/or XML editors for builders. Instead of
writing a number of Perl scripts to take various external file formats
and translate them into appropriate sets of database updates, I can
exploit already existing tools to edit the data directly.
The OLC system may also need the ability to modify the DTDs on the
fly, and I'd much rather tweak a DTD at runtime than alter the schema
of the database tables.
I also get the ability to write a little bit of XSLT code to translate
the objects into HTML for quick visual browsing. (This is for the
benefit of developers and builders, not players; one guiding
philosophy behind our design is that every numeric value about a
character that players can see reduces roleplaying by 5%.)
mme...@steinbeck.ucs.indiana.edu
>mme...@steinbeck.ucs.indiana.edu writes:
>
>
>
>> http://steinbeck.uits.indiana.edu/~mmeiss/ / Fomenter of Entropy
>
>i can't get to it..unknown DNS....
It looks like the DNS folks removed my CNAME. Until I get it fixed,
that's actually http://steinbeck.ucs.indiana.edu/~mmeiss/. Thanks for
pointing that out -- I never would have caught it.
That page hasn't been updated in quite some time and doesn't contain
any pointers to our development work, but that'll be coming in fairly
short order. We do intend to release under the GPL, as this is a
really just a labor of love that my fiancee and I plod away on when
we're not consumed by work and study. (Both of us are Ph.D. students
in Computer Science. This project is also a chance to test out some
design ideas we have for intelligent agents.)
--Mark
--
Mark Meiss (mme...@indiana.edu) 812/855-1878 / Disciple of Loki and
http://steinbeck.uits.indiana.edu/~mmeiss/ / Fomenter of Entropy
Matt Graham
> > database setup and configured. Not a functional mud or database yet,
> > but I'm planning to put all the data (zones, player data, everything
> > else) into the MySQL db.
> >
> [...all kinds of good ideas]
> > Matt
>
> do you plan to open source that?
well, I have to get something worth open sourcing first but I'm pretty
sure I will open source it once I get it in decent shape.
matt
Laurent Oget
> In article <7lofhuo...@zvolve.com>, Laurent Oget <lo...@zvolve.com> wrote:
> >mme...@steinbeck.ucs.indiana.edu writes:
> >
> >> In article <a6ivc7$1fg$1...@slb4.atl.mindspring.net>,
> >> Jon A. Lambert <jlsy...@NOSPAM.ix.netcom.com> wrote:
> >>
> >> I agree with what you've said here and just wanted to add a bit of
> >> commentary. I'm currently involved with a project to develop a
> >> Java-based MUD server that's basically somewhere in between a Diku
> >> derivative and a MOO. For most of the reasons discussed, we aren't
> >> going to use a RDBMS as a backend, but we do plan on using XML for
> >> external storage.
> >
> >what exactly does xml bring you that an RDBM would not?
>
> Mostly, the use of text and/or XML editors for builders. Instead of
> writing a number of Perl scripts to take various external file formats
> and translate them into appropriate sets of database updates, I can
> exploit already existing tools to edit the data directly.
>
so you are ready to take the big hit on performance just because it
saves you from writing a few perl scripts ( you still get to write
DTDs)
> The OLC system may also need the ability to modify the DTDs on the
> fly, and I'd much rather tweak a DTD at runtime than alter the schema
> of the database tables.
>
> I also get the ability to write a little bit of XSLT code to translate
are you really sure that having to write XSLT counts as a win.
might be just me but i do not think i know of anything clumsier than
the XSLT syntax.
Laurent Oget
I would personnaly love seeing design thought or database schemas.
But then i understand you do not want to unveil it now. I hope
you will tell us more when it is ready on here.
mme...@steinbeck.ucs.indiana.edu
>mme...@steinbeck.ucs.indiana.edu writes:
>
>so you are ready to take the big hit on performance just because it
>saves you from writing a few perl scripts ( you still get to write
>DTDs)
Yes, basically. On the other hand, it's a performance hit only at
boot time and I've got the process cycles to spare. But beyond that,
I don't have a lot of experience writing DTDs and I do have far too
much experience in coding user interfaces. Since this is a personal
project and not commercial code, I'd rather explore technology I'm not
completely familiar with than grow weary with more of the same old
stuff.
>are you really sure that having to write XSLT counts as a win.
>
>might be just me but i do not think i know of anything clumsier than
>the XSLT syntax.
Readily granted. But in a few months, I'll be having to write some
XSLT in support of a research application, and I'd like to get
experienced at it in a fun context before I have to spend days at work
poring over the standards documents.
Travis Nelson
http://sneezy.stanford.edu). We currently use postgresql for a number
of things and have had generally good experiences with it. I recently
converted us from mysql which I found to be unstable and a little weak
in some areas (mainly ACID and SQL compliance).
Currently, the following sets of data are stored in the database:
all items (production as well as individual builders)
shops (both normal game shops as well as player owned shops. player
owned shops track all transactions and produce balance sheets for the
owners - all this is stored in the db)
factions
fishing scores (fishing subsystem that tracks who catches the largest
of each kind of fish as well as the total poundage for all players)
gambling winners and losers
an internal area god task list
permadeath list (sort of like "Hardcore" in diablo - you can make
chars that can only die once)
player ping times (we ping players periodically so you can see what
your net connection is like - useful for people that don't understand
ping or traceroute etc)
trophy system (we track every single point of damage that any player
does to any mob. we use this for a number of purposes, statistical
info as well as game balance)
query performance tracking (I store how long each query takes so I can
look for trouble spots - this is off by default as it slow things
down)
usage logs (how many people are on)
who list
as well as 2 or 3 unfinished projects in the works
As you can see we've made some pretty significant use of it. You'll
note the absense of mobs, rooms, zones and player files - these are on
my todo list but I haven't had any pressing need to move them over
just yet.
So far things have been very positive. Gathering interesting
statistics is very easy. For example, its a very simple task to find
out which players spend time exploring and which plow the same zones,
as well as which zones get plowed the most often. Generating lists of
items is also very simple... want to see every 1 handed weapon that
does more than X damage? Piece of cake. Want to know what the max,
average and min on each stat bonus for all eq? No problem. Ad-hoc
information gathering like this makes it very easy to spot builder and
player trends, look for eq holes (how many pieces of level 20 elf
sized eq is there?) and make global changes, like increasing all AC by
10% or something.
The hardest part of it all has been converting flat file based mud
code to use the database. A lot of code would have to be rewritten to
utilize the db properly, so we skate by on dirty tricks here and
there, but overall it works great. We haven't really explored web
based applications too much, although item editors and such would be a
piece of cake. We do have someone playing around with a couple of
things:
http://www.grimhaven.org/index.php?page=whosplaying
http://www.grimhaven.org/index.php?page=gamestats
Both of these pull straight from the db, although I think the
gamestats page hasn't been optimized yet. :)
I'm rambling now so I'll cut off here. Feel free to swing by and chat
more about it if you like, being a recent victim of dot com fallout, I
tend to be around a lot...
trav
Peel @ sneezy
telnet://sneezy.stanford.edu:7900
mdgr...@analysts.com (Matt Graham) wrote in message news:<d74e664f.02031...@posting.google.com>...
Chris Mellish
building the system from scratch using perl and mysql. I use both all the
time at work (web stuff), so while I used to be a C programmer perl seems
more natural for me now.
Plus it's specialty is text processing, and what is a mud...? Oh yeah,
it's text processing!
The main reason I wanted to switch to using a database was that perl
doesn't have brilliant support for complex data structures, and I like the
flexibility and being able to access the data through other means, just as
others had mentioned.
Laurent Oget
> To be honest I've started along the same lines already. I am currently
> building the system from scratch using perl and mysql. I use both all the
> time at work (web stuff), so while I used to be a C programmer perl seems
> more natural for me now.
>
> Plus it's specialty is text processing, and what is a mud...? Oh yeah,
> it's text processing!
>
> The main reason I wanted to switch to using a database was that perl
> doesn't have brilliant support for complex data structures, and I like the
> flexibility and being able to access the data through other means, just as
> others had mentioned.
>
so you do not cache it? you access the database everytime you read something?
L, who got by performance reflex cause long ago computers were slow
Jon A. Lambert
> mme...@steinbeck.ucs.indiana.edu writes:
>
> > >
> > >The ultimate solution to the "database" problem with MOO and its
> > >relatives is to design a custom database that implements the
> > >object model of MOO (or whichever) along with a powerful query
> > >language (MOO-QL?). :-P
> > >
>
> I strongly believe this can be built onto SQL.
> But then i di dnot do the work to expose why
> I am.
>
I would suggest that most of the Tiny flavors of muds are already
custom databases in their own right. They just lack a few of features
that would make them useful for other purposes. That's an area that
might be productive. While I do RDBMS design and tuning for a living,
I'm not fixated on it. There are as many better solutions to problems
as there are storage mechanisms.
As for knowledge bases, well it would seem to me on the surface that
many problems of that type might be better suited to hierarchical or
network databases. But than that is just as much a general statement
as is knowledge base. It depends on the application. I'm using
a procedural reasoning system as my "AI agents" and storage is not
really the major concern, nor is an RDBMS the mechanism. The primary
concern in my own application is intelligent task scheduling and
concurrency.
Matt Graham
news:1996fa0b.02031...@posting.google.com...
> I code for SneezyMUD (sneezy.stanford.edu 7900 or
> http://sneezy.stanford.edu). We currently use postgresql for a number
> of things and have had generally good experiences with it. I recently
> converted us from mysql which I found to be unstable and a little weak
> in some areas (mainly ACID and SQL compliance).
>
What API do you use to access the postgresql? Or do you use embedded SQL?
One reason I wanted to go with MySQL over it was it seemed a little simpler
to set up and it has a pretty nice mysql_ API.
> Currently, the following sets of data are stored in the database:
> all items (production as well as individual builders)
> shops (both normal game shops as well as player owned shops. player
> owned shops track all transactions and produce balance sheets for the
> owners - all this is stored in the db)
> factions
Those all seems like really good ideas. Seems like you're using the SQL to
do back office accounting. This kind of reporting on a mud really couldn't
be done without using a SQL database. It sounds like a great way to (like
you said) help balance things and find out what's getting used and what
isn't.
>
> http://www.grimhaven.org/index.php?page=gamestats
>
This page is really cool!
Matt
Travis Nelson
> What API do you use to access the postgresql? Or do you use embedded SQL?
> One reason I wanted to go with MySQL over it was it seemed a little simpler
> to set up and it has a pretty nice mysql_ API.
I just use the standard C API that comes with it. There is also a C++
API for postgresql (our code base is C++) but it's basically just a
front end for the C API. I wrote my own class to wrap around the C
API, to simplify using it and to make moving among databases easy.
The wrapper works something like this:
#include "database.h"
const char *owner="Peel";
TDatabase db("immortal");
db.query("select vnum, short_desc from obj where owner='%s'", owner);
printf("%s's objects:\n", owner);
while(db.fetchRow()){
printf("%i\t%s\n", atoi_safe(db.getColumn(0)), db.getColumn(1));
}
You get the idea. Pretty simple. All of the error handling and
deallocating results are handled in the wrapper, as well as a
persistant connection class (so we don't reopen the db connection for
every query).
I will agree with you that Mysql is much easier to use initially and
is more intuitive. Postgresql just takes a little getting used to,
but I like it far better. The API's are comparable I think. It's
also worth pointing out that mysql is a bit faster on simple
transactions, which may make things easier on you. You pay for that
with ACID non-compliance though.
Miroslav Silovic
> I will agree with you that Mysql is much easier to use initially and
> is more intuitive. Postgresql just takes a little getting used to,
> but I like it far better. The API's are comparable I think. It's
> also worth pointing out that mysql is a bit faster on simple
> transactions, which may make things easier on you. You pay for that
> with ACID non-compliance though.
By the way, have you tried SapDB? I tested it a month or two ago...
I only have to say that I'm bloody impressed.
The only drawback to this thing is that it's pretty huge, you
definitely don't want to run it on a machine where 100megs of code
would be a problem. OTOH, it's open source /and/ enterprise class.
In particular, unlike PostgreSQL, it comes with a rather neat set of
admin tools and automatic self-maintainance.
Miro
soda....@xirr.com
>
> Laurent Oget <lo...@zvolve.com> wrote in message news:<7lu1rq8...@zvolve.com>...
> > I have been thinking about that. Even though i am more a MOO persone than
> > a MUD person. Do you know if anybody is working on that (putting a MUD
> > database in an actual SGBD) ?
[snip]
> - Dynamic WHO list on the web, letting people hit the webpage and see
> who's online. Maybe even let people send messages from the internet
> directly to players in the mud.
>
> - Maybe put world maps online. Dunno how this would work, I'm not
> actually planning this, but it might be cool if someone figured a good
> way to do it.
This sort of thing is a great idea. On Alter Aeon, I hacked up the
socket code to accept connections on an http port to display this sort
of thing. We export a bunch of information through the http interface,
including help search and browsing, command lists, player stats,
userload, etc. Having direct access to the help pages already loaded
into memory and sorted is wonderful - and in fact uses the same search
mechanism as the mud itself. Additionally, when changes are made on
line, they are instantly reflected in the http data.
I think adding http support directly into the mud server is definitely
the way to go for a lot of this stuff. It just made so many things
easy, things that would have required lots of cgi and/or cron jobs
otherwise. And since muds are already network servers, adding an http
port is dirt simple.
If bored, check it out - http://xirr.com:3004/
(Yes, I know the html is not perfect - feel free to send or post html
bugs, eventually I'll get them cleaned up.)
-dennis T
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alter Aeon Multiclass Mud - Beware The Hill Giants!
http://dentinmud.org/alter, telnet://xirr.com:3000
Alan Schwartz
>Matt Graham wrote:
>>
>> Laurent Oget <lo...@zvolve.com> wrote in message
>news:<7lu1rq8...@zvolve.com>...
>> > I have been thinking about that. Even though i am more a MOO persone than
>> > a MUD person. Do you know if anybody is working on that (putting a MUD
>> > database in an actual SGBD) ?
>
>[snip]
>
>> - Dynamic WHO list on the web, letting people hit the webpage and see
>> who's online. Maybe even let people send messages from the internet
>> directly to players in the mud.
It's not quite the same, but M*U*S*H has an art exhibit that can
be manipulated from within the MUSH or from the web, and the changes
are reflected in both places (textually or graphically, as appropriate).
The web site version:
http://www.pennmush.org/mush/canvas.html
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Javelin@M*U*S*H (mush.pennmush.org 4201) | Alan Schwartz
Owl@Rio: Manha de Carnaval | dune...@pennmush.org
Paul@DuneMUSH, and Javelin elsewhere | PennMUSH Server Maintainer