shacraft-core/docs/REQUIREMENTS.md

Original requirements

Source: the “Dynamic resource allocation” conversation, read in full by scrolling on September 14, 2026, and its continuation in Codex. This document preserves the requirements; it does not validate the implementation from the previous environment.

Project motivation

Shacraft runs two servers on a machine with 8 GB of RAM: survival on NeoForge (about 300 mods, including Create) and minigames on Paper 26.2. Research into dynamic memory allocation led to a standalone voxel engine project. Porting existing NeoForge mods is not a requirement for the first version.

Required capabilities

• An independent open-source Rust core with its own architecture. Low-level libraries are allowed; an existing game engine must not form the foundation.
• Server RAM is the main measured criterion. Rust, suspended ticks, or bit-packed palettes alone must not be presented as proof of savings relative to Minecraft.
• Separate core, test server, test client, and a dedicated MCP implementation. The core must not depend on graphics, sockets, MCP, or the launcher.
• Shared immutable maps, independent changes for each instance, unloading of inactive state, and limits on caches, queues, and history. One process serves multiple worlds/arenas.
• The complete base catalog of Minecraft Java 26.2 blocks, states, and entity types. Shapes, collisions, and persistent properties are required. Catalog completeness and mechanical accuracy are checked separately; full vanilla simulation was not agreed as a mandatory first implementation.
• Import from Minecraft to Shacraft and export back from Shacraft to Minecraft. The main output is a world; .schem is an additional format for builds. Unknown data must be preserved or explicitly reported; silent loss is unacceptable.
• A unified extension model: shared definitions, server and client logic, textures, sounds, and shaders in a single package format. The server declares the required set; the client downloads missing resources, checks versions and hashes, and uses a cache. Server secrets and code containing secrets must not be distributed to clients.
• A policy for permitted client modifications. The server validates actions and package compatibility. A checksum reported by the client itself does not prove that the client is unmodified.
• Future support for launching through Shacraft Launcher. The existing infrastructure is an integration target, not a core dependency.
• Original Minecraft textures, sounds, and models must not be included in distributed files. Content licenses must be tracked separately from the code license.

A capable MCP implementation

Minecraft Builder MCP is a source of experience, not a server to rename. The project needs its own tools for inspection and search, batch construction, entities and arenas, visual verification, and diagnostics. Foundations: a shared Control API, expected revisions, operation identifiers, conflict-safe undo, bounded responses, on-disk history, load limits, and authorization.

What counts as evidence

The previous conversation claimed 1,196 blocks, 158 entity types, seven tests, and a partial implementation. These figures must be checked again against sources and local results. They must not be carried into a new report as established facts.

The wish to use “2–4 times less RAM” was discussed as a possible target, not an achieved result. Comparisons must use the same maps, loaded regions, players, and mechanics, accounting for the entire process and all required services.