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
- Embedded languages, object persistance... ack. J C Lawrence
- Embedded languages, object persistance... ack. J C Lawrence
On Wed, 29 Dec 1999 01:03:00 -0800
Joe Kingry <jkingry@uwaterloo.ca> wrote:
> 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.
What you are talking about we commonly call "runtime morphism",
which is just the ability to edit the object heirarchy at runtime,
and to have the effects of those changes appear during the same
runtime (there may be a delay) without an interruption in service.
However the use of an internal scripting language in a MUD is rarely
driven by the need to support runtime morphism More often the
driving factors are things like ease and rapidity of world
development and suitability for non-programmer users/players.
Adding runtime morphism is not necessarily an automatic or trivial
task once you have an internal scripting language.
Consider a deep object heirarchy, where a large number of objects
which are in common use in the game all inherit from a common
shared object. What happens if I come along and edit the methods
and/or attributes on that shared object? What happens if I
totally redefine it? What happens to all the objects that descend
from it? What happens to the commands people have or are issuing
which affect the child objects? What happens if the changes cause
mass breakages such that few to no objects actually work any more?
For me some of the driving reasons behind internal languages are
Rapid Application Development (implementing the game world or world
features), suitability for non-professional programmer use, ability
to tailor to world building versus general programming problems,
ease of extending the language in "interesting" directions, and so
forth.
> 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.
Not so fast. The majority of MUD servers out there with internal
scripting languages don't actually have an internal Virtual machine
(VM) to which they byte compile their internal scripting languages
(eg the Tiny-* clan). Having a VM and building a byte code compiler
can significantly increase performance, but it is also a non-trivial
programming task that many have foundered on.
More simply: Language design is not easy and is very easy to get
wrong. This is why many of the new rash of MUD servers are (very
intelligently) avoiding this problem entirely and using the Java VM
and then using Java, JPython, or similar to produce the appropriate
byte codes. There area certain trade-offs of course. Your ability
to redefine and tailor the language to your task at hand is gone,
your selection of possible languages to use is heavily limited
(especially for us by non-programmers), etc.
Another distinction which needs to be made here (which most of the
object oriented servers fail to do) is between a class definition
and an object. A class definition describes and defines how
something would be and would work if it existed. It _defines_
something, it doesn't actually create one of those things. An
object is an "instance" of a class. It is a created example of the
class definition.
Why is this important? In systems which make a distinction between
classes and objects, you can compile the class definitions and store
the results with with class, and then merely have the various object
instances refer to that definition to access their defining code.
You can also build different systems to handle class definitions
than you use to handle objects, tailoring each system to handle its
data type (class or objects) best and not the other.
However, most current MUD servers do not define the difference
between a class definition and an object instance. They are one and
the same. (eg MOO, ColdC, etc). What this means is that an object
usually also defines its class. Often programmers for such systems
try and install an artificial distinction by only doing programming
(class definitions) in objects that they never actually use
anywhere, and just inheriting children from those object when they
want to create intantiations (ie the objects players actually use).
Not making the distinction makes things simultaneously a little
messier and a little easier in implementing the system. You now
have only one type of thing to deal with (objects), but you now also
have to deal with a mess of class heirarchies amd objected
heirarchies which are intermingled. Depending on how you approach
things, the difference can be large or quite small.
Now as to how the bytecode is actually stored, there are lots of
ways, if you think about the bytecode really is just another data
stream associated with a class or an object. You could even do
something as simple as:
class class_definition {
attribute *attrs;
method *methods;
byte-code compiled;
};
and keep them all together, and handle them all together in whatever
your persistence system is.
> 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?
See the above dinstinction between classes and objects. MUSHes fail
to make that distinction and thus every object has the potential to
both be an object _and_ a class definition for other objects and
classes.
Yes, it is kind of confusing if you come from a strict OO
background.
As mar as execution is concerned (which only ever properly occurs
for objects, not classes), that occurs by having something call one
of the methods on that object:
class X {
void poke () {
print "Hello there!";
}
}
Object Y is an instance of class X.
You then have something call Y.poke () to invoke and run that
code.
> I think I have my object/class/code/driver concepts all muddled.
That's really easy to do with most MUD server implementations.
> -doesn't require me to learn it's "own custom embedded
> language"...
Realise that no matter what language it uses, for someone it will
require learning a whole new language as they won't know it.
Doesn't really matter if its Java, Python, NetREXX, or whatever.
The advantage with chosing a generic programming language here is
that your audience of people who do know it increases, and they have
some chance of being able to exploit that skill elsewhere as well.
Note however that once you have a language chosen, the real learning
pain is in your class heirarchy -- which is expressly NOT portable
and NOT leveragable to other systems.
> -somehow allows for security and access levels while coding
> -somehow allows for an event type system
This is a bitch and a minefield. You are caught right in the middle
of usability requirements on the one hand, and the need to keep
things secure on the other.
> Muq seems to have most of these except for MUF, I got tired of
> programming backwards ;).
I'm no fan of RPN either (or lisp for that matter).
> 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.
I haven't looked at Momoko in any detail yet. Would someone care to
point out MUD-Dev to the authors?
--
J C Lawrence Home: claw@kanga.nu
----------(*) Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=-- - 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