Brave New Wonders is a PC factory automation and base-building simulation developed by City From Naught Inc., with City From Naught Inc. and LoongGate listed as publishers. It released on September 20, 2026 and is classified as Indie, Simulation, and Strategy.
The game’s most distinctive stated idea is not simply that players automate production, build factories, or manage resources. Those are broad ambitions shared across factory-building games. Brave New Wonders says its automatons can be directed through plain-language commands, with a behavior editor that turns those instructions into a behavior graph. Players are said to have access to presets, text commands in any language, and manual graph construction. The announced automation approach also avoids conveyor belts and conventional coding.
That is a consequential proposition for a factory game because the interface is often inseparable from the fantasy. Belts, inserters, pipes, wires, filters, and programmable components do not only move materials; they can become the player’s vocabulary for expressing a production plan. Replacing a substantial part of that vocabulary with autonomous workers and language-driven instructions could make Brave New Wonders feel less like laying industrial circuitry and more like directing a machine workforce. Whether that is a genuine gain in clarity depends on precision, feedback, and limits that the public description does not establish.
A factory builder where workers are the logistics layer
The publicly described production loop begins with mining ore and crystal, refining them into materials, and crafting increasingly complex components through branching production lines. The game is also described as including an expanding energy network, factories, warehouses, logistics routes, blueprints, and layout duplication. Taken together, those stated features point toward a design concerned with production interdependence, resource management, and growth beyond a small survival-crafting setup.
Where Brave New Wonders may diverge is in how materials move. Its automatons are described as transporting goods according to player-created commands. The public examples include moving between named locations in a defined order and responding to a colored signal by collecting a specified compound at one location and depositing it at another. Buildings and factories are also said to broadcast colored signals and react to one another, potentially forming a programmable network across the base.
As a design proposition, that could bridge direct instruction and logistics planning. A player could potentially think in operational terms—collect this resource, take it there, act when a particular condition occurs—rather than concentrating on a physical transport layout. That may be more immediately approachable for players who know the outcome they want from a factory but do not want every connection expressed through belts or similar infrastructure.
It could also create a different kind of complexity. Conveyors tend to make movement legible because their paths are persistent and visible. An automaton-driven system may be more flexible, but it needs to communicate task ownership, route choices, priorities, carrying limits, delays, conflicts, and failures. The public description confirms commands, signals, and behavior graphs, but does not explain how competing instructions are resolved or how a player traces a robot’s decisions. Those questions are central to the intended optimization puzzle, particularly as a base expands.
Plain language is the pitch; transparency is the question
The game’s public materials state that its text-command system uses an AI model solely to parse player text into a behavior graph. They also state that players who prefer not to use the command system can bypass it by manually assembling the graph. Separately, the developer states that the game’s illustrations, 3D models, textures, animations, sound effects, music, voice performance, and story were not generated by AI.
For design analysis, the significant distinction is that plain language is presented as an input method for a defined automation graph, rather than an open-ended promise that a model will independently devise a factory plan. That could be an important boundary. If the player supplies the intent, the game translates it into an inspectable logic structure, and that structure remains editable, the arrangement could preserve player control while reducing the initial friction of configuring routine tasks.
Still, “plain language” can cover a wide range of practical behavior. A robust version would ideally make clear what the parser understood, expose the resulting behavior in readable form, and provide dependable ways to amend a mistaken interpretation. An ordinary-language command may sound specific while leaving several game-specific questions unresolved. Which warehouse is being referenced? Which task takes precedence if two conditions activate together? What happens if a destination is full, inaccessible, or threatened? Does the automaton wait, choose a different job, or repeatedly attempt the same instruction? The public description does not answer these questions, so this feature cannot assume particular solutions.
The manual graph-building option may matter for more than player preference. If the graph is comprehensible to edit directly, it could give advanced players a way to refine a broad language request into exact behavior. If it is hard to understand, the command layer could become an opaque shortcut whose results are difficult to troubleshoot. The stated two-way structure—language for intent and graph editing for specificity—is appealing in principle, but its practical value cannot be determined from the description alone.
There is also a productive tension in the claim of no coding. Avoiding code does not necessarily mean avoiding logic. Conditional behavior, colored signals, and ordered tasks can still require careful thought about states and dependencies. That may be the point: Brave New Wonders could potentially make automation logic more approachable without removing the satisfaction of constructing a system. The key design challenge is distinguishing accessible expression from abstraction that conceals too much of the underlying process.
Blueprints, cloned automatons, and scale
Brave New Wonders is described as a game about expansion rather than one compact workshop. Its public feature list says blueprints can copy, paste, and mass-duplicate layouts, while cloned automatons retain their tasks. It also describes linking factories, warehouses, and logistics routes as production increases. Those are meaningful stated tools because factory designs often change character when they move from an early local setup to a large production network.
In principle, blueprinting paired with task-preserving robot clones could let a player reproduce a successful processing module without rebuilding every behavior manually. If a refining block has a working physical layout and a functional set of automaton instructions, copying both at once could support the game’s stated interest in larger networks and rapid expansion.
Replication, however, is not the same as adaptability. A copied behavior may fit its original context but need revision when it is placed beside a different warehouse, resource node, energy situation, or signal network. Publicly available information does not establish whether copied commands refer to local roles, fixed locations, reusable templates, or another framework. That uncertainty is particularly important because language-defined behavior could be convenient in a small base but harder to audit after repeated duplication.
The strongest version of this design would preserve a player’s proven logic without making a broad base difficult to read. That remains conditional analysis rather than a demonstrated conclusion. The available description establishes blueprints and task-retaining clones as intended features; it does not establish their usability across a developed factory network.
A mobile base could connect production to exploration
The setting is described as a far-future world after the fall of civilization. Players are identified as Pioneers who explore ruins, collect relics, and investigate humanity’s past. The public description also names hostile machines, gun turrets, dynamite for barriers, and a weapon relic. These details establish that combat and exploration are intended to sit alongside construction and production.
The largest travel-related promise is the Sky Pillar and the first Wonder: a massive airship described as an airborne fleet of factories. Players are said to travel between islands and continents with distinct biomes, resources, and breakthroughs while their base flies with them. If the released design operates as this description suggests, the premise could give the factory a distinctive relationship with geography. Rather than treating travel as entirely separate from construction, the game could ask how a portable productive system changes when new regions introduce different resources and needs.
That could make exploration materially relevant to automation. Newly encountered materials and breakthroughs could provide reasons to revise existing production, while a flying base could connect expansion to movement through the world. But the public description does not specify the scale or structure of travel, how the airship’s factory role functions moment to moment, or how combat intersects with economic planning. Those remain useful questions, not established details.
The narrative framing should be treated with the same restraint. The game is described as story-rich and includes relics, ruins, a mystery around humanity’s fall, and an ancient humanoid robot that remembers the old world. That identifies the intended fictional frame. It does not establish the frequency, format, or quality of story delivery, nor whether the investigation changes the automation systems in material ways.
What this design pitch still leaves open
Brave New Wonders presents a coherent stated identity: resource extraction and production chains, energy management, mobile expansion, programmable automatons, and post-apocalyptic exploration. Its central differentiator is specific enough to examine through future hands-on coverage. The important question is not merely whether players can type instructions to robots. It is whether the game makes those instructions precise, transparent, editable, and satisfying when a production network becomes complicated.
Several questions follow naturally from the public design. How broad is the command system’s supported vocabulary? How does the behavior editor show a command’s final meaning? What tools, if any, communicate why an automaton has or has not acted? How are colored signals configured and followed across a large base? What constraints keep robot-driven logistics readable? How do blueprints behave in new locations? And how strongly do the airship, different regions, hostile machines, and relics connect to the production core?
For another design-focused look at systems whose practical clarity remains the important question, read our Medium Rare PC design preview.
Based on public information alone, Brave New Wonders is best understood as a factory-building concept with unusually high interface demands. The description establishes an attempt to let players express automation through natural language while retaining manual graph construction for direct intervention. If that balance works in practice, it could offer an alternative to the genre’s familiar physical-logistics vocabulary. This feature does not assess whether the released game achieves that goal; it identifies the design questions that its stated systems make most important.
