The Long Silence: a WebGL2 space exploration game built by Claude Opus 5

What The Long Silence is, and who it is built for

The Long Silence is a procedural space exploration game that runs in a browser tab. The premise, as the README states it: forty thousand years ago nine hundred inhabited worlds inside an eighty light-year volume fell silent in four days, leaving no debris and no radiation signature. You fly the survey vessel Pale Seeker, chart systems, scan what you find, and attune to seven Resonators. Each Resonator yields a Canto and pushes the drive further; all seven opens the Aperture.

The audience is narrower than the premise suggests. This is a single-author project by Anshu Chimala, published under MIT, with one runtime dependency (three) and two dev dependencies (vite, playwright). There is no homepage field in the repository metadata and no release has been published. The README documents controls, rendering internals and directory layout, but it does not document a public API, a save format, a modding surface or a contribution process. If you are looking for a game engine to build on, this is not that. If you are looking for a worked example of how far a browser can be pushed with hand-written shaders and no downloaded art, it is unusually detailed.

A floating origin, baked cubemaps and GPU auto exposure

The rendering architecture is the interesting part, and the README is specific about it. One world unit is one kilometre. Systems span millions of units while the ship is 0.1 units long, so the world uses a floating origin: the ship sits at (0,0,0) and everything else is positioned relative to it each frame, combined with a logarithmic depth buffer. Custom ShaderMaterials opt into log depth by hand through the LOGD_* chunks in src/gfx/glsl/noise.js. The README warns that missing this makes two concentric spheres z-fight into triangular confetti, which is a concrete failure mode rather than a general caution.

Planets are baked, not evaluated. The README explains that twenty-odd octaves of simplex per pixel per frame is not survivable on a phone, so each solid world is rendered once into a cubemap holding linear albedo in RGB and terrain height in alpha. The runtime shader is then three texture taps for normals plus lighting. Cubemaps are chosen over equirectangular maps to avoid pole pinch and seams. The nearest world is re-baked at 1024 squared per face; everything else sits at 256 squared.

Atmospheres are single-scattering raymarches through a spherical shell in planet-radius object space, with Rayleigh coefficients set from real optical depths (the README gives roughly 0.05/0.10/0.23 at zenith) and a soft planetary penumbra on the light ray so twilight fades rather than ending at a line. Auto exposure runs entirely on the GPU: a 64 squared luminance reduction to 8 squared to 1 squared, then a ping-pong adaptation target. The metric is a square-root mean, and the README gives the reason: a log mean is the textbook choice, but space frames are 90 percent black sky and the log of near-zero drags the average to nothing, blowing out every shot. That is a design decision with a stated rationale, which is more than most rendering notes offer.

Post-processing is hand-rolled: bright prefilter, six-level dual-filter bloom with attenuated wide mips, anamorphic streak, god rays and lens ghosts, then a composite pass with radial blur, chromatic aberration inside the sampler, AgX tonemap, grain and dither, finished with FXAA. Performance holds 60fps by trading resolution rather than features: the engine watches frame time and moves the render scale between 0.62x and 2x.

Installing The Long Silence and taking a first flight

The README gives three commands and nothing else for setup. There is no installer, no account, no asset download step. Clone the repository, then install dependencies with npm:

npm install

Start the development server. The README states the dev server comes up on http://localhost:5173.

npm run dev        # http://localhost:5173

Open that address in a WebGL2-capable browser. You should see the game, not a loading screen for external assets, because the README says nothing is downloaded: every star, world, ring system, nebula and derelict is generated from a seed and shaded by hand-written GLSL. The one exception is ground material: the README states the materials, stones and leaves are authored by an image model and by Blender through the scripts in tools/, and shipped as images and one small GLB.

For a production build, the README gives a single command that produces a static bundle in dist/:

npm run build      # static bundle in dist/

To fly, the controls table in the README is the reference. Mouse click captures the pointer for steering, or use the arrow keys. W and S or the scroll wheel set throttle, Q and E roll, Shift boosts, and holding F scans. L lands and lifts off. J engages the fold drive, M opens the star map, Tab opens the archive. X is a full stop, V cycles camera, and P toggles frame stats. Touch users get dual sticks plus on-screen buttons for boost, scan, fold, map and archive. The README notes that fold speed scales with distance from the nearest mass, so an approach decelerates itself and drops you out just clear of the surface, and that interstellar transit is initiated from the star map and costs drive charge by distance.

The ground is a separate scene, and that shapes the whole design

The README draws a line that is easy to miss: orbit needs a whole planet with no visible geometry, while standing on one needs ten kilometres of terrain with no visible sphere. These are two different renderers. world/Surface.js is a radial grid whose rings grow exponentially, displaced by the same terrain law the orbital bake uses, bent down by the planet's real radius, and hazed by the same scattering coefficients as the atmosphere shell above it. Sharing the terrain law and the scattering coefficients between the two views is what keeps the transition from orbit to ground from looking like a scene change.

The ground is dressed in generated materials: thirteen PBR sets under public/models/mat_*, each a photographic albedo generated by an image model with height, normal, roughness and occlusion derived from it in numpy through tools/gen_material.py and tools/matlib.py, then seam-fixed in the gradient domain. A world picks four by type (bare rock, its loose set and two accents), and the terrain shader blends them by height, so sand pools in the hollows of the rock and the rock's crests break through. The shader samples the mid and macro octaves stochastically so no tile shows its period, and retints the albedo about each world's palette so one image serves an oxide desert and a bone one. The stones are eight carved variants at three LODs from tools/build_rocks.py; the leaves and bark are generated atlases.

