A guide to open-ended engineering puzzles

How to design a Zachlike

A Zachlike asks you to build an executable artifact, prove it against an exact behavioural specification, then find out how much better you can make it.

Version 1.1.0 · 08-08-2026

The loop is simple to describe: you build something, run it, inspect what happened, and revise it. The hard part is choosing rules that keep making this loop interesting.

The goal is a small set of understandable rules whose interactions produce a large space of solutions. A precise test then separates correctness from quality. Passing ends the required puzzle. Speed, size, cost, robustness, elegance, and other qualities create voluntary second puzzles after it.

I find it useful to hold the whole guide as one dependency:

Domain supplies the process, verbs, and natural constraints. Mechanics define the operations you can use. Systems are what those rules do together. Puzzles select and pressure the resulting possibility space.

Read the first four chapters in order because each gives the next its raw material. The arrows show where design decisions come from, not a one-way production schedule. Once you start prototyping, the chain becomes a loop. Evidence from one puzzle can force you back into the system, the mechanic set, or even the domain.

Around the core

Four more concerns turn a sound puzzle system into a complete game:

• Presentation makes rules, state, causality, failure, and cost inspectable and makes revision cheap.
• Teaching turns the campaign into a curriculum without turning the tutorial into the puzzle.
• Optimization gives a correct machine a second life through conflicting measures, comparison, and sharing.
• Story gives the work a purpose and helps choose which artifacts and briefs belong.

These concerns do not wait politely until the core is finished. They surround it, reveal it, and change it. Bring them into the prototype early enough to see those changes. The final chapter closes the loop by turning the whole structure into a prototyping and playtesting practice.

What remains outside the scope

This guide stays on the player-facing side of the game. It does not prescribe engine architecture, art direction, audio production, platform strategy, budgets, publishing, or marketing. It asks what the system must make possible, not how you should implement it.

The design-element catalog is vocabulary, not a specification. Do not mistake its size for a shopping list. A coherent game is defined as much by what it leaves out as by what it includes.

1 · Domain

The domain is the process the game simulates: the slice of reality, engineering, or invented physics that the player learns to manipulate. It isn't the setting, and it isn't the art style.

I find one question useful here: what kind of work should the player feel they are doing? A good domain creates that work fantasy. It gives you verbs, pressures, representations, and natural briefs, and it helps you reject mechanics that don't fit. Realism still can't make every decision for you.

Start from a process

Start with something a person could actually do, not a broad subject. “Electronics” is too broad. Designing a cheap consumer device, as in SHENZHEN I/O, immediately gives you more to work with: a product, components, signals, a board, a budget, and operating requirements.

A promising process has four properties:

• It produces an artifact. The player can name what they are making, what it receives, and what it must do.
• It supplies verbs. The player can route, join, split, schedule, store, transform, or test something.
• Its relevant state fits in one view. The player can inspect the causes that matter.
• It contains pressure. Capacity, timing, reach, scarcity, or irreversibility can force decisions.

Four shipped Zachlikes show the pattern:

Notice how aggressively these games simplify their domains. Each one keeps the part that protects the work fantasy and the decisions it needs. Before you depend on a metaphor, observe or research the real process behind it.

Test its yield and cost

Before you commit, walk the domain through six questions:

Specialist vocabulary has a real onboarding cost. Invented physics avoids assumed expertise, but it doesn't avoid explanation. It still needs consistent rules and representations the player can read.

So where should realism give way? Wherever accuracy would hide state, add labour, or create an exception the player can't predict. Keep the fiction coherent enough that every simplification feels deliberate.

2 · Mechanics

A mechanic is a rule, not a themed object. A conveyor, wire, pipe, and queue may look completely different, but if they create the same decisions, they may be the same mechanic.

So when do you count a second mechanic? When its rule changes what players decide or predict, how they fail, or what they can optimize.

Start with as few rules as the system needs. A new exception isn't depth. If the documentation grows faster than the possibility space, take that as a warning.

Build a construction language

You are designing a language for making systems, not a bag of themed parts. Before you expand the palette, define three things:

A finished solution usually has an architecture, which says where work happens, and a schedule, which says when it happens. Geometry may embody either one, but the rules have to make both predictable.

