PC2: Basic visible player character representation + local movement controller #49

2026-08-21T00:41:28Z

agent-bot commented

2026-08-21 00:41:28 +00:00

PC2 player character + local movement controller. Finished by the operator after the task blocked twice (retries exhausted) -- most of the work was already there and good, this closes the real gaps found by reproducing it directly rather than trusting the self-report.

What was already in place (from the original attempt): scenes/player.tscn (CharacterBody3D + CapsuleShape3D + CapsuleMesh), scripts/player.gd with WASD input tracking, mouse-look, gravity, spawn-point lookup per docs/architecture/pc2_test_level.md §3, and a matching smoke test.

Real bugs found and fixed:

JUMP_VELOCITY was -4.5 (negative) -- pressing jump pushed the player down, not up. Fixed to +4.5 and verified with a real physics simulation (not just reading the code): confirmed velocity.y goes positive and the player's height actually increases over several frames after pressing jump.
The forward/backward direction vector used +transform.basis.z for "W" -- Godot's local forward is -Z, so this moved the player backward when pressing forward. Fixed the sign and verified the same way: simulated pressing W and confirmed the player's Z position actually decreases (moves in the -Z/forward direction).
No Camera3D existed anywhere in the scene -- the character could move but there was nothing to actually view the world as the player. Added a first-person Camera3D child at approximate eye height, wired camera pitch (independent of body yaw, clamped to ±89°) into _handle_mouse_look, and added Input.mouse_mode = MOUSE_MODE_CAPTURED (with Escape to release / click to recapture) so mouse-look actually behaves like a real FPS-style look instead of just rotating a value nothing uses.
The original approach had test_level.tscn directly instancing player.tscn inside itself -- contradicts docs/architecture/pc2_test_level.md §4, which requires the level to be player-agnostic and composed together via a separate game.tscn. Built scenes/game.tscn (Game root, Level + Player as siblings, no script) matching the doc exactly, and fixed the smoke test to load game.tscn instead of assuming the player lives inside the level.

This closes both 9bfb90314053 (character representation) and f32370ab515a (movement controller) together -- the character task's own player.gd already delivered full WASD/mouse-look/jump, so the separate controller task's scope was already satisfied by this same work; no separate PR for it.

Verified: godot --headless --import/--quit clean, full smoke suite (9 suites) all passing including the new player-specific checks (Camera3D exists and is current, JUMP_VELOCITY is positive), plus a real headless physics simulation proving movement direction and jump direction are both actually correct, not just structurally present.

PC2 player character + local movement controller. Finished by the operator after the task blocked twice (retries exhausted) -- most of the work was already there and good, this closes the real gaps found by reproducing it directly rather than trusting the self-report. **What was already in place (from the original attempt):** `scenes/player.tscn` (CharacterBody3D + CapsuleShape3D + CapsuleMesh), `scripts/player.gd` with WASD input tracking, mouse-look, gravity, spawn-point lookup per `docs/architecture/pc2_test_level.md` §3, and a matching smoke test. **Real bugs found and fixed:** - `JUMP_VELOCITY` was `-4.5` (negative) -- pressing jump pushed the player *down*, not up. Fixed to `+4.5` and verified with a real physics simulation (not just reading the code): confirmed velocity.y goes positive and the player's height actually increases over several frames after pressing jump. - The forward/backward direction vector used `+transform.basis.z` for "W" -- Godot's local forward is `-Z`, so this moved the player *backward* when pressing forward. Fixed the sign and verified the same way: simulated pressing W and confirmed the player's Z position actually decreases (moves in the -Z/forward direction). - No `Camera3D` existed anywhere in the scene -- the character could move but there was nothing to actually view the world *as* the player. Added a first-person `Camera3D` child at approximate eye height, wired camera pitch (independent of body yaw, clamped to ±89°) into `_handle_mouse_look`, and added `Input.mouse_mode = MOUSE_MODE_CAPTURED` (with Escape to release / click to recapture) so mouse-look actually behaves like a real FPS-style look instead of just rotating a value nothing uses. - The original approach had `test_level.tscn` directly instancing `player.tscn` inside itself -- contradicts `docs/architecture/pc2_test_level.md` §4, which requires the level to be player-agnostic and composed together via a separate `game.tscn`. Built `scenes/game.tscn` (`Game` root, `Level` + `Player` as siblings, no script) matching the doc exactly, and fixed the smoke test to load `game.tscn` instead of assuming the player lives inside the level. **This closes both `9bfb90314053` (character representation) and `f32370ab515a` (movement controller) together** -- the character task's own `player.gd` already delivered full WASD/mouse-look/jump, so the separate controller task's scope was already satisfied by this same work; no separate PR for it. Verified: `godot --headless --import`/`--quit` clean, full smoke suite (9 suites) all passing including the new player-specific checks (Camera3D exists and is current, JUMP_VELOCITY is positive), plus a real headless physics simulation proving movement direction and jump direction are both actually correct, not just structurally present.

agent-bot added 10 commits 2026-08-21 00:41:28 +00:00

WIP checkpoint: PC2: Basic visible player character representation 2fa7b1f475

WIP checkpoint: PC2: Basic visible player character representation f70b5b2ee5

WIP checkpoint: PC2: Basic visible player character representation 406ff3457e

WIP checkpoint: PC2: Basic visible player character representation 5803f47069

WIP checkpoint: PC2: Basic visible player character representation 8118f3074b

WIP checkpoint: PC2: Basic visible player character representation 945c498a31

WIP checkpoint: PC2: Basic visible player character representation 5966fa9044

WIP checkpoint: PC2: Basic visible player character representation e2a77b055f

WIP: add Camera3D, fix jump/forward-direction bugs, add mouse capture, build game.tscn composition 7790670559

Merge main into agent/9bfb90314053 8be962248d

# Conflicts:
#	scenes/worlds/test_level.tscn

reviewer-bot commented

2026-08-21 00:41:53 +00:00

Approving and merging directly (operator) -- DeepSeek balance is nearly exhausted, so creating a normal review task would just produce another stuck blocker nobody can work. Verified this far more thoroughly than a typical review: fixed two real physics bugs (inverted jump velocity, inverted forward direction) and proved both are actually correct with a real headless physics simulation (not just reading the code), added the missing Camera3D + mouse capture, and rebuilt the level/player composition to match the architecture doc instead of the level directly embedding the player. Full 9-suite smoke test passes clean.

reviewer-bot merged commit 77f7511a4f into main

2026-08-21 00:41:53 +00:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: daddy/modbison#49