FactorioLab: thirteen factory games, one Angular calculator

One codebase, thirteen games

FactorioLab is a tool for calculating resource and factory requirements for factory games, and the table of supported games is the clearest statement of its scope. Each entry links a game, a calculator instance and a Steam page. Factorio is the first, at factoriolab.github.io/factorio, followed by Dyson Sphere Program, Satisfactory, Captain of Industry, Techtonica, Final Factory, Factor Y, Foundry, Outworld Station, Belts of Iron, Mindustry, MoteMancer, SkyFormer and StarRupture. Thirteen games in total, each with its own URL and therefore its own dataset. The games are grouped by publisher or engine lineage in practice: the Paradox titles appear together, the games built on Unity or Unreal have different recipe models, and a browser game like Factor Y sits alongside full 3D factory sims. The shared codebase is what makes the breadth affordable.

Built on Kirk McDonald's calculator, not from a blank page

The project states that it is intended to build on the features of the Kirk McDonald Factorio Calculator, whose repository is linked, and that it is built from the ground up using Angular, Redux and TypeScript. That provenance is worth understanding because it explains the shape of the product. The original calculator was a well-regarded single-purpose tool for one game, and FactorioLab is the attempt to take that idea, and the recipe data model behind it, to a set of games. The rewriting in a component framework is what allows the same UI to serve thirteen games, since a per-game dataset can be loaded at runtime rather than hard-coded into the bundle. It also explains the emphasis in the repository on data extraction scripts rather than on the interface, because the hard part of adding a game is never the form.

The data pipeline is where the answers come from

The package scripts are the most revealing part of the repository, because they show that the recipe data is generated rather than typed. There is a script for the Factorio API, one for preparing it, one to build the data, one to update it, and separate build scripts for StarRupture, Belts of Iron and MoteMancer. There is also a dump command with three variants, a batch file for Windows, a shell script for macOS and a shell script for Flatpak, which tells you the extraction step runs against the game installation on the machine doing the extraction. There is a minify-data script and an update-hash script, which is what keeps the generated payload small and cacheable in the browser. The pattern is the same for each game: dump the game's own data, transform it into the calculator's model, build the output, and only then does the Angular app consume it.

A Redux store and an Angular shell

The stack is Angular with Redux and TypeScript, and the repository layout confirms the build tooling is current rather than inherited. There is an angular.json file, a tsconfig set split into app and spec configurations, a karma.conf.js for the test runner, an ngsw-config.json for the service worker, and separate lint configurations for ESLint, Prettier and Stylelint with matching ignore files. The package scripts are named after the Angular CLI: ng is aliased, start is ng serve, build is ng build, test is ng test, with a test:ci variant that runs headless in Chrome with no watch, and watch is a development-configuration build. The result is a Progressive Web App, since the service worker configuration is checked into the repository, and the README documents a separate staging environment at factoriolab.github.io/staging for testing pull requests.

Translations are synchronised by a script, not by hand

The internationalisation setup is the part of the contributor documentation that shows the most care. Language data lives in the public/i18n folder, and the English file en.json is the master. The rule is strict: keys added to the English file are added to all the other files, and keys missing from the English file are removed from the others. That means the English file is the single source of truth for the key set, which is the only way to keep thirteen languages from drifting apart structurally. A script called npm run sync-i18n maintains the data, sorting all keys in all files, removing keys from non-English files that are not in the English file, and adding English values where a translation is missing. So a contributor who adds a feature does not have to add a string in every language, and the translation files stay complete by construction.

Adding a language takes five steps and one type change

Adding a language is documented separately from translating one, and the sequence matters. You add a new file in the i18n folder named with the localisation key for the language, which is usually a two-letter locale code and may include a country code where relevant, with pt-BR given as the example. You put an empty JSON object in it, run npm run sync-i18n so the file is filled with English translations, then replace the English strings with real translations. Finally you add the code, which must match the file name, to the Language string union type in language.ts, and add the language as an Option in the languageOptions array in the same file. The TypeScript union is what stops a language code that does not exist at runtime from being accepted at compile time, and it is why the last two steps cannot be skipped. The repository also welcomes contributors who are not comfortable with Git and git, by sharing the raw JSON files over Discord instead.

Releases, contributions and the licence

The release history shows a project shipping regularly: v4.14.5 on 2026-10-13, then v4.14.4 and v4.14.3 both on 2026-09-30, with the last push to the repository on 2026-10-13. The version numbering is a plain four-part scheme rather than semantic versioning, and there is a release.config.js in the repository root plus a scripts directory, so releases appear to be automated. Contributions go through the issues page for suggestions and problems, and discussion happens on Discord. The README also invites support through a coffee link, which is the usual sign of a project that is volunteer-run and wants to keep the lights on. The licence field on the repository says MIT, the package is marked private with a version of 0.0.0 in its own metadata, and the recorded contributor is Doug Broad, with the online instance hosted on GitHub Pages.

Where FactorioLab is the wrong choice

Four limits apply. It is a web calculator, so it works from the game's data and not from your save file, which means it cannot tell you what your current base already produces and every answer is a plan for an ideal layout rather than a diagnosis of yours. It depends on the game data extraction scripts, so if a game patches its recipes or the extraction breaks against a new version, the numbers are wrong in a way that is hard to spot, because the calculator will still produce a confident answer. It is a volunteer project with an MIT licence and a donation link rather than a company behind it, so there is no support commitment when the data goes stale. And the breadth cuts both ways: thirteen games means the feature set is the intersection of what those games model, so a game-specific mechanic that the shared data model cannot express is simply absent, and the fastest way to find out whether it is there is to open the calculator for that game and look.

Editorial conclusion

Use FactorioLab when you are planning a factory in one of the thirteen supported games and want a production plan rather than a spreadsheet, because each game gets its own calculator instance with the recipes, belts and modules extracted from that game's own data files. Do not expect it to replace in-game planning for the late game, since a web calculator cannot know your current layout. Verify first which game versions the data scripts target, because the extraction pipeline is where the accuracy of any answer comes from, that the instance you use matches the game you play rather than a similar one, and that the local build works with the Node version your machine has, since the repository pins Angular 22 in its dependencies.

Frequently asked questions

Official sources

1. factoriolab/factoriolab on GitHub
2. License: MIT
3. Project website
4. README
5. Releases