Now step back and ask what mental model this language makes the player learn. A conventional programming or construction model with new nouns may still be useful, but it gives up one of the form's strongest pleasures: discovering a genuinely different way to organize work. Originality isn't an excuse for obscurity. Whatever language you invent still has to survive the tests below.

Test every mechanic

The test I keep coming back to is not “does this mechanic sound interesting?” It is “does this mechanic deepen the whole system?”

Cut a mechanic when one use dominates, when it touches only one narrow subsystem, or when it duplicates another rule without changing any decisions.

Cut it too when explaining the rule takes more work than exploring it, or when it needs an incoherent exception to the core system.

Choose a central pressure

What is the player short of? One or two scarce things can organize an otherwise loose collection of rules.

If the honest answer is “nothing in particular,” pause. Construction may have become work without a decision.

Keep four related terms distinct:

Take a cramped board. The board is a constraint, packing may be the bottleneck, space can be the game's pressure, and footprint can be one metric. The words describe different jobs even when they all point at the same scarce thing.

The design-element catalog is a list of rules and related design ideas. Open it after you've chosen the domain and central pressure. Look for elements that reinforce each other. You are not trying to include everything.

3 · Systems

A system is what happens when mechanics meet. TIS-100 makes this concrete. Its nodes execute tiny programs in parallel, talk only to their four neighbours, and block until a matching read and write meet. None of those rules says “routing protocol,” “pipeline,” “starvation,” or “deadlock.” Put them together, and all four appear.

You write the local rules. The system is what they do together. That is where useful complexity comes from: many small, unambiguous rules interacting, not one complicated part nobody can predict. The machine also has to be repeatable. Give it the same input, rules, starting state, and seed, and you should see the same visible sequence again.

Freeze the system contract

Start with the rules every later mechanic will depend on. The system must answer each of these questions the same way, every time:

• Object identity and transformation. In SpaceChem, which atom does a waldo hold, and exactly when does a bond form or break?
• Connections, capacity, and transfer. In TIS-100, which ports may communicate, and when does a read or write wait?
• Time, update phases, and arbitration. In Opus Magnum, when do simultaneous arms act, and which collisions invalidate the cycle?
• Failure, completion, and editing. In Infinifactory, what counts as a malformed product or a finished run, and what state resets before the next test?

Together, these rules form the system contract. Determinism rests on it. The same machine, input, rules, and seed must produce the same visible sequence. Seeded variation still meets that standard if replaying a seed reproduces every failure exactly. A mature machine may loop forever or stop at a quota, but running it again can't quietly change what its rules mean.

Revise unfinished rules as freely as you need. Once players have saved solutions against a released rule, change it only deliberately, visibly, and with compatibility in mind.

Design interactions, not inventories

Take every pair of core mechanics and ask whether one changes the value, cost, timing, or failure modes of the other. Being connected isn't enough. An arm can load a belt, but if the belt treats every item alike, arm × belt has created no new decision.

Put the mechanics on both axes of a matrix, with one cell for every unordered pair. For n mechanics, that gives you n(n−1)/2 cells. Four mechanics produce six; seven produce twenty-one. Answer three questions in every cell:

Specify observable state

Now decide which facts any presentation must expose. Objects, values, and control need traceable paths. Transformations need inspectable inputs, conditions, and outputs. The player has to see both the architecture and the schedule, even when distance or layout is doing the work of time.

What is the earliest meaningful divergence the simulator can report? Define that too. A collision, wrong value, missed deadline, overflow, or illegal state should preserve the failing moment and the causal state around it. §5 turns this requirement into debugging tools.

Turn important limits into visible properties:

Local rules can create global complexity and still remain locally predictable. Seven mechanisms do most of that work:

You can see backpressure directly in TIS-100. A node writing to a port waits until its neighbour reads, which can leave every earlier node waiting behind it. Close those waits into a cycle and you have a deadlock. If your system permits either one, show the player where the chain or cycle begins.

Step back and notice what isn't on this list: hidden state, inconsistent exceptions, visual ambiguity, and sheer scale. Those usually add confusion rather than useful depth.

