Two weeks in. The visual direction is locked, the main menu is running. Time to go deeper. This week was about a question we've been asking since Slot Racing: what if the UI system itself was a reusable product, not just scaffolding?
SR_SettingsMenuWindow generates from a structured inspector definition. You author the main menu, submenus, buttons and selectors — the system builds the hierarchy at runtime. Change the structure? It rebuilds. No manual editing. No hardcoded strings. The inspector got its own pass: colored blocks by depth, collapsible sections, parent–child relationships visible at a glance. Building menus started feeling like authoring content, not fighting Unity. Presets for resolution, refresh rate, fullscreen, VSync, quality and anti-aliasing ship out of the box. Selectors support manual lists, dynamic presets, or bool toggles — all with the same row format.
Once settings worked, we tested the same pattern on something harder: the customizer. SR_CustomizerMenuWindow is the garage. Three root categories — Edit Trains, Edit Train Driver, Edit Train Controls — open into a model grid, then into variant and color. A full HSV panel with presets handles color. Everything reads from real runtime data. Color parts are named, not index-based. Preview in editor and truth in-game are explicitly separated. The whole panel rebuilds from data on each selection change. The garage is where the game starts feeling like yours. Same system. Train, driver, controls — one coherent experience. 9 weeks to Steam Train Fest. — BabelGames