notes: spread a kill's drops instead of stacking them on one tile - #167
Merged
Merged
Conversation
Backlog item only, no code. Verified before writing it down rather than recording the observation as-is: Every drop from a kill is pushed at exactly `enemy.x, enemy.y` — the guaranteed health pack (engine.ts:6125), the ammo/swap roll or its Toolchain consolation (:6152/:6159), the bonus-weapon roll (:6164), and both Elite pushes (lootApply.ts:156/:158/:167). A regular kill can therefore leave three drops on identical coordinates and an Elite two. The renderer applies no offset — sprites.ts:778 projects raw drop.x/drop.y — so they draw as perfectly overlapping billboards. Recorded two things the observation alone does not carry. It is cosmetic: collectLoot walks every drop within AMMO_PICKUP_RADIUS, so the whole stack is collected and nothing is lost, which is why nobody noticed. And the fix has a trap — jittering the position off the shared PRNG stream would shift every subsequent draw, re-rolling every level and invalidating stored replays. The drops already carry a per-enemy `dropSeq`, so an index-derived offset spreads them deterministically at no cost. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Backlog item only — one file, no code.
Verified before writing it down
Nis 3. Every drop from a kill is pushed at exactlyenemy.x, enemy.y:engine.ts:6125engine.ts:6152/:6159engine.ts:6164lootApply.ts:156/:158,:167So a regular kill can leave three drops on identical coordinates and an Elite two. The renderer applies no offset —
sprites.ts:778projects rawdrop.x/drop.y— so they draw as perfectly overlapping billboards and the player sees one pickup.Two things the observation alone doesn't carry
It is cosmetic, which is why it went unnoticed.
collectLootwalks every drop withinAMMO_PICKUP_RADIUS, so the whole stack is picked up and nothing is lost. The bug is that you can't tell there was anything to notice.The fix has a trap worth recording now rather than rediscovering. Jittering the position off the shared PRNG stream shifts every subsequent draw, re-rolling the layout of every level ever generated and invalidating stored replays — the same constraint that keeps the styleset on its own salted stream and
planAcidOverflowsat zero draws.The drops are pushed in a fixed order and already carry a per-enemy sequence number (
pushLootDrop'sdropSeq), so an index-derived offset spreads them deterministically, costs no rng draw, and changes no existing map.Verification
notesonly — nothing to build or test. Diff is purely additive (4 added, 0 removed), checked because that file is edited concurrently.🤖 Generated with Claude Code
https://claude.ai/code/session_017ncJfux8GDacSTeLDcqrhr