A note before the review: I'm posting this on the Factorio forums because Steam's 8,000-character review limit can't accommodate the full content. My Steam review for the game links here for readers who want the complete write-up. If you arrived from Steam, welcome — the full review follows.
I have played for over 1,000 hours.
Verdict
Buy it. Play it. The game is excellent and well-programmed. Factorio: Space Age is one of the most impressive technical achievements in the simulation genre — a working, deterministic, multi-planet factory simulation with tens of thousands of entities running at scale across multiple surfaces, interplanetary cargo logistics, and a clean optional difficulty layer in the quality system. It deserves the recommendation without qualification for new players, and earns the recommendation a second time over for returning veterans going deep into Space Age content.
The value is well worth the price. It is addictive in the way a good MMO is addictive — long arcs of progression, hundreds of small decisions every session, a base that demands return visits — but with the satisfying feedback loop of an engineering simulator rather than an MMO grind.
The criticisms that follow are not deal-breakers. They are the ergonomic frustrations of someone who has poured hundreds of hours into late-game mid-to-large base play with multi-planet outposts, where a handful of management systems have not scaled up as gracefully as the rest of the game. The fixes belong in vanilla (unmodded Space Age), not in mods, and most are small UI / API changes rather than design rework.
A note on the source of this review. The frustrations below are not theoretical. Each has been deep enough that I've reached for a code fix when no in-game solution existed — including writing local mods to address vanilla gaps, and patching other authors' mods to repair performance issues caused by runtime-heavy implementations. That level of engagement is what surfaces the issues described here; a more casual player would not encounter most of them, which is fine — the game is genuinely excellent at the surface level. The criticism is from the inside looking out.
What the Game Gets Right
- Technical achievement. Multi-planet simulation with thousands of entities on each surface, deterministic across multiplayer, with space platforms moving between them. That this runs at all on consumer hardware is remarkable. That it runs at 30–60 FPS on a multi-planet base with outposts on a strong rig is a credit to the engine.
- Core loop. Crafting, automation, scaling up, tearing down, rebuilding with new strategies and new technology. The replayability is not artificial — each tier unlocks genuinely different solutions to old problems.
- Quality system. A new optional layer of systems that is not shoved down the player's throat. You can ignore it entirely and finish the game, or you can build elaborate upcycling loops once you are ready to challenge yourself. The opt-in design is exactly right.
- Space platforms. Designing a ship that survives the trip between planets is fun in its own right. Managing asteroid composition, thruster fuel efficiency, and cargo logistics adds a dimension that does not exist in any comparable game.
- Interplanetary logistics. The decision to ship intermediate products (bioflux over raw fruit, for example) rather than raw inputs is a real design choice with real consequences. Premium content.
Late-Game Pain Points
These are ranked roughly by impact for an experienced player. None of them are dealbreakers. Most are click-volume or visibility issues that the game's overall polish does not match.
1. BOT MANAGEMENT IS THE WORST PART OF LATE-GAME
Once a base has thousands of bots across multiple planets — and especially once quality enters the picture — managing the bot fleet becomes miserable. The vanilla mechanisms exist but don't scale to the situations that actually matter at this point in the game.
- Mass bot recall is technically possible but practically painful, and the difficulty scales with roboport count. You can set a roboport's logistic request list to pull bots into its inventory, and you can wire roboports to the circuit network for batch enable/disable workflows. But the more roboports you have, the more places bots can settle into — at the scale of tens of thousands of mixed-quality bots across hundreds of roboports on multiple planets, the available tools require either tedious per-roboport setup or whole-network shutdown. There is no clean "drain this network of bots" or "drain only quality tier X" operation.
- Quality bot tracking is poor. The logistic network overview does not break bots down by quality tier. You have a number for "logistic robots" — but if 80% of them are normal and 20% are legendary, the game won't tell you cleanly, and you cannot filter the network display by quality.
- No quality-specific delivery. When a logistic request is filled, bots are picked from any available depot, regardless of quality. There is no way to say "deliver this with legendary bots only" or "drain normal-quality bots from the network first." This means quality upgrades happen by attrition rather than design — and bots don't wear out, so attrition never finishes on its own.
- No "upgrade bots in place" workflow. The natural workflow is: build higher-quality bots, replace lower-quality bots in the network. The vanilla game offers nothing for this. The same problem applies to construction bots, which can't even be filtered or counted by quality in their roboport.
Concrete data point: I have been actively trying to complete a quality bot swap for over 200 hours of play, on networks of 10,000–20,000 bots (count varies by planet). The operation is still incomplete. The roboport logistics-list approach works in principle but scales unusably past about 2,000 bots — slow enough that planet-wide quality migration becomes a months-long background task rather than a deliberate operation.
2. ALERT FILTERING IS BRUTALLY UNDER-DESIGNED
The alert system has no granularity, and at scale this turns the alert log and audio feed into noise rather than signal. This is the second-biggest day-to-day frustration in late-game play.
The design problem in one sentence: vanilla alerts treat all incoming damage as equivalent, but at scale this is the wrong model. A well-designed late-game base is a layered defense system with intentional sacrifice. Outer walls are supposed to take damage. Landmines are supposed to explode. Construction bots auto-repair the lot, and the cycle continues. The only event that actually matters is when the inner line fails — a turret destroyed means biters got through, which is the one signal the player needs to act on. The same logic extends beyond static defense: on Gleba, a biochamber under attack from a hatched pentapod egg is not a problem if a nearby turret kills the attacker — the biochamber takes a few hits and continues working. The only event worth alerting on is when the biochamber is actually destroyed. Damage is noise across the board. Destruction is the signal. Currently every wall hit and every biochamber scratch triggers the same audio and panel alert as a turret loss. The result: under sustained pressure (Gleba spores, biter raids, asteroid storms), the alert feed screams constantly about expected outcomes, training the player to tune it out entirely — which means real emergencies also get ignored.
- No per-entity-type alert control. Vanilla offers global alert toggles (turn all "entity damaged" alerts on or off), but nothing per entity type. The result: on a base with thousands of walls, mines, gun turrets, lightning rods, and fish that incidentally take damage from passing biters, drifting asteroids, lightning strikes, or Gleba spores, the alert feed becomes a constant siren of low-value events. The actual emergencies — a biochamber going down on Gleba, a turret destroyed in a wall breach — get buried in the same audio channel as a fish taking 3 damage.
- No distinction between damage and destruction in alert config. The player cannot say "warn me when this entity is destroyed, but don't warn me when it takes damage." The two are coupled. A wall taking damage and a wall being destroyed produce alerts in the same channel, with the same priority, and the same sound.
- Runtime alert filtering doesn't actually kill audio. This is the technical kicker. The vanilla disable_alert API and the runtime approach used by community alert-management mods can hide an alert from the panel — but the audio has already played by the time the mod sees the event. The only way to actually prevent the sound is the data-stage prototype flag alert_when_damaged = false, which has to be set before the game world loads and cannot be reconfigured at runtime.
- The behavior players actually want is achievable only via custom modding. What I want, and what I built for myself, is: configurable lists at startup specifying which entity types are silenced from alerts entirely (no panel entry, no audio). Implementing this required data-stage prototype patching against alert_when_damaged. The vanilla configuration screen exposes none of this; the API surface to do it cleanly is half-missing.
3. TRAIN MANAGEMENT AT SCALE
Trains scale to dozens or hundreds in a late-game base, but train management UI does not scale with them.
- No hotkey to cycle through trains. Vanilla provides a train overview list that is navigated with mouse clicks. At 60+ trains across multiple surfaces, a keyboard cycle binding is sorely missed.
- Train groups don't sync temporary stops. Train groups correctly sync schedule edits across all member trains, which is excellent — but temporary stops (sent via map ping or autopilot interrupt) are per-train state and don't sync. Cleaning up stale temporary stops across a fleet is a per-train operation.
- Station rename does not propagate to interrupt targets. This one is silent and dangerous. If you globally rename a station, train interrupts that referenced the old name don't update. Trains keep running, hit the interrupt, fail to path, and either deadlock or fall through to parking interrupts. The failure mode is mysterious and the diagnosis is buried.
- LuaTrain.schedule writes from the Lua console wipe interrupts and group data. This is technically a modding/API quirk, but it bites players who reach for console commands to do batch fixes. There should be a clean API (or, frankly, an in-game tool) for batch schedule edits that respects groups and interrupts.
4. QUALITY FILTERING ON SPLITTERS AND INSERTERS VIA CIRCUIT NETWORK
In 2.0.67 splitters got circuit network support, which is great. But the implementation is incomplete in a way that hurts at scale.
- No >= quality comparator on circuit-set filters. The vanilla filter GUI on splitters and inserters supports >= quality, but you cannot send >= as a circuit condition. To dynamically filter "epic or better holmium plate" you must explicitly enumerate every item-by-quality combination as a signal — [holmium plate @ Epic] and [holmium plate @ Legendary] as separate signals. With multiple items across five quality tiers, the constant combinator content balloons.
- No quality wildcards in circuit signals. Related: you can attach quality to a signal, but not a wildcard. So even with a selector combinator, you can't broadcast "any quality" — only one tier at a time.
5. CARGO LANDING PAD: EITHER/OR LIMITATIONS, NO INNER-ORBIT TRANSFER, NO LOGISTICS CATEGORY
The cargo landing pad has several related design quirks that interact poorly:
- You can read the pad's contents, or you can set its requests via circuit — not both at once. Pick one. This is the core friction: at scale you want a pad that auto-adjusts its requests based on what's already sitting in the pad (don't request more iron if 5,000 plates are already there), but the circuit interface forces an either/or that requires awkward workarounds. A single unified circuit interface for both read and request would clean this up.
- The pad is treated as a generic logistic provider with no way to opt out. Anything inside the pad is fair game for requester chests on the same surface logistics network. If you have a requester chest asking for iron plates and the pad contains iron plates, bots will pull from the pad whether you want them to or not. The pad cannot be excluded from standard logistic flow without physically isolating it from the network — which defeats the entire point of having a network.
- Concrete example: science packs delivered by space platform land in the cargo landing pad and are routed to labs by belt. Occasionally a belt cleanup leaves stray science packs floating in the logistics network. The natural recovery is a requester chest that pulls the strays back onto the belt — and that part works correctly: the chest pulls the stray packs from the network first and feeds them onto the belt. The problem comes after that. Once the strays in the network are exhausted, the requester chest does not stop. It starts pulling fresh science packs out of the cargo landing pad itself, even though those packs are supposed to flow via the belt that is already serving the labs. The bot fleet now ferries science packs back and forth between pad and chest in parallel with the belt that is already doing the job, and the only way to stop it is to manually intervene each time. Constant micromanagement to avoid the bot fleet undoing its own work.
- Pads should be their own logistics category — not lumped in with provider chests. The cleanest fix is to make cargo landing pads a distinct logistics category alongside provider, requester, storage, buffer, and active provider. Bots would no longer treat them as default sources for requester chests, and players could opt in to pull-from-pad behavior explicitly when they want it. This single change would resolve the unintended-pull problem without touching any other mechanic.
- No inner-orbit space platform transfer. There is no way for one space platform in orbit to hand cargo to another space platform in orbit. Everything must transit through a planet's cargo landing pad. For multi-platform builds (one ship optimized for asteroids, one for express shipping, one as a fuel tender), this is a real gap. You end up dropping cargo to a planet, then re-launching it. Pure wasted thrust. A "cargo shuttle" transfer mechanic — with a fuel cost paid in rocket fuel for each transfer — would solve this without trivializing logistics. The cost preserves the design intent that interplanetary movement is expensive; it just removes the absurd ground-bounce.
6. GLEBA SOIL IDENTIFICATION
Gleba's plantable tile types — yumako wetlands vs. jellynut wetlands vs. less-fertile marsh — are visually too close in the default tileset. Telling them apart with the naked eye is genuinely difficult, and that's before any colorblind considerations.
Vanilla expects players to read the agricultural tower's overlay to plan farms. That works, but the underlying terrain remains hard to read at a glance when scouting on foot or planning expansions in remote view. A built-in higher-contrast option for plantable soils would make the early Gleba experience much less frustrating. The existence of a community mod for exactly this purpose is the strongest evidence that the visual design here missed.
7. AQUILO HEAT CONSUMPTION OPACITY
Aquilo's heating mechanic is excellent in concept and frustrating in execution. The frustration is not the mechanic — it is the information vacuum around it.
- Heat consumption values per entity are not in any tooltip. A pipe-to-ground consumes 150 kW; a regular pipe consumes 1 kW. That's a 150x difference, and the only way to discover it is forum posts and player-built spreadsheets.
- Similar surprises exist for underground belts, certain crafting machines, and several "obvious-looking" entities that turn out to consume vastly more or less heat than intuition suggests.
- The cost of a misjudgment on Aquilo is high: a freezing base may require flying back home for materials.
8. BELT CONTENT CLEARING
When troubleshooting belt jams, mistaken item routing, or rebuilding a section that has the wrong items running through it, the only vanilla way to clear contents off a belt is to deconstruct, wait for bots, blueprint paste back. This works, but it's a hack — the deconstruction planner is not a "clear belt contents" tool, it just incidentally does that as a side effect.
A native "clear contents" bot operation — bots pick belt items into the logistic network without removing the belts — would replace a whole category of awkward workflows that come up constantly during diagnosis and rework.
Performance and Mod Caution
Performance scales remarkably well. A mid-to-large base with multi-planet outposts on strong consumer hardware (high-end CPU, plenty of RAM, modern GPU) runs at 30–60 FPS, which is the engine working hard, not the engine struggling. The variance reflects what the game is doing, not what's wrong with it. There is no comparable factory simulation that holds up at this scale.
Be careful with mods. Factorio's mod ecosystem is huge and includes both excellent, performance-conscious mods and poorly-written ones that hammer on_tick and tank UPS at scale. The grand scale of the game makes mod quality matter much more than in most games. Some general rules:
- Look for mods that explicitly mention zero-runtime-overhead designs (Bottleneck Lite is a good example — it uses entity sprites and prototype properties rather than scripting).
- Avoid mods that update many entities every tick unless the author has demonstrated they know what they're doing.
- Check the mod's discussion page for UPS reports before installing on a large save.
A Suggestion: Threats on Fulgora and Aquilo
Vulcanus has demolishers. Gleba has pentapods. Both are well-designed because they fit each planet's identity — they're not biters with reskins. Fulgora and Aquilo have no native hostile content, which makes them feel oddly safe relative to the engineering challenges they pose.
Not asking for pollution clouds and biter waves. Asking for threats that fit each planet's design pillar:
- Fulgora: storm intensification events. Heavy lightning that overwhelms standard lightning rod coverage and forces you to design power buffering and damage tolerance.
- Aquilo: cold-snap events or asteroid bombardment from above. Punishes weak heating coverage and demands repair-pack logistics.
Recommendation
- New players. Buy it. Don't install any QoL mods. Vanilla holds up from start to finish, and the friction points described above are not friction points you'll encounter early. Reach Space Age, build out on each planet, and decide for yourself what you'd want changed.
- Returning veterans / Space Age players. Buy it twice over. The frustrations listed above are real, but the QoL mod list below addresses most of them. You will get hundreds more hours out of it.
Appendix: Recommended Quality-of-Life Mods
These are mods I run personally and would recommend incorporating into vanilla. Each is performance-conscious and addresses a friction point that the game has not solved natively. Items marked borderline are useful but more cleanup-tool than QoL, and players should treat them as such.
- Agricultural Tower Placement Helper. Colors tiles by plantability for ag towers. Removes guesswork on overgrowth vs. plantable soil.
- Aquilo Thermometer. HUD window showing current heat requirements on Aquilo. Surfaces what should already be in tooltips.
- Area Paste. Paste copied entity settings onto every matching entity in a selected area. Massive bulk edit time saver.
- Automatic Underground Pipe Connectors. Auto-places the connecting pipe when two undergrounds are placed at a corner or one tile apart.
- Barreling Group (barreling-group2). Moves all barreling and IBC recipes into a dedicated crafting tab. De-clutters the intermediates tab.
- Bio Processing Group (bioprocessing-tab). Adds a dedicated tab for Gleba organic recipes. Same de-cluttering principle.
- Bottleneck Lite. Status dots on every crafting machine and miner. Zero runtime overhead — scales to any base size.
- Circuit HUD V2. Persistent on-screen HUD showing wired signals. Essential for monitoring production, fluids, or buffers.
- Circuit Visualizer. Highlights all circuit wire connections like the vanilla pipe visualizer. Untangles complex circuit layouts.
- Circuit-Controlled Quality Filters. Adds >= and comparator support for circuit-set quality filters on inserters (splitters currently buggy). Fills the vanilla gap described in pain point #4.
- Easy Void (borderline). Voids items and fluids from chests/tanks. Cleanup utility, more cheat-tier than QoL.
- Even Distribution. Ctrl+drag distributes a stack evenly across multiple buildings. Should be vanilla.
- Factory Search. Shift+F searches your entire factory across planets for items, fluids, entities, or signals.
- Far Reach. Build, mine, and interact with anything on screen, customizable. Eliminates constant repositioning.
- Filter Helper. Context-aware filter suggestions for inserters, splitters, loaders, and chests. Skips the search box.
- Inserter Throughput. Tooltip showing items/sec for the selected inserter. Removes the need to leave the game for cheatsheets.
- Item/Fluid Wiper (rs-wiper) (borderline). Area-select permanent deletion of items/fluids. Cleanup tool, admin-only by default — not strictly QoL.
- Logistic Group Explorer. GUI listing all logistic groups, their members, and their filters. Critical at multi-planet scale.
- Orphan Finder. Shift+O highlights underground belts/pipes with no matching partner. Finds the missing pipe in seconds.
- Pushbutton. Constant combinator that emits a single-tick pulse on toggle. For manual circuit triggers.
- Show Max Underground Distance. Visual indicator showing maximum reach of the underground belt/pipe being placed.
- Space Platform Groups. Platform groups with shared schedules and load/unload limits, mirroring train groups. Glaring vanilla omission.
- Squeak Through 2. Shrinks collision boxes so you can walk between adjacent panels, pipes, miners. Eliminates pathing snags.
- Tapeline. Persistent or temporary measurement tools for planning layouts before committing entities.
- Uranium Geiger. Geiger sound effect near uranium ore. Minor flavor convenience.
Personal Mods (Not Publicly Published)
These are two patches I've written for my own play that address issues described in this review. Neither is currently on the mod portal. If you'd like to use either of them, leave a comment and I'll share the files.
- Selective Destruction Alerts (custom). Data-stage prototype patch that silences alerts for configured entity types entirely (walls, mines, fish, etc.) by setting the alert_when_damaged prototype flag to false. Uses prototype-stage patching rather than runtime alert removal, so it actually prevents the audio rather than just hiding the alert from the panel after the sound has played. Addresses pain point #2.
- Circuit-Controlled Quality Filters performance + splitter patch. Patches the third-party mod listed above to fix UPS issues from a runtime-heavy implementation and to repair the splitter checkbox-persistence bug that breaks circuit-driven quality filtering. Addresses pain point #4.
My patch for the circuit-controlled quality filters is available on GitHub at this link, which is a fork of the original project.
https://github.com/Mr00Anderson/Circuit ... ty-Filters
