Evolve: a browser incremental game where a civilisation runs on idle time

What the game is

Evolve is an incremental game about evolving a civilisation from primordial ooze into a space faring empire. The README describes it as combining elements of a clicker with an idler, and says it has lots of micromanagement. The question the game asks of the player is what will you evolve into.

That framing explains the genre conventions. An incremental game is one where progress continues whether or not you are watching, and a clicker layer means some actions are performed by hand. Combining them means the game has a build order, a set of jobs that produce resources, and a set of research or upgrade choices layered on top, with the idle part covering the time you are not there.

The project is MPL-2.0 licensed, written in JavaScript, and the repository is not archived with the last push on 2026-10-06. There are no published GitHub releases, and the package version in the manifest is 1.4.10 with the name evolveidle.

A hosted instance runs at pmotschmann.github.io/Evolve, so you can play without setting anything up.

The interesting thing about the repository for an engineer is that the game is also a working example of a static site with a generated wiki, a LESS stylesheet pipeline, a locale system and a container image, and the README is unusually explicit about how to work on each of those.

The build pipeline, and the two platform variants of every step

The build is npm scripts, and the structure is the interesting part: almost every build step has a Linux variant and a Windows variant, because the underlying tools differ.

# Builds everything on Linux
npm run build
# Builds everything on Windows
npm run build-win
# Builds the game bundle
npm run evolve
# Builds the CSS file for the game on Linux
npm run evolve-less
# Builds the wiki bundle
npm run wiki
# Launches the game server locally on localhost:4400
npm run serve
# Deploys the game to GitHub Pages on Linux (requires forking)
npm run deploy

The JavaScript bundling is done by hand-written Node scripts rather than a bundler library: buildEvolve.js, buildEvolveDebug.js, buildWiki.js and buildWikiDebug.js, all four at the repository root, and the scripts call them by name.

The CSS pipeline is lessc followed by csso, and the two steps are chained in one npm script with a cleanup between them. On Linux the cleanup is rm of the intermediate unminified file, and on Windows it is del with a backslash path, which is why each of the four CSS scripts has a -win twin. The manifest spells out both forms, for example lessc src/evolve.less evolve/evolve-unminified.css && csso -i evolve/evolve-unminified.css -o evolve/evolve.css && rm evolve/evolve-unminified.css on one side and the same with del evolve\evolve-unminified.css on the other.

The deploy step is a copy plus gh-pages. On Linux it removes and recreates a dist directory, copies the HTML files, the icon, the LICENSE, and the evolve, lib, font, strings and wiki directories into it, then runs gh-pages -d dist. The Windows version does the same thing with rmdir, xcopy and copy.

The serve script runs servehere -c, and the game server listens on localhost:4400 according to the comment in the README.

The Docker image, and the Node and nginx versions it pins

The Dockerfile builds the game and serves it with nginx, in two stages driven by build arguments.

The builder is node:16.20, and the runtime is nginx:1.26.1-alpine. The builder stage copies the whole tree in, runs npm install and npm run build, and then assembles a dist directory containing the HTML files, the icon, the LICENSE and the evolve, lib, font, strings and wiki directories.

The runtime stage copies that dist directory to /usr/share/nginx/html in the nginx image, so the shipped image contains no Node runtime at all, only static files and a web server.

The commands to build and run it are:

# Build evolve server image
docker build . -t evolve

# Run evolve server. Default address: http://localhost:8080/
docker run --name evolve -p 8080:80 -d evolve

So the container serves on port 80 inside and is published on 8080 on the host.

One thing to notice is that the builder image is node:16.20, which is an old Node line for a project whose last push was in 2026. The build works, since the tooling is a plain Node script and lessc and csso, but the pinned base is worth knowing about if you want to rebuild the image with a newer Node and see whether the scripts still pass.

The repository top level also has an index.html and a wiki.html alongside the generated directories, a save.html, the font directory, the lib directory, the strings directory, the src directory where the LESS sources live, and the evolve and wiki output directories, plus two icon files, evolved.ico and evolved-light.ico.

Translating the game, and the tokens you cannot move freely

The translation contribution path is documented step by step, and it is the most approachable way to contribute to a project like this.

You make a copy of strings/strings.json and name the copy strings/strings.locale.json, with the locale being the language alpha-2 code joined with the country alpha-2 code, for example strings.es_US.json. The strings live in JSON and look like this:

"job_farmer_desc": "Farmers create food to feed your population. Each farmer generates %0 food per second."

Two rules are stated and both matter. The first part is the key, which cannot be altered, and you must not translate or modify the key in any way. The second part is the string to be translated.

The subtle rule is about tokens. Many game strings use tokens, %0, %1, %2 and so on, to represent game values, and these tokens must remain in the final translated string. Their position can be moved, because the number represents a specific value and not its position in the string. That distinction is the one translators get wrong, and it is the reason for the wording.

Then the registration step: to enable your language translation in the game you must add it to the locales constant in locale.js, at the bottom of the file. So a new language needs two things, the JSON file and a line in the constant, and the second is easy to forget because nothing fails loudly without it.

Once the file is ready, you send a pull request with it to the Evolve main branch.

The contribution rules, and the one that shapes every feature request

The contributing section has a rule that is unusual and worth quoting in full, because it governs what the project is.

Bug fixes, additional translations, themes or UI improvements can simply be submitted as pull requests and, once reviewed and accepted, merged into the main game branch. But a new feature cannot arbitrarily make something easier without making something else harder, and if a new feature idea simply makes the game easier it will not be accepted.

That is a design constraint on the whole game, and it is the kind of rule that comes from a game where the difficulty is the point. An incremental game with no friction is a checklist, and the author is guarding against that. The practical consequence for a contributor is that a feature proposal has to come with a compensating difficulty, which raises the bar for ideas considerably and explains why the remaining work list in the project focuses on infrastructure rather than on new gameplay.

The mechanical rules are also specific. All pull requests should be based off the current dev branch, and the dev branch is either master or named after its version number, so you have to check the current game version and what branches are available before contributing. And pull requests should not contain the JS and CSS files generated by the build, which is the usual rule for a project with committed build output, and it keeps the diff readable.

The CSS rule follows from the pipeline. Evolve uses LESS to build its CSS, you cannot just edit the minified CSS file, and you must instead edit src/evolve.less and then use the less compiler to rebuild the CSS file.

Issues are for bugs and other problems with the game. Gameplay questions belong on Reddit or Discord, and the links for both are in the footer of the game.

Editorial conclusion

Evolve suits a player who wants an idle civilization game they can host themselves, and a contributor who wants to add a translation, a theme or a UI improvement to a project with a clear contribution path. It is a poor fit if you want a game with a paced story or a fixed ending, since it is a long-form incremental loop by design, and it is a poor fit if you need the game to be reachable from outside your machine without setting up a server. Before playing, note that saving uses a local page rather than an account, so check how save.html behaves in your browser before you invest hours in a run, and if you self-host, use the Docker command and keep the data volume in mind.

Frequently asked questions

Official sources

1. Issues
2. License: MPL-2.0
3. pmotschmann/Evolve on GitHub
4. README