[MUD-Dev] Rooms, 3D arrays, etc.

[Shawn Halpenny]

RHS Linux User wrote:
> 
> On Sun, 25 May 1997 coder at ibm.net wrote:
> 
> >
> > On 25/05/97 at 10:32 AM, Michael Hohensee
> > <michael at sparta.mainstream.net> said:
> >
> > Yup.  This is actually a workable idea, especially f you code in some
> > form of compressing array (a simple RLE would do fine, even better if
> > capable of handling several dimensions).  Multi-dimensional arrays can
> > get big, quickly.
> 
> Hmm, never heard of a compressing array.  I just figured on an array of
> structures like:
> 
> struct space
> {
>    int              terrain;
>    GENERIC_THINGY   *room;
> };
> 
> struct space world [MAX_LENGTH] [MAX_WIDTH] [MAX_HEIGHT] [MAX_TIME];
> 
> I suppose this could get on the large side.  I calculate a 400 X 400 X
> 100 X 10 world would use up 2,080,000,000 bits.  Hmm.  Might need a 3 Gig
> partition to run this thing on.... :)
> 
> How would you do compression?

Yep, a set of structures like that would get utterly huge if you had
even a moderately sized world.  Things like oct-trees, quad-trees,
R-trees, etc.  can be used to compress things like that down, but the
compression is really only effective if there are comparatively few
regions of detail.  These things are typically used to compress
bitmaps and geographical information, so they'd certainly be
applicable.  One could get away with using a set of adjacent n-sided
polygonal regions to compose the world (something I will probably end
up doing since I plan to have a very large world--probably in
conjunction with oct-trees, though exactly how is still up in the
air).

I wonder at using some sort of RLE, since if you compressed the entire
array, wouldn't you have to uncompress the first n elements in order to
address some element deep into the array?

--
Shawn Halpenny

"Don't force it--get a bigger hammer."
                            - Unknown