# Prototype foundation validation Date: 5 October 2026. Scope: initial prototype steps 1–3 only. ## Environment - Project: `E:/IndieGameProject/ProjectI`. - Editor: Unity `6000.6.4f1`; target Windows 64-bit; active PC URP quality asset verified. - Resolved networking: NGO `2.13.3`, Multiplayer Services `2.3.3`, Transport `6.6.0`. Pins preserved. - Connected Editor MCP verified. CLI absent from PATH. Existing cloud project linked; user confirmed free tier without paid billing. - Local Git/LFS baseline: `7fd00c7` on `prototype-foundation`; no remote operations. ## Automated checks - Foundation rules red run: 9 passed, 6 expected failures before implementation. - Foundation rules green/integrated run: **15 passed, 0 failed**. - Lifecycle regression red run: 15 passed, 2 expected failures before recovery implementation. - Full foundation suite after recovery fixes: **17 passed, 0 failed**; `TestResults/foundation-final.xml` and `.txt`. - Coverage includes four-player/pre-run admission, join-code validation, distinct/reusable spawn slots, diagonal/non-finite input, travel/bounds plausibility, retained failed cleanup for retry, and deferred connection loss at operation completion. - Built-player multi-process integration: **14 phases passed**, overall success, no cleanup errors, and all launched processes stopped. Evidence: `TestResults/foundation-4b06176822684310b8a81a9201de655f/result.json` plus per-player reports/logs. This used the real cloud connection service from one PC with separate anonymous profiles. - Verified actual two-process and four-process groups; four distinct spawns; one local player/camera/listener per process; owner movement replicated to host; fifth-player rejection; leaving/despawn/spawn reuse; run-start replication; admission rejection with a free slot; abrupt host loss; rehost/rejoin/reset; and invalid-code/valid-code retry. - First integration run timed out due to a PowerShell predicate checking the wrong client through dynamic-scope variable shadowing. Retained reports showed correct game rejection. The harness variable was corrected; the complete rerun passed. First-run evidence is retained at `TestResults/foundation-d3c2697e411149d8ad59c3673c3dda15/`. - No standalone Unity PlayMode test suite has been added; built-player integration and Editor Play Mode observations are reported separately. ## Editor and build checks - Initial Editor inspection: correct project/version, not playing/compiling, sample scene clean; zero console errors/warnings at that inspection. - Baseline Windows development build: **Succeeded, 0 errors, 512 warnings**, 4 minutes 9 seconds. Launched hidden outside the Editor; runtime/physics initialized without a reported exception; test process stopped. - First arena Windows development build: **Succeeded, 0 errors, 513 warnings**, 1 minute 42 seconds. - Initial Windows development build with recovery fixes: **Succeeded, 0 errors, 2 warnings**, 22.6 seconds. This was the build used for the original successful 14-phase integration run. The current rebuild is recorded below. - Baseline/first-build warnings include template Pipeline runtime configuration and existing rendering/inference shader warnings. Current-build warnings are unused template Pipeline runtime configuration and the diagnostic `DEVELOPMENT_BUILD` conditional deprecation in Unity 6000.6. The diagnostic probe still runs correctly in the verified development build; future release/variant work should update that conditional. - Supported Editor APIs generated the arena, four spawn markers, player prefab, NetworkManager, authoritative run flag, and UI Toolkit document. Original sample scene retained; GUIDs/meta files created by Unity. - Editor Play Mode hosted a private online game successfully; one host player at its assigned spawn, one enabled camera, one enabled audio listener, and successful normal leave. - Session menu screenshot inspected: readable text/buttons and status, correct connected controls, low-poly greybox visible behind it. ## Movement authority limitation Movement uses owner-authoritative `NetworkTransform` with local `CharacterController` and remote interpolation. Host checks reject/correct gross non-finite, out-of-arena, or excessive-travel poses. These checks happen after owner updates may have been forwarded; they are not authoritative movement simulation, wall-crossing prevention, or complete anti-cheat. Future authoritative shooting must use validated poses rather than trusting a raw client transform. No claim of prediction/reconciliation or latency quality is made yet. ## Human gameplay and external-network checks - Solo keyboard/mouse feel and collision checks: pending human control validation. - Two actual PCs on separate internet connections: pending. - Four independently controlled players: pending. - Controlled latency/jitter/loss: pending; belongs to further foundation acceptance and later refinement. - User said they can arrange two-PC and four-player tests. Follow `SETUP.md` and record results here before marking the parent steps fully complete. ## Status Step 1 is verified. Steps 2–3 are implemented and locally validated; their separate-network/human gameplay exit checks remain pending. Build/test success does not fulfill those external checks. Later prototype steps 4–12 are untouched. ## Rehosting after another game ends — 5 October 2026 User reported successful joining/leaving but failure to host after leaving or removal. The failure was reproduced when a remote host closed its game normally: the survivor's cleanup retained a leave request for a deleted game, and its next Host attempt failed with `SessionNotFound` before creating a new game. A failed SDK leave can also retain the old local type registration. Pre-fix built-player failure evidence: `TestResults/foundation-8741883bfceb4c94827ead4bb2d1a760/result.json` and `failure-reports.json`. Other focused leave/kick/disconnect/immediate-rehost cases passed and remain covered. Added regressions for absent membership before/during cleanup, deleted remote games, genuine transient errors, and retryable local-shutdown failure. Red: **20 passed, 4 failed** as expected. Green: **24 passed, 0 failed**. The application now finishes terminal cleanup locally and uses the SDK's per-connection default keys; a real outage still retains cleanup for retry. Review found no blocking issues. Current Windows rebuild: **Succeeded, 0 errors, 2 known warnings**, 20.7 seconds; `Builds/Prototype/build-result.txt`. Full built-player suite: **32 phases passed**, no cleanup errors, all test processes stopped. Evidence: `TestResults/foundation-888df4e1899942dc9477375b12c0e8ca/result.json`. Recovery coverage now includes normal client leave→host, cloud membership kick→host, transport/debug disconnect→host, immediate leave→host after run start, normal remote-host deletion→survivor hosting→another player joining, and two repeated alternating recovery cycles on the same processes. Original two/four-player, movement replication, admission, rewards-free run flag, and abrupt host-loss checks still pass. All built clients ran locally through the real cloud service; this does not substitute for separate-PC keyboard/mouse playtesting. The installed SDK may retain obsolete local registry entries after terminal cloud failures; no supported purge API exists. The application stops their networking and avoids key reuse. The session UI reports the current session only.