[MUD-Dev] Thinking outside of the room . . . ur . . . box

[Zach Collins {Siege}]

On Wed, 30 Jul 2003, Nolan J. Darilek wrote:

> At the moment my current structures are simple rectangular prisms
> which are responsible for defining their own containment
> mechanisms. I.e. a character's containment need not include
> coordinates, as it really doesn't matter where your longsword is
> in relation to your pocketwatch. Rooms, space (in the
> galaxy/universe sense) will probably use Cartesian, while planets
> will use spherical.

Okay, full stop.  Let's make a list from what you've said:

  - Objects may contain other objects.

  - Objects may define their own coordinate space.

  - An object within a container is also in its container's
  container, with a position relative to that environment should the
  nearest container vanish.

  - The code that displays a player's view should not have to
  perform extra translation from one data structure (e.g.,
  spherical) to another (e.g., Cartesian).

Now a second list, of shoulds:

  - Some or all objects should be containers.

  - All objects should be in a tree structure of containers.

  - Some means should be provided of translating an object's
  location in one container's coordinate space to another
  container's coordinate space.

  - All objects with a coordinate space should translate their
  coordinates to something the renderer will accept.

  - Only the objects a player may look at from the inside should
  have their own coordinate space.

You'll note some of my own opinion has snuck in there, but I'm
leaving it where it is, for you to ponder or toss as you like.

> Another idea: descriptions are comprised of objects, not strings
> of text attached to rooms. If, for instance, you stand at an

...

> rubble. As I also want descriptions to change based on perspective
> and read more like a book than a random string of text that just
> so happens to be connected, descriptions will consist of a
> tag-based language which will allow for both textual substitutions

You'd better have a lot of recognizable landmarks, since a room's
description is normally static and thus helps to contribute to the
location's recognizability.  People getting lost would be a common
occurrence until they got used to translating their local
description back to a spacial image.

> start coding. First, I'm not terribly clear on how to integrate
> polar and Cartesian coordinates. I mean, say I have a square area
> on a planet's surface. I want the square area to represent a city,
> so I decide that it's, say, 5X5 KM. It would be easiest to handle
> this as a square using cartesian coordinates . . . and, for such a
> small area, the curvature of the sphere won't matter. What if the
> area is, say, 1000X1000 KM, however? I'm trying to avoid
> special-case situations ("You can instantiate rectangular areas,
> but don't make them larger than X!"), so I'm wondering if there's
> a more elegant solution for creating shapes atop spheres?

You shouldn't worry; the special case you mentioned always exists.
You could instantiate a zone of that size, but players most likely
will not be able to see that far.  Besides, containers define their
own coordinate spaces.  There are means to map points from one space
to another (you should look into topology), so the only problem is
whether and how you can see into or out of the container.

> containing a list of vertices, but are there any generic
> algorithms for taking a polygon of N sides and determining whether
> a point is contained within, or is this problem solved on a
> case-by-case basis (I.e. define a triangle class, rectangle class,
> etc.?)

Okay, topology and geometry (I believe there is such a method).

> hill and have your radius of visibility expand, walk into a valley
> and lose sight of the castle beyond the last hill, etc. Given that
> I'm only aiming for reasonably simple inclines, are there any good
> mechanisms for handling something like this?

Yes, and plenty of bad ones as well.  I'm inexperienced myself,
though, and haven't studied the necessary algorithms.

> I'm not sure if this last requirement is horribly naive . . . but,
> as this platform will be 3-D (albeit with a more simplified
> structure) I'd like to offer graphics of some sort in the future
> (though this isn't an initial design goal and, in fact, may be
> struck entirely.) As descriptions consist almost entirely of
> nearby

I think you'd probably be better off with a graphical renderer in
the first place, as several of the problems mentioned in this post
have been handled in various graphical game engines already.
Granted, many of those engines are indoor-oriented, meaning they
don't render unlimited visibility areas very well (or at all in some
cases), but there are also some good outdoor-oriented renderers.
It's hard to do both at once, though, so consider the needs of your
game.

--
Zach Collins
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev