Re: [glob2-devel] Checking for nondeterminism

[Joe Wells]

Erik Søe Sørensen <address@hidden> 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