unity-roject-test/workspace/history/index.page

33 lines
9.3 KiB
Plaintext

<!DOCTYPE html>
<html lang="en"><head>
<meta charset="UTF-8">
<title>History — Unity-Roject-Test</title>
<style>
@import url('/fonts/barlow.css');
</style>
</head>
<body data-theme="default-roject">
<page--header></page--header>
<page--root data-theme="default-roject">
<full--width--block data--page--block>
<full--width--area data--page--area contenteditable="true" spellcheck="false" autocorrect="off" autocapitalize="off" style="outline: none;"><h1>History</h1></full--width--area>
</full--width--block>
<full--width--block data--page--block>
<full--width--area data--page--area contenteditable="true" spellcheck="false" autocorrect="off" autocapitalize="off" style="outline: none;"><h2>25 September 2026 - Reference &amp; Outline Update</h2><div>Wrote four reference pages documenting the systems built earlier today: <a href="../reference/rokojori-base/index.page">reference/rokojori-base</a> (Unique, EventSlot, Locale, RJLog, extensions), <a href="../reference/game-state/index.page">reference/game-state</a>, <a href="../reference/dialog/index.page">reference/dialog</a>, and <a href="../reference/simulation/index.page">reference/simulation</a>. Linked all four from reference/index.page under a new "By System" section.</div><div><br></div><div>Each page leads with the non-obvious part rather than restating the code: for Game State, the asset/runtime-value split and why <code>key</code> exists separately from the inherited <code>name</code>; for Dialog, the per-block-type behaviour table and the DialogList flow assumption; for Simulation, that <code>playerCount</code> and the renderer are placeholders with nothing wired up yet.</div><div><br></div><div>Ran the Update Outline action: <a href="../outline/index.page">outline/index.page</a>'s "Current State" and "What's next" sections had been stale since project creation ("It just started, only the first initial files exist") - replaced with the actual state (three singletons implemented, not yet Editor-verified, no real UI) and a concrete next-steps list. No code changed in this entry - documentation only.</div></full--width--area>
</full--width--block>
<full--width--block data--page--block>
<full--width--area data--page--area contenteditable="true" spellcheck="false" autocorrect="off" autocapitalize="off" style="outline: none;"><h2>25 September 2026 - Implementation Session</h2><div>Took over the "Session Hand-Over: Tech Outline Normalization" task, confirmed the Dialog Manager section of <a href="../outline/tech/index.page">outline/tech/index.page</a> read correctly, then implemented all three Tech Areas from that outline: Game State Management, Dialog Management, and Simulation Management. Code lives under Assets/Scripts/Rokojori/GameState/, Dialog/, and Simulation/ (about 28 files). Removed the stale "Get Initial Picture" board task (its description no longer matched what had actually happened) and closed out the hand-over task.</div><div><br></div><h3>Compile Toolchain</h3><div>Set up a way to verify C# compiles without opening the Unity Editor - see <a href="../guides/compiling-without-unity/index.page">guides/compiling-without-unity/index.page</a>. Two things were needed: a <code>global.json</code> pinning the SDK to 8.0.417 (the default .NET 10.0.401 SDK crashes compiling Unity's generated csproj on this machine - a Windows/CET incompatibility, not a project issue), and a hand-written <code>CompileCheck.csproj</code> that globs Assets/Scripts/Rokojori and Assets/Scripts/Project directly, since Unity's own generated Assembly-CSharp.csproj only lists files present at its last sync and won't pick up files written outside the Editor. All new code compiles clean against this (2 pre-existing, harmless serialization-analyzer warnings on EventSlot fields, unrelated to this session's code). This has only been compile-checked, never run in Unity - see the new "Verify in Unity Editor" board task.</div><div><br></div><h3>Coding Convention Correction</h3><div>Wrote the first pass without noticing <a href="../guides/Writing-C#/index.page">guides/Writing-C#/index.page</a> - it exists but wasn't linked from guides/index.page (now fixed, and linked here alongside the new compiling guide). Had to go back and fix: no bare <code>private</code> fields (use public with an underscore prefix, or protected), no parameterized constructors (DialogProcessor changed to a static <code>Create()</code> factory), switch statements replaced with if/else-if chains (CompareInt, ListCondition), and explicit initial values added to all fields that lacked them.</div><div><br></div><h3>Decisions</h3><div>Kept GameStateManager's per-type value dictionaries as the runtime source of truth (marked <marked-text>[NonSerialized]</marked-text>), with GameStateVariable ScriptableObjects only holding the initial value and a stable <marked-text>key</marked-text> field for JSON save/load - editor-facing "name" (inherited from UnityEngine.Object) stays separate from save identity.</div><div><br></div><div>DialogManager.Show() throws NotImplementedException rather than faking a response - there is no UI to wire it to yet (Assets/UI is empty). SimulationRenderer.Enqueue() is a similar placeholder that completes instantly. Both are flagged as open To Do items rather than silently pretending to work.</div><div><br></div><h3>Assumptions Needing Sign-off</h3><div>The tech outline left several implementation details unspecified. Filled them in with the simplest defensible choice and flagged all five in outline/tech/index.page under "Implementation Status" rather than guessing silently: DialogList's flow semantics (flat sequence, ignores children's own "next"), PlayerChoice options gaining an optional GameStateAction, HasObject modelled as a bool flag (no inventory system exists), SimulationManager.playerCount as a plain int (no Player type is defined anywhere), and GameStateVariable.key replacing the outline's literal (but already-inherited) "name" field. See the new "Sign Off Implementation Assumptions" board task.</div><div><br></div><h3>Not Done</h3><div>SimulateWorld and ShowTurnStartConditions (the example GamePhase subclasses) were described only narratively in the outline with no code contract, so they weren't written - see the "Example Simulation Phases" board task. DialogPhase was written since GamePhase now exists, closing a gap from last session.</div></full--width--area>
</full--width--block>
<full--width--block data--page--block>
<full--width--area data--page--area contenteditable="true" spellcheck="false" autocorrect="off" autocapitalize="off" style="outline: none;"><h2>25 September 2026</h2><div>Project created.</div></full--width--area>
</full--width--block>
<full--width--block data--page--block>
<full--width--area data--page--area contenteditable="true" spellcheck="false" autocorrect="off" autocapitalize="off" style="outline: none;"><h2>25 September 2026 - Tech Outline Session</h2><div>Rewrote <a href="../outline/tech/index.page">outline/tech/index.page</a>. It previously held roughly 92KB of copy-pasted ChatGPT export markup (wrapper divs around a 15-section simulation brainstorm) plus an unedited Roject placeholder block. Replaced with a normalized design across three tech areas: Game State Manager, Simulation Manager, Dialog Manager.</div><div><br></div><h3>Decisions</h3><div><marked-text>GameStateManager</marked-text> is the single shared state layer - Simulation Manager and Dialog Manager both read/write through it instead of keeping separate state.</div><div><br></div><div>Simulation Manager is built around <marked-text>GamePhase</marked-text> ScriptableObjects run asynchronously across five ordered lists (intro, preTurn, playerTurn, postTurn, outro). Any phase can flag the game finished, which jumps straight to outro. Phases only talk to Unity through <marked-text>SimulationRenderer</marked-text> (command in, "done" callback out). The earlier standalone systems architecture (ProductionSystem, PollutionSystem, spatial fields, deltas) was folded into one example phase, <marked-text>SimulateWorld</marked-text>, instead of being its own top-level section - it was more detail than a portfolio-sized prototype needs.</div><div><br></div><div>Dialog Manager went through two passes. The first coupled dialog execution directly into DialogPhase. The user corrected this: dialog needed to work standalone, not just inside the simulation loop. Settled on three layers - <marked-text>DialogProcessor</marked-text> (standalone cursor engine, depends only on an <code>IDialogDisplay</code> interface, no knowledge of UI or the simulation loop), <marked-text>DialogManager</marked-text> (singleton, owns UI wiring, sole entry point via <code>StartDialog()</code>, implements <code>IDialogDisplay</code>), and <marked-text>DialogPhase</marked-text> (thin GamePhase wrapper calling <code>DialogManager.instance.StartDialog()</code>). The <code>IDialogDisplay</code> seam also covers a future debug/headless display for testing, mentioned but not built.</div><div><br></div><h3>Not Done</h3><div>No code was written - this was entirely the design pass in the tech outline. The To Do board items (Game State Management, Dialog Management) still need actual implementation. Final sign-off on the Dialog Manager section of the tech outline was still pending when the session was handed over.</div></full--width--area>
</full--width--block>
</page--root>
<page--footer></page--footer>
</body></html>