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
-- Start of included mail From: J C Lawrence <claw@kanga.nu>
> On Wed, 22 Dec 1999 22:14:44 -0500 (EST)
> Rahul Sinha <rsinha@glue.umd.edu> wrote:
>
> >> I implemented this because people can create their own worlds
> >> offline and when they start each becomes a shard. And two
> >> players with mutual agreeance can create links between their
> >> worlds and thus users can navigate over player created terrains.
>
> > so distribute the server binaries, and code in a easy way to link
> > servers.
>
> While I don't know the mechanics of how he does it, Dr Cat does
> something not entirely unrelated to this with Furcadia. I recall
> that he's discussed the high level features of these "dreams"
> (corret term?) on the list, but not the implementation.
Furcadia comes with a "dream editor" players can create their own maps
with, and which lets them test most of the features supported by the
scripting language (DragonSpeak) offline. The game server runs one
process per "dream", and when a player uploads one they've created it
assigns a process that currently has zero players in it to handling the
new map, and puts a teleporter to it next to the player that uploaded it.
The model is designed specifically to allow the processes to be
distributed across multiple host machines for scalability. But
I don't plan to let players run dream server processes. If it
ever looks like it might make good business sense & wouldn't degrade
the quality of the game experience, I might consider it. Right now
I'm running the server at an exodus.net hosting site, which as far
as I know is the best way to assure the lowest latency for the greatest
percentage of players. My experience suggests that most netlag comes from
the public peering sites that data gets routed through when a player's ISP
and the MUD's connection are provided by two different backbone providers.
If your MUD host is on PSInet, then players using ISPs connected through
PSInet will tend to get low latency, and performance for users on any of
the other backbones will be highly variable and unreliable (though
sometimes it will be good). The solution is to have a site with "private
peering", meaning basically they bought high bandwidth connections to most
of the major backbones. Generally traffic from any user that's using any
of those backbones will come right in through that backbone with low
latency. Exodus connects to six of the top backbones with fiber optic
lines, which is pretty good if you ask me.
For a less latency-sensitive game, or a hobby project, spreading the
servers all over and having highly variable performance might be fine
anyway. But for a commercial server, quality of service is essential,
and it would be bad to have people wander into a tavern and suddenly find
themselves being served by some user machine on an obscure backbone, or
through a sattelite link that guarantees 500 milliseconds extra latency,
or sharing some guy's 56K modem with 70 other players.
I've also been kind of assuming that all the server machines will be
connected by a LAN. It's conceivable some or all of the communication
between hosts could be done by having multiple CPUs with a shared memory
architecture as well. This allows for more lenient assumptions about how
much volume of data can pass between the server processes and with what
kind of latency it will arrive. If they were talking halfway around the
world to each other it'd take a lot less to choke the game and slow it
down. That's a theoretical issue at the moment, though. Right now the
architecture would work modestly well with widely separated hosts, and
after a major reworking I'm going to do next year to improve scalability,
it'd work even better. It's more an issue of my design goals, performance
goals, and business goals not being served by giving out the server
binaries than one of the architecture not being suited.
Of course there would be huge security issues with users hacking their
servers to do whatever they wanted, which they would do. Right now
security is dealt with in the game mainly by A) not having much of any
goal-oriented mechanics implemented yet so there's little motivation to
cheat, and B) having all significant decisions made by the server, so when
I do finally get some goals in people would want to cheat at, we'll still
be in fairly good shape. Turning the server binaries over to the public
would make method B very ineffective and inadequate, and I'd have to do a
huge amount of work to implement some more difficult approach (which would
still be less effective after all that work, most likely). Of course
continuing to avoid having goal-oriented mechanics would be one way to
reduce the impact of passing out server software. But giving a player
godlike powers would still enable them to impersonate anybody, spy on
people invisibly to listen in on their private conversations or simply log
ALL of everyone's speech to browse through later, and trick and mess with
people in a variety of other ways. Again, such insecurity might be
acceptable for a hobby game with a little warning to players up front to
watch out for that kind of stuff. But for a commercial game it's a bad
idea.
When it comes right down to it, a lot of the motivation players have for
wanting to run their own machine is psychological. Having it right there
on their PC is "cool" and gives them a feeling of greater control over it.
But a game running on someone else's server machine can give them as much
control over their areas as the designer/programmers choose to give them,
and can potentially offer them (and the players that enter their areas)
better and more consistent performance and reliability. The amounts of
CPU, RAM and disk resources it takes to handle a few dozen players
visiting their dream/shard/map/whatever-you-call-it are pretty trivial and
inexpensive these days, when you can pick up a machine for 500 bucks that
would have been called a "supercomputer" not that many years ago. Even a
hobby project shouldn't have too much trouble getting enough computing
power together to smoothly handle a few hundred simultaneous players, if
the server is coded for efficiency rather than for "let's fulfill the
creator's desire to implement a bunch of complex cool stuff the players
won't even notice". If you get a thousand or two thousand people - ask
'em to pitch in a few bucks or sell a t-shirt, and go buy a second server
machine and network them. Or scrape together a thousand bucks from your
inflated salary professional programmers are supposed to get, decide your
hobby is now officially an Expensive Hobby, and buy the machine yourself.
(If you're not getting an inflated salary yet, try a headhunter. :X)
Distributing a game server all over the net might also be fun because A)
it sounds cool and gets press and attention and people saying "wow that's
neat", and B) it's yet another technical challenge and a lot of programmers
are motivated primarily by the fun of figuring out how to solve interesting
new technical challenges. But to build the biggest and best online
environment, I think distribution is primarily a solution to the fact that
no single CPU system can handle more than N users (where N is a number
that rises each year, but is far smaller than the largest number of users
you'd like to have and won't pass that threshhold any time soon, if ever).
Distributing the game processes over machines on a LAN (or multiple CPUs
in a box with shared memory) solves that problem quite decently in my
opinion. Spreading things out further can degrade performance and
introduce huge security issues. Not to mention bigger problems keeping
every machine running the latest update to the server code, etc. And I
think the gains from spreading it out are tenuous at best, it's a solution
in search of a problem because it "sounds cool". It would have been an
appealing one back when machines were weaker - indeed, I did some thinking
about it back in 1990.
One place where there might seem to be some merit would be in serving
different countries, if there's enough demand for this to be an issue & if
the game is latency sensitive enough for it to matter. You're never going
to get latency halfway around the world faster than the speed of light
(unless we make some major new discoveries in physics), and right now
you're going to get performance a lot worse than that. But games like
Ultima Online solve this by putting a whole separate copy of the game in
those other countries that have sufficient demand to warrant it. Which
probably makes more sense anyway. Why make a "seamless" world where
walking to areas hosted in other countries made performance degrade badly,
and then go to extra effort to encourage people to stay in the locally
hosted areas so the game experience is better... When with less effort,
you can just set it up so they can only have the good performance?
*-------------------------------------------**-----------------------------*
Dr. Cat / Dragon's Eye Productions || Free alpha test:
*-------------------------------------------** http://www.bga.com/furcadia
Furcadia - a graphic mud for PCs! || Let your imagination soar!
*-------------------------------------------**-----------------------------* - 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