shacraft-core/docs/STATUS.md

Project status

Updated 2026-09-17. The agreed local MVP profile is implemented and verified. The original plan was committed before implementation as ddfcef2; claims from the previous cloud environment were not used as evidence. The earlier published baseline is commit b6ba064 at emil28092005/shacraft-core, whose GitHub Actions run passed. The current implementation adds shared Rust/WASM movement, block lighting, worker meshing, procedural worlds, movement diagnostics, atlas texture packs, and full-height streaming at up to 64 chunks of render distance. The README includes an in-game screenshot of an imported minigames lobby.

Implemented

• Independent Rust core: compact sections, a bounded shared LRU, durable edits and history, immutable snapshots, independent worlds, revisions/idempotency, undo, and reset.
• Separate authoritative server with a 20 Hz game loop, movement/shape/reach validation, bounded queues, and persistent settings and entities.
• Custom browser WebGL2 client: building, a catalog, players/entities, chat, worlds, package downloads, and diagnostics. It does not depend on an existing game engine. The MVP interface currently uses Russian text; repository documentation is in English.
• Separate stdio MCP server: 17 tools, 4 resources, a building prompt, plans/commit, PNG previews, and verification through an independent MCP SDK.
• Complete Java 26.2 catalog: 1,196 blocks, 32,366 states, 158 entity types, DataVersion 4903. Collision shapes are measured through the source API, rendering templates are independently authored, and contextual cases are marked.
• Packages: exact versions, dependency graphs, SHA-256 hashes/sizes, private server files, and a verified client cache. Working WASM on_jump, custom block definitions, and original textures/shader/audio.
• Spleef: two independent arenas sharing a map, countdown, elimination, winner/draw, reset, spectators, persistent rules, and recovery after interruption. A lobby and a gallery of 1,197 samples.
• Anvil and Sponge v3 import/export: typed NBT, original preservation, atomic output publication, loss/conversion reports, and transfer of block and entity edits made in Shacraft.

Current checks

On 2026-09-17, bash scripts/verify.sh passed formatting, a physics WASM rebuild, workspace Clippy with warnings denied, 130 Rust tests, 190 JavaScript tests, storage crash recovery, and real HTTP/WebSocket scenarios for gameplay, chunk transitions, and movement prediction. Native and WASM movement agreed within the test tolerance. The browser also accepted the 64-chunk, full-height view, built all 27 nearest sections, and continued loading distant terrain. These checks do not establish a performance guarantee at the maximum distance.

Verified baseline

84 Rust tests, 6 JavaScript tests, formatting, and Clippy without warnings; 14 groups of real HTTP/WebSocket scenarios, a separate MCP SDK session, SIGKILL, and recovery. Exports were read by the official Java 26.2 codecs and an independent NBT reader. The client was inspected in a real browser: rendering, state search, gallery navigation, material loading, reconnection, and resource caching were confirmed.

Final release benchmark: 100 idle map instances used 50.50 MiB RSS; 10 moving clients reached a maximum of 59.65 MiB RSS/VmHWM, with sampled tick-work p95 of 7.33–9.54 ms. This is a bounded local profile, not a comparison with Paper. Commands and evidence are in VERIFICATION.

Exact boundaries

• This is an independent minigame platform with a Minecraft catalog, not a complete vanilla simulation: no full AI, redstone, inventories, or fluid simulation. Context-dependent shapes are marked; models do not reproduce the vanilla assets.
• exact conservatively refuses export after edits; best-effort reflects changes and produces a report. Anvil and .schem conversion does not translate all biome/block-entity semantics; source data is archived. Version, size, and context limits are documented in interop.md.
• Block history is stored on disk without automatic deletion. Undo accepts only the current target edit. Preview plans are ephemeral and expire after five minutes. Entity/rule metadata has its own revision; its API does not claim the core's idempotency journal.
• Procedural gameplay uses double precision through ±29,999,872 with Y=−64…319 building layers. The menu selects a visible radius of 2–64 chunks, default 3. Including a preloaded ring, the default data window is 144×384×144; the maximum is 2,096×384×2,096. The full world height remains loaded during vertical flight. Horizontal unload hysteresis retains overlap across single chunk crossings. Nearby terrain uses local lighting in an independent worker; distant data and meshes load progressively. Uniform sections stay compact, but large views still incur substantial loading time and memory costs. Distant-terrain LOD is not implemented, and there is no single hard RSS cap. See current world implementation and local measurements.
• Linux x86_64 and local workloads have been tested. A long production soak, power-loss testing, all operating systems, and an exported-world playtest in a running Minecraft game have not been claimed as passed.
• Launcher integration, accounts, production deployment, and existing servers are future integration work. The source repository is public; the game server has not been deployed to a remote machine.

Component contracts: SERVER, MCP, CONTENT, PACKAGES, and interop. scripts/make_release.py packages source and release binaries. Archives exclude tokens, local runtime worlds, and the Minecraft JAR.