Arrays: new and old keys, i

Björnke von Gierke bvg at mac.com
Sat Sep 13 12:02:55 EDT 2008


On 13 Sep 2008, at 09:37, John Vokey wrote:

> Again, I ask, what have we gained by the ``new'' array features,  
> besides more brackets?


Maybe you're more of a hands on guy, and no explanation found on this  
world will ever give you the same "aha" like trying it out yourself.  
Barring that, here's a recent story on multidimensional arrays which  
made me understand why they can help me:

I am constantly trying out systems for games, among other things  
making maps. I have made a couple such test map stacks since spring,  
and started with 2.9, then switched to the 3.0 beta. For those game  
maps, I had chosen to use a 2d Cartesian coordinate system with square  
fields, like a checkers board. Normally I'd start out with a fancy new  
idea to scroll a map view, or how to speed certain animation things up  
(As rev is horribly slow with setting more then 100 objects visuals at  
the same time). So a common map might look like this in data:

Array[1,1] = 1
Array[1,2] = 1
Array[1,3] = 0
...
Array[100,100] = 0

Where 0 would be ocean, and 1 would be land. The problem of course  
would arise if I added another map feature, like player token  
positions, roads, cities, climate zones, whatever. Such an array might  
then look like this (example is with items, normally i'd use lines):

Array[1,1] = 1, savannah, bottom, village
Array[1,2] = 1, desert, , , settler_1
Array[1,3] = 0,,,, ship_2
...
Array[100,100] = 0

Now to read/populate that I'd normally just do:  "put "topleft" into  
item 3 of Array[x,y]". Normally by now I'd have the idea to add plant  
cover. I could add it as a fifth item, but that would not be the  
correct place (should be before roads, after terraintype). The place  
is important because it's easier to remember there, and because I have  
no way to identify which item is what otherwise. To enter a new item  
in between, I'd need to look at all my existing code, and change the  
items around (with great chances of entering something wrong, or  
overlooking a number). Now the same with multiple arrays (hierarchical  
representation):

Array[1,1]
-----------[land] = 1
-----------[terrain] = savannah
-----------[road] = bottom
-----------[city] = village
Array[1,2]
-----------[land] = 1
-----------[terrain] = desert
-----------[unit] = settler_1
Array[1,3]
-----------[land] = 0
-----------[unit] =  ship_2
...
Array[100,100]
-----------[land] = 0

Now this is self explanatory, just look at the keys and know what's  
there. No need to depend on a mental ordered model, and adding other  
information is dead simple, existing code that does not need that  
information will just ignore additional keys (if it was done in  
anticipation of that). So this form of data allows me to change my map  
much easier, and therefore increase my productive output.


When I work more with this new data structure, I'll probably will find  
many more very interesting things especially considering split and  
combine, as well as union and merge.

Bjoernke

-- 

official ChatRev page:
http://bjoernke.com/runrev/chatrev.php

Chat with other RunRev developers:
go stack URL "http://bjoernke.com/stacks/chatrev/chatrev1.3b3.rev"




More information about the use-livecode mailing list