[MUD-Dev] Re: (fwd) Re: DESIGN: Proposed topic of Discussion (Injecting Pure Signal)

[Mik Clarke]

J C Lawrence wrote:

> From: <telford at xenon.triode.net.au
>
> An on-topic thread is generally doomed to failure but I might as
> well give it a stab.
> 
> > Administrators, designers, and coders - what are you creating?
> > Some seem to want to recapture your first mud, or get your very
> > own mud... I've no interest in those. But for the rest of
> > you... what is your objective? Do you want a lot of players?
> > Mature players? To show of your art?
> 
> My main spare-time project at the moment is movement and mapping.
> To put it simply I want to get something that goes beyond the
> discrete nature of rooms and exits. In a conventional MUD you map
> the mud by using graph theory and you explore by enumerating the
> rooms.
> 
> My feeling is that this doesn't offer enough scope for designing
> interesting maps and playing the game gets too mechanical. I want to
> store the position of each MOB (including characters) as a floating
> point vector to allow similar type of virtual world modeling that
> Quake uses (sans the graphics :-)

Firstly note that the graph can be in terms of more than north, south,
east and west.  I had an LP Mudlib at one point that allowed you to
define exits with any name you liked.  It worked quite well for,
allowing exits like 'swim in the pool', 'jump down', 'climb down',
'small tunnel'.  It also broken the graph away from the X-Y-Z grid and
made mapping a lot harder.

The current mud I'm working on will have contitional exits - they are
only present under certain circumstances and conditional destinations -
the exit normally leads to room A, but under some circumstances might
take you to room B or C.  This is useful for apparently changing a part
of the world in accordance to something that has happened elsewhere.
 
> The first main issue I wanted to address was scaling. A step in a
> discrete map is a step whether you be walking the wilderness or
> shopping in the main street or wandering the corridors of a
> castle. This is totally unrealistic, especially when movement points
> are taken into consideration. I am working on a multi-scaling map
> that is built from squares where the squares have a range of
> sizes. It only stores the squares that exist -- not the entire grid
> -- so memory efficiency is good. It can also take a given position
> and search for the region that the position is located in, the
> search is currently O(log N) where N is the total number of regions
> because I use B-tree storage. In theory, a suitable hash table could
> bring the search to O(1).

Sounds interesting.  Did you consider a hierarchy of fixed scales, where
each level would be a fixed size, with a fixed movement cost, but you
would have the ability to change levels?  Levels might be continental,
national, city and building, with maybe a factor of 10 between each one.
 
> What's implemented so far:
> 
> * moving around is easy enough when you specify the exact distance to move
>   but most players want to just give a direction and have the move distance
>   implicit. With suitably chosen implicit move distances the system should
>   `feel' quite similar to room-oriented MUDs that players are familiar with
>   while still allowing the realism of a virtual reality world.

Hmmm. Sounds a bit like the old Elite movement system.  One of the
problems with that is in the way it did colision detection.  It took a
fixed fraction of your current speed and extrapolated along your course
in steps that size to see what you hit.  This meant that, if you were
going fast enough, you could fly through a planet.  You'll probably need
some sort of ray/surface model or to step along the path using single
units to look for the walls.  Movement distance should probably depend
upon movement mode, but you might want to automatically stop it when the
player enters a new square.
 
Mik
--
http://www.geocities.com/SoHo/Cafe/2260