The Powder Toy: the newest release is a snapshot, and the readme is still dated June 2026

The newest release is a snapshot, and the numbers run backwards across naming schemes

The three most recent releases use two different naming conventions. The newest is snapshot-401, dated 2026-10-04. Before it came v100.1.400 on 2026-08-08 and v100.0.399 on 2026-06-23.

So the trailing number rises steadily, 399 then 400 then 401, while the name changes shape completely at the last step. A versioned release carries a three part number; a snapshot carries a single one and the word snapshot, which describes a build rather than a release anyone intends to keep.

There is a second oddity in the dates. The snapshot is dated 2026-10-04, and the repository was last pushed on 2026-10-31, so the newest published artefact was produced from something that is not the newest thing in the repository. Nothing here says a build is broken. It does mean there is no single line to follow, and a user who wants the newest stable thing has to pick the versioned one by eye.

The readme datestamp is four months behind its own releases

The document opens with a title and a date:

The Powder Toy - June 2026

After that comes a v100.0.399 release from June 2026, a v100.1.400 from August 2026, a snapshot from October 2026 and a push from late October 2026. The datestamp is therefore describing the oldest of those four events.

For a project whose front page is otherwise quite well maintained, this is a small blemish with a disproportionate effect, because that line is the only place a reader can get a sense of how current the file is. Everything after it is timeless, which is what you want from a readme, and the one line that is meant to carry freshness is the one carrying stale information.

The practical answer is to ignore it and read the release list and changelog.txt instead. Both live outside the readme, which is arguably where a datestamp belongs anyway.

Build instructions are one wiki link, with no command anywhere in the page

There is a section headed Build instructions and it contains a single sentence: see the Powder Toy Development Help section on the main page of the wiki. There is no configure line, no build command and no dependency instruction in that section.

That is a real gap for a project released under a licence that explicitly invites modification, and it is more noticeable because the repository root shows a build system ready to be driven. There is a meson.build, a meson_options.txt and a subprojects directory, which is how meson vendors its dependencies, plus a cross-examples directory for cross compilation, a .clang-tidy file for static analysis, a fonttool.py written in Python, and an android directory.

That last one contradicts the repository description, which calls this a desktop version. So the source tree includes an android directory while the readme points at a wiki page for building. The wiki is also not part of the repository, which means the only build documentation can change without a commit and without a review.

Ten libraries, including both Lua and LuaJIT

The credits list what the game is built from, and the list is short enough to be worth reading closely: bzip2, FFTW, JsonCpp, libcurl, libpng, Lua, LuaJIT, Mallangche, mbedtls and SDL.

Each answers a question the readme asks. libcurl and mbedtls are the online layer, one for HTTP and one for TLS. SDL is the window and input layer.

Two entries are worth a second look. Lua and LuaJIT are both listed, so the script runtime question is answered twice, which is normal for a project that wants a fast interpreter and a reference implementation but means you cannot infer which one your build uses from this page. And Mallangche is credited to a named individual's repository rather than to a foundation.

Three keys change meaning when the console is open

The controls table is the most precise document in the repository, running to more than forty rows. It covers the brush shape, pause and quit, zoom, grid size up and down, the HUD, view modes selected with the number keys 0-9, screenshots, element search, stepping a single frame, undo and redo, drawing rectangles and lines with different modifiers, and sampling an element with the middle or alt click.

Three rows carry a parenthetical that changes the key: save stamp, debug mode, and cycling gravity modes each say to use the key with Ctrl when STK2 is out. The backtick key separately toggles the console.

There is also a row for Ctrl+I that installs the game so saves and stamps can be loaded by double clicking.

The sandbox is grid and brush based, and the readme says so in one line

The instructions section is a single paragraph, and it is the most honest description of the game on the page. Click on the elements with the mouse and draw in the field, like in MS Paint. The rest of the game is learning what happens next.

Everything else follows from that. The grid can be resized in both directions, the brush has a shape cycled with Tab and a size changed with the brackets or the scroll wheel, and an element is picked from the field rather than chosen from a menu. Modes are switched rather than configured: view modes, gravity modes, air modes, edge modes, Newtonian gravity on or off, ambient heat on or off.

The feature description on top adds the range: building materials, liquids, gases and electronic components for constructing complex machines, guns, bombs and terrain, then mining them, adding wirings and operating the result.

The game runs offline; only the account backed layer is gated

One sentence separates the two halves of the software. To use online features such as saving, you need to register an account.

Everything else is local. There is a Lua API for automating work or writing plugins, the controls are all local, and the simulation runs on your machine. Registration is needed for online features such as saving; the readme also mentions browsing and playing thousands of community saves and uploading your own.

The distribution picture matches that split. The latest version comes from the project's own website, and the game is also on Steam. So there are two sources for the binary and one rule about what needs a login.

For a project released under the GNU General Public License with a wiki, a forum, a Steam page and a website, that is a lot of infrastructure around a single sentence about needing an account, and it is worth knowing which parts of your experience depend on somebody else's machine.

Sixteen names in the credits, two of them with a role attached

The special thanks list is long, and mostly bare names. Two entries carry a description: Stanislaw K Skowronek designed the original Powder Toy, and Simon Robertshaw wrote the website and is the current server owner. The other fourteen are names only, among them Me4502, mniip, jacksonmj, MaksProg, Pilihp64, Catelite, Victoria Hoyle, Nathan Cousins and others.

The structure says something. This is a project where the original design has one author, the infrastructure has another, and the continuing work is a long tail of individual contributions with no role labels at all. There is no company section and no foundation section.

The one detail with consequences beyond the credits page is the server ownership. Online features such as saving are described as account backed and community saves are hosted rather than distributed, so somebody's machine is in the path for anyone who wants the shared library. The readme credits that person by name and role rather than pointing at an organisation, which is a more honest thing to do and also a reminder of where the dependency sits.

Editorial conclusion

The Powder Toy is worth judging on two separate tracks, because they are in very different condition. As a program it is a long lived sandbox with a precise, published control surface, a Lua API for automation and plugins, and a licence that lets you modify and redistribute it. As a published artefact it is loose: two release naming schemes in one list, a newest entry that is a snapshot rather than a version, and a readme whose datestamp is four months behind its own releases. If you want to play, download from the website or Steam and register only if you want the account backed layer, since the game itself runs offline. If you want to build it, the repository has everything a build needs and the documentation has none of it, so budget time to work through the wiki's development section. And if you want to extend it, the Lua API is the documented seam.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. The-Powder-Toy/The-Powder-Toy on GitHub