4 · Puzzles

A puzzle combines three things: a specification, a board, and a palette. Together they tell the player what must happen, where they may build, and which parts they can use.

Author the specification first

Before you explore layouts, decide which observable behaviour passes. The engine checks the player's output against this puzzle specification. It does not compare their machine with your reference build.

Write the specification in one sentence:

Then make every boundary explicit: the legal input range, required outputs, quota or duration, available workspace and tools, hard limits, failure conditions, and exact pass condition. The specification must not prescribe construction steps or depend on rules outside the published system contract.

Build a small test set:

• a simple case that proves basic understanding;
• a boundary case;
• a case that breaks the most obvious shortcut;
• a case that exercises the puzzle's central pressure; and
• enough variation to require a general design.

Unseen cases may vary values, but they can't introduce new semantics. When a run fails, show the smallest useful counterexample.

The verifier does more than check the answer. It shapes the work. A repeated quota rewards throughput; an input-output stream rewards generalization; a test suite rewards branching and state; a final-state target rewards construction and emergence.

Keep internal reference builds to prove solvability and expose accidental restrictions. These builds are evidence about the specification, never the definition of the answer. Writing the specification first doesn't remove your responsibility to verify that somebody can actually solve it.

Choose the floor and the ceiling

I find it useful to give every puzzle two difficulty targets:

• Solution floor: the effort needed to make anything correct.
• Optimization ceiling: the depth available after it works.

Let the obvious, clumsy solution pass. Don't require an optimized score to continue unless satisfying that bound is the puzzle itself. This is the trick: lower the floor without flattening the ceiling.

Pressure one facet

Before you build the puzzle, name its bottleneck: routing, synchronization, storage, geometry, state, collision, transformation order, or topology. This bottleneck selects one facet of the central pressure from §2. If the game's scarce thing is flow, for example, routing and storage should matter before geometry. The board and palette then decide how directly the player has to confront it.

Use the palette as a balance lever. Make it too loose and the bottleneck disappears. Make it too tight and you funnel the player toward one architecture.

Separate reasoning from labour. Raise a quota only until startup, steady state, or a timing interaction becomes visible. If the insight arrives quickly but the player then spends ten minutes placing, retiming, or waiting, shrink or reframe the puzzle.

Distinguish novelty from openness

Two kinds of variety are easy to blur together. Puzzle distinctiveness compares puzzles across a campaign: can the player reuse the same process with trivial edits? Solution diversity compares answers to one puzzle: can valid builds differ in decomposition, topology, scheduling, use of state, or metric priority?

These are separate tests. A campaign can contain wildly different puzzles that each funnel toward one answer. It can also contain an intentionally familiar puzzle that revisits a known process but remains rich to optimize. Label reinforcement honestly. Don't present repetition as a new idea.

For every open puzzle, construct two plausible same-palette references from different solution families. Two references prove possibility, not prevalence, but they quickly expose a specification that permits only one recipe by accident. Scores can't prove diversity on their own. Unrelated machines may share a score, while one architecture may span many scores.

Use antagonistic metrics

A metric earns its place when it changes which architectures look attractive. Two or three measures are usually enough. Speed, space, resources, program size, power, and robustness only become interesting together when improving one can make another worse.

The solutions where no measure can improve without another getting worse form a Pareto frontier. You want that frontier to contain several specialists that look structurally different. If one solution wins every metric, change the cost model, palette, or specification. Show the measures separately because a weighted total hides the trade-off.

A hard limit defines validity. A metric compares valid solutions. Leave some valued qualities unscored: symmetry, readability, choreography, and audacity. The graphs should not exhaust taste.

5 · Presentation and debugging

You can build a deep system and still make a bad puzzle game if the player can't see what it is doing. Presentation includes visual design, sound, animation, interface, editing, feedback, documentation, and terminology. It cannot create mechanical depth, but it determines whether the player can perceive, predict, and work with the depth that already exists.

A decorative skin is presentation. A visible port, capacity slot, timing trace, or collision boundary goes further. It becomes part of play because it changes what the player can reason about.

