Re: [glob2-devel] Gradients (again)

[Andrew Sayers]

If I'm understanding your post correctly, this system would still only
be able to represent one fixed ratio of movement speeds, it's just that
instead of the grass/sand/water ratio being 1:1:2 or 1:2:4, it's
(10?):20:100.  The problem is that having separate buildings for
swimming pools and race tracks means you can currently have 16 different
ratios.  The example I outlined in my first post showed a situation
where the ratios could be split into 3 sets, where each set has a
different optimal path.  You could probably create a
situation where there are 16 different optimal paths, so any
gradient-based system must be have a separate grid for each ratio.

If we want globs to find a truly optimal path in a gradient-based way,
the first thing we need to agree on is how many speed ratios we actually
need to have a fun game.  Personally, my vote is that we only need one -
1:2:4, 1:1:2 and 1:2:10 are all good candidates, and we can see which
plays out best in practice.  We could even try making it configurable on
a per-map basis, although that might slow the game down a bit,
processor-wise.

Memory use is a very significant issue when thinking about how many
grids to have.  Each player needs a complete set of grids for each of
the 7 different types of resource, for forbidden areas, guard areas, and
every building he owns.  In a two-player game where each player has 10
buildings, that's a total of 38 sets of grids.  With the current system
of 2 ratios (swim/noswim) of one-byte grids, that means that a 512x512 map
needs at least 19 megabytes of memory just to represent all the grids.
Having 8 times as many grids, or making each elevation 4 bytes long
would make the memory requirements prohibitive.

In case that paragraph didn't come out right, what I'm trying to say is
that the memory requirements for an average game right now are:

        7 resource grids
        1 forbidden grid
        1 guard area grid
+       10 building grids
-----------------------------------------------
=       19 types of elevation

        19 types of elevation
        1 byte per square
        512x512 squares on the map
        2 ratios ("can swim" and "cannot swim")
*       2 players
-----------------------------------------------
=       19922944 bytes (19 megabytes)

Obviously these are rough numbers, but it gives you an idea of the
storage requirements Glob2 has (and the amount of data it is expected to
keep constantly updated).

Incidentally, it is quite easy to make certain areas completely
off reach.  The "deep water" idea could be implemented simply by
creating an inert "deep water" resource.  We'd have to do a bit of work
to make this system work elegantly, but it's not a huge challenge from
my perspective.

        - Andrew