Parity
Training starts with a deterministic engine
Problem
An AlphaZero run is meaningless if the Python simulator can drift from the Unity/C# rules engine. A single wrong branch order in combat, targeting or effect resolution would teach the model a game that does not exist.
Resolution
The Python engine is treated as a parity port first and an AI substrate second. The C# behaviour remains the source of truth, method names and state fields are mirrored, RNG is centralized, and every training layer consumes the engine through public replayable state.
System flow
- 01The decompiled Unity behaviour is documented into phase-by-phase engine notes before Python code is written.
- 02Seeded matches, recorder/player logs and scenario tests replay the same inputs against deterministic snapshots.
- 03Only after the replay and parity harness is green does the ML layer receive the state through OptcgEnv.
Implementation notes
EngineRng is the single randomness surface; rogue random imports are blocked by tests.
Replay snapshots use canonical JSON and parity scenarios cover blockers, replacements, costs, power, silence and DON flows.
Verb coverage guards V3 and legacy effect fields so new card mechanics cannot disappear silently.
