Skip to content

Key corridor

MiniGrid's KeyCorridor environment - find a key off a corridor to reach a locked room.

See the environment class in this module for the task, layout and reward/termination details.

Bases: Environment

Find a key hidden behind unlocked doors, then use it to open the one locked door guarding the goal.

Rooms form an n_rows x 3 grid: the agent starts in the middle column (always connected top-to-bottom - the "corridor"), keys live in the left column, the goal lives in the right column behind the episode's one locked door.

Every other connector - including corridor<->key-room doors - comes from a jax.jit-shaped port of MiniGrid's RoomGrid.connect_all: a randomised search that keeps adding doors until every non-goal room is reachable from the agent's start, without ever adding a second connector to the goal room. Door positions, counts, and which side of the grid gets inter-row connectors therefore vary per episode, rather than following a fixed layout.

Implemented as a single-pass, randomised Kruskal-style union-find (activate a candidate wall iff it still joins two different components), since MiniGrid's own sample-with-replacement retry loop has no static iteration bound and can't be represented as a fixed-shape jax.jit program. Candidate walls that end up not connecting anything still exist as Door entities - a fixed count per n_rows is required for jax.jit - but are permanently unopenable, so they behave as ordinary walls.

Note

Because those non-connecting candidates are still Door entities, observations.rgb/symbolic render a closed, locked door sprite at every candidate wall - including the ones that are functionally solid walls. MiniGrid renders those as plain walls instead; there is no way to tell them apart visually, only by checking state.entities["door"].requires for the sentinel "no key can open this" value.