December 1999
- Neural Networks as the AI system for a MUD? PartyG2816@aol.com
- Neural Networks as the AI system for a MUD? claw@kanga.nu
- Neural Networks as the AI system for a MUD? Marc Bowden
- Neural Networks as the AI system for a MUD? Lo, Kam
- Neural Networks as the AI system for a MUD? Marc Hernandez
- Neural Networks as the AI system for a MUD? Kræn Munck
- Neural Networks as the AI system for a MUD? Hans-Henrik Staerfeldt
- Neural Networks as the AI system for a MUD? PartyG2816@aol.com
- Neural Networks as the AI system for a MUD? Hans-Henrik Staerfeldt
- Neural Networks as the AI system for a MUD? Andrew Norman
- Neural Networks as the AI system for a MUD? Mik Clarke
- New member IronWolf
- Scenarios Chris Lloyd
- ColdStore J C Lawrence
- New AI Engine released Fabian
- New AI Engine released Steve Houchard
- New AI Engine released Bruce Mitchener, Jr.
- New AI Engine released Elysium
- AI's in MUDS and Online Gaming IronWolf
- AI's in MUDS and Online Gaming Matthew Mihaly
- AI's in MUDS and Online Gaming IronWolf
- AI's in MUDS and Online Gaming Ryan P.
- Garbage Collection Miroslav Silovic
- Capture of players. (was: Fair/Unfair? Scenarios) Kræn Munck
- Capture of players. (was: Fair/Unfair? Scenarios) J C Lawrence
- Capture of players. (was: Fair/Unfair? Scenarios) Chris Lloyd
- Biosystems (was Fair/Unfair? Scenarios) Richard Ross
- Biosystems (was Fair/Unfair? Scenarios) Philip Loguinov -- Draymoor
- Biosystems (was Fair/Unfair? Scenarios) Mik Clarke
- Biosystems (was Fair/Unfair? Scenarios) J C Lawrence
- Biosystems (was Fair/Unfair? Scenarios) Greg Miller
- Biosystems (was Fair/Unfair? Scenarios) Dundee
- Biosystems (was Fair/Unfair? Scenarios) Travis S. Casey
- Biosystems (was Fair/Unfair? Scenarios) Douglas Couch
- Biosystems (was Fair/Unfair? Scenarios) Marc Hernandez
- Biosystems (was Fair/Unfair? Scenarios) J C Lawrence
- Biosystems (was Fair/Unfair? Scenarios) Mik Clarke
- Ideas for dynamic worlds Nolan Darilek
- Ideas for dynamic worlds Chimera
- Ideas for dynamic worlds Ilya, Game Commandos
- Ideas for dynamic worlds J C Lawrence
- Ideas for dynamic worlds Nolan Darilek
- Ideas for dynamic worlds Joe Kingry
- Ideas for dynamic worlds David Morgan
- The GTS Library J C Lawrence
- Combat systems Neil Edwards
- Combat systems Kylotan
- Combat systems Kylotan
- Combat systems Chris Lloyd
- Combat systems J C Lawrence
- Combat systems Marc Spoorendonk
- Combat Systems Ben
- Combat Systems Raph Koster
- Metakit J C Lawrence
- Commercial Online Roleplaying Games (fwd) J C Lawrence
- Mud-Dev FAQ Marian Griffith
- Mass bannings (was The grass is always greener in the other field) AR Schleicher
- Game Balance: Statistical Analysis in MPORPGs Lovecraft
- Game Balance: Statistical Analysis in MPORPGs Koster, Raph
- Biosystems & simulation [RAMBLE] Ben Greear
- Souveniers Douglas Couch
- Souveniers Lovecraft
- Souveniers J C Lawrence
- Souveniers Raph & Kristen Koster
- Souveniers J C Lawrence
- Souveniers Raph & Kristen Koster
- Ideas for dynamically generated worlds Cynbe ru Taren
- Ideas for dynamically generated worlds J C Lawrence
- Balancing between anxiety and boredom (was Fair/Unf air? Scenarios (fwd) ) Sellers, Michael
- Online Migration and population mobility in a virtual gaming setting - Ultima Online J C Lawrence
- lockpicking Matthew Mihaly
- Optimized Object Storage Ian Macintosh
- Optimized Object Storage Sellers, Michael
- Optimized Object Storage Matthew Mihaly
- Optimized Object Storage J C Lawrence
- Optimized Object Storage Ian Macintosh
- Optimized Object Storage Ian Macintosh
- Optimized Object Storage Sellers, Michael
- Optimized Object Storage Ian Macintosh
- The Habitat Papers are missing J C Lawrence
- Waving Hands -- Debian's Spellcast for Linux J C Lawrence
- Waving Hands -- Debian's Spellcast for Linux Dan Shiovitz
- Waving Hands -- Debian's Spellcast for Linux Travis Casey
- Waving Hands -- Debian's Spellcast for Linux J C Lawrence
- Upload to ftp.kanga.nu J C Lawrence
- Farewell again Ilya, GC
- Telnet Protocol and Winsocks method
- Telnet Protocol and Winsocks J C Lawrence
- Telnet Protocol and Winsocks cg@ami-cg.GraySage.Edmonton.AB.CA
- Telnet Protocol and Winsocks Ilya, GC
- Telnet Protocol and Winsocks J C Lawrence
- Proper liscense for MUD source? Perhaps not GPL... (fwd) J C Lawrence
- Proper liscense for MUD source? Perhaps not GPL... (fwd) J C Lawrence
- Proper liscense for MUD source? Perhaps not GPL... (fwd) Ben Greear
- Proper liscense for MUD source? Perhaps not GPL... (fwd) Christopher Allen
- Proper liscense for MUD source? Perhaps not GPL... (fwd) J C Lawrence
- Proper liscense for MUD source? Perhaps not GPL... (fwd) Christopher Allen
- MUD source licensing: beyond GPL? (fwd) J C Lawrence
- MUD source licensing: beyond GPL? (fwd) Matthew Mihaly
- Classes and Races and more (a BIG list) (fwd) J C Lawrence
- Originality/Points of Reference (was Classes and Races and more (a BIG list) (fwd)) Richard Ross
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) Justin Rogers
- Collecting ideas for a MUD server... (fwd) Rahul Sinha
- Collecting ideas for a MUD server... (fwd) Justin Rogers
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) Rahul Sinha
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) Christopher Kohnert
- Collecting ideas for a MUD server... (fwd) Rahul Sinha
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) Greg Miller
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) Greg Miller
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) Greg Miller
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) Matthew Mihaly
- Collecting ideas for a MUD server... (fwd) Jon A. Lambert
- Collecting ideas for a MUD server... (fwd) Rahul Sinha
- Collecting ideas for a MUD server... (fwd) Wesley W. Terpstra
- Collecting ideas for a MUD server... (fwd) Greg Miller
- Collecting ideas for a MUD server... (fwd) Rahul Sinha
- Collecting ideas for a MUD server... (fwd) Wesley W. Terpstra
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) Rahul Sinha
- Collecting ideas for a MUD server... (fwd) Greg Miller
- Collecting ideas for a MUD server... (fwd) Greg Miller
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) Rahul Sinha
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) Rahul Sinha
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Originality/Points of Reference Ian Klimon, Esq.
- Job Openings - Mud Engineering Christopher Allen
- PGP player certificates (was: collecting ideas...) Wesley W. Terpstra
- PGP player certificates (was: collecting ideas...) David Bennett
- Re[4]: The grass is always greener in the other field Travis Casey
- Re[4]: The grass is always greener in the other field J C Lawrence
- Re[4]: The grass is always greener in the other field Adam Wiggins
- Two threads forced to one CPU? (was: Collecting ideas for a MUD server...) Wesley W. Terpstra
- Two threads forced to one CPU? (was: Collecting ideas for a MUD server...) J C Lawrence
- Two threads forced to one CPU? (was: Collecting ideas for a MUD server...) Marc Bowden
- Two threads forced to one CPU? (was: Collecting ideas for a MUD server...) Greg Miller
- Two threads forced to one CPU? (was: Collecting ideas for a MUD server...) cg@ami-cg.GraySage.Edmonton.AB.CA
- Two threads forced to one CPU? (was: Collecting ideas for a MUD server...) Hans-Henrik Staerfeldt
- Two threads forced to one CPU? (was: Collecting ideas for a MUD server...) cg@ami-cg.GraySage.Edmonton.AB.CA
- PGP confusions hopefully resolved (was: collecting ideas ...) Wesley W. Terpstra
- MUD-Dev digest, Vol 1 #237 - 9 msgs Dr. Cat
- MUD-Dev digest, Vol 1 #237 - 9 msgs J C Lawrence
- MUD relevant references (was: The grass is always greener...) Ola Fosheim Grøstad
- Re[6]: The grass is always greener in the other field Travis Casey
- Embedded languages, object persistance... ack. Joe Kingry
- Embedded languages, object persistance... ack. cg@ami-cg.GraySage.Edmonton.AB.CA
- Embedded languages, object persistance... ack. Laurent Bossavit
- Embedded languages, object persistance... ack. Kevin Littlejohn
Hey, this stuff looks familiar ;) Check www.bofh.net.au/mud/ for mine -
python-based, MySQL based, doing persistance and code objects and etc.
(Um - This post has a lot about my own little play area, Moebius, in it.
That's because I'm still trying to find other examples of this stuff. My
apologies in advance if it sounds like I'm pushing what I've done - I'm
not, it's not nearly ready to run an honest-to-ghod mud yet, and is
probably badly coded to boot - but it's the only thing I know atm ;)
>>> "Joe Kingry" wrote
> I've been trying to figure this out lately. At first glance I generally
> thought I knew what it was about, but now I'm not so sure.
>
> I mean, I know what the goals in general are. Persistance. You have a house
> say in some place in the world. It get's damaged, it stays damaged until it
> is repaird. So persistence is done through some kind of database, or
> multiple databases broken up to distribute categories/workload.
Databasing gives you a little more than that in terms of persistance, tho.
Because there's no load/save, things are committed immediately, there's no
potential loss of information in crash etc. Also, if you're storing time,
you can either roll the database forward on restarting a mud, or split out
things like the event engine and run that seperately from the rest of the
mud - so it's "alive", even when the mud isn't.
> I want a mud server on which I can change the code online of say a skill, a
> spell or something else. I understand that this is the purpose of having an
> embedded language that runs "on top of" the mud's driver. i.e. MUF for MUQ,
> Python for AR3 etc. So in general I know this code is to be compiled since
> you don't want to be executing "scripts", but is this code an object? and
> then is the byte-code stored? ack.. I'm confused.
In mine, yeah, bytecode is stored in the database. You _can_ treat the
code as objects (as I'm about to play with doing), or you can re-build them
as methods on objects - so a door would be an object, the open and close
methods (which exist in the database, so you can hack them up whenever) are
methods on the object, and are re-attached when they're executed.
I suspect others have different ways of dealing with it, and I suspect
it'll be affected by the ease of doing certain things in certain languages.
> Here, I'll try to demonstrate what I little I think I know from MUSH type
> enviroments. A MUSH allows you to create an object. Great. This object is
> unique and persistent. Ie. it will be there when you get back if you so
> desire. You can assign code to execute based upon certain defined actions on
> the object, or you can create a new action for this object. Going by this
> model then, does that mean every single object in these "new" muds is a
> class and is inherited from a previous object? But then it's executed how?
That's not a problem. (and yeah, every object can be considered a class
also). Python at least offers you the ability to 'execute' classes - you
just give them a __call__ method, and you can call them. Best used for:
class player:
def attr1
def attr1
normalPlayer = player()
normalPlayer.strength = normalPlayer.strength + 20
dwarfPlayer = normalPlayer()
If you've done good databasing in the backend, creating an instance of a
player, tweaking it, then using it as a class essentially means you created
a new 'type' of object.
Moebius starts with a bunch of pre-defined object types - player, object,
location - but they're completely arbitrary, and not at all needed. They
make life easier for the creators - create a 'door' object, you
automatically get dest_location attributes and an open() and close()
function.
Why should you treat classes and instances seperately?
(Incidentally, there's a topic in there I'd love to pursue with other
like-minded souls - multiple inheritance vs. single inheritance, levels of
inheritance, and the possibility of a 'kit' approach on top of inheritance
- so you go "mageDwarf = mageKit(dwarfPlayer)" to extend things, then
optionally use _that_ as a prototype...)
> I think I have my object/class/code/driver concepts all muddled.
It does seem to get mixed up once you start playing with this stuff.
Objects are things that exist, classes are the things you create them from
(and can optionally be objects themselves, in some cases, maybe?), code is
executable stuff that belongs to objects (or floats free), the driver is
the underlying core that should not need changing(tm)...
ColdC looked like another interesting place to look for stuff like this.
>
> All I want in a mud server is this:
>
> -stores things in a database file(s). No more 4000 player files.
> -allows me to define objects online. Ie. I can decide I need an object that
> will act like a boat, and I can code and modify this online.
Part of the trick to that is being able to add new methods. For example, I
wanted doors to work - so I coded 'close' and 'open' functions to toggle a
attribute 'open' in the object they're attached to, added that attribute
(and those functions) to something, re-coded the 'move' function to pay
attention to whether the door was open or not - and presto, closeable doors
;) Should be doable, but you need to have access to change even the base
functions like move and look every so often...
> -doesn't have every object in memory, only when needed, otherwise on file.
Yup, although you'd be surprised what's "needed", when you've got complex
interactions happening. Moebius handles this really badly atm :( Because
the top-level code pretends it's not using a database, it touches every
object when you do things like 'who' or 'list live creatures' or whatever.
> -doesn't require me to learn it's "own custom embedded language", this one
> really gets to me
> -somehow allows for security and access levels while coding
This is really interesting. Moebius at the moment is dog-slow, because of
'bastioning' - protecting the internal classes from external view (python
doesn't have a concept of public vs. private attributes in objects). That
has to be done for the sake of one variable - the 'self._db' - which gives
full access to the database :(
I'd love to find a solution to this, but it's an interesting exercise
creating objects that can talk to the database, and then creating a view of
those objects that can only use the defined methods.
> -somehow allows for an event type system
That's a whole 'nother kettle of fish ;) Also another thing I've got to
read up on - what do people consider appropriate for event systems/what
needs to be supported?
> -allows code to be contained in packages and has appropriate management
> features. Ie. I can write the code offline in a file and then upload the
> file to the server
Upload? Hrm. I'm going to shortly write something that drags code from
the database, presents it in a flashy tk-based window, lets you edit it,
and commit the changes. Would that be the sort of thing you're thinking
of?
Once you throw a db into the equation, your ability to tinker with things
_should_ increase dramatically - you open up a range of ways of dealing
with the data, from web pages (see below) to python/tk/C/C++/perl/insert
favourite language here, to the "stranger" (because I don't know anything
about 'em ;) things like ODBC...
(Hrm - forte as a mud building tool...)
> -will allow for http access to the database
If you've got a database, you've got that - um, again, check
www.bofh.net.au/mud/, in particular the 'live' section there. I cheat -
Zope has beautiful database connectivity, so it's simply a case of writing
the sql to retrieve the info from the db, and wrapping that sql in basic
pages.
>
> An added bonus would be, but hardly nessesary:
> -driver ported to both Win32 platform and *nix platforms and database is
> independent of platform.
Pick a platform-independant language, any platform-independant language ;)
python/java for your base code, pretty much any database, ODBC support and
you're there...
> Muq seems to have most of these except for MUF, I got tired of programming
> backwards ;).
> Then there is Momoko, it uses Java which would be great, but I'm not quite
> sure how to go about things and if it insists on having everything in memory
> or not and file management etc and i'm unclear if every unique object is
> it's own class on a persistent system.
Hrm - new things to look at ;)
It looks like the answers to your questions might be codebase specific, in
honesty. I can say what' I've done in Moebius, others will be able to
explain the object/class model and inheritance system for their own
codebases - but those are not likely to be the same thing across muds. In
fact, I suspect with the newer muds, they're being built specifically to
try out new and interesting ways of modelling objects, at least in part ;)
KevinL - Embedded languages, object persistance... ack. J C Lawrence
- Embedded languages, object persistance... ack. J C Lawrence
- Embedded languages, object persistance... ack. Jay Carlson
- Embedded languages, object persistance... ack. Jay Carlson
- Embedded languages, object persistance... ack. J C Lawrence
- Embedded languages, object persistance... ack. icecube@ihug.co.nz
- Embedded languages, object persistance... ack. Kevin Littlejohn
- Storing tokens with flex & bison Christer Enfors
- Storing tokens with flex & bison Rahul Sinha
- Storing tokens with flex & bison J C Lawrence
- Storing tokens with flex & bison cg@ami-cg.GraySage.Edmonton.AB.CA
- Storing tokens with flex & bison Christer Enfors
- Storing tokens with flex & bison Ola Fosheim Grøstad
- Storing tokens with flex & bison J C Lawrence
- Storing tokens with flex & bison cg@ami-cg.GraySage.Edmonton.AB.CA
- Storing tokens with flex & bison Jon A. Lambert
- Storing tokens with flex & bison cg@ami-cg.GraySage.Edmonton.AB.CA
- Storing tokens with flex & bison Jon A. Lambert
- Storing tokens with flex & bison cg@ami-cg.GraySage.Edmonton.AB.CA
- Storing tokens with flex & bison Jon A. Lambert
- Storing tokens with flex & bison cg@ami-cg.GraySage.Edmonton.AB.CA
- Storing tokens with flex & bison Jon A. Lambert
- Storing tokens with flex & bison cg@ami-cg.GraySage.Edmonton.AB.CA
- Storing tokens with flex & bison Kevin Littlejohn
- Storing tokens with flex & bison cg@ami-cg.GraySage.Edmonton.AB.CA
- Storing tokens with flex & bison Phillip Lenhardt
- Storing tokens with flex & bison Dominic J. Eidson
- Storing tokens with flex & bison cg@ami-cg.GraySage.Edmonton.AB.CA
- Storing tokens with flex & bison Chris Jones
- Storing tokens with flex & bison J C Lawrence
- Storing tokens with flex & bison cg@ami-cg.GraySage.Edmonton.AB.CA
- Storing tokens with flex & bison Ola Fosheim Grøstad
- Storing tokens with flex & bison Per Vognsen
- Storing tokens with flex & bison Christer Enfors
- Storing tokens with flex & bison Chris Turner
- Storing tokens with flex & bison Christer Enfors
- Storing tokens with flex & bison Jon A. Lambert
- Storing tokens with flex & bison Christer Enfors
- Storing tokens with flex & bison Jon A. Lambert
- Storing tokens with flex & bison J C Lawrence
- Storing tokens with flex & bison Greg Miller
- Storing tokens with flex & bison J C Lawrence