The scenes were never destroyed. Pressing Play with only Bootstrap open means
GameBootstrap loads Systems and the level at runtime, and Unity discards
runtime-loaded scenes when Play ends, restoring whatever the Editor had open —
Bootstrap alone. The Hierarchy comes back nearly empty. Every scene file was
byte-identical to HEAD throughout, still text.
Tools > Nightclub Arcadia > Open Game Scenes opens all three with the level
active, which is the authoring setup. With them already open, GameBootstrap's
LoadIfNeeded skips them and they survive Play. GameSceneWorkflow also captures
the scene setup before Play and restores it afterwards as a safety net, skipping
the restore when Unity already got it right and ignoring scenes deleted meanwhile
— an exception in that callback would leave the Editor in a worse state than the
problem it fixes. Toggleable under the same menu.
Also fixes `make lock`, which had a self-matching bug since Phase 1: `pgrep -f`
on the full binary path matched the very shell running the check, because the
pattern appears in its own command line. It reported the Editor as running when
nothing was, and would have blocked every make test/build once anything else
matched. Now `pgrep -x Unity`, which matches the process name and cannot match
the shell.
EditMode 42/42, PlayMode 6/6, YarnCheck 9 files / 35 nodes.
Co-Authored-By: Claude Opus 5 <[email protected]>
No project code is in Assembly-CSharp any more. Five assemblies: Core (no
dependencies), Locomotion.Math, Skills, Game (everything else under Scripts),
and StarterAssets.
Game is one assembly rather than one per area, which is what the plan assumed.
Measuring the dependency graph first found three cycles, all through UI —
CharacterPanelView reaches into Dialogue, PlayerControlLock into Player, and
UILayerBootstrap into Cinematics — plus two edges a using-scan cannot see,
because NPCStandIn is in the global namespace. Assemblies cannot be circular, so
splitting further means relocating those three files. That is a code-movement
task, not an asmdef task, and nothing needs it yet.
StarterAssets had to get an assembly of its own. It had none, so it lived in
Assembly-CSharp, and an asmdef assembly cannot reference the predefined
assemblies — four runtime files use it, and all four would have stopped
compiling.
The payoff is immediate: BootstrapTests no longer needs reflection to reach
NPCStandIn and CinemachineFollowsPlayer, which is exactly why Phase 3 wanted
this.
Assets/Editor/PlayerBuild.cs is the headless build entry point. It reads the
enabled scenes, asserts Bootstrap is scene 0 because the player opens scene 0 on
launch, honours the -buildOutput the CLI forwards from -o, and calls
EditorApplication.Exit(1) on anything short of Succeeded — without which Unity
exits 0 on a build that produced nothing and CI goes green on it. Verified end to
end: a 172MB .app in about two minutes.
Two renames, both different from what the plan described. DialougueSkillComparison.cs
contains a class called SkillFunctions — the filename never matched the type, so
it is now SkillFunctions.cs. The two .yarn files with spaces in their names lost
the spaces rather than becoming kebab-case, which would have made them
inconsistent with Bartender.yarn and SC101.yarn; spaces were the actual problem.
Both renames preserved their .meta GUIDs, and the yarnproject graph keys and the
two character sheets were updated.
EditMode 42/42, PlayMode 5/5, YarnCheck 9 files / 35 nodes, make build green.
Co-Authored-By: Claude Opus 5 <[email protected]>
The game now starts from Bootstrap.unity, which additively loads Systems (the
dialogue runner, skills, UI layer, camera rig and the player) and then a level
(geometry, light, navmesh, reveal cameras). The level becomes the active scene so
new objects and lighting land there.
The player moved into Systems. It had been parented under Room_101 — under level
geometry — and it is persistent content, not level content. Moving it also
removes most of the cross-scene breakage on its own.
Unity nulls any serialized reference that crosses a scene boundary. Measured
rather than guessed: the pre-split scene was pulled from git and its null
references diffed against the split result. Exactly seven were lost — both NPCs'
dialogueRunner, dialogueUI and player, plus the reveal camera's tracking target.
A first naive audit reported 210, which turned out to be pre-existing Unity
defaults like Image.m_Material; the baseline diff is what separated the two.
Each of the seven now resolves at runtime. SceneServices.Resolve fills in a null
Inspector reference by searching the loaded scenes, keeping an assigned value if
there is one; CinemachineFollowsPlayer binds the reveal camera once the player
exists. Both follow the pattern already used by CameraFramingVolume and by
NPCStandIn's player lookup, rather than introducing a new one.
Assets/Tests/PlayMode is new, and it immediately paid for itself. BootstrapTests
loads Bootstrap and asserts the whole game comes up; on its first run it caught a
real bug the split had introduced. The player's NavMeshAgent lives in Systems
while the NavMesh is baked into the level, so during load the agent exists
off-mesh and ResetPath logs an error. ClickToMoveController now guards on
agent.isOnNavMesh rather than a bare null check. No EditMode test could have seen
that, because none of it has run yet.
Two of those checks reach their types by name through reflection: NPCStandIn and
the Cinematics namespace live in Assembly-CSharp, and an asmdef test assembly
cannot reference the predefined assemblies. Per-area asmdefs remove the need.
Build settings list all three scenes with Bootstrap at index 0, which
LoadSceneAsync by name requires.
EditMode 42/42, PlayMode 5/5, YarnCheck 9 files / 35 nodes.
Co-Authored-By: Claude Opus 5 <[email protected]>
The invocations in CLAUDE.md were correct but long, and retyping them is how
flags get dropped. `make check` is the gate a change should pass: Yarn compiles,
voice sheets are in sync, EditMode is green.
`make test` and `make build` depend on a `lock` target that fails if the Editor
has the project open, which removes the most common confusing failure. It
filters out AssetImportWorker children, which are not a second Editor.
tools/ci/report_tests.py parses the NUnit results and exits non-zero on failure,
because Unity documents no common exit-code definition across the components
under test — the XML is the authority, not $?.
`make merge-driver` configures UnityYAMLMerge for the .gitattributes rules added
earlier. Note the binary lives in the Editor bundle under Contents/Helpers, not
Contents/Tools as most guides say; there is no Tools directory in Unity 6 on
macOS.
Also ignores the local .test-results/ and build/ output.
Co-Authored-By: Claude Opus 5 <[email protected]>
lennartandClaude Opus 5