Placement is where the README gets unusually candid about cost. A tuft, a tree and a stone each ask the height field where the surface is, which way it faces, whether the habitat rules let them exist and whether they are in the sun's shadow, and every vertex of every instance used to ask again. A placement pass now answers per instance into three small float textures each frame, and the vertex shaders fetch their texel by instance id. The README cuts off mid-sentence at the point where it reports the effect on the worst landed frame, so the measured improvement is not stated in the text available.

One kit builds every hull, station and derelict

gfx/greeble.js is described as owning the plate-seam law, the weathering, the sun-bleaching, the grazing rim term and five base materials. The player's hull, every freighter, every station and every derelict are surfaced by it. Parts bake their transforms into their geometry and are welded per material, so panel lines run continuously across part boundaries and, per the README, a hundred pieces cost six draws. That is a batching strategy tied to the material count rather than to object count, and it explains why the five base materials matter: each additional material is another draw call across every assembled object.

Traffic is on a schedule, not a simulation. Craft follow analytic paths keyed to the clock, so the README states they are exactly where they belong after a fold jump or a two-minute pause. Each carries a beacon, a quad sized from view depth to hold a constant few pixels, because sixty metres of hull four million kilometres away is far below one pixel, and a moving spark is what makes a system read as busy. This is a deliberate cheat, and the README presents it as one.

Where The Long Silence stops being the right tool

The repository metadata shows no releases and no homepage. There is no changelog, no migration guide and no versioned API. Upgrades are therefore a source-level exercise: you read the diff, you check whether the shader chunks you depend on still exist, and you rebuild. For a project whose README warns that missing one log-depth opt-in turns planets into z-fighting confetti, that is a real cost, because the failure appears visually rather than as an exception.

The documentation has gaps. The README does not document a save format, a settings persistence mechanism, a replay or seed-sharing workflow, or any rollback path. It documents a smoke script in package.json (npm run smoke) and a deploy script that runs vite build followed by npx wrangler deploy, but the README itself does not describe what the smoke test covers. The licensing terms are MIT, stated in package.json and in the LICENSE file at the repository root, but the README does not discuss what that means for the generated image assets under public/models/, which is the one part of the project that is not procedurally derived at runtime.

If your goal is a maintained game engine with a stable interface, this is the wrong tool. If your goal is a browser-native game whose entire runtime footprint is three plus your own code, the constraint is the point rather than a defect.

How it compares to a general-purpose WebGL engine

The obvious alternative is to build the same game on a general-purpose WebGL engine such as three.js alone, or on a higher-level framework that wraps it. The Long Silence already depends on three (version ^0.185.1 in package.json), so the difference is not the underlying library but what sits on top of it. A general-purpose engine gives you a scene graph, a material system, asset loaders, a physics integration and a documented extension API, and it expects you to feed it geometry and textures. The Long Silence does the opposite: it generates geometry, bakes planet surfaces into cubemaps before the frame starts, writes its own post-processing chain instead of using an effects composer, and opts individual shaders into logarithmic depth by hand.

The trade is legibility against reuse. A framework's abstractions are documented and shared across thousands of projects, so a new contributor can guess where things live. Here, the shared surface is gfx/greeble.js and the terrain law in world/, and the README is the only map. In exchange, the renderer has no general-purpose overhead: no scene graph traversal for objects that are millions of units away, no material permutations you did not ask for, and a render scale that moves between 0.62x and 2x in response to frame time. The README's own performance framing makes the priority explicit: it trades resolution, never features. A general-purpose engine would more likely expose quality tiers that disable effects.

Maintenance, licence and what an upgrade actually costs

The repository is not archived, and the last push was on 2026-09-03. That is the only maintenance signal available: there are no releases, no issue templates described in the README, and no stated support channel. Treat the project as a snapshot you can fork, not a dependency you can track.

The licence is MIT, declared in package.json and present as a LICENSE file at the repository root. MIT is permissive and places few obligations on reuse, but the README does not address the generated image assets under public/models/ or the single GLB it mentions. Whether those carry the same terms as the code is not stated in the README, and that is the first thing to check before redistributing the game or its art. That is a documentation gap, not a legal conclusion.

Upgrade cost is dominated by the GLSL surface. The README says custom ShaderMaterials opt into log depth by hand through LOGD_* chunks in src/gfx/glsl/noise.js, and that the post chain is hand-rolled end to end. Any change to three's shader chunk names or to the renderer's depth handling lands directly in your code rather than behind an adapter. The runtime scale range of 0.62x to 2x and the 1024 squared versus 256 squared cubemap split are the two knobs the README identifies for performance work.

Editorial conclusion

Adopt The Long Silence if you want a readable, self-contained WebGL2 reference for procedural rendering, floating origin, baked cubemap planets and GPU auto exposure, or if you want a browser game that ships no third-party assets. Do not adopt it if you need a maintained engine with versioned releases, a documented API or a support channel; the repository has no releases, no homepage and the README ends mid-sentence. Before building on it, run npm install and npm run dev, open http://localhost:5173, and read src/gfx/greeble.js and src/world/Surface.js to confirm the module boundaries match your needs.

Frequently asked questions

Official sources

1. achimala/TheLongSilence on GitHub
2. Issues
3. License: MIT
4. README