Nuclear Design Bureau RDS-1 — The Directive Device and How to Build It

In Nuclear Design Bureau, RDS-1 is the name attached to a campaign directive device rather than a standalone mode. The campaign is a series of numbered directives, and community material titles one of them Directive 3-1 RDS-1, with the follow-up appearing in a Steam discussion thread as RDS-4 Directive 3-2. This page covers the in-game directive only: what the game asks of you, how it expects a device to be assembled, and how to check your work before the red button.

RDS-1 as a Campaign Directive

The directive system is the campaign's spine. You play a junior engineer at the Kurchatov Institute, the State gives you a target, and you build a device that meets it. Some directives limit which materials you may use on that job, which turns each one into a constrained puzzle rather than an open sandbox problem.

Directive element	Documented behaviour
Goal	A technical requirement handed down from the State
Constraints	Material limits apply on some directives
Naming	Directives are numbered and carry device names such as RDS-1 and RDS-4
Follow-on directives	Campaign expansion, many more directives and a voiced campaign are on the roadmap
Success condition	The device does what the directive asks, evaluated by the simulation

• Read the brief before touching the blueprint grid, because a material limit discovered late invalidates a design.
• Expect the campaign to be the constrained track and sandbox mode to be the free one.
• Treat each directive as a diagnosis exercise: the brief tells you what to achieve, not how.
• Check the community hub for directive-specific threads, since RDS-series naming makes them easy to search.

How the Game Expects a First Device to Be Built

The official description splits a device into a primary, a casing and the supporting systems, and it puts the criticality lab before the design phase rather than after. That ordering is deliberate: you are expected to understand how close your materials are to criticality before you commit to a layout on the grid.

Build stage	What the game provides
Measure	The criticality lab: core in its cradle, beryllium reflector, live k-effective estimate
Design	Materials painted straight onto the blueprint grid
Assemble	Primary, casing and supporting systems
Simulate	Full detonation physics run in real time from the red button
Refine	Diagnosis and rebuild after a fizzle, failure or waste of material

Practical habits that follow from that structure:

• Start in sandbox mode if you want to learn the physics without a material limit, then return to the directive.
• Save the design as you go, because the game keeps designs in a design files box rather than saving every experiment automatically.
• Keep the first device simple, since the simulation is compute-heavy and the store warns that large designs run slowly on minimum hardware.
• Expect yields to move between patches: an official physics patch changed how fissile material resists compression and explicitly noted that yields will change.

Keeping the Scope In-Game

Because this game is set around a design bureau and uses device names that echo real programmes, it is easy to blur the line between the simulation and the historical record. Do not. What the game models is a physics-driven sandbox: shockwaves, heat, radiation and chain-reaction behaviour in real time, with a criticality lab built around a Monte Carlo estimate and an operator who absorbs exposure. Real-world history, real devices and real programme timelines are not part of this simulation's documentation and are not treated as game facts here.

The in-game constraints are what matter for planning: material limits on some directives, limited grid resolution on weaker machines, and a physics model that the developer keeps adjusting. If your directive device will not ignite, the tips page collects the reported workarounds, the implosion page explains the compression step, and the guide page walks the whole loop in order.