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
- Embedded languages, object persistance... ack. Jay Carlson
On Saturday, January 01, 2000 2:03 PM
"J C Lawrence" <claw@kanga.nu> wrote:
> 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?
Cold and MOO have reasonable, well-defined answers to those questions.
The answer to that last question is: your fellow programmers form a lynch
mob. How is that any different than checking in a bunch of busted changes
to CVS?
> 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.
Agreed, and add "useful multiauthor security".
> > 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.
MOO got speed out of going bytecode, but the critical motivation was task
suspension. In a straightforward tree-descent interpreter, you end up with
continuation information sprayed all over the C stack; if you want to, say,
block the currently executing method and wait for a line of input from the
user, you'd have to save the C stack and later restore it when the line was
available. Ew.
The work involved in explicitly managing all the activation records on a new
explicit stack was probably about the same as doing the full rewrite to
bytecode.
> 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.
I think you've wandered into an old argument with both arms flailing.
Although most mainstream languages are class-based, a lot of important
languages and theoretical work are object-based. Cardelli's page at
http://www.luca.demon.co.uk/ has many interesting links; see in particular
http://research.microsoft.com/Users/luca/Slides/PLDI96Tutorial.pdf for many
of the issues outlined in one place. Cardelli forcefully argues that
class-based systems are strictly less expressive than object-based systems.
> 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.
This is a red herring. Object-based language implementations can and do
perform this kind of optimization without the model restriction required by
classes.
> 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.
If this is being argued as an advantage of the class-based model, I think
this begs the question.
> 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.
No. A MOO object defines its *behavior*, often in terms of delegation to a
parent object.
(Sidetrack: MOO frobs were a little like instances of classes described by
MOO objects; Cold borrowed them. Ben Jackson's WAIF proposal carries this
much further.)
> 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.
I haven't seen many examples in the MOO world where this has been an ongoing
problem. Singleton "real" objects (like swords and exits) frequently get
new behavior, but people tend not to create children of them. There is a
strong distaste in some parts of the community for not following a strict
prototype/instance distinction, but it's sure come in handy from time to
time.
(For a while, some people changed their parent object to *me* on LambdaMOO.
I was asked to disallow that because it could be used for quota scamming,
and the wizards involved thought it would be a lot easier to ask me to stop
than to go bug hunting.)
> > 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.
Only if your strict OO background isn't very broad. :-) No, I know what
you're trying to get at, but I think "mainstream OO" would be a better fit.
> > -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.
Absolutely. Here's a concrete example. Suppose you're using a restricted
Java subset as your extension language. You probably do *not* want to have
java.util.Vector easily available; whenever Alice's code returns a Vector
to Bob's code, Bob can mutate it. Gosh, I hope that wasn't a skill list....
This is patchable by adding authorization tests to the Vector class, but
then you have to teach your builders how Java-with-controlled-Vectors works,
ad infinitum.
Jay
- 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