maniator / maniator/verticopolis
[Feature]: [P3] Lobby skybridge: span a gap with nothing below if anchored on both ends (Modern)
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 5
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Description
Spun out of the Modern autoBridge toggle work (branch claude/modern-floors-auto-create), agreed with the owner as its own follow-up rather than folding into that PR.
Idea
Today every above-ground structural tile must rest on the story directly below it (restsOnStoryBelow in src/engine/tower/placement.ts), so a floor can never span open air. This proposes a Modern-only relaxation for lobbies only: a contiguous lobby run may cross an empty gap (nothing below the middle) as long as it is anchored on supported structure at both ends and the unsupported middle is within a span cap. In short, a skybridge concourse connecting two separate wings across a canyon of sky.
Lobby-only on purpose: a wide public concourse reads as architecture when it spans, while a plain-floor office catwalk floating in the void reads as a rendering bug. Plain floors keep the strict rest-on-story-below rule.
Why it fits
- It gives the disconnected-sections model (see #647) the honest "crossing exists only where real structure spans the gap" case: no tiles across the gap means no crossing, a skybridge across the gap means crossing. It does not conflict with the autoBridge toggle; it is the complementary tool (autoBridge-off stops connecting sections, this lets you connect them elegantly across a void).
What it touches (three systems must learn the new support rule)
- Placement validates the run as a unit: a contiguous empty lobby gap is legal only if both flanking tiles are supported lobby of the same substrate and the gap length is within the cap. The current
placeStructureRunretry loop grows tiles from support outward and has no valid tile-by-tile order for a both-ends span, so this needs a run-level check. - Support / reachability: a both-ends-anchored lobby tile counts as supported.
- Demolition (
removalReason): pulling an anchor must refuse or cascade, so a span can never be left hanging by one end.
Plus a render treatment (an underside, truss, or shadow gap) so a spanning lobby reads as a bridge, not a floating tile.
Open questions
- Max unsupported span between anchors (the span cap): decide during this spec, informed by canon and a quick playtest. Start narrow (a cap can loosen; a floating city cannot be un-shipped).
- Whether escalators/stairs may land on a skybridge lobby, and how the express elevator relates to it.
Process
Gameplay-facing new mechanic: /gds-code-review plus a Samus feel check and a version bump on implementation. Modern-only; Classic keeps the strict rest-on-story-below rule.
Tracked in _bmad-output/implementation-artifacts/backlog.md (row lobby-skybridge).
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with src/engine/tower/placement.ts and the placeStructureRun retry loop, then trace the support/reachability logic and demolition handling through removalReason. Review the lobby-skybridge row in _bmad-output/implementation-artifacts/backlog.md and the linked Modern autoBridge context. Done means a capped, both-ends-anchored Modern lobby span works without weakening Classic or plain-floor support, including demolition and rendering treatment, followed by the requested code review, feel check, and version bump.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- game-dev
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100