Don't postpone this as polish. An illegible prototype can't tell you whether a playtest exposed a system problem or merely hid a sound rule.

Make causality visible

Pause the machine, then run it. In both states, the game should answer six questions:

Preserve object identity while things move and transform. If an item disappears into a process and an apparently unrelated result pops out elsewhere, the player can't connect architecture to behaviour.

Look at TIS-100. It prints values on ports and highlights the instruction each node is executing, so you can trace a blocked transfer across the grid. Opus Magnum puts an arm's program, swept space, held atom, and collision in the same view. Both games remain difficult without making their current state a secret.

Use colour, sound, and motion redundantly. Required information has to survive grayscale, silence, pausing, and reduced motion. At overview scale, preserve identity, direction, state, and faults. Reveal the detail as the player zooms in.

Make revision cheap

Open-ended construction is repeated refactoring. The player has an idea, changes the machine, runs it, and looks for the consequence. Keep the time between those steps short.

• Make place, delete, rotate, connect, and edit-instruction actions immediate.
• Support region selection, move, copy, paste, rotate or mirror, and deep undo and redo.
• Preserve camera, selection, partial edits, and simulation state when switching between the workspace, specification, documentation, tests, and scores.
• Show reach, collision, occupancy, and illegal connections before the player commits an edit.
• Allow several named solution variants so experimentation never requires destroying the known-good build.

Let partial and incorrect machines run whenever they can produce meaningful behaviour. Missing output is an unmet specification, not a reason to disable the simulator. Broken machines are often where the player learns the most.

Treat the simulator as the main interface

Treat the simulator as the centre of the interface. Keep run, pause, reset, single-step, and useful speeds reachable at all times. One step must advance one defined unit of simulated time. Show the current cycle, case, and phase.

When an instruction or controller acts, highlight both it and the object it affects. Waiting and blocking are states, not generic errors. Show what the part needs, what holds the resource, and whether the machine is merely slow or actually deadlocked.

Stop automatically at the first meaningful failure and preserve that state. Then show a readable trace around it. A cascade of later faults must not bury the first place where the player's mental model diverged from the simulator.

Failure can be pleasurable to watch. It still has to remain fast, local, informative, and costless to retry.

Be a trustworthy development environment

Use one term for every part, state, port, and operation across the editor, specification, manual, tutorial, and error messages. Pair unfamiliar icons with words until the player has had a fair chance to learn them.

The same machine, input, rules, and seed must replay identically. Ordering, limits, tests, and scoring can't contain hidden preferences or unexplained exceptions. A strict simulator feels fair when it exposes three things: the rule, the relevant state, and the exact reason the run stopped.

6 · Teaching and campaign

What is the player actually learning? Not a collection of puzzles. They are learning one system, and the puzzles are the vehicle. Progress means fluency: predicting behaviour before running, recognizing reusable structures, diagnosing failures, and choosing an architecture on purpose.

That makes every campaign a curriculum, whether you designed it as one or not.

Teach purpose before syntax

Teach the job before you teach the gestures: given these inputs, produce these outputs. A perfect placement walkthrough can still leave the player unable to explain what the machine is for.

Start in the real editor, with the real rules. Pre-place enough context that the minimum correct solution needs one meaningful action, then remove the scaffolding. If that first solution requires five unfamiliar actions at once, simplify the solution. Don't answer complexity with another paragraph of explanation.

SpaceChem exposed this failure mode. Its first complete loop required the player to understand input, grab, path arrows, drop, and output all at once. Later Zachlikes lowered the floor by asking for a first useful artifact with fewer simultaneous concepts.

For each mechanic:

1. show its purpose;
2. demonstrate the smallest useful action;
3. let the player reproduce it;
4. ask for a simple independent use;
5. reinforce it in a changed context; and
6. combine it with earlier mechanics later.

Use counterexamples to correct the false rules players are likely to invent. If you can choose between a clearer representation, a simpler rule, and another paragraph of instructions, choose one of the first two.

Alternate novelty and reinforcement

Give every puzzle a job in the curriculum:

Constant novelty turns the campaign into a series of exams. Constant repetition turns it into labour. Alternate the two deliberately, and don't pretend a reinforcement puzzle is a new idea.

