NPCStandIn was written to be dropped on a sphere and carried its identity in
per-instance public fields. The cost of that showed up in the scene itself: of
the two spheres, one was the Bartender and the other was named "Bartender (1)"
in the hierarchy while being configured as the Chair — data changed, name never
was. Nothing outside the scene could see what existed, and two copies could
disagree.
Identity now lives in an InteractableDefinition asset and the scene only places
a prefab. The migration matched the old objects by yarn node rather than by
name, which is the only reason the chair ended up as the chair.
InteractableDefinition rather than the planned "character definition": it covers
a character and a talkable object equally, so Bartender.prefab sits under
Prefabs/Characters and Chair.prefab under Prefabs/Interactables.
Three components collapse into one. DialogueInteractable was in no scene at all
— a dead trigger-zone variant of the same idea. ClickInteractableBridge existed
only to adapt NPCStandIn without modifying it, a constraint that died with
NPCStandIn; DialogueInteractor implements IClickInteractable itself. The parts
worth keeping were lifted out rather than discarded: WorldSpaceLabel and
InteractionPrompt are now normal components on prefab children, so a label can
be seen and positioned in the Editor instead of existing only at runtime.
InputDeviceTracker moved into NightclubArcadia.Core and gained a namespace,
leaving no global-namespace runtime types.
Characters get the same pipeline as Skills and Candidates:
Assets/Characters/characters.json is the source of truth, CharacterSetup
regenerates the definition assets on script reload and removes orphans. Adding
an NPC is a JSON entry plus a prefab — no code, and no Unity for the data half.
Phase 5.4 deletes the one-shot builders rather than disabling them. UILayerSetup,
PlayerControlSetup, UILayerSetupAutoRun and YarnDemoSetup assumed the
single-scene layout, had already destroyed a level scene and turned Systems
binary once each, and after NPCStandIn went they no longer compiled. The prefabs
they used to generate are authored and committed; the wiring knowledge is in
those prefabs and in git history. The asset generators — Skill, Candidate,
Character — are untouched and still work.
EditMode 42/42, PlayMode 7/7, YarnCheck 9 files / 35 nodes. All three scenes
still text.
Co-Authored-By: Claude Opus 5 <[email protected]>
Fixes "[SceneServices] Bartender: could not resolve dialogueRunner".
Resolving a cross-scene dependency in Awake is a race by construction. The
dialogue runner lives in Systems; an NPC lives in the level. Open the level on
its own, or let the scenes load in the other order, and the NPC wakes with no
Systems scene in sight. Worse, the failed lookup was cached into the serialized
field, so it stayed broken for the rest of the session rather than recovering
once Systems appeared.
NPCStandIn and DialogueInteractable now resolve lazily through a property and
cache only a successful result, so any load order works. Awake still does a
silent best-effort pass, which keeps the common case free.
SceneServices splits in two accordingly. TryResolve is silent and is what
speculative callers use; Resolve logs an error and belongs only where the
dependency is genuinely required. Both now include inactive objects — a system
parked inactive is still the object we mean, and excluding it reported "not
found" for something sitting in the hierarchy. The error text now says where the
runner lives and how to open the scenes, instead of asking a question.
BootstrapTests only ever covered the happy order, which is why it stayed green
while this was broken. SceneOrderTests loads the level BEFORE Systems and holds
that NPCs still reach the runner. It also asserts it is reproducing the race —
it counts the NPCs whose Awake-time resolution failed and fails if that is zero,
so the test cannot quietly start passing for the wrong reason. It currently
reports 2 of 2, which is the bug this commit fixes.
EditMode 42/42, PlayMode 7/7, YarnCheck 9 files / 35 nodes.
Co-Authored-By: Claude Opus 5 <[email protected]>
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]>
Fixes the "no Yarn Project has been configured" error coming back after running
the setup menus.
Last commit fixed the wrong layer. Retargeting YarnDemoSetup at a sandbox
stopped it destroying the level, but left the deeper problem: all of these
builders assume the single-scene layout, and after the split there is no target
path that makes them correct.
Two failures, both observed rather than reasoned about. Running the Yarn setup
left a generated scene open whose DialogueRunner had no project and auto-started
— that is the error the user kept seeing, coming from Dev/YarnSandbox.unity, not
from Systems. And retargeting the other three at Systems made PlayerControlSetup
pull navigation in with it; the baked NavMeshData is embedded rather than an
asset, so Systems.unity silently turned binary, 61KB text to 109KB binary. That
is trap 1 recurring on a scene that had just been fixed.
So the three scene builders now return early through LegacySceneSetup.Blocked,
with a message saying what they would have done and what to do instead. They are
not deleted: UILayerSetup alone is 818 lines that still record how the UI layer
is wired, and that record matters until prefabs replace it in Phase 5.
Set Up Skill System keeps its useful half. It regenerates the SkillDefinition
assets from JSON, which touches no scene; only the WireWorkingLevelScene call is
dropped, because those objects already exist in Systems.unity. Set Up Candidate
System was always asset-only and is untouched.
While diagnosing, YarnDemoSetup's own bug was found and fixed even though the
menu is now blocked: it set yarnProject through a SerializedObject on a prefab
instance without recording the override, so the assignment was dropped on save.
It now records the modification and refuses to save a scene whose runner has no
project.
Verified by running all five menus headlessly: the two asset generators run and
produce no diff, the three builders refuse, and no scene or asset changes.
Systems.unity restored to text, the level scene intact at 5 roots.
EditMode 42/42, PlayMode 6/6, YarnCheck 9 files / 35 nodes.
Co-Authored-By: Claude Opus 5 <[email protected]>
Fixes "Can't start dialogue: no Yarn Project has been configured."
Cause, and it was mine. Phase 3.7 said "retarget YarnDemoSetup.cs or retire it";
I retargeted it. But that menu does not modify a scene — it builds one from
scratch and calls SaveScene over its target. Pointing it at
SC101_ConferenceHall.unity armed it at the real level, and running it replaced
the scene with a bare Yarn demo: ten of fourteen roots gone, including the
player, the lighting and the navmesh. The leftover Dialogue System prefab
instance it left behind had no yarnProject override, auto-started, and produced
the error.
The scene was committed, so nothing was lost; it is restored from HEAD at 14
roots with its sun reference intact.
The menu now targets Assets/Scenes/Dev/YarnSandbox.unity and refuses to run if
its target is not under Scenes/Dev, via ScenePaths.IsDisposable. It is renamed
to "Set Up Yarn Sandbox Scene" so the menu says what it does. The other three
setup menus open and modify their target rather than regenerating it, so they
were never affected and are unchanged.
The test suite could not have caught this, because it asserted only that a
DialogueRunner existed. TheDialogueRunner_HasItsYarnProject now asserts there is
exactly one runner across the loaded scenes and that its project is set and
compiled — which reproduces the failure exactly when the scene is broken.
Also here: four UI prefabs pick up m_EditorClassIdentifier changes from
Assembly-CSharp to NightclubArcadia.Game, written by Unity after the assembly
split in the previous commit. Expected and correct.
EditMode 42/42, PlayMode 6/6, YarnCheck 9 files / 35 nodes.
Co-Authored-By: Claude Opus 5 <[email protected]>
The macOS build in the previous commit flipped UnityConnectSettings.m_Enabled
from 0 to 1 as a side effect of running through the authenticated CLI. Nothing
asked for that, and it was off before. The sub-settings — Insights, crash
reporting — were already 0 and stayed 0, so nothing was actually being sent.
It may well flip again on the next build. If it does, that is why.
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 scene is now Assets/Scenes/Levels/SC101_ConferenceHall.unity, serialized as
TEXT: 101KB of YAML, diffable and mergeable for the first time.
Root cause of the binary problem, which four earlier approaches had failed to
fix: the NavMeshSurface on the Navigation root held its baked NavMeshData
*embedded in the scene* rather than as an asset. NavMeshData prefers binary
serialization, and one such object forces the whole scene file to binary
regardless of the project's Force Text setting — which is why toggling that
setting, re-saving, and saving to a new path all did nothing.
Bisecting the roots one at a time found it: thirteen roots each saved as text on
their own, Navigation did not. Extracting the data to
Scenes/Levels/SC101_ConferenceHall/NavMesh-Navigation.asset — which is what
baking from the NavMeshSurface inspector produces anyway — lets the scene
serialize as text. The embedded copy was the anomaly.
The scene was rebuilt rather than copied, because saving the binary scene to a
new path reproduces binary. All 14 roots were moved into a fresh scene and
verified: roots 14 -> 14, cross-root references 25 -> 25, zero missing scripts.
Render settings were carried across by hand, since they do not travel with
GameObjects.
Nothing is split yet — every object is still in one scene, so no reference
crosses a scene boundary. That split is the next step.
Also here: the four Editor setup menus no longer each hardcode the scene path;
they share NightclubArcadia.EditorTools.ScenePaths, which is what made renaming
the scene a four-file edit. Build settings point at the new scene, the URP
template leftovers (SampleScene, Readme.asset, TutorialInfo) are deleted, and
.gitattributes drops the binary exception that existed only for the old file.
EditMode 42/42, YarnCheck 9 files / 35 nodes.
Co-Authored-By: Claude Opus 5 <[email protected]>
Mechanical consequence of the .gitattributes in the previous commit, done in one
deliberate pass rather than left to trickle out as surprise diffs whenever
someone next touches a vendored file.
74 files, all CRLF -> LF, 71 of them in StarterAssets. `git diff -w` over this
commit is empty: nothing but line endings changed. DialogueTest.unity is
correctly untouched, being marked binary.
Co-Authored-By: Claude Opus 5 <[email protected]>
Dialogue was already plain text, so the gap was never the .yarn files. It was
that the character material a writing session needs was either missing or stored
somewhere a writer could not comfortably work.
Three things were wrong. The writing handbook was not in the repo and was cited
by SC101.yarn as though it were. The best voice material — register, verbal tics,
success/failure/passive samples — was a \n-escaped string inside a JSON field.
The named NPCs had no sheets at all, existing only as their Yarn lines.
writing/ now holds the dialogue-facing layer, at the repo root so it gets no
.meta files and is not a Unity asset:
STYLE.md register, the five tone moves, the ban list, branching
shapes, the Wrong Truth rule, flag families, candidate rules
YARN-PRIMER.md the one page of syntax needed to write a scene
GLOSSARY.md in-world and project vocabulary
voices/ the eleven skill voices, one readable sheet each
characters/ Bartender, Chevalier Cassian Thal, Bradford Kane
scenes/ SC-101's brief: intent, beats, checks, constraints
lore/ the three identity readings and the rules that bind them
STYLE.md is a digest of the Mystery Writing Handbook in the Obsidian vault, with
pointers rather than copies. The vault stays the authoring home for design work,
and Ground Truth — the solution document — deliberately stays out of this repo.
The voice sheets are generated from skill_bible.json but are the source of truth
for the prose. tools/writing/sync_voices.py folds edits back; voicelib.py
guarantees notes -> dict -> notes is identity for all eleven, so --to-json on
unchanged sheets is byte-identical. VoiceSheetSyncTests fails the build on drift
in either direction, and was verified to fail on real drift rather than merely
to pass.
SC101.yarn's header is trimmed from prose rationale to the six rules that bind
while editing that file, with the reasoning moved to the scene brief.
EditMode 42/42. YarnCheck compiles 9 files / 35 nodes.
Co-Authored-By: Claude Opus 5 <[email protected]>
Both were test bugs; MotionInputMath itself is correct.
WorldToCameraRelativeInput_Yaw90 expected +1 for the camera-relative x. A camera
yawed +90 degrees faces +X, so world +Z is to its left and the value is -1. The
conversion applies Quaternion.Euler(0, -cameraYaw, 0) and Unity's Y rotation is
clockwise viewed from above, so forward maps to -right. The round-trip test
already pinned this convention and passes precisely because of it.
ScreenDeltaToWorldPan compared Vector3 with Assert.AreEqual, which is exact.
-10f * 0.02f lands one ulp from the -0.2f literal, so a correct result failed a
comparison that printed as identical at two decimals. Now compared per component
with a tolerance.
EditMode suite is 39/39.
Co-Authored-By: Claude Opus 5 <[email protected]>
This is the scene the camera rig, UI layer, player control, and dialogue work in
the preceding commits were built against: 14 roots covering Room_101, the
Dialogue and Skill systems, the three UI canvases, the Cinemachine brain and
camera, the reveal volume, navigation, and the camera anchor.
Committed as-is, in binary, deliberately. The file is a valid Unity scene and
opens intact, but it is serialized as binary while the project is set to Force
Text, so it is not diffable or mergeable. Converting it needs the Asset
Serialization setting to be re-applied from the Editor UI, which cannot be done
from a batch-mode run — the setter does not trigger a reserialize pass. Checking
it in binary is strictly better than leaving days of scene wiring untracked;
the conversion is a follow-up, tracked in docs/restructure-plan.md.
Co-Authored-By: Claude Opus 5 <[email protected]>
DialogueInteractable, DialogueTransitionController, and DialogueUIVisibility are
reworked against the new UI layer: visibility is driven by UIStateController
rather than each component toggling canvases itself, which removes the
duplicated show/hide logic the two had accumulated.
NPCStandIn now ignores the interact button while UIStateController reports a
menu open, so pressing interact through an open panel no longer starts a
conversation behind it.
The yarnproject change is graph-editor node positions only.
Co-Authored-By: Claude Opus 5 <[email protected]>
Editor/PlayerControlSetup.cs is the one-shot menu that assembles the playable
player: the armature, the Cinemachine rig, the NavMesh agent, and the pointer
input wiring, so a scene can be brought up to a controllable state repeatably
rather than by hand.
StarterAssets input actions gain the pointer and interaction bindings the new
locomotion and interaction layers read, and PlayerArmature is updated to match.
ThirdPersonController blends the animator toward target speed scaled by input
magnitude. Previously a partial stick deflection or a click-to-move arrival
played a slowed run clip via MotionSpeed alone; scaling the blend makes those
use the walk cycle instead.
Co-Authored-By: Claude Opus 5 <[email protected]>
Runtime UI under Scripts/UI: a UIStateController owning menu/dialogue state, a
PlayerControlLock so opening a panel suppresses world input, panel visibility
helpers, and the menu input binding.
Views: the dialogue stream presenter and its options presenter and message row,
the portrait HUD, and the player menu with character, journal, and tab-bar
views. Skills gains SkillsPanelView and SkillRowView, which is why the Skills
asmdef now references UnityEngine.UI.
Prefabs/UI holds the authored canvases (dialogue stream, HUD, player menu) and
their rows. UILayerBootstrap remains a hand-added runtime fallback for scenes
where those prefabs are not instantiated; it deliberately does not auto-spawn.
Editor/UILayerSetup.cs is the one-shot menu that builds and wires those prefabs
into a scene, with UILayerSetupAutoRun reminding after a script reload.
Art/UI/Placeholder carries the placeholder portrait the HUD falls back to.
Co-Authored-By: Claude Opus 5 <[email protected]>
Camera: Cinemachine-based rig with an anchor, a state director, point-of-
interest framing, pan input, and dialogue framing volumes.
Player: click-to-move over the NavMesh, a pointer input layer, and a motion
arbiter that reconciles direct stick input with navigation-driven movement.
The pure math is isolated in NightclubArcadia.Locomotion.Math with an EditMode
suite, so the arbitration rules are testable without a scene.
Interaction: IClickInteractable plus a bridge that routes pointer clicks to it.
Supporting project settings: adds the Cinemachine package, the Interactable and
Ground tags the raycasts depend on, and NavMesh agent dimensions matched to the
player capsule (radius 0.3, height 1.8, climb 0.25).
Co-Authored-By: Claude Opus 5 <[email protected]>
lennartandClaude Opus 5