Joe Wells skrev:
And non-determinism can lead to net games being aborted, so this is
an important consideration.
Yes, I know...
which is why some seriousish regression testing in this area might be a
good idea.
I propose (in case this doesn't exist already) an automated way to run
the following test, e.g. when called as glob2 --twin-test <savegame>
<number of steps>:
- $n versions of the game is loaded, on the same host as a default,
where $n is the number of AI players in the savegame.
- The games commence a multiplayer game, loading the savegame and
running as each of the AIs.
- Besides the normal inter-game traffic, the games `compare notes',
comparing the exact locations and states of all the entities involved,
and perhaps other stuff like the gradients. For instance, after each
turn a random tenth of the entities are picked and compared.
It would be interesting to see if a test like that would catch the error
I mentioned...
I don't really know this part of the code. I think there are two
versions of “locked”: one for not-reachable by non-swimmers and one
for not-reachable by swimmers. I think this information is used by
some of the AIs.
Yes, looking at the code I figured 'locked' must mean 'reachable'.
But, reachable from where exactly? Any point on the border of the local
gradient? That would have been my guess, but that's not how I read the code.
/Erik
_______________________________________________
glob2-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/glob2-devel
