I designed this around Dynamo’s preferred difficulty patterns: stateful/emergent interactions, specification through the environment, a silent but discoverable planning crux, and replay-based verification rather than answer matching. The public guidance specifically favors those over mere task volume and requires the verifier to grade exactly the observable behavior requested. (GitHub)

:::writing{variant="document" id="58341"} Category: Games Puzzles and Interactive Simulation
Sub-Category: Interactive text games

Proposal: Blackglass Station — Recover a Winning Plan in a Partially Observable Crisis Simulation

Task overview

The agent is given a deterministic command-line text adventure representing a research station during a cascading emergency. The executable behaves like a small commercial immersive-simulation game: the player can move between locations, inspect objects, operate machinery, speak with NPCs, exchange items, reroute power, wait, and trigger or prevent scheduled events.

The objective is not merely to reach an exit. The agent must discover and execute a valid sequence of commands that simultaneously:

• evacuates all four trapped personnel with zero casualties;
• stabilizes the reactor before its irreversible failure state;
• preserves and retrieves a critical incident-record cartridge;
• prevents the station-wide security alarm from reaching lockdown;
• boards the evacuation shuttle before its departure window closes; and
• completes the scenario within a stated maximum number of turn-consuming actions.

After exploring the game interactively, the agent must write its final replayable walkthrough to /app/solution.txt, one command per line.

The environment contains a single fixed, deterministic scenario. A clean execution of the same command sequence therefore always produces the same result.

Why is this task genuinely difficult?

The core difficulty is partially observable temporal planning across several interacting state machines, rather than finding an obscure command or solving a single conventional puzzle.

The game contains approximately 12 locations, seven mobile NPCs, several unique items, access-control states, NPC trust/knowledge states, three power zones, and a sequence of timed environmental events. Each subsystem is individually understandable, but actions taken in one subsystem alter future behavior elsewhere.

For example, rerouting power may open a door but also change which station clock controls an NPC's patrol schedule, disable a terminal needed later, and cause a technician to abandon their normal route. An apparently successful local action can therefore make the scenario unwinnable several turns later without producing an immediate error.

A senior gameplay systems QA engineer, game-AI engineer, or automated game-testing engineer would perform analogous work in a real production environment. Complex narrative and simulation games frequently contain interacting quest flags, schedules, inventory dependencies, timed events, and soft-lock conditions. Finding a reproducible critical-path walkthrough is valuable because it demonstrates that a release build remains completable after changes to interconnected gameplay systems and provides a regression case that can be replayed automatically.

The scenario data is synthetic, but it is structured to reproduce realistic game-system complexity rather than random puzzle content. NPC schedules, device states, dialogue prerequisites, resource consumption, environmental timers, and event propagation all follow deterministic rules implemented by the simulation engine.

Key reasoning challenges and likely failure modes

The game deliberately makes several locally reasonable strategies fail.

First, NPC movement is not governed by a single static timetable. Certain power-routing actions alter the phase of NPC schedules. An agent that maps locations once and assumes NPCs continue following the observed routes will later arrive at the correct location at the wrong time.

Second, some textual evidence refers to different internal time bases. A maintenance display continues counting from the last power-cycle boundary while the station clock resumes after emergency power returns. The information is consistent, but simply sorting displayed timestamps produces an incorrect causal ordering.

Third, several resources are reusable under some conditions and consumed under others. In particular, an access credential that appears to be the obvious way through an early obstacle is required later unless the agent discovers a more indirect early route.

Fourth, dialogue is stateful. NPCs do not simply expose every useful dialogue option when first encountered. Their knowledge changes when they witness events, receive evidence, or observe changes to the station. Consequently, talking to the right NPC in the right location but before the required state transition produces plausible but incomplete information.

Finally, the winning solution requires planning for deferred consequences. The major latent insight is that power routing is simultaneously an access mechanism and a scheduling mechanism. The final plan must intentionally create a short auxiliary-power interval that aligns two otherwise incompatible NPC/event windows while preserving a one-use resource for the final phase.

None of these rules will be stated as puzzle hints in instruction.md; they are discoverable from consistent game behavior, environmental text, logs, and controlled experimentation.

Intended solution approach

A strong solution would begin by exploring the command grammar and constructing a rough map of the station. The solver should then perform several controlled runs, using restart to change one action at a time and record NPC positions, event timing, power-state effects, and item dependencies.

The next step is to convert those observations into a compact dependency model rather than trying random complete walkthroughs. The solver should identify:

1. irreversible deadlines and failure states;
2. resources that must be conserved;
3. prerequisite relationships between dialogue, items, and device actions;
4. NPC schedule changes caused by power transitions; and
5. events that can be reordered versus events that are fixed.

The crucial planning step is to reason in terms of a partial order of required events instead of a rigid path through rooms. Once the solver recognizes that the auxiliary-power transition can be used to deliberately synchronize the technician and courier schedules, most of the apparent timing conflict disappears.

The solver can then construct a candidate route, replay it from a clean restart, remove unnecessary exploration commands, and save the resulting command sequence to /app/solution.txt.

I estimate that a qualified gameplay-systems or planning expert would require roughly 4–6 hours to solve the scenario from behavior alone. The difficulty comes primarily from discovering the causal model and synthesizing the final plan, not from executing a large number of repetitive commands.

How will the solution be verified?

The verifier will not compare the submitted walkthrough with the reference solution. Multiple genuinely different winning strategies are intentionally allowed.

During verification, /app/solution.txt will be replayed from the initial state against a clean verifier-owned copy of the game engine using the same fixed scenario configuration. This prevents modifying the game executable in /app from manufacturing a passing state.

The verifier will reject malformed, undocumented, debug-only, restart, or save/restore commands in the submitted final walkthrough. It will then execute the commands sequentially and inspect the authoritative final simulation state.

A submission passes only if all of the following observable conditions are true after replay:

• all four required NPCs are marked evacuated;
• casualty count is exactly zero;
• reactor state is STABLE;
• the original incident-record cartridge is aboard the shuttle and remains intact;
• security state never entered irreversible lockdown;
• the player is aboard the shuttle;
• the shuttle departed successfully within the permitted departure window;
• no prohibited bypass/debug action occurred; and
• the walkthrough uses no more than the explicitly stated maximum number of turn-consuming actions.

Any transcript satisfying those conditions passes regardless of the route, dialogue order, or intermediate states used. This makes the grading semantic rather than dependent on reproducing the author's exact walkthrough.

The reference solution will itself be generated by playing the same packaged game and will be replayed through the same verifier. A no-op submission, a transcript that merely exits the game, a patched /app executable, and superficially successful routes that lose evidence or leave an NPC behind will all fail.

Because every acceptance condition will be explicitly listed in instruction.md, the hidden verifier does not introduce secret objectives. Its hidden component is only the clean engine and authoritative replay, not additional game requirements.

Category and sub-category justification

Category: Games Puzzles and Interactive Simulation

The central work is reasoning about and acting within a simulated game world containing locations, characters, items, timed events, and interacting gameplay systems. Success requires developing and executing a strategy inside that simulation rather than performing conventional software maintenance or data processing.

Sub-Category: Interactive text games

The entire task is experienced through a terminal-based text-game interface. The agent explores the world and changes its state using textual commands such as movement, inspection, dialogue, item interaction, waiting, and machinery operation. Its final artifact is a replayable text-command walkthrough that must successfully complete the interactive scenario. :::

This version also avoids a common Dynamo verifier problem: every hidden check corresponds to an explicitly stated success condition, while alternative valid routes are accepted by replaying behavior rather than comparing against a golden command sequence. (GitHub)