NICECHUNK Game: a browser voxel client that keeps Solana as the authority

What the client renders, and what it is not allowed to decide

The repository holds the browser client for NICECHUNK, a voxel world whose persistent state lives in Solana programs rather than in a game server's database. The README describes the client's job in one sentence: it "renders the world, handles player interaction, constructs transactions, and reconciles confirmed chain state". Read that list again and notice what is missing. Deciding what is true is not on it.

Two groups will care. Players who would rather run the client themselves than trust a hosted build get a complete, Apache-2.0 licensed source tree. Engineers evaluating on chain game design get something more useful: a working example of where the seam between a browser and a chain actually falls, written by people who were willing to document the parts that do not line up. The project is a pre-release on Devnet, so anyone arriving for a finished game will be disappointed. Anyone arriving to study the architecture will find more than the usual marketing page.

Four authority layers, and why an animation proves nothing

The README sets out four layers and assigns each one an authority. The browser runtime covers rendering, input, prediction, UI and local caches, and its authority is "immediate presentation only". Guardian handles nearby movement, chat, presence and regional messages, described as low latency coordination and explicitly not Solana finality. Solana programs hold players, inventory, skills, world deltas, buildings and market state as confirmed PDA state. Deterministic reconstruction sits underneath, combining a world seed, public rules and confirmed deltas into a reproducible view.

That table does real work. It tells a player that watching a block break is not evidence the break was accepted, and it tells a developer that a Guardian message must never be written into anything durable. Most chain game documentation blurs exactly this line, because blurring it makes the game feel faster than it is.

The backpack behaviour is the clearest illustration in the repository. The README states that presentation stacks up to 99 matching resources while preserving the underlying independent chain records. The interface aggregates what the chain deliberately keeps apart. If you are reading inventory through the SDK in `sdk/` rather than through the UI, expect the shape of the data to differ from what the screen shows.

Physical quantities are handled with the same bias toward explicit rules. Materials carry volume, density, mass and burden limits, and smelting, forging and skill bonuses are driven from rule adapters in `src/data/` and `src/world/` rather than from scattered constants. That is what makes deterministic reconstruction possible at all: if the rules are data, a second client can reach the same world from the same seed and the same confirmed deltas.

Cloning with the Chunk.js submodule and reaching the preview

Chunk.js, the WebGL2 engine that draws the world, is a pinned Git submodule at `chunk.js/`, so a plain clone gives you a repository that cannot build. The README's install path recurses into it and then runs the full check before the build:

git clone --recurse-submodules https://github.com/nicechunk/game.git
cd game
npm ci
npx playwright install chromium
npm run check
npm run build

The prerequisites are Git with submodule support, Node.js `^20.19.0` or `>=22.12.0` with Node 22 recommended, npm 10 or newer, Chromium for the browser integration tests, and a WebGL2 capable browser. `npm run check` is a wrapper: the `scripts` block in `package.json` chains `check:policy`, `check:i18n` and `test`, so one command runs the credential and secret policy scan, validates all nine locale dictionaries, and drives the Playwright game tests against an isolated local server. On a fresh Linux CI machine the README says to use `npx playwright install --with-deps chromium` instead, which pulls the system libraries too.

The local run is the next command:

npm run preview

That assembles the generated runtime, the chain bundle and the public assets into a disposable `.play-preview/` directory and serves it. Open `http://127.0.0.1:4173/play/` and you should get the game shell rendering against Devnet. Edit source afterwards and the preview will not pick it up on its own: run `npm run build` again first.

Devnet, resets, and a wallet warning that is not boilerplate

The README carries a warning block that deserves to be read literally. The public game is an experimental pre-release on Solana Devnet, Devnet state can be reset and carries no monetary guarantees, and the project tells you never to import a mainnet wallet or any private key protecting assets of real value.

This is the governing limitation of the whole project right now. Every inventory item, every registered chunk of land, every marketplace listing sits on a cluster that can be wiped. Building a long running community, a secondary market or anything with financial expectations on top of that is a mistake the documentation has already warned you about. The status table adds that runtime schemas, program addresses and game balance can all change before a mainnet release, and it tells readers to read configuration from the repository rather than copying the values out of the table. The runtime configuration file it names is `public/mainnet.json`, which is a slightly confusing name for a build currently pointed at Devnet.

The local preview is not the production shell

There is a second limitation that is easy to miss and expensive to discover late. The README states that the hosted game also depends on the NICECHUNK website for its login and shared site routes, and that a local preview validates the Game repository but is not a replacement for the complete production shell.

So the repository is honest about being one of several pieces. You can verify rendering, chunk reconstruction, transaction construction and the test suite locally. You cannot verify the login path, because it lives somewhere else and is not in this tree. A contributor fixing a wallet connection bug is working with partial visibility, and the issue tracker is the only route to the rest.

The release picture is similarly thin. The repository publishes no tagged releases, so there is no version to pin other than a commit hash. For a pre-release that is defensible. For anyone planning to fork the client and keep it in step with upstream, it means tracking two moving repositories by commit: this one and the pinned Chunk.js submodule.

Against a server authoritative voxel game like Luanti

The obvious comparison is a conventional open source voxel game such as Luanti, formerly Minetest, where one server process owns the world and clients are drawing terminals. That design wins on the things NICECHUNK finds hard. Writes are immediate, there is no fee attached to breaking a block, and a mod author can change world rules without touching a deployed program.

What it cannot offer is verification. In the server authoritative model, the world is whatever the operator's process says it is, and a player who suspects their inventory was edited has no way to check. NICECHUNK inverts that cost: a world delta is a confirmed transaction, the rules are public, and the seed is public, so a second implementation can rebuild the same world and disagree loudly if it does not match. The price is latency, transaction failure as a normal event, and a whole extra layer, Guardian, that exists mostly to hide confirmation time behind movement and chat that feel instant.

Pick the chain design only if auditability is the feature you are selling. If it is not, a server keeps far more of your engineering budget for the game itself.

Apache-2.0, a version number that disagrees with itself, and upgrade cost

The project is Apache-2.0 with a `NOTICE` file in the tree, which is the permissive end of the range: forks and commercial derivatives are allowed provided attribution and the notice travel with them, and the patent grant comes along. For a game client that other people may want to reskin, that choice removes most of the friction.

One inconsistency is worth flagging before you depend on a version string. The README's status table lists the client runtime version as `0.1.69`, while `package.json` declares `"version": "0.1.0"` and marks the package `"private": true`. Those are two different numbering systems living in one repository, and the manifest is not the one being updated. If you are writing tooling that reads a version, read the runtime configuration, not the manifest.

Upgrade cost is mostly submodule cost. The engine is pinned, the dependency set is small (`@solana/web3.js`, `@solana/spl-token`, `bs58` and `buffer` in production, with `vite`, `playwright` and `typescript` in development), and `npm run check` gives a single gate that catches locale drift and policy violations before a build. The part that will hurt is schema change on the Solana side, since the README says program addresses and runtime schemas can still move. Nine maintained locales also means every user facing string change is a nine file change, enforced by `check:i18n`.

Editorial conclusion

Adopt this if you are studying how a chain backed game splits presentation from confirmed state, or if you want to run the NICECHUNK client from source rather than the hosted build: the layer table and the deterministic reconstruction path are the parts worth reading. Do not adopt it as a foundation for anything with money attached, because the public deployment is a Devnet pre-release whose state can be reset. Verify two things first: that `npm run check` passes on your Node version, and that the values you need are read from `public/mainnet.json` rather than copied out of the README's status table.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. nicechunk/game on GitHub
4. Project website
5. README