Players pile up on the cell they arrive at

backlog priority 3 estimate M

world-map-and-portals/008 · created 2026-08-16 · updated 2026-08-16

What

Every player’s home portal leads into the same cell of the Village of Lor (its authored entry_x/entry_y, currently 20,38), and every home_area arrival lands on the same cell inside that player’s own home. Players can currently walk through each other, so they will simply stack on those cells — two people standing in exactly the same square.

Noted deliberately during world-map-and-portals/009 rather than solved there, because the fix depends on something that doesn’t exist yet.

Kris’s sketch of the fix (2026-08-16)

“We will be making it that you can’t walk through other players in the future, so the fix might be as simple as: you don’t actually land on top of a portal but one cell to the side of it, AND if that cell is occupied then use the nearest cell that isn’t occupied.”

That is the shape to build: an arrival resolves to a cell beside the entry point, and walks outward to the nearest free one if it’s taken.

Why it waits

Player collision doesn’t exist. movement.gd checks the grid — walls, soft blocks, bounds — and nothing checks whether another entity occupies the target cell. Until it does, “the nearest cell that isn’t occupied” has no meaning the server can evaluate, and building a spreading-arrival rule on top of nothing would be guesswork.

The natural order is: entity occupancy in movement.gd first (it already has spatial_hash.gd to make the lookup cheap), then this.

Definition of done

Arriving through any portal never places you on the same cell as another entity.
Arrival is beside the portal, not on it, so you don’t immediately re-trigger anything.
The search for a free cell is deterministic (same inputs, same result) and bounded — a full area must not be able to hang a transfer.
Covered by a test with two players arriving at the same entry cell.

View source in repository · also available as raw markdown.