# План переноса оригинальной игры в браузер

## Разделить движок правила и оформление

Движок должен получать профиль правил и набор ресурсов через стабильные идентификаторы. Тогда одна и та же логика сможет работать с собственным оформлением, разрешёнными внешними материалами или локально подготовленными ресурсами установленной игры. Это также позволит сохранить требуемые пользователем редакторы карт и типов юнитов.

Профиль правил содержит объекты, численные параметры, требования и ссылки между ними. Набор графики содержит изображения, анимации, маски, точки привязки и звуковые события. Состояние партии содержит изменяемые объекты мира. Эти данные не следует объединять в один огромный объект с путями к файлам Windows.

## Последовательность работ

| Этап | Конкретный результат | Проверка готовности |
| --- | --- | --- |
| 1. Профиль Atlants | Собственная схема JSON поверх извлечённых таблиц, стабильные идентификаторы, единицы и известные флаги | Все ссылки корректны; служебные технологии и недоступные юниты классифицированы |
| 2. Статическая графика | Конвертер PCX, масок, тайлов и значков; манифест атласов | Контрольные кадры без розовых полей, неправильных теней и швов |
| 3. Анимации | Один полный юнит с восемью направлениями, несколькими действиями, цветом владельца и привязкой | При смене направления и действия положение не прыгает; нет лишнего кадра в цикле |
| 4. Полноценная модель карты | Отдельные слои местности, рельефа, рек, улучшений, ресурсов и видимости | Редактор корректно обновляет соседние переходы и сохраняет все слои |
| 5. Первый законченный игровой срез | Поселение, город, пища и рост, производство, одна ветка исследований, движение и бой | Воспроизводимые случаи сверяются с выбранной оригинальной игрой |
| 6. Основные экраны | Город, производство, дерево технологий, дипломатия, справка, настройки и сохранение | Для каждого действия описаны вход, состояние, результат и выход |
| 7. Расширение системы правил | Правительства, культура, торговая сеть, специальные действия, чудеса и способы победы | У каждой механики есть профиль, проверяемый пример и ограничения |
| 8. Редакторы и совместимость | Пользовательские карты и юниты на той же схеме, версионированный формат сохранений | Пользовательский набор проходит валидацию и не зависит от каталога оригинальной игры |

Переход к следующему этапу не требует предварительно переносить все 413 типов юнитов. Для проверки конвертации достаточно репрезентативного набора: обычный наземный юнит, всадник, корабль, летающий объект и армия с вариантами по эпохам. Поддержка всего состава добавляется после проверки модели данных и воспроизведения.

## Что использовать первым

Наибольшую непосредственную пользу дадут:

1. `conquests.biq` как эталон состава и параметров конкретного Atlants.
2. Pediaicons и INI как готовый индекс связей, экономящий ручное сопоставление тысяч файлов.
3. Листы местности и панели как исходные данные конвертера и опорная геометрия.
4. Встроенные правила сохранённой партии как проверка выбранного профиля.
5. Локальные описания, лицензии и авторские Readme как происхождение конкретных материалов.

Источники описаний форматов, включая OpenCiv3, полезны для проверки структуры. Их собственные лицензии относятся к их коду и не распространяются автоматически на файлы Civilization III. Заимствование внешнего кода, если понадобится, следует учитывать отдельно от переноса данных.

## Объём загрузки и память

Аудит основных типов, вариантов по эпохам и значков дал **4 255 уникальных прямых ресурсов**, суммарно **327 929 759 байт**: 1 858 FLC, 1 501 PCX, 646 WAV и 250 AMB. Это нижняя граница части набора, а не готовый полный комплект: сюда не включены внутренние зависимости AMB, вся местность, городские экраны, музыка, шрифты и видео.

Поэтому браузер не должен скачивать архив целиком перед первым ходом. Практический вариант — загружать интерфейс и видимую местность при старте, а анимации и справочные изображения по мере появления объектов. Подготовленные ресурсы кэшируются по хешу и версии набора. Атласы следует делить на страницы, особенно для длинных листов зданий и большого числа кадров.

Подробная оценка: [reference-footprint.json](data/reference-footprint.json). Она не включает размер после веб-конвертации: такой размер можно измерить только на реально подготовленном наборе.

## Что нужно реализовать заново

Таблица с силой атаки не определяет бой. Потребуются собственные расчёты раундов, здоровья, защиты, отступления, бомбардировки и специальных действий. Аналогично предстоит реализовать рост, труд горожан, очереди производства, округление экономики, исследования, торговлю, дипломатию, культуру, события и компьютерную стратегию.

Графические фоны не задают кликабельные области и логику окон. Веб-интерфейс должен поддерживать клавиатуру, подсказки, выбор объекта, отмену, очередь действий и разные размеры экрана. Редактор юнитов должен работать с флагами и действиями профиля, а не ограничиваться тремя числами атаки, защиты и движения.

## Проверки перед расширением

Для графики нужны контрольные изображения на нескольких типах местности, двух цветах владельца и всех направлениях выбранного юнита. Для правил — небольшие детерминированные примеры роста, производства, исследования и боя с зафиксированной случайностью. Для совместимости данных — повторяемый импорт с совпадающим хешем исходного профиля, проверкой ссылок и явным отчётом об исключениях.

Эти проверки относятся к следующему этапу реализации. Текущий результат — исследование, таблицы и инструменты извлечения; действующая игра в `dist/app.js` на новый движок не переводилась.
