Files
shacraft-core/docs/PLAN.md
T

11 KiB
Raw Blame History

План разработки

План составлен до реализации. Каждый этап заканчивается воспроизводимым результатом в локальном репозитории. docs/STATUS.md обновляется после проверок. Пункт не считается выполненным по наличию интерфейса, заглушки, каталога имён или успешной компиляции.

Этап 0. Сохранить контекст и проверить проектирование

  • Записать исходные требования, решения, контракты и критерии приёмки.
  • Зафиксировать источники данных совместимости и ограничения лицензий.
  • Разделить компоненты так, чтобы можно было независимо разрабатывать хранение, совместимость, сетевой сервер и клиент.
  • Согласовать обработку ошибок, координаты, ревизии, ограничения операций и формат диагностики.

Выход: документы в docs/; список решений без молчаливого сокращения объёма.

Этап 1. Ядро и доказуемое управление памятью

  • Rust workspace; координаты с корректными отрицательными значениями; реестр канонических состояний блоков.
  • Секции 16×16×16: единообразное состояние или палитра и упакованные индексы. Отсутствие отдельного объекта на каждый блок.
  • Собственный версионированный формат хранения, ограниченный кэш, выгрузка на диск; операции чтения не изменяют мир.
  • Независимые экземпляры общей карты. Изменение/сброс одного экземпляра не влияет на другие; снимок основы имеет чёткую семантику.
  • Атомарные правки с журналом восстановления, ревизиями и идемпотентностью. История и undo хранятся на диске с ограниченным потреблением RAM.
  • Проверки границ секций, упаковки, изоляции миров, повторов, конфликтов, сохранения и восстановления после сбоя. Измерение хранения общей карты против копий.

Выход: самостоятельная библиотека и воспроизводимые тесты/измерения. Это ещё не весь MVP.

Этап 2. Сервер и минимальный клиент — сквозной сценарий

  • Сервер владеет миром и симуляцией; фиксированный тик, серверные движение/столкновения и проверка взаимодействий.
  • Версионированный протокол: подключение, начальный снимок, изменения блоков, игроки, переход между мирами, ошибки и восстановление подключения.
  • Лимиты числа игроков, радиуса мира, сообщений, частоты действий и очередей. Медленный клиент не увеличивает память сервера без ограничения.
  • Тестовый клиент: собственный рендерер, камера, управление, блоки, простые сущности, состояния соединения. Сервер остаётся без графики.
  • Два независимых клиента видят одинаковые изменения. Перезапуск сохраняет мир. Подключение и выход не оставляют сущности и фоновые задачи.

Выход: запускаемая локальная сетевая песочница. На первом проходе допустим небольшой набор материалов; это не выполнение требования полного каталога.

Этап 3. Control API и собственный MCP

  • Общий API чтения, редактирования, истории и диагностики; MCP — отдельный процесс с stdio.
  • Поиск материалов, чтение ограниченной области, пакетное строительство и шаблоны, preview/commit, undo с защитой от чужих изменений.
  • Ресурсы с системой координат и возможностями; структурированные ответы и понятные ошибки.
  • Визуальная обратная связь: снимок с явно указанными типом отображения и ревизией; топографический preview не объявляется снимком игрового клиента.
  • Тестовые миры, сущности, управление аренами и метрики. Авторизация управляющего API; токен не попадает в клиентский код и журнал.
  • Реальная MCP-сессия: initialize → list → build → inspect/capture → undo; параллельный клиент видит результат.

Выход: законченный цикл автоматизированного строительства с проверкой результата.

Этап 4. Контент и двусторонняя совместимость

  • Проверить полный источник каталога именно Java 26.2; генерировать воспроизводимо, хранить происхождение и версию данных.
  • Реализовать формы, коллизии и отображение семейств блоков; отдельно учитывать неподдерживаемые особенности. Базовые определения сущностей и сохраняемые свойства.
  • Импорт Anvil/NBT по частям с ограниченным бюджетом памяти; обработка измерений и дополнительного NBT.
  • Экспорт мира в целевую версию; режим точности и явных замен, sidecar для неподдерживаемых данных, корректное инвалидирование происхождения после правок.
  • .schem import/export; тестовые fixtures; повторное открытие экспортированных данных независимым читателем и, при доступности целевой игры, самой игрой.

Выход: проверенный обмен заявленными данными с отчётом покрытия. Полный каталог имён без форм/данных не закрывает этот этап.

Этап 5. Единые пакеты и законченная миниигра

  • Версионированный манифест с зависимостями, клиентскими/серверными частями, размерами, хешами, лицензиями и возможностями.
  • Небольшой собственный базовый набор ассетов. Проверяемая загрузка клиентских ресурсов и кэш; обязательные ресурсы отделены от необязательного качества.
  • Первое расширение через единый формат, работающий клиентский и серверный сценарий. Декларативная конфигурация не называется полноценной средой произвольных модулей.
  • Spleef: ожидание → отсчёт → игра → выбывание → победитель → сброс. Несколько независимых арен используют общую карту.
  • Повторные матчи, отключения, вход во время игры, переход в лобби, сохранение настроек после перезапуска.

Выход: друзья могут сыграть законченный матч, а другой разработчик — добавить документированное расширение.

Этап 6. Приёмка, измерения и поставка

  • Проверить все критерии ACCEPTANCE.md; отдельный список фактического покрытия и ограничений.
  • Измерить RSS/пик памяти, хранение секций, кэши, сетевые очереди, p95/p99 тика, поведение после многократных матчей и перезапуска.
  • Сравнение с Paper проводить только при доступном сопоставимом стенде. До этого публиковать собственные числа без заявлений о кратности выигрыша.
  • Инструкции запуска, конфигурация MCP, описание API/формата пакетов, лицензии, контрольная сумма исходного архива, Git-коммит.
  • Продакшен-публикация и изменение лаунчера — отдельная интеграционная работа после локальной проверки.

Выход: воспроизводимый локальный релиз MVP с честным отчётом, исходным архивом и известными ограничениями.

Рабочий порядок после планирования

Сначала этап 1. Параллельно с ним можно готовить протокол и клиент по согласованному контракту, изучать каталог/конвертер. Подключение этих частей, изменения общих интерфейсов и проверки выполняются последовательно. После каждого этапа — сохранить результат; не оставлять единственную копию в одноразовой среде.