Named item order [was : Arrays: new and old keys, i]

Alex Tweedly alex at tweedly.net
Sat Sep 13 19:16:40 EDT 2008


I don't want to take anything away from your very calid point about 
arrays - but on a tangent mention a cuple of techniques I use to 
overcome the problem with using the 'old' way.

Björnke von Gierke wrote:
> 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:
> ...
> 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):
What I often do for this kind of situation is define a set of constants

constant cLand = 1, cTerrain=2, cRoad=3, cCity=4
> 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.
The constants provide some of this advantage, but still requires the set 
of constants to be replicated in each script (i.e. use script-local 
rather than handler-local constants). Sometimes (but not often enough 
:-), I go to the trouble of adding a global variable  to hold a version 
number for the constants, and then check against it (and, oviously, 
increment the version number each time I make *any* change to the list 
of constants).

global gMapConstantsVersion
constant cMapConstantVersion=1, cMapLandOrSea=1, cMapTerrain=2, ...

on openCard
   if gMapConstantVersion is an integer then #already defined - check it 
matches ...
      if gMapVersionConstant <> cMapConstantVersion then
          # explode
     end if
  else
      put cMapVersionConstant into gMapVersionConstant
  end if
end openCard

and a similar test in 'enough' places to detect problems.

I really wish we had either 'global constant's, or an 'include file' 
mechanism to fix this in a better way.


The other technique I use (particularly when I have CSV or TSV files to 
play with) is to have a list of then item names somewhere (e.g. in the 
first line of the TSV file), and use those ....

global cOffsets
...

repeat for each item tItem in theLine
   add 1 to tCount
   put tCount into cOffsets[tItem]
end repeat

and then I can do

put village into item cOffsets['town'] of Array[x,y]

Not as tidy - but very helpful if the data format is defined by someone 
else.

-- Alex.



More information about the use-livecode mailing list