Re: 3 dimensional world arrays

From: Daniel A. Koepke (dkoepke@circlemud.org)
Date: 06/26/01


On Tue, 26 Jun 2001, Robert Masten wrote:

> Has anyone implemented this or have constructive thought before I hurt
> myself coding it....

You need to address:

  a) Coordinates and geometry.
  b) A scale, either uniform or dynamic.
  c) Memory concerns.
  d) Visibility.

The first is easy to address -- you need only add the coordinates and know
some simple Geometric formulae (distance formula, for instance).

The second requires some thought.  Do you want the scale to be uniform?
That is, does every "square" in your world have the same dimensions,
width, length, and height wise?  Or can rooms have differing scales?  Can
one room be wider than another?  Is this necessary to represent any part
of your system?  You might decide that some attribute is uniform, such as
the Z scale (every room has the same height), or that no attributes are
uniform.  How does the system layer to accomplish non-uniform scales?
Consider:

   +---+---+---+---+---+---+---+---+---+---+
   |   |   |   |   |   |   |   |   |   |   |
   +---+---+---+---+---+---+---+---+---+---+
   |   |   |   |   |   |   |   |   |   |   |
   +-+-+-+-+-+-+-+-+-+-+-+-+---+---+---+---+
   | | | | | | | | | | | | |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+---------------+

The final row is the one of interest.  We have several rooms smaller than
usual and several larger than usual.  It ends up being 13 rooms in the
last row, while the remainder have 10.  Socratically: How do you handle
cases where one row, column, or height-index has a different number of
rooms because of differing scales?  If you make every room the same scale,
how do you represent rooms that are smaller or larger than others?  If you
have an ant's nest and a human house, aren't the interiors both rooms?
But the scale is different.  How do you accomplish this?  Is everything on
the exterior in one scale, while interiors act like portals into their own
space?  (This is a good system, I think.  Maybe I should expand on my
thoughts about it?)

Consideration (c) is one of resources.  Consider if it were possible to
describe every room by a single byte (it's not, of course, but let's
pretend for a second) -- all of the data of a room fit into a single byte.
Now you decide you want your world to be small -- 100x100x10.  100 rooms
north and east, 10 rooms vertically.  Thus you have

  typedef byte roomType;
  roomType world_3d[100][100][10];

and we find

  sizeof(world_3d)
  ==> 100000

or roughly 100kB.  Now consider how sizeof(struct room_data).  This might
be around 888 bytes for just the members.  Our memory usage becomes 888
times greater:

  sizeof(world_3d)
  ==> 88800000

or roughly 88MB.  How do you propose to address memory consumption?  How
much efficiency can you trade-off for space?  One way might be to add
these rooms to 'neighborhoods' and rather than store containment
information per room (e.g., which characters are in what rooms), store it
in the neighborhoods.  This is an efficiency trade-off: you'd need to deal
with longer lists of objects and characters, but you'd save in per-room
storage.

Consideration (d) assumes you desire a player to be able to see in the
distance.  How do you see if anything's blocking his line of sight?  Is
there an efficient way to do this if we can't store containment lists on a
per-room basis?

There are ways to address all of these problems.  They're too numerous and
long to go into each, here.  Anyway, rather than posting solutions I've
cooked up, I'd prefer discussion of the issues.  Even if such discussion
eventually leads to the same conclusions I've come to, it'd be helpful for
everyone, I think, to participate in some design discussion.

-dak

--
   +---------------------------------------------------------------+
   | FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
   | Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
   +---------------------------------------------------------------+



This archive was generated by hypermail 2b30 : 12/05/01 PST