Kaizen: A Factory Story deliberately used easier reinforcement puzzles. Players could apply a process they had just learned, then explore its optimization surface. That is not the same thing as padding a campaign with a larger quota.

Teach collision order, simultaneous action, blocking, overflow, capacity, and test timing before any of them can cause an expensive failure. Let players discover strategies. Don't make them discover undocumented semantics.

Curate the order after playtesting

Author more specifications than you need, then watch people play them. Remove accidental logical duplicates, fill genuine conceptual gaps, and reorder what remains. Difficulty order is an evidence problem, not an intuition problem.

When a puzzle becomes a wall, ask why before you tune it. Did it introduce several burdens at once? Did it depend on an edge case you never demonstrated? Or did the player understand the idea and then face too much construction?

For a broad campaign, open small batches and require only some puzzles to advance. Put the hardest material after the narrative ending or mark it clearly optional. One mandatory puzzle should not end both play and story for an otherwise capable player.

Use documentation as reference and fiction

Manuals, datasheets, zines, diagrams, and reference cards can make looking up a rule part of the work fantasy. Keep them searchable or well indexed. Use the same terminology as the interface, make them available without losing work, and state edge cases explicitly.

Documentation can support a good first-use path, but it can't repair an unreadable mechanic. §8 shows how the same artifact can also carry voice and world-building.

7 · Optimization and sharing

The first valid machine isn't the end. It is where a second game begins. Correctness and quality are separate, and §4 defined the conflicting measures that reshape the solution space after correctness.

Optimization should feel voluntary. You don't need to withhold progress, currency, or story to make improvement meaningful. The machine, the cost model, and visible evidence of better approaches can supply the challenge on their own.

Reveal the distribution after success

Show per-puzzle histograms only after the first correct solution. The order matters. First the player owns an answer. Then the distribution asks a new question: how else could this machine work?

A global leaderboard makes nearly everyone a distant loser and rewards cheating at the extreme. A histogram makes the middle legible. It shows how far away an improvement might be, exposes clusters that may represent different solution families, and lets an ordinary player choose a reachable target.

SpaceChem established the pattern with separate histograms for cycles, symbols, and reactors. The graphs include first-pass and optimized solutions together, so beating the middle remains a plausible personal challenge rather than a bid for a world record.

Show each antagonistic metric separately, with the current result and personal best marked. Don't collapse the measures into one total, and don't reveal another player's architecture without an explicit spoiler action.

Make cost causal

Connect every score to behaviour the player can inspect. Which operation spends power? What adds latency? Where does the footprint grow? Which component creates waste, and where does capacity sit idle? The machine should answer these questions.

An opaque total supports trial and error. A causal cost model supports engineering. That difference is the whole point.

Leave some qualities unscored. Symmetry, readability, robustness beyond the tests, elegant motion, and audacious excess give communities room to develop tastes the official graphs do not define.

Protect experiments

Never make improvement require overwriting the machine that worked. Support named solutions, duplication and branching, a known-good baseline, metric-specific variants, thumbnails, and recorded scores. Experiments become easier when failure can't destroy the proof you already have.

Comparison should make specialists visible. When the fastest, cheapest, smallest, and most legible solutions are different artifacts, the player has several meaningful reasons to come back.

Design the export with the system

A shared number says much less than a shared machine. The export may be a looping animation, short video, schematic, code listing, or importable solution. Whatever form it takes, it has to reveal the intelligence of the answer rather than only its final effect.

Opus Magnum's stable two-dimensional view, repeating machines, and visible arm choreography make its GIFs readable without editing a camera. EXAPUNKS exposes the opposite risk: agent movement alone reveals less when the important reasoning lives in code off-screen.

Include the puzzle identity, relevant execution, metrics, and enough program or structure to understand the trick. Keep the frame stable, make the result easy to produce in one action, and mark spoilers. If importing and modifying shared work suits the community, preserve authorship and make the remix explicit.

Now step back and notice the loop. The export format feeds back into the mechanic and presentation. A beautiful motion that hides its control logic is a weak explanation. A complete code dump that hides the machine's choreography is equally incomplete.

