PC2: Design the test level & player spawn approach #46

2026-08-20T21:11:19Z

architect-bot commented

2026-08-20 21:11:19 +00:00

Auto-opened by architect for task a6deeb84eace.

Dashboard: http://cloudbison:7070/task/a6deeb84eace

Real design decision, not routine implementation -- route to architect. Decide how the PC2 playable test level gets built: a plain static Godot 3D scene (ground/terrain mesh, a few simple props, lighting) is a legitimate, low-risk choice for this checkpoint -- the existing chunk streaming system (scripts/chunk.gd, chunk_stream_manager.gd, chunk_scene.gd, chunk_data_decoder.gd -- see docs/architecture/world.md) has never actually been exercised with real content and integrating it here is optional, not required. State the decision explicitly either way -- don't default silently. Also decide: player spawn point convention (e.g. a named Marker3D the level scene must contain), and where the level scene(s) live (e.g. scenes/worlds/ or similar). Output a short design note (docs/architecture/pc2_test_level.md or similar) that the two implementation tasks below (level, player) can follow without guessing.

Scope reminder: single-player, local-only, no networking, no avatar customization UI -- see the feature description for the full PC2 scope and what's explicitly deferred to later milestones.

Auto-opened by architect for task `a6deeb84eace`. Dashboard: http://cloudbison:7070/task/a6deeb84eace Real design decision, not routine implementation -- route to architect. Decide how the PC2 playable test level gets built: a plain static Godot 3D scene (ground/terrain mesh, a few simple props, lighting) is a legitimate, low-risk choice for this checkpoint -- the existing chunk streaming system (scripts/chunk.gd, chunk_stream_manager.gd, chunk_scene.gd, chunk_data_decoder.gd -- see docs/architecture/world.md) has never actually been exercised with real content and integrating it here is optional, not required. State the decision explicitly either way -- don't default silently. Also decide: player spawn point convention (e.g. a named Marker3D the level scene must contain), and where the level scene(s) live (e.g. scenes/worlds/ or similar). Output a short design note (docs/architecture/pc2_test_level.md or similar) that the two implementation tasks below (level, player) can follow without guessing. Scope reminder: single-player, local-only, no networking, no avatar customization UI -- see the feature description for the full PC2 scope and what's explicitly deferred to later milestones.

architect-bot added 1 commit 2026-08-20 21:11:20 +00:00

WIP checkpoint: PC2: Design the test level & player spawn approach 2ffcd9cd3f

reviewer-bot commented

2026-08-20 21:58:55 +00:00

Approving on the reviewer's behalf (operator). This review got stuck twice (once on an LLM connectivity timeout, once on a confused self-report claiming this PR was "code implementation details" when it's actually a single, pure architecture doc with no code). Read the full document independently: it makes a real, well-justified decision (static hand-authored test level, not chunk streaming integration -- explained why), a precise player-spawn convention (Marker3D named PlayerSpawn, with a concrete lookup snippet and a safe fallback), a clean composition scheme (scenes/game.tscn wires level + player with zero coupling between them), concrete content requirements for both dependent tasks, explicit PC2 scope boundaries, and even specifies what each dependent task's own smoke test should assert. This is exactly the kind of unblocking design work the architecture task was meant to produce.

reviewer-bot merged commit 66adcff145 into main

2026-08-20 21:58:55 +00:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: daddy/modbison#46