zeekayandHanzo Dev
f154f41c58
Chunk: a voxel world is a meshing problem, not a drawing problem. 81 chunks of
16x16x24 is ~500k cells; emitting only faces that touch air leaves ~62k quads at
60 fps. Editing re-meshes only the touched chunk and its four neighbours.
Why this exists: static-SPA builders cannot ship a game. Proving hanzo.app can
meant finding what actually stopped it, and three things did:
1. POST /v1/projects/:slug/deploy carries the entire build in ONE request body
and the public edge caps a body at 4 MiB (measured: 4194304 accepted,
4198400 gets the opaque fasthttp "Error when parsing request"). Godot emits
a 43 MB engine wasm; Unity 22 MB + 5.7 MB of data. The artifact lane cannot
express a game at all, so these ship through the release lane instead: stage
to the object store, then POST /v1/sites/:slug/publish promotes it
server-side with no body.
2. Engine loaders emit NON-fingerprinted filenames (index.js, <name>.loader.js)
and clients/sites.CacheControlFor only marks a content-hashed name
immutable. A redeploy therefore leaves the CDN and the browser running the
OLD loader against the NEW wasm. That is not a visible error: emscripten
prints "still waiting on run dependencies" forever and the canvas stays
300x150. Every template here fingerprints its own asset names so the case
cannot recur.
3. A cross-origin-isolated document (COEP: require-corp) BLOCKS a plain
cross-origin script, so the shared a.hanzo.ai runtime needs
crossorigin="anonymous" on exactly the pages that opt into isolation.
Co-authored-by: Hanzo Dev <[email protected]>
Chunk — a voxel sandbox
First-person voxel world: procedural terrain, face-culled chunk meshing into one merged
BufferGeometry per chunk, pointer-lock controls, and place/break editing that re-meshes
only the chunk you touched.
Live: https://voxel-craft.hanzo.app
A voxel world is a meshing problem, not a drawing problem. 81 chunks of 16x16x24 voxels is ~500k cells; emitting only the faces that touch air leaves ~62k quads and holds 60 fps.
Build
npm install && npm run build
Deploy to hanzo.app
An engine build is far bigger than the 4 MiB the public edge accepts in one request body, so games ship through the release lane, not the artifact lane: put the built tree in your object space, then publish it server-side.
# 1. declare the engine — `unity`, `unreal`, `godot` make clients/sites serve the
# site cross-origin-isolated (COOP/COEP) so multithreaded WASM gets SharedArrayBuffer
curl -X POST https://api.hanzo.ai/v1/projects -H "Authorization: Bearer $TOKEN" \
-H "X-Org-Id: $ORG" -H "Content-Type: application/json" \
-d "{\"slug\":\"my-game\",\"name\":\"my-game\",\"framework\":\"godot\"}"
# 2. stage the build to s3.hanzo.ai under <org>/_stage/my-game/
# 3. promote it into an immutable content-addressed release + flip the pointer
curl -X POST https://api.hanzo.ai/v1/sites/my-game/publish -H "Authorization: Bearer $TOKEN" \
-H "X-Org-Id: $ORG" -H "Content-Type: application/json" -d "{\"source\":\"_stage/my-game\"}"
Fingerprint your asset names. The site server serves a content-hashed filename
immutable and everything else with a plain max-age. A redeploy that reuses the same
asset name leaves browsers and the CDN running the OLD loader against the NEW binary —
for a WASM app that is a silent, permanent hang with no error, not a visible failure.
License
MIT (this sandbox). three.js is MIT, (c) the three.js authors.