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
I've been a lurker on this list for nearly a year. After taking a 8-9
month break (more like 'forced leave of absence' :) from MUDding, I've
come back, sorta. :) I've had some ideas which I'd like to toss around
for criticism, since the community here seems
knowledgeable. Since I'm writing a design document for a project which
I'm working on to implement these ideas, I'd like to expose any flaws
before I put much time and effort into this, and frankly, I'm not sure
how possible it is to implement.
For the past few months or so, I've been kicking around the idea of
designing a new MUD platform. One of the ideas I've had is to use an
already-available scripting language such as Java or Python instead of
creating my own, since I lack the experience and the time to do the
latter, and I don't really see the point, since I'd have to implement
the most basic functionality in my own language. So I initially began
developing a better object persistence system for Python (Basically I
made functions objects, with their code stored in a string to support
online editing of code and such.) I soon gave up on this when I
discovered Momoko, and since I hate duplication of effort, I changed
my design goals to encompass creating an environment rather than both
a server and environment. That was about a month ago, one long and
busy month, and now that my last final is approaching, I'm
anticipating pouring lots of work into my ideas.
What are my ideas, you ask? I'm trying to design a framework for
creating a very dynamic world with a very rich level of detail. I have
quite a few ideas, and I've noted several flaws in a few of them, but
I'm sure that I'm missing more.
I've often been obsessed with the idea of coordinate systems in
MUDs. I don't mean the typical 'one room per grid square' idea which
many MUDs use. Instead, I'm considering a system of stacked
grids. Each grid has a width and length, and an attached description
written in an XML-based mark-up language which will be used for all
text sent to the user. (The language is parsed server-side and has
switch tags for conditionally displaying text blocks based on time of
day, weather, etc. along with tags which display short textual
descriptions describing one object's relative position to another. 'to
the right', 'to the left', 'ahead', ...)
Maps represent a "logical area." On most MUDs, each room might be
replaced by a map with the room's width and depth. Furthermore, no
matter where you are, you are always present on a map. Imagine a
tree-like structure. The root node of the tree represents the terrain
atop which your world is set. In most cases, this would probably be an
ocean, but it could certainly be a desert, or maybe even the
universe.
Maps can also be transparent or opaque, depending loosely on whether
the area is indoors or not. Of course, there are many exceptions to
this rule; a heavily-wooded patch of woods may be defined as opaque,
while the observation dome of a colony ship may be
transparent. Transparency/opaqueness is important for the description
algorithm.
The algorithm which I am considering for rendering text descriptions
has one major flaw, which I'll mention below. It is recursive, first
displaying the description of the map atop which the user stands, also
describing surrounding objects. If the current map is transparent, it
recurses downward to the surrounding maps until the map boundaries
extend beyond visibility. So, if you are standing on a forested road
near an ocean, you first see a description of the road concatenated
with a description of the forest and the ocean. Since both likely
are impossible to see past, the description algorithm doesn't recurse
further.
This algorithm doesn't take into account visibility of distant
objects. If a mountain range rises past the forest, the algorithm
would stop after noticing that the forest is too far to see past. One
workaround which I've considered is marking certain objects as
'noteworthy', and thus continuing the recursion and only selecting
marked objects from the countless others, but this would be a waste of
CPU time. I'm sure there are ways of handling this; I just don't know
what they are.
This system would allow for some interesting features. Since movement
is based on speed and direction, and not on typing a single command
and moving an arbitrary distance in an arbitrary amount of time, it
seems that adding vehicle systems would be a natural extension to the
game. A disadvantage, though, is that it would be difficult to
represent a world which didn't conveniently use right angles for
everything. A winding wilderness road would be quite annoying to walk
down if you had to sit at your computer with a graphing calculator,
punching in trig equations every few seconds. Since most games use
compass directions anyway, I doubt that would pose much of a
problem. Additionally, it may be possible to create an intelligent
server-side algorithm for following roads, paths, bridges, etc. Since
they would be represented by rectangular maps, the algorithm would
only need to determine which border is the map's width and which is
its length, and set the object's course to the path which the line
follows, updating this every second or so.
Another idea is to extend the concept of object-orientation to
descriptions as well. Currently, a room's description consists of a
text string. What happens if something changes in the room's vicinity,
though? What if someone builds a shop? Nukes an office building? What
if a fire rages through a city? Someone has to change room
descriptions to accommodate for this. What if a room's entire
description doesn't consist of just a string, though? In my
description algorithm, I mentioned describing the objects on the
map. What if buildings, lamp posts, trees, shrubberies, etc. were
objects? A game developer would need only define a building and its
basic description, as well as other states in which the building could
be and their accompanying description. Thus, a builder would only need
to change the building's normal description, and once it is added to a
location, the description is automatically added by the algorithm. If
the building were to be moved somehow, its description would disappear
from the old location description and be added to the new one. If it
were destroyed, the description for its 'destroyed' state could be
substituted. This would require additional development time for
designers, but it might add lots of descriptive realism to the
world. This could be taken even farther; buildings could consist of
walls, which could consist of windows, though a builder doesn't
necessarily need to create each wall and window; a building template
could create everything. Objects could also have pre-programmed
behaviors as well; trees and lamp posts could be climbed to conceal
someone, windows can be looked through and or broken into, and
buildings could be scaled.
There are a few problems with this approach, though. If, for example,
you are in a forest, you don't necessarily want to see the description
of every single tree nearby. Certain objects could be defined as
groupable with group descriptions. Thus, lots of trees could be
described as such, while a single tree could be described in
detail. Additionally, depending on how far the object paradigm is
extended, building could eventually require someone to plot out
blueprints before starting, which isn't what I want to see. A building
object could handle the creation of all walls, windows, etc. while
giving the builder the chance to customize his work
afterwards. Arranging room maps within the building to fit within the
walls may also pose a problem. If the dimensions of the building are
made into an easy-to-work-with number though, laying out rooms
shouldn't pose much of a problem.
I have quite a few more ideas, though none are quite this complex. I'd
like to steer away from writing text directly to the client for
example, instead using events to signify changes in the
environment. Eventually the events would be converted into message
events depending on the user's immediate environment (in an attic,
rain may be heard pounding on the roof, while it may sound more
distant in a basement for example) but the environment will not be
allowed to simply send strings to the client.
On one hand, I can see how this could pose quite a problem for world
developers, and I'm sure some of you are thinking that it would be too
much work. My reasoning, though, is that if reasonable defaults for
most options can be provided, the developers aren't necessarily
required to put forth any additional work unless they want to make
their world even more detailed than it already is. Using the above
example, default weather messages can be provided for indoor and
outdoor locations. If a builder wants to implement a special case,
though, the facilities are there for him to do so.
I'd really like to hear your thoughts on some of these ideas before I
pour much more work into the design documents. I currently have a
rather shabby website for my project, but I'm almost embarrassed to
give it out until I have more to show for my efforts, though I'd
certainly welcome any folks who are interested in helping with
these ideas. If you are, or if you're just interested in watching my
slow progress (Though hopefully I'll speed up next week :) drop me a
private message and I'll send the URL. Thanks for reading; I rambled
on a bit longer than I had planned to. :) - 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
- 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