replace the NPC scaffold with data-driven prefabs, and retire the builders
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]>
This commit is contained in:
@@ -328,10 +328,14 @@ There is **no manual sync step** for dialogue. The chain is:
|
||||
The only things that need a human/Editor step are the *data* files, not the dialogue:
|
||||
|
||||
```
|
||||
skill_bible.json → Tools ▸ Nightclub Arcadia ▸ (SkillSystemSetup) → Skills/Definitions/*.asset + SkillDatabase.asset
|
||||
candidates.json → Tools ▸ Nightclub Arcadia ▸ (CandidateSystemSetup) → Candidates/Definitions/*.asset + CandidateDatabase.asset
|
||||
skill_bible.json → Tools ▸ Nightclub Arcadia ▸ Set Up Skill System → Skills/Definitions/*.asset + SkillDatabase.asset
|
||||
candidates.json → Tools ▸ Nightclub Arcadia ▸ Set Up Candidate System → Candidates/Definitions/*.asset + CandidateDatabase.asset
|
||||
characters.json → Tools ▸ Nightclub Arcadia ▸ Set Up Characters → Characters/Definitions/*.asset
|
||||
```
|
||||
|
||||
`characters.json` is where an NPC or a talkable object gets its display name, its Yarn node and
|
||||
its interaction range. Adding one is a JSON entry plus a prefab; it needs no code.
|
||||
|
||||
Those setup scripts also register a `[DidReloadScripts]` callback, so in practice the assets
|
||||
regenerate on script reload too. The JSON is the source of truth either way.
|
||||
|
||||
@@ -445,8 +449,8 @@ should not be — see `docs/restructure-plan.md`.
|
||||
|
||||
- Namespaces: `NightclubArcadia.<Area>` — `Skills`, `Dialogue`, `UI`, `UI.Dialogue`,
|
||||
`UI.HUD`, `UI.Menu`, `Cinematics`, `Interaction`, `Player`, `Player.Math`.
|
||||
**Exception:** `NPCStandIn.cs` sits in the global namespace. That is a scaffold tell, not a
|
||||
convention to copy — new runtime types always get a namespace.
|
||||
There are no global-namespace runtime types left; the last one, `NPCStandIn`, went with the
|
||||
scaffold, and `InputDeviceTracker` moved into `NightclubArcadia.Core`.
|
||||
- **Assemblies.** No project code is in `Assembly-CSharp` any more:
|
||||
|
||||
| Assembly | Covers | Depends on |
|
||||
@@ -457,6 +461,10 @@ should not be — see `docs/restructure-plan.md`.
|
||||
| `NightclubArcadia.Game` | the rest of `Scripts` | Core, Skills, Math, StarterAssets, packages |
|
||||
| `StarterAssets` | vendored template code | Input System |
|
||||
|
||||
`Scripts/Interaction` holds the interaction layer: `InteractableDefinition` (the asset that
|
||||
says what a thing is called and which node it starts), `DialogueInteractor` (the component
|
||||
that places one in the world), plus `WorldSpaceLabel` and `InteractionPrompt`.
|
||||
|
||||
`Game` is one assembly rather than one per area because the areas are genuinely cyclic:
|
||||
UI ↔ Dialogue, UI ↔ Player and UI ↔ Camera, via `UILayerBootstrap`, `PlayerControlLock` and
|
||||
`CharacterPanelView`. Splitting further means moving those three, not just adding asmdefs.
|
||||
@@ -505,15 +513,13 @@ should not be — see `docs/restructure-plan.md`.
|
||||
four runtime files use — without that, everything referencing it would have stopped compiling.
|
||||
Keep it in mind before adding loose scripts outside an asmdef folder.
|
||||
|
||||
5. **The one-shot scene builders under `Assets/Editor` are disabled, on purpose.**
|
||||
`Set Up UI Layer`, `Set Up Player Control & Camera` and `Set Up Yarn Sandbox Scene` were
|
||||
written for the single-scene layout. After the split they do damage rather than work: pointed
|
||||
at a level they rebuild systems content that already exists in `Systems.unity`, and pointed at
|
||||
Systems, `PlayerControlSetup` drags navigation in and silently turns that scene binary (trap 1
|
||||
again). Both were observed. They now return early via `LegacySceneSetup.Blocked` and are kept
|
||||
only as a record of how the wiring works until prefabs replace them (Phase 5).
|
||||
`Set Up Skill System` and `Set Up Candidate System` still work — they regenerate assets from
|
||||
JSON and touch no scene. **To run the game, open `Bootstrap.unity` and press Play.**
|
||||
5. **The one-shot scene builders are gone.** `UILayerSetup`, `PlayerControlSetup`,
|
||||
`UILayerSetupAutoRun` and `YarnDemoSetup` built scenes from scratch and assumed the
|
||||
single-scene layout; after the split they produced duplicates, and one of them destroyed a
|
||||
level. The prefabs they used to generate are authored and committed now, so they were deleted
|
||||
rather than fixed. They are in git history if the wiring ever needs consulting.
|
||||
`Set Up Skill System`, `Set Up Candidate System` and `Set Up Characters` remain — they
|
||||
regenerate assets from JSON and touch no scene. **To run the game, open `Bootstrap.unity`.**
|
||||
|
||||
6. **`unity run` reserves `-batchmode`, `-nographics`, `-quit`, `-logFile`.** Passing any of them
|
||||
after `--` is a hard error, and its output does not reach stdout — read `Logs/Editor.log` (§3.4).
|
||||
|
||||
Reference in New Issue
Block a user