188 lines
15 KiB
Markdown
188 lines
15 KiB
Markdown
# Текущий roadmap реализации Project Sacrifice
|
|
|
|
Этот документ описывает ближайшие работы относительно существующего vertical slice. Полный утверждённый GDD + TDD + production roadmap находится в [`DEVELOPMENT_PLAN.md`](DEVELOPMENT_PLAN.md).
|
|
|
|
Актуально на 18 августа 2026 года.
|
|
|
|
## 1. Текущее состояние
|
|
|
|
Проект находится на стадии проверенного vertical slice:
|
|
|
|
- реализованы 10 последовательных уровней;
|
|
- работают движение, прыжок и мобильное multitouch-управление;
|
|
- смерть не сбрасывает состояние уровня, тела остаются физическими объектами;
|
|
- реализованы шипы, пила, нажимные и временные кнопки, двери, движущиеся платформы, заморозка и электричество;
|
|
- сохраняются прогресс, лучшее время и минимальное число жертв;
|
|
- intended route всех уровней 1–10 защищён Android acceptance-ботами: каждый маршрут выполняется по три раза через production-ввод без прямого перемещения персонажа;
|
|
- blocker-softlock уровня 8 после истечения таймера устранён recovery relay и покрыт отдельным трёхкратным сценарием;
|
|
- исправлено перекрытие `FREEZER` уровня 6, которое повторно убивало игрока на frozen stepping stone;
|
|
- final integrated Android 16 matrix: 14/14 методов, 35 игровых выполнений и lifecycle-проверка; wall time `5:59`;
|
|
- финальный debug APK проверен на Android 16: установка, холодный запуск, ZIP-структура и v1/v2-подписи корректны.
|
|
|
|
Главный текущий риск: автоматическая проходимость доказана, но ручная понятность и баланс этапа 2 ещё не подтверждены. Отдельно остаются гипотезы об альтернативных решениях уровня 2 и обходе frozen corpse на уровне 10.
|
|
|
|
Performance-оговорка: критерий этапа 1 «полный прогон до 5 минут» пока не выполнен — финальный зелёный matrix занимает `5:59`. Сокращать количество трёхкратных прохождений или скрывать нестабильность retries запрещено; требуется отдельная оптимизация тестового runner.
|
|
|
|
## 2. Принципы разработки
|
|
|
|
1. Сначала acceptance-тест, затем исправление уровня.
|
|
2. Бот использует те же команды движения и прыжка, что и игрок, без прямого перемещения персонажа или подмены физики.
|
|
3. Новый контент не добавляется, пока текущие 10 уровней не проходят обязательный регрессионный набор.
|
|
4. Изменения физики проверяются на всех уровнях, потому что скорость, импульсы и коллизии являются общими.
|
|
5. Debug APK используется для внутренней проверки; внешняя альфа собирается отдельной release-подписью.
|
|
|
|
Оценки ниже указаны в рабочих днях для одного Android-разработчика при доступности дизайнера и QA на проверках. Это ориентиры, а не календарные обещания.
|
|
|
|
## 3. Этапы
|
|
|
|
### Этап 1. Боты проходимости для уровней 1–10 — P0, 4–6 дней
|
|
|
|
Задачи:
|
|
|
|
- выделить общий сценарный движок поверх существующего `LevelPlaytestBot.Driver`;
|
|
- добавить наблюдаемые состояния: положение и скорость игрока, опора, активные сигналы, состояние платформ и дверей;
|
|
- реализовать отдельный маршрут для каждого уровня;
|
|
- выдавать полезную диагностику таймаута: координаты, число смертей, тела, сигналы и последняя выполненная команда;
|
|
- запускать все сценарии одной Gradle-командой на эмуляторе;
|
|
- исключить случайные повторы как способ скрыть нестабильность.
|
|
|
|
Критерии завершения:
|
|
|
|
- уровни 1–10 проходят по три последовательных запуска;
|
|
- каждый сценарий использует предусмотренную механику уровня;
|
|
- один полный прогон укладывается в 5 минут;
|
|
- падение теста показывает этап и состояние, на котором бот остановился.
|
|
|
|
### Этап 2. Исправление уровней и баланс — P0, 4–7 дней
|
|
|
|
Задачи:
|
|
|
|
- исправить найденные ботами тупики и нестабильные взаимодействия;
|
|
- увеличить допуски у прыжков и зон срабатывания, не убирая смысл головоломок;
|
|
- проверить, что тела не выталкиваются с плит и не застревают в дверях;
|
|
- выровнять кривую сложности: знакомство, закрепление, комбинация механик;
|
|
- уточнить подсказки и целевые показатели времени/жертв;
|
|
- провести минимум две ручные сессии на каждом уровне.
|
|
|
|
Критерии завершения:
|
|
|
|
- `10/10 passed` в автоматическом прогоне;
|
|
- каждый уровень впервые понимается тестировщиком не более чем за три попытки либо содержит достаточную подсказку;
|
|
- restart всегда возвращает чистое начальное состояние;
|
|
- после смерти невозможно потерять обязательный объект без возможности перезапуска.
|
|
|
|
### Этап 3. Управление, интерфейс и доступность — P1, 3–5 дней
|
|
|
|
Задачи:
|
|
|
|
- добавить настройку размера и прозрачности экранных кнопок;
|
|
- улучшить зоны multitouch и визуальную обратную связь на нажатия;
|
|
- добавить короткое обучение без блокирующих длинных окон;
|
|
- доработать экран завершения: время, жертвы, лучший результат и следующая цель;
|
|
- локализовать интерфейс и подсказки на русский и английский;
|
|
- проверить контраст, масштаб текста, вибрацию и режим без вибрации;
|
|
- корректно обрабатывать pause/resume и системную кнопку Back.
|
|
|
|
Критерии завершения:
|
|
|
|
- игра полностью управляется на телефоне без внешней клавиатуры;
|
|
- элементы управления не перекрывают игровую информацию на поддерживаемых экранах;
|
|
- смена языка и настроек не сбрасывает прогресс;
|
|
- UI проверен минимум на форматах 16:9, 20:9 и планшете.
|
|
|
|
### Этап 4. Контентная архитектура и инструменты — P1, 5–8 дней
|
|
|
|
Задачи:
|
|
|
|
- перенести описания уровней из Java-констант в валидируемый JSON-формат;
|
|
- добавить загрузчик с проверкой геометрии, сигналов и обязательных объектов;
|
|
- создать простой desktop-скрипт предпросмотра или экспортёр координат;
|
|
- закрепить версию физики и формата уровня;
|
|
- сохранять воспроизводимый журнал команд бота для расследования регрессий.
|
|
|
|
Критерии завершения:
|
|
|
|
- геометрию и подсказки уровня можно изменить без перекомпиляции игрового кода;
|
|
- некорректный сигнал, дверь или объект отклоняется валидатором при сборке;
|
|
- все существующие уровни после миграции проходят тех же ботов.
|
|
|
|
### Этап 5. Художественная и звуковая альфа — P1, 8–15 дней
|
|
|
|
Задачи:
|
|
|
|
- утвердить самостоятельный визуальный стиль, не копирующий коммерческий референс;
|
|
- заменить prototype-графику персонажа, опасностей, окружения и интерфейса;
|
|
- добавить анимации движения, смерти, respawn и реакции механизмов;
|
|
- добавить звуки управления, механизмов, результата и фоновую музыку;
|
|
- предусмотреть независимые настройки музыки, эффектов и вибрации;
|
|
- оптимизировать ресурсы для Android.
|
|
|
|
Критерии завершения:
|
|
|
|
- все игровые состояния визуально различимы без чтения внутренней логики;
|
|
- звук не является единственным источником обязательной информации;
|
|
- проект сохраняет стабильную частоту кадров на целевых устройствах.
|
|
|
|
### Этап 6. Техническая стабилизация — P0 перед внешней альфой, 4–7 дней
|
|
|
|
Задачи:
|
|
|
|
- проверить Android 8–16 и устройства с 2–4 ГБ памяти;
|
|
- измерить frame time, память, запуск и размер APK;
|
|
- протестировать сворачивание, возврат, блокировку экрана и уничтожение Activity;
|
|
- добавить журналирование необработанных ошибок без персональных данных;
|
|
- проверить обновление приложения поверх предыдущей версии и сохранность прогресса;
|
|
- подготовить release build, отдельный application ID для тестового канала и закрыто хранимый keystore;
|
|
- сформировать APK для прямой установки и AAB для Google Play Internal Testing.
|
|
|
|
Критерии завершения:
|
|
|
|
- нет блокирующих падений, ANR и потери прогресса;
|
|
- 95-й перцентиль кадра соответствует целевым 60 FPS либо документированному минимуму 30 FPS на слабых устройствах;
|
|
- release APK/AAB подписан, устанавливается и запускается на чистом устройстве;
|
|
- debug-инструменты не попадают в публичную конфигурацию без необходимости.
|
|
|
|
### Этап 7. Закрытая альфа — 1–2 итерации по 5–7 дней
|
|
|
|
Задачи:
|
|
|
|
- привлечь 20–30 тестировщиков разного игрового опыта;
|
|
- собирать по каждому уровню время, число смертей, restart и точку выхода;
|
|
- разделять дефекты на блокирующие, значимые и косметические;
|
|
- повторно проверять исправления ботами и ручным smoke-тестом;
|
|
- определить уровни с высоким процентом выхода или неверно понятой механикой.
|
|
|
|
Критерии завершения:
|
|
|
|
- 90% тестировщиков завершают уровни 1–5 без помощи разработчика;
|
|
- 70% завершают все 10 уровней;
|
|
- отсутствуют открытые блокирующие дефекты;
|
|
- все значимые дефекты имеют решение или явно принятое продуктовое решение.
|
|
|
|
## 4. Обязательный набор проверок каждого APK
|
|
|
|
Перед передачей тестировщикам должны выполняться:
|
|
|
|
1. `testDebugUnitTest` — математика, каталог и валидация уровней;
|
|
2. `lintDebug` — Android Lint без ошибок;
|
|
3. `connectedDebugAndroidTest` — боты уровней 1–10;
|
|
4. проверка APK через `unzip -t`;
|
|
5. проверка package/version через `aapt2 dump badging`;
|
|
6. проверка подписи через `apksigner verify`;
|
|
7. установка поверх предыдущего билда и на чистое устройство;
|
|
8. холодный запуск и проверка crash-буфера;
|
|
9. ручной smoke-тест уровня 1 и одного сложного комбинированного уровня.
|
|
|
|
## 5. Текущая итерация
|
|
|
|
Этап 1 завершён автоматическим доказательством intended route уровней 1–10. Текущая итерация ограничивается этапом 2:
|
|
|
|
- выполнить полный integrated `10/10 passed` перед каждым APK;
|
|
- провести по две ручные сессии каждого уровня и зафиксировать попытки, restart и непонятные места;
|
|
- скорректировать допуски прыжков и подсказки только по наблюдаемым проблемам;
|
|
- проверить чистый restart из ключевых промежуточных состояний;
|
|
- закрыть или документировать гипотезы альтернативных решений уровней 2 и 10;
|
|
- не добавлять уровень 11 и новые механики до завершения критериев этапа 2.
|
|
|
|
Результатом итерации должны стать обновлённый исходный проект, проверенный APK, integrated bot report и протокол ручных игровых сессий.
|