docs(workshops): create world generation workshop brief from Q-077
Q-077 promoted to full workshop brief with 9 reference implementations, 7 key questions, 5 zone types, and agent assignments (Tyre, Gestalt, Nigel, Miri, Ozzie). Also: Q-089 through Q-092 filed (starfield, Markov names, event audio, modular settings menu), make clean-imports target added. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Claude Opus 4.6
@@ -180,7 +180,7 @@ Technical foundation questions: engine, protocols, data structures, performance,
|
||||
|
||||
### Q-074: Screenshot manager for in-game captures and bug reports
|
||||
- **Status:** Open
|
||||
- **Question:** ScreenshotManager (https://github.com/ASecondGuy/ScreenshotManager) — evaluate for improving the existing F12 bug reporter's screenshot capture. We already have F12 screenshot + bug report in-game. This plugin could improve it: better file management, auto-naming, viewport isolation, gallery/history. Evaluate what patterns we can adopt into the existing bug reporter flow.
|
||||
- **Question:** Two references for improving the existing F12 bug reporter: (a) ScreenshotManager (https://github.com/ASecondGuy/ScreenshotManager) — better screenshot file management, auto-naming, viewport isolation. (b) BugReporter (https://github.com/ASecondGuy/BugReporter) — patterns for attaching system info, game state snapshots, reproduction steps to bug reports. Both from the same author. Evaluate what patterns we can adopt into our existing bug reporter flow.
|
||||
- **Cross-reference:** `/bug-report` skill, character creator screenshot system
|
||||
|
||||
---
|
||||
@@ -199,11 +199,10 @@ Technical foundation questions: engine, protocols, data structures, performance,
|
||||
|
||||
---
|
||||
|
||||
### Q-077: CityCrafter3D — procedural city/settlement generation
|
||||
- **Status:** Open (high interest)
|
||||
- **Question:** CityCrafter3D (https://github.com/immaculate-lift-studio/CityCrafter3D) — procedural 3D city generation in Godot. The generation logic needs to be in Rust (server-side, D-020), but the patterns are highly relevant: road network generation, building placement rules, district zoning, lot subdivision, procedural layout algorithms. Study as a reference implementation for our Rust-side location generator. Key questions: what algorithms does it use (wave function collapse, L-systems, grid subdivision)? How does it handle building variety from limited asset sets? What's the data model for a generated city — can we extract the layout representation and replicate it in Rust with the client rendering from server-sent layout data?
|
||||
- **Additional references:** (a) Retro Terrain (https://github.com/NickToony/gd-retroterrain) — tile-based 3D terrain like Rollercoaster Tycoon / old strategy games. Terrain edges, height variation, water. Directly applicable to wilderness zones, rural villages, and outdoor areas. The tile-based approach maps to our server grid. Study for how terrain type transitions (grass→rock→water) are handled at tile edges. (b) Godot Spatial Gardener (https://github.com/dreadpon/godot_spatial_gardener) — procedural vegetation placement with instancing, density controls, collision awareness, LOD. For populating wilderness zones with trees, grass, bushes. Server sends vegetation density/type per tile, client uses gardener-style instancing to render it efficiently.
|
||||
- **Cross-reference:** Generator architecture, D-096 (chunk loading), D-097 (simulation tiers), location generation
|
||||
### Q-077: World generation architecture → PROMOTED TO WORKSHOP
|
||||
- **Status:** Promoted — see `docs/workshops/world-generation/BRIEF.md`
|
||||
- **Question:** Outgrew Q-record format. All references (CityCrafter3D, Chunk Manager, Retro Terrain, Spatial Gardener, GridMapLayer, PathMesh3D, DeformableMesh, Poly Haven) consolidated into the workshop brief.
|
||||
- **Cross-reference:** `docs/workshops/world-generation/BRIEF.md`
|
||||
|
||||
---
|
||||
|
||||
@@ -238,6 +237,7 @@ Technical foundation questions: engine, protocols, data structures, performance,
|
||||
### Q-082: VoronoiShatter for destruction effects
|
||||
- **Status:** Open
|
||||
- **Question:** VoronoiShatter (https://github.com/robertvaradan/voronoishatter) — procedural Voronoi fracture of 3D meshes into rigidbody pieces. MIT, Godot 4.4+, native GDScript. Convex and concave mesh support, seamless materials, auto rigidbody generation. Use cases: wall breaches during combat, crate/container destruction, station hull damage, environmental destruction. Pure client-side visual effect — server sends "object destroyed," client shatters the mesh locally. The Voronoi pattern gives natural-looking irregular fractures. Could pre-compute shatter patterns at load time for performance, trigger on damage event.
|
||||
- **Companion:** Particle Scene Compositor (https://github.com/tvenclovas96/particle-scene-compositor) — spawn scene instances as particles. Destruction fragments + sparks/smoke/dust in one effect. Shatter → fragments fly → each fragment emits particles.
|
||||
- **Cross-reference:** Combat system, damage visualization, environment interaction
|
||||
|
||||
---
|
||||
@@ -285,4 +285,32 @@ Technical foundation questions: engine, protocols, data structures, performance,
|
||||
|
||||
---
|
||||
|
||||
*40 questions (7 resolved, 1 partially resolved, 32 open). Last updated: 2026-03-23.*
|
||||
### Q-089: Procedural star rendering for space viewports and star map
|
||||
- **Status:** Open
|
||||
- **Question:** Godot Starlight (https://github.com/tiffany352/godot-starlight) — procedural starfield rendering. Use cases: (a) Station viewport backgrounds — look out a window, see stars. (b) Star map navigation screen. (c) Docking bay exterior views. (d) Skybox for any exterior/surface zone. Could combine with Q-064 (planet generator) for full space vista — procedural stars + procedural planets visible from station viewports. Seed from system coordinates for consistent views per location.
|
||||
- **Cross-reference:** Q-064 (planet generator), station viewport design, star map UI
|
||||
|
||||
---
|
||||
|
||||
### Q-090: Markov chains for procedural name/text generation in Rust
|
||||
- **Status:** Open
|
||||
- **Question:** Pattern reference: Markov Machine (https://github.com/BirDt/markov-machine) — Markov chain text generation. Need a Rust crate, not the Godot plugin. Candidates to evaluate: `markov` crate, `markov_chain` crate, or hand-roll (Markov chains are ~50 lines of Rust). Use cases: NPC name generation from cultural name pools (train on corridor-specific names, generate plausible new ones), shop/business name generation, procedural signage text, news ticker filler, overheard conversation snippets. Faster and cheaper than LLM for short text that just needs to feel culturally consistent. Could train separate chains per corridor/culture for regional flavor. The existing voice pipeline (Gemma 2) handles dialogue variation — Markov is for the lightweight procedural text that doesn't need semantic coherence.
|
||||
- **Cross-reference:** Generator architecture, name pools, voice pipeline (server/src/voice/)
|
||||
|
||||
---
|
||||
|
||||
### Q-091: Event-driven audio system
|
||||
- **Status:** Open
|
||||
- **Question:** Event Audio (https://github.com/bbbscarter/event-audio-godot) — data-driven event→sound mapping. Game events trigger audio without hardcoded play() calls. Complements Q-088 (spatial audio handles WHERE, this handles WHEN/WHAT). Server sends game events in ObserverSnapshot (door opened, NPC entered, combat started), client maps these to audio via configuration. Inigo's audio design specs define the sound palette — this system is the dispatcher that connects game events to that palette. Evaluate whether we adopt the plugin pattern or build our own event→audio bus.
|
||||
- **Cross-reference:** Q-088 (spatial audio), Q-063 (footsteps), Inigo (sound designer), AudioManager autoload
|
||||
|
||||
---
|
||||
|
||||
### Q-092: Modular settings menu as foundation for #735
|
||||
- **Status:** Open
|
||||
- **Question:** Godot Modular Settings Menu (https://github.com/MarkVelez/godot-modular-settings-menu) — composable settings panels for keybinds, audio, video, accessibility. Evaluate as the foundation for epic #735 (Settings and input system). Instead of building keybind remapper, audio sliders, resolution picker, and controller support from scratch, start from this template and restyle to match our UI aesthetic. Key: the modular approach means we can add/remove panels as features are implemented without restructuring.
|
||||
- **Cross-reference:** Epic #735 (settings/input system), Frame0 wireframe session
|
||||
|
||||
---
|
||||
|
||||
*44 questions (7 resolved, 1 partially resolved, 36 open). Last updated: 2026-03-23.*
|
||||
|
||||
Reference in New Issue
Block a user