Nested scenarios as hermetic puzzle rooms/dungeons

We are amassing a collection of disjointed Scenarios that are accessible from the toplevel game menu UI. For its part, this UI does facilitate a sense of "progression" and grouping by theme.

However, it would achieve a greater sense of immersion to embed self-contained scenarios as a sort of "dungeon" or "minigame" within a larger overworld. We could design scenario files to be composible with one file referencing another as a "child".

It raises a number of design questions:

Are sub-scenarios conceptually orthogonal to sub-worlds (#144)?
Puzzles are often designed around some constraint on available devices/entities. What mechanism(s) can be used to restrict the player's devices after having accumulated them in the overworld?
- Can the player take control (including piloting it directly with a keyboard) of some device-constrained robot other than base to play the minigame? C.f. the view command, which allows inventory inspection of other robots but not piloting.
- Can a system robot "steal" devices from the player, to be returned upon exiting the minigame?
- Alternatively, we could forego the idea of constraining device availability altogether and just design minigames/dungeons within a particular world to have a certain visitation order by unlocking each other
Aside from constraining available devices, there is a performance advantage to excluding computation of any ambient content of the overworld while participating in the mingame.
How should the completion of a minigame be reflected in the overworld?
- Should the player be able to keep any items obtained in the game?
- Can the "objectives" of a sub-scenario be grafted on to the objectives tree of the overworld?
Can nesting of scenarios be arbitrarily deep, or should it be restricted to one level (a la dungeons in Legend of Zelda)?
What should the file format look like?

swarm-game / swarm

Nested scenarios as hermetic puzzle rooms/dungeons #1352