[Home] [Groups] - Message: [Prev in Group] [Next in Group]

nu.kanga.list.mud-dev

47: Re: Room coding

[Full Header] [Plain Text]
From: Furball <K.L.Lo-94@student.lut.ac.uk>
Newsgroups: nu.kanga.list.mud-dev
Date: Thu, 13 Mar 1997 21:32:19 +0000 (GMT)
References: [1]
Organization: Kanga.Nu
Hi folks,

My name is Ling Lo and I'm working on a LPMud driver (of the Amylaar
flavour)... My mud is aiming for a space opera kind of theme, it has a
webpage situated at http://dark.x.dtu.dk/~ceilidh (temporary).  So far so
good, I've managed to write my own mudlib but recently, the driver is
becoming a hinderance to my needs (speed mainly, it's extremely flexible).
One of which is stated below:

On Wed, 12 Mar 1997, Nathan Yospe wrote:

> On Wed, 12 Mar 1997, Furball wrote:
> 

[stuff cut out]

> :The assassin waits patiently...
> 
> The assassin should have recieved a message when Ross zipped by, triggered
> by the request to the room to move Ross from point A to point B in the
> assassin's corridor. Now, if the event waiting state of the assassin was
> tight on the trigger, fire on the first thing that moves, there should
> have been a toss up between Ross and the assassin, no typing needed on the
> assassin's part, in that permission to move request.

I agree on the no typing bit, it seems insane to have to control your
character's every move down to the smallest detail.  Muds which do require
fast reactions tend to be dominated by the clients with the fastest
triggers.

> :The reason I present such a weird scenario is coz, if there are
> :transparent exits and characters run, in my system, the characters would
> :appear in the mudworld at certain points skipping the intervening space...
> 
> Right, noticed this.
> 
> :Any ideas on this one?
> 
> Running should poll ahead, not just for assassins, but for covered pits,
> loose gravel, etc, etc, etc. Of course, this does work better in an event
> driven system with sleeping events, a concept I borrowed from threads. My
> events are very much based on threads, in fact. Aside from that, perhaps
> smaller, faster steps? If you are running on a pulsed cycle, that may not
> be possible....

Yep, I'm running on a pulsed cycle, which means I can't run any real time
movement effectively but I can try.  Maybe I could spend the summer
hacking away at a driver.  Anyone care to teach me something on this? :)

A solution I just thought up whilst typing is to place an object the size
of the assassin's field of vision on the floor of the corridor.  Anything
colliding with the object will trigger a reaction on behalf of the
assassin.  Although, I need to work out how to check collisions first...


Ling aka Ceilidh at a few muds.

  |
_O_O_  Ling - Freshwater fish
ly ends up reducing the amount of writing that builders need to do, because it will tack on stuff like "There is some sort of settlement several miles to the north" instead of requiring the builder to enter it. They are only obliged to describe the immediate surroundings. Even things like plant life are added automatically; we have a database of several hundred trees, flowers, ground cover, and other sorts of plants which have areas in which they grow "automatically", and the builder doesn't need to do different descriptions for each season - the flowers only bloom at a certain time, the leaves fall off of certain trees in the winter, etc. In addition, different players will see the world in a very different way. A character that is 9 feet tall can see quite a bit further than a character who is 3 feet tall; however, if the smaller character attempts to hide from the larger character, he will find it quite easy, while the larger character will find it nearly impossible to hide from the 3 foot character given normal conditions. In addition, intelligence and perception as well as general world knowledge make stuff appear in different ways. For example, a stupid character might see, "A large pile of coins rests on the table" whereas a smarter/more perceptive one would see, "Several hundred coins rest on the table" and Rain Man sees, "231 coins rest on the table, one of which has a small dent on its surface." A character with knowledge of botany would see, "Two oak trees and a yew sappling grow here" versus a normal character who sees, "Three trees grow here." Naturally you can always try to take a closer look at a certain thing, which takes a certain amount of time, but gives you a bonus to your perception rolls. (Of course, if you just don't know the name of any trees, you can stare at it all day long and at most you'll get a detailed description of the type of bark, flowers, leaves, and what have you.) Obviously there is quite a bit more than these rather specific examples, but the point of all this is that we ended up sticking to the room concept. The main problem with getting more specific than this is that you loose the simple elegance of the room + cardinal directions setup. We have all our rooms aligned on a perfect grid (256x256x256, which is bigger than it sounds), which actually makes it extremely easy to conceptualize for both the builder and the player. You always know that if you go north, east, south, west, you're going to end up back in the same room, assuming you make your direction-sense rolls. By throwing in all this "extra" stuff, it works out that _most_ of the room description is very dynamic. Two different characters see two very different things, and even the same character returning later sees a different setting due to time of day, season, and their character's worldly knowledge. Yet it remains simple to imagine the actual layout and easy to navigate, no matter how complex the rooms themselves get, and you get to keep the mood and creative effect of having individual room descriptions, even though they serve a lesser purpose. > descends from the concept of my graphical MUD project. This is basically what we decided - if you want to get much more complex than current muds (refering to all those with a grid system already in place, of course), you have to go graphical. Many have done the overhead ansi map ala nethack/moria/angband, although this doesn't appeal to me much. I like to think that the ideal mud would play (and read) just like a good piece of fantasy literature. ANSI-maps don't really fit too well into this category, handy as they may be. As far as doing an _actual_ graphical mud, I don't think it would be worth doing unless you could do a real, totaly interactive 3d environment, maybe with a view along the lines of Tomb Raider, but with mud-like controls (ie not arcade-ish). > A blocking description would block things "behind" it, using the 2D > crystal latice matrix transforms to determin "behind"ness. Screening hides > the things behind it to varying degrees. Multiple objects can occupy the > same location, but have volume concerns. A "node" corresponds to a room, > and could concievably have size variation, though that is not necessary to > the design. The nodes portrayed here have scope 5x5. Nod...I think most grid-maps I've seen on muds work pretty much like this, although with varying amounts of detail as far as volume limitations. I tend to think that the z-axis control is generally the weakest part of these implementations, however. In addition, this goes back to the fundamental problem of this seeming pretty arbitrary to someone reading a text description. So you're left with a totaly non-traditional graphical display of some sort, of which I've yet to see one that conveys anything of the sense of mood and environment which you get with a really well-written area; it feels more like some abstract game of chess or something. Then again, perhaps this is the "crude" diku-coder side of my brain speaking.