Skip to content

World fields set after make-world are dropped on floor transition (:title, :quest-item) #177

Description

@mparrett

main.lg:336-338 assocs three fields onto the world immediately after make-world:

(-> (world/make-world 79 30 seed)
    (assoc :title title
           :scheme scheme
           :quest-item (:item quest)))

Descending drops two of the three. change-floor's regen branch carries :scheme by hand (world.lg:700), and restore-floor's world literal carries :scheme by hand (world.lg:416). Neither carries :title or :quest-item, and nothing else puts them back.

Probe against a real world (make-world 40x20 seed 7, then descend and return):

d1          title= "The Chasms"  scheme= [1 2 3]  quest= :amulet  rooms-cache? true
d2-new      title= nil           scheme= [1 2 3]  quest= nil      rooms-cache? true
d1-revisit  title= nil           scheme= [1 2 3]  quest= nil      rooms-cache? false

Impact

render.lg:1196 reads (or (:title world) "") for the death-screen tombstone, so a player who dies below depth 1 gets a tombstone with no game title. That is the live symptom.

:quest-item has no reader today — ui_bridge.lg:44 emits the quest at startup from its own arguments, not from the world — so its loss is latent. It is the one that will bite: the next feature to read :quest-item mid-run will read it as nil on every floor but the first.

restore-floor also drops :rooms-cache (the probe's third column), which makes spawn-runestones (world.lg:1061) no-op on a revisited floor. That may well be intended, since the cache is per-floor derived data, but it is unstated.

Root cause

Three separate places declare what a world holds: world/empty-world, restore-floor's 21-key literal (world.lg:400-421), and change-floor's carry-over assoc (world.lg:694-702). #176 unified construction onto empty-world; the transition path still spells the shape out twice by hand. A field only survives a floor change if someone remembers to add it in two more places, and :title/:quest-item are the proof that nobody did.

This is the drift #172 describes, with a symptom attached.

Proposal

Name the distinction the code is actually making — fields rebuilt per floor versus fields that belong to the run — as an explicit set that both change-floor and restore-floor consume, instead of two hand-maintained literals. :title, :scheme, and :quest-item are run-scoped; :terrain, :entities, :lights, and friends are floor-scoped.

Happy to take this one as the follow-up to #176.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions