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

[clawrenc at cup.hp.com]

In <Pine.LNX.3.91.970527141836.3629B-100000 at localhost>, on 05/27/97 
   at 08:35 PM, RHS Linux User <michael at sparta.mainstream.net> said:



>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.  

The standard solution would be to use a sparse array.  However your
array is actually pretty dense (almost all fields are filled with
data), so most sparse array techniques won't work too well.  The next
tack that struck me was to RLE compress lines, columns, or even
recatngles in the array as fit.  Why RLE?  Its incredibly cheap to
decompress -- you can afford to do a lot of it at runtime,

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];

Very space wasteful -- most of those pointers will be NULL.  Why not
have a simple array of unsigned chars for the terrain, using the 255
value as a flag.  If the value is 255, instead use those coordinates
as an offset into a sparse array to get the pointer value, if its not
255 the char value is the terrain type.

Additionally this allows you to compress the terrain array as above.

>How would you do compression?

RLE is incredibly cheap but not terribly efficient.  Its main benefit
to this area is that you don't want to decompress large data sets at
any one time -- you just want the value at a specific coordinate,
which is very easy to get from RLE.

With RLE I'd just compress rows and columns, or possibly even
rectangles.  Then on reading its just a matter of using the repeated
pattern to predict what the value is at a specific coordinate.

You could also use something like arithmetic compression.  Its also
cheap to decompress (very expensive to compress), but much more
difficult to impossible to extract that value of a specific byte at a
known position without decompressing the entire blob.

See the *.compression groups and FAQs for other details.

>> The problem here is preserving state changes at the various "time
>> levels".  Consider the cimple form of two players crossing the same
>> ocean.  Bubba  crossed two hours ago IRL, and Boffo is crossing right
>> now.  If you go for the 4'th D == time, then you should be able to
>> move some distance in the 4th D and find Bubba still crossing the
>> ocean (even if you can't interact with him for obvious reasons).  

>Well, you could always come up with some arbitrary rule which
>prevents  this.  Say that due to the laws of physics/magic, you can
>only travel in  time in 100 year intervals.  And each universe is
>moving forward in time  at the same rate.  So in the year 101, you
>could go back to the year 1,  but in the year 102 you could only go
>back to year 2.

So, after sufficient time has passed in the game, shouldn't you be
able to see Bubba passing there 100 years ago?  There are other forms
of this question you'll also need to account for.

>It would take a rather determined player to prove your universe 
>inconsistent. :)

You'd be surprised.

--
J C Lawrence                           Internet: claw at null.net
(Contractor)                           Internet: coder at ibm.net
---------------(*)               Internet: clawrenc at cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...