Erik Søe Sørensen <[EMAIL PROTECTED]> writes: >> 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.
Are you proposing to implement and _maintain_ this? If so, great. :-) Otherwise it likely won't happen. :-( Even if implemented, without active maintenance it will quickly rot. >> 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. I seem to remember that one place it is used is for determining if _enemy_ buildings are reachable. Maybe it is also used for other purposes. Anyway, I guess that it means “reachable from my home base”, so it is per-player. (Please verify this information before relying on it! I don't really know these implementation details.) -- Joe _______________________________________________ glob2-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/glob2-devel
