[MUD-Dev] Room and Terrain Integration in Textual Environments

[vognsen at post10.tele.dk]

This is my first real post to MUD-Dev. Working almost full-time and
attending school at the same time has left me with but little free
time so my posts will likely be infrequent indeed. I hope that this
post will spark some discussion or at least provide some inspiration
to some people out there.

The recent thread on room generation (more specifically the post by
Bruce outlining the design used at TEC) reminded me of a rather unique
design for room/terrain integration I did a while ago. First, I will
attempt to outline the basic room and terrain architecture and then
explain the mechanisms used to provide seamless integration of these
two subsystems. If anything described here seems vague or downright
wrong, I will be happy to provide further elaboration.

The sector system is largely inspired by the portal approach to
visibility determination in computer graphics. A sector is defined by
n edges (line segments) which go together to form a simple, convex
polygon. There are three different kinds of edges: sector portals,
terrain portals as well as normal edges. Each sector has a local
coordinate system with the origin positioned at the center of the
sector. So an object's position (ignoring terrain for the time being)
is defined by its sector and a placevector relative to that sector's
coordinate system.

A character's field of view (FOV) is defined by a triangle with one
vertex placed at the character's position. When you want to find out
what objects can be seen by the character at a given point in time,
you do recursive intersection tests to determine what objects are
contained within the FOV triangle. An object's physical geometry is
described by either points or polygons. When you have collected a set
of all the visible objects, you create a text string based on their
properties.

The quadtree sector database mentioned above also contains the sector
edges. If a portal edge (either of the sector or terrain variety) is
intersected you clip the view triangle to that edge and recurse to the
pointed-to sector/terrain, now using the clipped triangle as the view
triangle. Each of these recursions result in a text string of the
contents of the recursed-to sector. All these text strings are now
concatenated in a more-or-less intelligent manner.

Movement through sectors is handled by the collision detection
system. When a character collides with a portal edge, he/she is
automatically transferred to the sector that edge is connected to. All
movement in sectors or sector clusters containing players is based on
vector arithmetic, and is a well-studied and trivial problem when only
linear motion is considered. Also, the interface presented to the
player is based on relative positioning and motion (e.g. walk near to
the dresser) and not on the actual coordinates as such.

The terrain system primarily stores two types of data: the actual
terrain data and the objects on the terrain. The former is stored as a
heightmap in a quadtree and the latter is stored in a octree. Note
that sectors only work with 2-space positions, while the terrain
subsystem is based in 3-space.

Visibility while located in the terrain is handled by a technique
practically identical to the one used for in-sector
visibility. Besides containing normal objects, the terrain can also
contain sector portal polygons which allow visual and physical access
to sectors.

While the above descriptions may indicate a very complex system, the
actual implementation is very compact and the algorithmic complexity
is relatively low. It should be noted that high-edge or high-polygon
models are not needed for describing any of the objects, as the
textual descriptions are still generated based on more explicit
properties like color, material, textual descriptions, and so on.

Regards,
Per Vognsen
Software Designer at Wireless Interactive A/S

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