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
On Wed, 22 Dec 1999 11:19:09 -0800 (PST)
Wesley W Terpstra <terpstra@iota.dhs.org> wrote:
> On Wed, 22 Dec 1999, Rahul Sinha <rsinha@glue.umd.edu> wrote:
>> is this more advantageous than coding the mud in C++ and making
>> it scriptable via this language, that way you can have whatever
>> language features you need to write the mud, and still avoid
>> making the scripting langauge overcomplicated....
> Well... The idea is that we would like to be able to change the
> underlying protocol without needing a reboot. This is because we
> wanted to have a special client program to render graphics. That
> way we can use openGL. :-)
You are relating several concepts as being dependent on each other
when they are not.
Some of the items are:
1) persistance of state across game reboots.
2) persistance of state across protocol redefinitions.
3) persistance of player experience across game reboots.
4) persistance of player experience across protocol redefinitions.
5) client server architectures and the server state dependencies
of the clients
6) OpenGL in the client
Taking those in order:
#1 State persistance across reboots really has nothing to do with
the languages the MUD or server are programmed in. It is a question
of data persistance and re-initialisation. You can go whole hg as
I've tried to do and to create and use a truly persistent language
where ALL data is ALWAYS persistent no matter what happens to the
system, or you can use your own manual data marshalling and
demarshalling routines with a backing store and handle all the
migrations yourself, or soemthing in between.
#2 Gets a little more tricky as it requires an adaptive client.
If you define a meta-protocol for the client such that the client is
able, transparently at runtime, to acquire and implement new methods
in a controlled manner, this can be done. This is of course easier
to do in a some sort of scripting language (Tcl/TK, Python,
whatever) which provide explicit support for runtime object
import/export, but it can be accomplished with hard coded languages
as well. The really big concern is security -- data integrity,
corrrectness, and authentication -- for the meta-protocol and the
entire "plugin/replace" process otherwise you run the risk of your
users spending more time killing/taking_advantage_of each other's
clients than of the game.
#3 Has significant prior art. The usual method is to fork the
sockets along with some state and authentication data to a holder
process while the game server reboots and then recover them when the
server comes back (method is OS dependent).
#4 Depends on how elegantly you handle the meta protocol in #2.
If you attempt to go for a base redefinition you require the client
to be able to do a quit/restart and retain state. An easy way to do
this is in exactly the same manner as #3, just treating the client
as a server.
#5 Is a rats nest that really has nothing to do with any of the
other points. It comes down to your definitions of your Finite
State Machines, your protocols (which are state machines in
themselves), and the logical dependencies of your data structures
(which is really part of your over-all FSM).
#6 Has nothing to do with any of the rest, and exists in
parallel.
> Writing a scripting language isn't that difficult using flex&bison
> - two tools I've used quite often.
Having been there, I would strongly recommend ANTLR (was PCCTS) over
the above (see the Library at Kanga.Nu). You can find some
discussion of all these tools, and others, in the archives.
Its also worth reading the Crenshaw compiler tutorial. Building a
decent VM or bytecode engine is trivial only at the very beginning.
You can find a copy in the archives or at ftp.kanga.nu.
> Of course, but how do current in-MUD programming languages handle
> race conditions? Do they do something similar to the java
> synchronize keyword? Do they use semaphores? What? What? And what
> is the best in peoples opinions?
My own view is that the data and synchronisation model of the base
server should bever be exposed to the User Programmer. As such I
use a fully persistent language and a mutli-threaded lockless DB
(see the archives) to hide all of this from the users. Due to this,
User Programmers are able to assume, correctly as happens, that ther
code executes in isolation and with the full control of the system
during that time.
Not-So-Simple-Translation: To the User Programmer the system is a
simple single-threaded linear procedural system without an interrupt
system.
> Our model was going to be more just one virtual machine which
> opens a bunch of ports and connects objects (inMUD language) to
> the sockets and tags on a thread or two. :-) Any problems with
> this model that people have run into?
Beware of thread count performance limits and the "thundering herd"
problem.
>> all commands are implemented as shared libraries, so that they
>> can be dlopen()ed during runtime (so as to not have to take down
>> server)
> Hmmm. That's interesting. I didn't think of that. In fact, I like
> that very much. That's certainly faster than an interpreted
> language. Maybe the MUD should allow you to code in C++ and
> compile to .so files which it then loads on the fly. Of course
> this is a security can of worms, but... I will have to think
> about this. Maybe a virtual machine isn't the only solution.
My approach (which is about to change again), uses Python as an
embedded persistent language. The server itself consists only of a
socket/connection engine, the language interpreter, the DB for the
persistence layer, and an event engine
(Executor/Dispathchor/ThreadPool) to turn the crank. Everything
else is in the DB under Python.
Recoding the world, the in-game parser, or anything of that nature
is just a matter of logging into the game and of editing the
appropriate objects in the game world and then watching the game
redefine itself about those new definitions.
Recoding the base server (say a tweak to the event engine), merely
requires killing ths server and having its manager process restart
it (the server is a child of the manager). The new child server
then inherits all the same old sockets etc from the manager, and as
far as the players are concerned, NOTHING changes in the game world
encluding their running commands and command queues due to the
persistent nature of the base system.
> I want clients to store certificates - player stats on their own
> machines.
...etc on using digital signatures to create a web of trust among
servers for character edits...
Hurm. Neat idea. The problems with rogue servers are obvious, but
probably can be either worked around or simply accepted for most
cases.
> You see the potential? Forgetten realms characters can walk into
> Ravenloft and some of their skills carry over and some don't. They
> are now under the Ravenloft admin's jurisdiction and any missing
> skills can be explained away as: "physically impossible to do a
> flying roundhouse kick from a ..."
The next problem of course is when the base models of the two MUDs
are so entirely different that little to nothing translates. Add
any sort of user programming to the scene and it gets *really*
messy.
--
J C Lawrence Internet: claw@kanga.nu
----------(*) Internet: coder@kanga.nu
...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... - 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
- 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