8 · Story and work

Story gives the puzzles something to be about. It helps you select artifacts, constraints, clients, failures, and reasons to optimize. Paste it on after those decisions and it can't do that work anymore.

Start with the core activity and the core story, then grow them together. A puzzle may begin with a mechanical need or a story beat. It earns its place when both sides agree.

Let the world choose the briefs

The domain supplies all kinds of possible products. The story chooses which one matters now. A client, incident, research question, production order, or institutional demand turns an abstract specification into a job.

Ask of every brief:

• Why does this artifact exist?
• Who needs it and under which conditions?
• Which functions or constraints follow from that situation?
• What does completing it reveal about the world or relationship?

Try replacing the setting. If the artifact, functions, constraints, and documents all survive unchanged, the setting is wallpaper. Revise the brief or admit that the fiction is decorative.

Look at SHENZHEN I/O. Consumer products such as signs, controllers, and novelty devices generate their own ports, signals, budgets, and test conditions. The briefs also reveal who commissioned the work. One specification is now carrying both character and system design.

Put story in the interface

Put the story in media that belong to the work: emails, requests, manuals, logs, specifications, invoices, zines, test reports, and the products themselves. One artifact can carry rules, voice, and world-building as long as each role remains clear.

TIS-100's printable computer manual presents the instruction set and the mystery of the machine as one object. EXAPUNKS' Trash World News pulls off the same trick with a hacker zine. Neither format excuses hidden semantics. Both make necessary reference material feel native to the role.

Keep the mandatory channel short and place it at the edge of the build-run-inspect-revise loop. Put deeper material in an optional, re-readable tier. Don't trigger irreplaceable dialogue during execution, and don't make the player leave the workspace to recover a missed requirement.

The player must always be able to extract the requirements from the voice. Flavour may complicate motive, but it can't hide inputs, outputs, limits, or failure conditions.

Give optimization a meaning

Metrics can express production economics, scarce material, limited power, urgency, secrecy, professional pride, or the standards of a demanding institution. The fiction doesn't need to reward every improvement, but it should make the measured qualities feel native to the work.

The same goes for sharing. A shareable artifact should look like something this world or profession might value: a demonstration, report, schematic, listing, recording, or proof of craft.

Use tone to widen the door honestly

A realistic-looking discipline may trigger assumed expertise before the player even meets the rules. Story and art can make the role inviting, but they must not promise a different activity from the one the system delivers. Translate specialist knowledge into rules the player can learn. Don't disguise unexplained complexity as authenticity.

9 · Prototype, test, and revise

Now the guide has to survive contact with a game. Don't begin with a full campaign. Build the smallest version that can prove the system, the editor, the curriculum, and the post-solve loop actually belong together.

Make a six-puzzle vertical slice

Build the actual runner and debugging controls. Add a representative test harness, at least two conflicting score axes, provisional histograms, named solution variants, and one real export format. All of these features change how you author puzzles. Postpone them and you are testing a different game.

Write the one-page definition

Before you expand the campaign, record the decisions every later puzzle will depend on:

Treat this page as a decision record, not a prophecy. When a prototype or player disproves it, change the record and revisit every puzzle that depends on the old decision.

Use three evidence streams

In fresh sessions, give players only the information the shipped game provides. Don't coach. Watch for hesitation, false assumptions, ignored controls, and the first moment when a player can no longer explain what happened.

For telemetry, record only what you can use, and collect it with consent and privacy safeguards. Useful events include puzzle starts and completions, time to first run and first correct run, resets, exits, returns after solving, score improvements after seeing a distribution, exports, and a short post-solve difficulty rating.

Metrics show you where a problem is. Observation and interviews tell you why. You need both.

Diagnose the layer that failed

Use release gates

Before you author more content, stop at these release gates:

• System: Can a few primitives express surprising behaviour without special-case parts?
• Specification: Can the player state exactly why a failed run failed?
• Diversity: Do several correct solutions differ structurally?
• Floor: Can the intended audience make a crude correct artifact?
• Ceiling: Can experts keep finding meaningful improvements?
• Trade-off: Does improving one score sometimes worsen another?
• Curriculum: Are purpose, reinforcement, combination, and optional mastery ordered cleanly?
• World: Does each brief reveal something about the setting or work?
• Artifact: Does the share format reveal what is clever?
• Evidence: Have fresh players, experts, and observed behaviour all changed the design?

