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
On Wed, 22 Dec 1999, Wesley W. Terpstra wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> > > Our plans (at present) are to make a compiler/interpreter for a custom
> > > OO language and build the actual MUD completely in this language. As I
> > > understand it, MOO already takes this approach. What I would like to
> > > gather is a list of features that people consider essential to a MUD
> > > programming language.
> >
> > 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. :-)
>
> Writing a scripting language isn't that difficult using flex&bison - two
> tools I've used quite often. Besides, I would make it a purists langauge:
> super short EBNF. ;-) Just to knit-pick, I meant a programming language -
> not a scripting language. :-)
>
> > > I also wanted to know of what MUDs currently implement any of the
> > > following: multithreading
> > A Good Thing...
> 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?
well our intention (keeping in mind that it is mostly vapor, aside from
much brainstorming we have some classes written, but ... (project only
began 1 1/2 months ago, with a temporary halt for finals)) was to have
single threads per zone, iterate through players per tick, have all
threads block until tick is over. we dont need thread-per-player as the
netowrk stuff is in its own process-per-player...
>
> > >guis
> > making your mud room-less?
> > so long as you keep your mud interface agnostic its ok... this will
> > distract you from the rest of the mud, as a decent gui interface takes
> > work (if you are doign more than simply applying menus and mapping as gui
> > stiff...)
> agnostic? I don't get the analogy...
> There are several of us. One of us will be writing the client and telling
> the server programmers what he wants for the protocols etc.
> So, I have no problems with shunting work on him. :-)
> We had planned on the actual gui being customizable between worlds, but
> for the first server we would have a birds eye view like Ultima 6. (great
> game!)
what I meant by interface agnostic is that the game can be played either
via text client or gui, but I guess you want gui...
> Yes, I know. But making it have a gui already forces our hand, so why not
> suck on their processor to lighten the servers burden?
> Not being an openGL techie myself, I don't even know if java can do
> openGL. Or if it can whether it can do it portably. Time to call up Alex.
you _can_ make it cross platform, GL is cross platofrm, the only platform
dependant part is the DirectX stuff (iow the screen grabber) but that is
not too hard to duplicate (directx for windows, DRI for Xwindows, and the
equivalent that I am sure exists for BeOS and Macs)
>
> > I personally am splitting up the traditional mud structure into a
> > inetd-based concurrent server that is jsut the client program (ie here
> > lies presentation, mapping stuff, etc), that connects via loopback to a
> > "event server" that handles movement, etc, all physically manifested
> > stuff, both using MySql for data storage, and IC AI stuff is implemented
> > by virtual clients connecting to the event server from mob programs.
> IC AI stuff? What is this? Some sort of 'bot that connects to your server
> locally on one of the more programatical ports? That's interesting. I will
> have to think on that.
mobs are controlled by a single program that logs into the event server
multiple times (this is being re-evaluated, for efficiency reasons prob
going to allow mult chars to be controlled by one connection (for the
queuing of commands in the event daemon) even though players will nto
be able to hook into this)
> Is inetd really a good choice? You'll be fork()ing like mad. How are your
> components talking - TCP or some memoryish IPC?
> You are storing your data in MySQL. That's a pretty good idea as long as
> you have some major program level caching going on. Mind if I borrow it?
yes, but only the 2nd stage client will fork, only the program that
outputs messages etc does this, not much overhead
>
> 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?
>
> Of course, there's alot to be said for your model 'cept for the overhead
> it's very modular. Hmmm. Hybridization time. *grin*
keep in mind, the eventd does not know about the room descs for example,
meaning that we get to shrink the eventd's ram requirements by a lot. The
db delivers that sort of data directly to the clients (if MySql can handle
the beating it takes in the corporate sector, it can handle delivering
room descs to 100 simultaneous connections ...
anyway, since these components talk over network stacks, you can run the
mud on 3-4 different computers, allowing VERY easy load sharing... just
dont try to do it across Inet (iow the 4 computers ought to be on a LAN,
as while bandwidth is not so much of an issue, latency is very important)
>
> > 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.
the best part is that one of the .sos is going to allow perl/python/etc
scripts to be used, and via perl modules reach into the mud
datastructure...
oh and the .so model is also being used for rooms; you odnt HAVE to have a
.so per room (that woudl be heinous) but can transparently add them, such
that you can have a house somewhere that does all sorts of logic outside
of the mud itself. Allowing hooks to outside logic gives total
configurability and control of the mud (asuming you can also reach into
the mud to change any data value, which is what the perl module is for)
>
> > >pgp
> > umm if you are talking about encrypting the text stream, just pawn off ssh
> > now that there is an opensource version of it... pgp is more for
> > non-streaming data authenticaiton and encryption
> >
> > > certificates about players so their characters can move from one server
> > > to another w/o the two servers ever talking directly.
> > servers talking is much better than trusting the client. Clients can be
> > reverse-engineered...
> You're not understanding my goal here:
>
> I want clients to store certificates - player stats on their own machines.
>
> We wanted to make this mud a sort of mud network that allows players to
> move between systems freely and without needing to trust the new server.
but their is inherent trust issue server vs server
>
> So, when you 'save' your character the server runs a pseudo-diff on the
> player status compared to the last save. It then timestamps and signs
> these changes with the server's public key. The client program then
> receives them.
>
well it signs them with the private key; the public key is used to
unencrypt them
> What this gives you: a player can import the things they gained from one
> server into another server as long as the new server trusts the old one.
>
> You can even have trusted server rings like 'The All Canadian Magi League'
> or something which is a ring of servers who all sign spells known with
> their key, and include their public key signed by the leagues private
> key. Hence a player can traverse these realms with all his spell casting
> intact.
>
> 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
> ..."
this is fine, but isn't this easier via a separete server-server protocol
unless you want tforward the actual packets, you are going to have to
make the user reconnect to the new server. So he does, enters the name of
the old server, the name of the char, and then the new server contacts s
the old one, the old one presents a challenge that is answered
cryptographically (think rsa keys) by the player. (there is an assumption
of trust among the various servers, else the propagation of data back from
the new server to the old is ludicrous) the old server then gives the new
the vital stats, no need for pgp, and this can also allow for encrypted
connectiosn..
> PGP was designed for a web of trust, and this is exactly the use I want to
> put it to on an inter-mud network. :-)
>
> Also, this system lets a player who was wronged by some server admin just
> drop that certificate from his character. It means he's now out of sync
> with that server and will be rejected in future connection attempts, but
> that he probably never planned on going back!
>
> So, to summarize:
> Servers keep state of the players.
> Players keep incremental character diffs signed by the servers they were
> obtained on.
this information is not reliable though
> When connecting, the player transmits any diffs the server hasn't seen.
this is unsafe, even with encryption, better that the servers talk amongst
themselves
> The server chooses to accept them or not based on its trust of the signing
> servers.
sas you are trusting the servers here, why not just keep this a server
issue
> If a player is abused, he drops that servers diff and is now out of sync
> with that server so cannot reconnect. However, he may continue to play
> elsewhere.
>
> Cool 'eh? This is why I want to know if anyone has already done this or
> whether I can stamp my name on it. ;-)
> If we get going on this, I fully intend to include this. Now if only RSA
> was proven secure... *sigh*
rsa != rsaref, I think the hole was a rsaref-specific problem, but je ne
suis pas un cryptographer
Rahul Sinha
Computer Science/ Government,
University Of Maryland College Park
AIM: qui dire ICQ: 9738191 (301)935-5542 - 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