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
Nolan Darilek wrote:
>
> I've been a lurker on this list for nearly a year.
Same here. :)
> After taking a 8-9 month break (more like 'forced leave of absence'
> :) from MUDding, I've come back, sorta. :)
I've only really played one MU*, and haven't had much access to it for
a year and a half now, except during the summer. It also has had a
playerbase of about 3 or 4 for the last year or so, and now they tell
me it's going down permanently.. :s
So take my input with a grain of salt.
> 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.
whaddya know, I'm considering the same thing.. estimated release date
is in ten years, especially considering the current [nigh-nonexistant]
rate of development.
> 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.
Same here, at least to some degree.
> 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.
[snip]
hm.. I think I'm trying for a more dynamically-generated appraoch:
the underlying layers have some environmental effects, but most of the
current description depends on what objects are visible.
> 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.
Again, this is similar but not the same as what i'm planning. there's
a base 'ground' layer, which has various terrains on top of it (town,
forest, desert, mountain, etc) and those will likely have objects on
them for the room's appearance. I don't think there would be a way to
translate the 'standard' MU* concept of rooms to my system, although
indoor 'rooms' might be similar.
> The algorithm which I am considering for rendering text descriptions
> 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.
That doesn't sound too bad, but I don't like your next statement:
> Since both likely are impossible to see past, the description
> algorithm doesn't recurse further.
How do you know that both are likely to be impossible to see past?
Perhaps you could implement some sort of sight radius for the
character which determines how far away you recurse?
> 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.
[someone mentioned heightfields, which you need for various reasons]
OK, another question: do you recurse _through_ the neighboring maps
as
well, or just add them in? I didn't entirely understand you there.
> 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.
It's not something I would've thought of easily, but it is needed for
my MU* for other reasons, so hearing that they're a "natural
extension" is good news for me :)
> A disadvantage, though, is that it would be difficult to represent a
> world which didn't conveniently use right angles for everything.
Why must this system use only 4 directions?
> 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.
You couldn't just say 'follow road' or something, and let the computer
handle the direction changes? [reads the next paragraph] yeah,
something like that. Mayhaps make roads etc with some sort of radial
vectors[1] that say where & how the road turns, and then the algorithm
can apply the same vectors to anyone following the road?
[1] I just made up that phrase, actually.. In this usage it appears to
be approximately a derivative of the road if it were a function.. it
would be a series of values for how much the road swerves;
{.1,.1,.1,-.2,-.2,-.2} would be a gentle right curve followed by a
left curve that was twice as sharp.
> Since most games use compass directions anyway, I doubt that would
> pose much of a problem.
Perhaps, but it also would eliminate some of the richness your system
could have.
> 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.
Which is more or less what people do, right? ..You might also be able
to use this to implement 'drunkenness'... instead of following the
road straightly, you weave all over it. [randomly 'push' the
character's direction] heheh :s
[snippage throughout]
> 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. 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; a building template could create
> everything. Objects could also have pre-programmed behaviors as well.
<nod> That's how I intend my system to work.
> 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.
The MUD-Dev list mentioned something about uber-objects that I thought
applies to this.. Instead of grouping objects, make a group-object &
then say what individual objects it may contain.
> 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.
<nod> I'm now toying with the idea (just an idea right now) of using
POV-Ray files (or something similar) as area files...
Sure it'll take a bunch of work, but you can see what the place
actually looks like if you want.. <g>
> 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.
sounds good.
> 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.
<nod> there more functionality you put into your part, the less
details the builders will need to mess with.
> 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. :)
This is really why I'm writing - I'd like to watch your progress :)
I may be able to help or I may not, but either way I'd like to see how
you do with this.
Hope I gave you _some_ useful input..
Strike & Co.
--
Rule # 1: There are always exceptions to the rules.
- 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