If several gates fail, don't write more levels. More content will only bury the problem. Change the system or the product layer that is hiding it.

References

Go deeper

The design-element catalog, a play list, and the original sources behind the guide.

The catalog includes rules the player can build with, effects those rules may create together, and tools for testing, explaining, or scoring a machine.

If you open the catalog looking for ideas, start with the combines with column. It points to elements that may become more interesting together.

A · Design-element catalog 100 rows · M001–M135

This catalog is an idea source, not a checklist. You will find three kinds of entries:

• Rules the player uses to build.
• Effects that can emerge when rules interact.
• Tools for specifying, explaining, testing, or scoring a machine.

One mechanic in §2 may use several rows here. Choose only the entries that strengthen the game's central pressure and one another.

IDs never change. When a row is removed, its number stays unused, so gaps such as those in M011–M029 are intentional.

Ratings and game examples are prompts, not measurements. Some examples come from open factory games rather than specification-driven puzzles, so their ideas may not transfer directly. Inspect a game before you borrow from it, then test the rule against the five questions in §2.

Start with the combines with column. It suggests pairs worth testing, although a pair may appear in only one of its two rows.

A · Specification & verification M001–M010

Can the player infer a fair spec and test against it? M103 and M113 belong here by subject; they sit in G and H by number.

B · Flow & capacity networks M011–M029

How do topology, capacity, and timing make movement a design problem?

C · Transformation grammars M030–M044

Can a small vocabulary of operations compose into several routes from input to output?

D · Spatial construction M045–M060

Does geometry create real access, routing, and timing decisions?

E · Time & concurrency M061–M073

Can the player understand how local schedules produce global behaviour?

F · Programming & information M074–M093

How much behaviour can the player express with a deliberately poor language?

G · Rule manipulation & deduction M094–M104

Is the player manipulating objects, or the rules themselves? This can be powerful, but it attacks the stable core the player relies on. Make it foundational or leave it out.

H · Optimization & architecture M105–M117

Do different priorities produce visibly different machines?

I · Progression, pressure & meta M118–M135

Does this deepen construction, or compete with it? These rows pace, frame, and contextualize construction rather than extend it. Several sit at the presentation boundary the guide draws up front, so include them deliberately.

B · Games

This is a selected play list, not a complete studio catalogue or an attempt to settle the genre boundary.

Zachtronics lineage

Precursors

• The Bureau of Steam Engineering · 2009
• The Codex of Alchemical Engineering · 2009
• The Magnum Opus Challenge · 2009
• KOHCTPYKTOP: Engineer of the People · 2009

Commercial games

• SpaceChem · 2011
• Infinifactory · 2015
• TIS-100 · 2015
• SHENZHEN I/O · 2016
• Opus Magnum · 2017
• EXAPUNKS · 2018
• MOLEK-SYNTEZ · 2019

Open-ended games in Last Call BBS

• 20th Century Food Court · 2022
• ChipWizard Professional · 2022
• X'BPGH: The Forbidden Path · 2022

Direct continuation

• Kaizen: A Factory Story · 2025
• U.V.S. Nirmana · 2026

Selected Zachlikes

• Manufactoria · 2010
• Human Resource Machine · 2015
• Prime Mover · 2018
• 7 Billion Humans · 2018
• Comet 64 · 2021
• Turing Complete · 2021 · Early Access
• The Signal State · 2021
• Alan's Automaton Workshop · 2022
• Manufactoria 2022 · 2022
• SIC-1 · 2022
• SOKOBOT · 2022
• Stack Machines · 2023
• SokoCode · 2023
• Neon Noodles · 2023
• Word Factori · 2023
• Hexahedra · 2024
• ABI-DOS · 2024
• 1000-BIT · 2025

C · Sources

This guide makes a design argument. It isn't a literature review. These primary sources let you inspect how shipped puzzle systems were designed and discussed, but none of them establishes a universal recipe.