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.
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
