Walker Bullet Shower: 500 Bullets, No Nodes, One Side Effect
Two scripts, one scene, three textures, and three tests produce a field of 500 server-managed bullets. The film pairs focused source excerpts with the visible results they create. It also shows the parked-player collision gap that the existing moving-mouse test misses.
Walker Bullet Shower: 500 Bullets, No Nodes, One Side Effect
Two scripts, one scene, three textures, and three tests produce a field of 500 server-managed bullets. The film pairs focused source excerpts with the visible results they create. It also shows the parked-player collision gap that the existing moving-mouse test misses.
Chapters: 0:00 Reconstructed Walker prompt 0:31 Runtime scene tree beside the probe numbers 1:04 Reused capture frames 175 onward: follow path 1:31 Reused capture frames 0 onward: 11 visible at frame 0, 130… 2:01 bullets 2:40 Reused capture frames 480 onward: sad from 489 3:05 Recorded result image evidence/collision-vs-sprite-f1500 3:36 Recorded result image evidence/tests-stdout 4:04 Reused capture frames 1450 onward: parked 4:36 Verdict: built, tested, broken, cause, human 5:15 Locked title outro, spoken, no music, 1 s tail
https://github.com/nikbearbrown/walker-2d-bullet-shower
Liam in for Nik Bear Brown · AI-assisted; scripted-input Godot captures, no human playtest claimed.
What this video covers
- 0:00 — Reconstructed Walker prompt
- 0:31 — Runtime scene tree beside the probe numbers
- 1:04 — Reused capture frames 175 onward: follow path
- 1:31 — Reused capture frames 0 onward: 11 visible at frame 0, 130…
- 2:01 — bullets
- 2:40 — Reused capture frames 480 onward: sad from 489
- 3:05 — Recorded result image evidence/collision-vs-sprite-f1500
- 3:36 — Recorded result image evidence/tests-stdout
- 4:04 — Reused capture frames 1450 onward: parked
- 4:36 — Verdict: built, tested, broken, cause, human
- 5:15 — Locked title outro, spoken, no music, 1 s tail
Transcript
A lightly formatted transcript of the video, with timestamps so you can jump to any section on YouTube.
Reconstructed Walker prompt
[0:00] Hi, this is Liam in forbear. The prompt on screen is a reconstruction, not a saved chat. Use Walker to turn a design document about a mouse-driven bullet demo into a god dot project. This film opens the result up each piece of code than what it does on screen in the real engine. What was built? Two scripts, one scene, three textures, and three headless tests. 500 bullets that are not nodes at all. They live as physics server bodies drawn by one loop and one walker change made for good reason with a side effect nobody tested. Start with the scene tree
Runtime scene tree beside the probe numbers
[0:32] Inspected while the game was running. Five nodes, the route, a bullets node that owns a script and the player in area 2D with a sprite and a collision circle. That's all. Even at runtime, the 500 bullets never appear here. They exist as 500 body handles in the physics server sharing one circle shape. Now the player script, two jobs in 10 lines. On ready, it hides the operating system cursor. Then on every mouse motion event, it sets its own position to the event position minus 16 pixels up. No smoothing, no speed, no bounds. Watch what that looks like. The scripted mouse
Reused capture frames 175 onward: follow path
[1:05] Draws a path and the face lands on it every frame. The logged player position equals the mouse minus 16 on every one of the runs 690 motion frames. Where do bullets start? Each one gets a random X between one and two screen widths. So every bullet begins off screen to the right. Its Y is anywhere on the screen. Then the script writes that position straight into its physics body as a transform. Result, the field fills in from the right. Frame zero, no input
Reused capture frames 0 onward: 11 visible at frame 0, 130…
[1:33] Yet. 11 bullets are already visible. The rest are still off to the right and they arrive at their own speeds. Every physics tick, each bullet moves left by its own speed times delta. When it passes 16 pixels beyond the left edge, it jumps back to 16 pixels beyond the right. Then the same transform right keeps the body on the drawing. Watch one bullet do it. Bullet seven ringed in the edit from its logged path. It crosses the left edge and one frame later it's back at the right. Drawing is one
bullets
[2:02] Function, not one sprite per bullet, one draw call per bullet, all issued from the bullets node with the same 32 pixel texture offset so it's scented. That's the trade. Fast and compact, but nothing to click on in the editor. And the result, about 490 of the 500 are on screen now, and everyone is painted by that single loop. Back to the player, the scene wires two signals from the physics server into these functions. Enter adds one to a counter and shows frame one, the sad face. Exit subtracts one, and only at zero does frame zero, the smile come back, a count, not a flag, so overlapping bullets can't flicker it. The driver rides one bullet,
Reused capture frames 480 onward: sad from 489
[2:41] The counter goes above zero, and the face frowns. It pulls away. The counter returns to zero and the smile comes back. Here's the player in the saved scene. An area 2D, an animated sprite holding the two-face textures, and a circle shape of radius 27. The signal wiring you just saw sits a few lines further down. Note, the circle is smaller than the 64 pixel sprite. On a
Recorded result image evidence/collision-vs-sprite-f1500
[3:05] Real frame with the shapes drawn over it in the edit, the orange collision circle sits just inside the face and the blue box is the sprite. Contact means the orange circle meets a bullet's radius 8 circle, not the drawing. Now walkers one change. Each bullet gets a body, a space, the shared shape, and a collision mask of zero, so bullets never test each other. Upstream left the body in the default rigid mode, and gravity integration pulled it about 16 pixels off its drawing. Walker set static mode instead. The test output shows what that fixed. The three existing tests were run
Recorded result image evidence/tests-stdout
[3:38] Today on an isolated copy. Mouse follow true. Collision sad then recovery happy true and the motion test body mode zero static and all 500 bodies aligned with their drawings. The fix works but look at how the collision test gets its contact for 10 frames. It moves the mouse onto a bullet moves every frame. Then it moves far away. It never holds the mouse still while a bullet drifts in. That's the case the next clip shows.
Reused capture frames 1450 onward: parked
[4:04] Mouse parked bullets drift straight through the face and it stays happy. The counter reads zero. a one pixel nudge and it jumps to two. With static bodies, a still area never notices a body that moves into it. To check that it's the static mode, the same route ran headless on two throwaway copies that change only line 37. The shipped static bodies register zero new contacts while the mouse is still. The upstream default gives 81 but drifts off its drawings. Kinematic gives 84 and stays aligned. Diagnostics, not a fix. The verdict:
Verdict: built, tested, broken, cause, human
[4:36] What's implemented is small and clear. Two scripts, five nodes, 500 server bodies, one draw loop, one shared shape, and a clean exit. What's tested? Follow contact while moving, motion, and alignment. What's broken? Contact while the player stands still caused by the fix for alignment. What needs a person, whether to fix it, and whether this demo should ever grow a goal. Your turn on a copy of Walker 2D bullet shower. Change only bullets. GD line 37 from static to kindic. Predict whether a park player now frowns. Add a headless test that parks the player and rerun all four tests. Write down your prediction before you run anything and keep the alignment test green. A fix that brings back the drift isn't a fix. Liam in for bear
Locked title outro, spoken, no music, 1 s tail
[5:15] Walker bullet shower. 500 bullets, no nodes, one side effect at Nick Bear Brown.
