31 lines
3.5 KiB
Markdown
31 lines
3.5 KiB
Markdown
# Original requirements
|
||
|
||
Source: the [“Dynamic resource allocation” conversation](https://chatgpt.com/share/6aa7eba7-d0e8-83ed-804a-818e7d94cef5), 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.
|