# GDD + TDD + Production Roadmap Это основной утверждённый план разработки Project Sacrifice. Текст ниже сохранён из предоставленного владельцем проекта документа. Ниже — план, который можно передать команде как основу **GDD + TDD + production roadmap**. В качестве референса берём основную формулу *Life Goes On: Done to Death*: комедийный puzzle-platformer, где смерть персонажа является частью решения, а оставшиеся тела используются как физические объекты — например, для перекрытия шипов, нажатия кнопок, создания ступеней и взаимодействия с механизмами. Оригинальная игра также строится вокруг коротких самостоятельных уровней и постепенно вводит новые способы использования погибших персонажей. Если у проекта **нет лицензии правообладателя**, не следует буквально воспроизводить название, персонажей, графику, музыку, тексты, конкретную геометрию уровней или последовательность головоломок *Life Goes On*. План ниже поэтому рассчитан на **максимально близкий по механической формуле, но самостоятельный Android-проект**. Если права на оригинал у команды есть, те же технические блоки можно использовать уже для полноценного портирования. # 1. Концепция проекта **Рабочее название:** Project Sacrifice. **Жанр:** 2D/2.5D physics puzzle-platformer. **Платформа первой версии:** Android. **Ориентация:** landscape. **Основная игровая сессия:** 1–5 минут на уровень. **Основная идея:** игрок управляет последовательностью персонажей. Смерть не означает поражение. После смерти персонаж остаётся в игровом мире и становится частью головоломки. Следующий персонаж появляется в точке спавна и может использовать тело предыдущего. Главный цикл: **изучить уровень → понять требуемую цепочку действий → пожертвовать персонажем → изменить состояние уровня → вызвать следующего → пройти дальше → добраться до цели.** Важное дизайнерское правило: игрок должен перестать воспринимать смерть как наказание. Основной ресурс головоломки — не здоровье, а **количество и положение предыдущих персонажей**. --- # 2. Целевая структура продукта Релизную версию разумно проектировать на: - 4 тематических мира; - 12–18 основных уровней на мир; - 3–5 дополнительных challenge-уровней; - 55–70 уровней суммарно; - 4 финальных уровня/испытания; - 8–12 основных игровых механик; - 20–30 типов интерактивных объектов; - 30+ косметических элементов персонажей; - систему дополнительных целей; - локальное сохранение; - достижения; - настройки графики, звука и управления. Для первой production-версии не нужно сразу делать весь объём. Сначала команда должна доказать жизнеспособность механики на **vertical slice из 8–10 уровней**. --- # 3. Главный персонаж Персонаж должен иметь минимальный набор действий: **Movement** - движение влево; - движение вправо; - остановка; - разворот. **Platforming** - прыжок; - падение; - приземление; - движение по наклонной поверхности; - взаимодействие с движущейся платформой. Не стоит добавлять атаку, сложный инвентарь или комбинации кнопок: фокус должен оставаться на головоломке. ### Состояния персонажа State machine: ```text Spawn ↓ Idle ├── Run ├── Jump │ └── Fall ├── Interact ├── Stunned └── Death ↓ Corpse ``` После `Death` живой контроллер отключается и объект переходит в физическое состояние `Corpse`. --- # 4. Ключевая система — смерть Это центральная техническая система проекта. Каждый персонаж должен состоять из двух логических сущностей: ```text LivingCharacter CorpseEntity ``` При смерти: ```text Damage received → определить DeathType → заблокировать управление → запустить death animation → создать/активировать физическое тело → перенести позицию/импульс → зарегистрировать тело в CorpseManager → через задержку породить нового персонажа ``` Новый персонаж появляется, **не уничтожая старое тело**. --- # 5. Типы смерти Система должна работать через универсальный интерфейс. Например: ```csharp public interface IKillSource { DeathType DeathType { get; } void Kill(Character character); } ``` `DeathType`: ```text Spike Saw Crush Fire Electricity Freeze Pit Projectile Explosion Generic ``` Каждый тип смерти может определять: - анимацию; - звук; - импульс; - физическое состояние тела; - возможность дальнейшего использования тела. --- # 6. Corpse System Главное требование: тело погибшего персонажа является полноценным элементом головоломки. У тела должны быть: ```text Position Rotation Velocity Mass Collider CorpseType DeathType FrozenState ConductiveState BurningState IsPinned IsDestroyed ``` ### Возможные состояния **Normal corpse** Обычный физический объект. **Pinned corpse** Прибит к поверхности ловушкой. **Frozen corpse** Превращается в твёрдый блок. **Electrified corpse** Может проводить электричество. **Burned corpse** Больше не активирует некоторые механизмы. **Crushed corpse** Меняет размеры коллайдера. Это позволит создавать комбинационные головоломки. --- # 7. Corpse Manager Отдельная глобальная система на уровне. Ответственность: ```text CorpseManager ├── RegisterCorpse() ├── RemoveCorpse() ├── FreezeCorpse() ├── DestroyCorpse() ├── GetCorpseCount() ├── ResetLevel() └── SerializeState() ``` Необходимо заранее установить лимит одновременно существующих ragdoll/physics-объектов. Для Android важно не оставлять десятки тяжёлых физических объектов с постоянным расчётом. После полной остановки тело можно переводить: ```text Dynamic Rigidbody → Sleeping Rigidbody → Static-like optimized state ``` При внешнем воздействии оно снова активируется. --- # 8. Система спавна На каждом уровне находится `SpawnPoint`. Последовательность: ```text Knight dies ↓ Death registered ↓ 0.2–0.8 sec feedback ↓ Spawn animation ↓ new character becomes controllable ``` Уровень **не перезагружается после смерти**. Полный restart происходит только: - по кнопке игрока; - при softlock; - при необратимо неправильном состоянии головоломки; - после выбора Restart. --- # 9. Определение softlock Это важная система для такого жанра. Игрок может физически привести уровень в нерешаемое состояние. Поэтому UI должен всегда содержать: **Restart level.** Дополнительно можно создать систему: ```text PuzzleStateValidator ``` которая определяет очевидные невозможные состояния и предлагает: > Решение стало невозможным. Перезапустить уровень? Автоматический restart лучше не делать — игрок может использовать неожиданное решение. --- # 10. Базовые препятствия Первый набор: ### Spikes Убивают персонажа. Тело остаётся лежать/висеть на шипах. Несколько тел постепенно создают безопасный проход. ### Circular Saw Убивает или отбрасывает персонажа. Используется для перемещения тела в другую часть уровня. ### Crusher Раздавливает объект между двумя поверхностями. Может создавать низкий объект, пригодный как платформа. ### Fire Уничтожает живого персонажа. Может менять свойства тела. ### Electricity Убивает живого персонажа. Через тело может активироваться электрическая цепь. ### Ice Замораживает персонажа или тело. Frozen corpse становится стабильной платформой. ### Pit Мгновенная смерть/потеря тела. Используется как отрицательное пространство. --- # 11. Кнопки и переключатели Нужны минимум три типа. ### Pressure Plate Активна, пока на ней присутствует достаточная масса. Работают: - живой персонаж; - тело; - физический объект. ### Toggle Switch При нажатии меняет состояние: ```text ON ↔ OFF ``` ### Timed Switch После активации запускает таймер. Например: ```text Switch activated → Door opens → 4 seconds → Door closes ``` --- # 12. Двери и ворота Универсальный компонент: ```text DoorController ``` Состояния: ```text Closed Opening Open Closing Locked ``` Door должен получать сигналы через event-систему, а не иметь прямые ссылки на конкретную кнопку. Например: ```text PressurePlate ↓ PuzzleEventChannel ↓ DoorController ``` Так level designer сможет быстро собирать головоломки. --- # 13. Moving Platforms Платформы должны поддерживать: - циклическое движение; - движение A→B; - multiple waypoints; - activation by switch; - остановку; - изменение направления; - изменение скорости. Персонаж и тела должны корректно перемещаться вместе с платформой. --- # 14. Физические объекты Помимо тел: ```text Box Rock Ball IceBlock Counterweight ExplosiveObject ``` Все должны реализовывать общий интерфейс массы/активации: ```csharp IWeightedObject ``` Это позволит pressure plate не знать, стоит на ней тело, ящик или персонаж. --- # 15. Система физики Ключевая цель — **предсказуемость**, а не реализм. Для puzzle-game одинаковое действие должно давать практически одинаковый результат. Нужно избегать чрезмерно свободного ragdoll. Лучше использовать: **гибридную модель.** При смерти: 1. проигрывается контролируемая animation; 2. задаётся предсказуемый импульс; 3. тело переходит в ограниченную physics simulation; 4. после остановки фиксируется. Это значительно уменьшит случайные провалы головоломок. --- # 16. Управление Android Базовая схема: ```text [ ← ] [ → ] [ Jump ] ``` Вариант 2: ```text Virtual joystick Jump ``` Для такого жанра предпочтительнее отдельные кнопки направления — они точнее. Дополнительные элементы: ```text Restart Pause ``` Не следует размещать больше 4–5 интерактивных зон на основном HUD. --- # 17. Требования к мобильному управлению Обязательно: - multitouch; - возможность держать направление и одновременно прыгать; - регулируемый размер кнопок; - configurable opacity; - вибрационная обратная связь; - dead zone; - защита от случайных повторных прыжков. Добавить: ```text InputBuffer = ~100–150 ms CoyoteTime = ~80–150 ms ``` Значения должны быть вынесены в конфиг, а не захардкожены. --- # 18. Камера Основной тип: **side-view tracking camera.** Функции: ```text Follow character Look ahead Vertical damping Camera bounds Room transitions Camera shake Focus target ``` Камера не должна напрямую повторять каждый пиксель движения персонажа. Добавить look-ahead: ```text character runs right → camera shifts slightly right ``` чтобы игрок видел будущую часть уровня. --- # 19. Устройство уровня Каждый уровень содержит: ```text LevelRoot ├── SpawnPoint ├── Goal ├── StaticGeometry ├── Hazards ├── PuzzleObjects ├── MovingPlatforms ├── Triggers ├── CameraBounds ├── Decorations └── LevelController ``` --- # 20. Level Controller Хранит: ```text LevelID WorldID TargetDeaths TargetTime Collectible SpawnPosition CurrentDeaths CurrentTime PuzzleState CompletionState ``` Отвечает за: ```text Start Restart Complete Pause Checkpoint Statistics ``` --- # 21. Завершение уровня Игрок должен добраться до финального объекта. Например: ```text Goal / Artifact / Portal / Crown / Relic ``` После контакта: ```text Character reaches Goal ↓ disable controls ↓ completion animation ↓ calculate result ↓ save progress ↓ result screen ``` --- # 22. Дополнительные цели Для replayability на каждом уровне можно использовать три испытания. Например: **Casualty target** ```text Complete with ≤ 5 deaths ``` **Time target** ```text Complete in ≤ 45 sec ``` **Optional collectible** Найти скрытый объект. Результат: ```text ✓ Level complete ★ Low casualties ★ Fast completion ★ Collectible ``` Главное — количество смертей не должно восприниматься как «очки здоровья». Это показатель эффективности решения. --- # 23. Прогрессия механик Не вводить несколько новых элементов одновременно. Пример: ### World 1 — Foundations 1. movement; 2. jump; 3. death; 4. corpse platform; 5. spikes; 6. pressure plate; 7. doors; 8. moving platforms. ### World 2 — Physics Вводятся: - saw; - pushable objects; - launch mechanics; - crusher; - moving hazards. ### World 3 — States Вводятся: - ice; - electricity; - timed mechanisms; - corpse state transformations. ### World 4 — Mastery Комбинируются: ```text body positioning + timing + electricity + ice + moving platforms + multiple switches ``` Новые механики почти не вводятся — проверяется владение уже изученными. --- # 24. Формула дизайна уровня Для каждого уровня дизайнер сначала пишет **solution graph**. Например: ```text Goal inaccessible ↓ Door must open ↓ Pressure Plate must remain active ↓ Character cannot stay on plate ↓ Need corpse on plate ↓ Need to die while positioned above plate ↓ Use saw to launch corpse ↓ Door opens ↓ Next character reaches goal ``` Только после этого строится геометрия. Так команда избегает уровней, представляющих собой просто набор случайных ловушек. --- # 25. Design Bible для головоломок Для каждого интерактивного объекта создать таблицу: | Объект | Убивает | Двигает тело | Меняет тело | Активирует механизм | |---|---:|---:|---:|---:| | Spike | Да | Нет | Иногда | Нет | | Saw | Да | Да | Нет | Нет | | Ice | Возможно | Нет | Да | Нет | | Electricity | Да | Нет | Да | Да | | Pressure plate | Нет | Нет | Нет | Да | Затем level designer проектирует комбинации механик. --- # 26. Художественное направление Не копировать оригинальную визуальную идентичность. Рекомендуемая формула: **stylized medieval / fantasy slapstick.** Визуально смерть должна быть смешной, а не жестокой. Избегать: - реалистичной крови; - расчленения; - натуралистичных повреждений. Использовать: - exaggerated animation; - squash & stretch; - particles; - комические звуки; - лёгкую физику; - визуальные реакции персонажа. Это также существенно облегчает возрастное позиционирование мобильной игры. --- # 27. Персонажи Создать модульную систему: ```text Character ├── Body ├── Helmet ├── Face ├── Weapon ├── Cape └── Accessory ``` Каждый новый персонаж может получать случайную комбинацию. Например: ```text Name = random Helmet = random Cape = random Accessory = random ``` Так очередная жертва визуально ощущается новым персонажем без необходимости создавать сотни моделей. --- # 28. Анимации Минимальный набор: ```text Idle Run JumpStart JumpLoop Fall Land Turn Fear Celebrate Spawn DeathGeneric DeathSpike DeathElectric DeathFire Freeze Crush GoalInteraction ``` --- # 29. Sound Design Отдельные категории: ```text Movement Environment Puzzle mechanisms Deaths UI Music Voice reactions ``` Смерти требуют нескольких вариантов каждого звука, иначе повторение станет раздражать. Например: ```text DeathVoice_01 DeathVoice_02 ... DeathVoice_12 ``` Выбор должен исключать немедленное повторение предыдущего клипа. --- # 30. Музыка Не нужна отдельная композиция на каждый уровень. Оптимально: ```text World 1 track World 2 track World 3 track World 4 track Finale Menu ``` Каждый игровой трек должен иметь длинный ненавязчивый loop. --- # 31. UI Основные экраны: ```text Splash Main Menu World Select Level Select Gameplay Pause Level Complete Settings Statistics Credits ``` Gameplay HUD: ```text Deaths: 4 Timer: 00:42 Restart Pause ``` Не перегружать HUD дополнительными кнопками. --- # 32. Главное меню ```text Continue Play Settings Achievements Credits ``` После первого запуска `Continue` скрывается. --- # 33. Level Select Представление: ```text World ├─ 01 ★★★ ├─ 02 ★★☆ ├─ 03 ★★★ └─ 04 🔒 ``` Игрок сразу видит: - завершён ли уровень; - выполнены ли challenges; - найден ли collectible. --- # 34. Save System Хранить: ```json { "saveVersion": 1, "currentWorld": 2, "levels": { "1_01": { "completed": true, "bestDeaths": 3, "bestTimeMs": 34100, "collectible": true } } } ``` Обязательно добавить `saveVersion`, чтобы будущие обновления могли выполнять миграцию сохранений. --- # 35. Архитектура проекта Для Unity-подобной архитектуры: ```text Assets/ ├── Art/ ├── Audio/ ├── Animations/ ├── Materials/ ├── Prefabs/ │ ├── Characters/ │ ├── Hazards/ │ ├── Puzzle/ │ └── UI/ ├── Scenes/ │ ├── Boot │ ├── MainMenu │ └── Levels/ ├── Scripts/ │ ├── Core/ │ ├── Character/ │ ├── Physics/ │ ├── Puzzle/ │ ├── Level/ │ ├── UI/ │ ├── Audio/ │ └── Save/ └── Data/ ``` --- # 36. Основные программные модули ```text GameManager LevelManager CharacterController CharacterSpawner DeathSystem CorpseManager PuzzleSystem CameraController InputManager AudioManager SaveManager UIManager SceneLoader AnalyticsManager ``` Не превращать `GameManager` в класс, управляющий всем проектом. Каждая система должна отвечать только за собственную область. --- # 37. Event Architecture Системы связывать событиями: ```text CharacterDied CharacterSpawned CorpseCreated SwitchActivated DoorOpened LevelRestarted LevelCompleted CollectibleFound ``` Например: ```text DeathSystem → CharacterDied → CorpseManager → HUD → Audio → Analytics ``` Это намного удобнее, чем жёсткие зависимости между компонентами. --- # 38. Data-driven mechanics Параметры опасностей должны находиться в данных. Например: ```text SpikeConfig damageType corpseImpulse animation audio canPinCorpse ``` Level designer должен иметь возможность настраивать объект через Inspector без изменения кода. --- # 39. Level Editor Tools Это одна из самых окупаемых частей проекта. Разработать редакторские инструменты: **Hazard Palette** Перетаскивание ловушек. **Snap Tool** Привязка к сетке. **Level Validator** Проверяет: - наличие spawn; - наличие goal; - отсутствие duplicate ID; - camera bounds; - отсутствующие references. **Quick Play** Запуск текущего уровня одной кнопкой. **Puzzle Debugger** Показывает: ```text switch states door states trigger bounds corpse colliders physics velocity ``` --- # 40. Restart Architecture Restart должен занимать минимум времени. Не рекомендуется каждый раз полностью перезагружать приложение/главную сцену. Использовать: ```text Level initial snapshot ↓ restart ↓ destroy runtime entities ↓ restore puzzle states ↓ spawn character ``` Или быструю асинхронную перезагрузку только level scene. Целевое UX-требование: игрок нажимает Restart и практически сразу снова управляет персонажем. --- # 41. Производительность Android Цель: **60 FPS на средних устройствах**, с возможностью режима 30 FPS для слабых. Контролировать: ```text Draw calls Physics bodies Particles Dynamic lights Transparent materials Overdraw Audio voices Garbage allocations ``` Особенно внимательно — физика тел. --- # 42. Object Pooling Пули, частицы, эффекты смерти и некоторые персонажи не должны постоянно создаваться через Instantiate/Destroy. Создать: ```text ObjectPool ``` Pools: ```text DeathFX DustFX ImpactFX AudioSource Projectile Character visual ``` --- # 43. Physics Optimization Отдельный budget на уровень: ```text Active dynamic bodies Sleeping bodies Joint count Collision pairs Raycasts/frame ``` Тела вне камеры можно переводить в упрощённое состояние, если они не участвуют в активной головоломке. --- # 44. Графические профили ### Low - reduced particles; - no dynamic shadows; - simplified post-processing; - reduced physics visual effects. ### Medium Стандарт. ### High - shadows; - additional particles; - enhanced effects. --- # 45. Разрешения экранов UI тестировать минимум на: ```text 16:9 18:9 19.5:9 20:9 tablet ratios ``` Игровая область не должна зависеть от конкретной ширины экрана. Использовать safe areas. --- # 46. Android lifecycle Обязательно обработать: ```text application pause incoming call screen lock app background app resume low memory ``` При уходе приложения в background игра автоматически ставится на паузу. --- # 47. Analytics Если аналитика используется, нужны события: ```text level_start level_restart character_death death_type level_complete level_abandon challenge_complete session_start session_end ``` Особенно полезно: ```text level_id death_position death_type restart_count completion_time ``` По этим данным можно построить heatmap мест, где игроки застревают. --- # 48. QA для головоломок Каждый уровень тестируется минимум по пяти направлениям. **Expected solution** Работает ли основное решение? **Alternative solution** Допустимы ли неожиданные решения? **Sequence break** Можно ли пропустить половину уровня? **Softlock** Можно ли необратимо застрять? **Physics instability** Может ли одинаковое действие случайно привести к разным результатам? --- # 49. Mobile QA matrix Проверять: - разные GPU; - различные Android versions; - 2–4 GB RAM; - 60/90/120 Hz дисплеи; - различные aspect ratios; - thermal throttling; - background/resume; - low battery mode; - прерывания звонком; - Bluetooth controllers. --- # 50. Unit tests Автоматизировать минимум: ```text Save serialization Level unlock logic Challenge calculation Death counter Timer Puzzle signal propagation Settings persistence ``` --- # 51. Integration tests Например: ```text Spawn → death → corpse created → new character spawned ``` И: ```text Corpse enters pressure plate → switch activated → door opened ``` --- # 52. Content production pipeline Каждый уровень проходит стадии: ```text Concept ↓ Puzzle diagram ↓ Greybox ↓ Internal playtest ↓ Iteration ↓ Art pass ↓ Audio pass ↓ Optimization ↓ QA ↓ Final ``` Никогда не выполнять art pass до того, как puzzle стабильно работает в greybox. --- # 53. Vertical Slice Первый серьёзный milestone должен содержать: **8–10 уровней.** В них продемонстрировать: - movement; - jump; - death; - respawn; - persistent corpse; - spikes; - buttons; - doors; - saw; - moving platform; - один state-changing mechanic; - mobile UI; - sound; - save system. После прохождения этих уровней должно быть понятно, работает ли весь проект. --- # 54. Этап 1 — Prototype Команда: ```text 1 gameplay programmer 1 game designer ``` Создать только: ```text character controller death corpse respawn spikes pressure plate door goal restart ``` Без финальной графики. **Exit criteria:** дизайнер способен создать минимум пять разных головоломок только из этих элементов. --- # 55. Этап 2 — Vertical Slice Добавляются: ```text final art direction Android controls camera audio UI save system 5–6 mechanics 8–10 polished levels ``` **Exit criteria:** игру можно дать внешнему тестировщику без объяснений. --- # 56. Этап 3 — Production Параллельные потоки: ```text Gameplay programming Level design Environment art Character art Animation Audio UI QA ``` Главная производственная задача — выпуск уровней. Разработчики механик должны максимально быстро перейти в режим поддержки дизайнеров. --- # 57. Этап 4 — Alpha Alpha означает: **вся игра проходима от первого меню до финала.** Допускаются: - placeholder audio; - недоработанные эффекты; - баги; - временные элементы интерфейса. Но весь контент уже существует. --- # 58. Этап 5 — Beta На Beta: - feature freeze; - новые механики больше не добавляются; - уровни зафиксированы; - исправляются баги; - оптимизируется Android; - корректируется сложность; - производится localization QA. --- # 59. Этап 6 — Release Candidate Требования: ```text 0 blocker bugs 0 critical progression bugs all levels completable save migration tested cold launch tested background/resume tested store build signed analytics verified crash reporting verified ``` --- # 60. Состав команды Для полноценного коммерческого производства: ```text 1 Producer 1 Lead/Game Designer 1–2 Level Designers 2 Gameplay Programmers 1 Technical Artist 1 Environment Artist 1 Character/Prop Artist 1 Animator 1 UI/UX Designer 1 Sound Designer — part-time/outsource 1–2 QA ``` Некоторые позиции могут совмещаться. Минимальная indie-команда: ```text 2 programmers 1 designer 1 artist/animator 1 QA/content designer ``` плюс outsource на музыку и звук. --- # 61. Распределение ответственности **Lead programmer** Архитектура, physics, build pipeline. **Gameplay programmer** Character, hazards, puzzle objects. **Designer** Ruleset, progression, challenge targets. **Level designer** Greybox → playtest → iteration. **Artist** Environment, characters, props. **Animator** Movement/death reactions. **QA** Regression и physics edge cases. --- # 62. Backlog Epic-структура В Jira/Linear/YouTrack проект можно сразу разбить на: ```text EPIC-01 Character EPIC-02 Death & Corpse EPIC-03 Physics EPIC-04 Hazards EPIC-05 Puzzle Objects EPIC-06 Camera EPIC-07 Levels EPIC-08 UI/UX EPIC-09 Save/Progression EPIC-10 Audio EPIC-11 Art EPIC-12 Android EPIC-13 Optimization EPIC-14 Analytics EPIC-15 QA EPIC-16 Release ``` --- # 63. Definition of Done для механики Любой новый gameplay object считается готовым только если: ```text ✓ работает ✓ работает после restart ✓ взаимодействует с corpse ✓ корректно сохраняет/сбрасывает state ✓ имеет sound feedback ✓ имеет visual feedback ✓ не создаёт GC spikes ✓ работает на Android ✓ имеет prefab ✓ задокументирован ✓ проверен QA ``` --- # 64. Definition of Done для уровня ```text ✓ существует проверенное решение ✓ нет blocker softlocks ✓ challenge targets настроены ✓ restart корректен ✓ camera bounds настроены ✓ collectible работает ✓ sound pass выполнен ✓ art pass выполнен ✓ optimization выполнен ✓ QA regression выполнен ✓ level ID зарегистрирован ``` --- # 65. Главные технические риски **Риск №1 — нестабильная физика.** Решение: ограниченная и предсказуемая physics model. **Риск №2 — управление на touch.** Решение: большой input buffer, coyote time и раннее тестирование на телефонах. **Риск №3 — слишком длинные головоломки.** Решение: маленькие puzzle rooms и быстрый restart. **Риск №4 — однообразие.** Решение: механики, изменяющие свойства тел, а не просто новые разновидности шипов. **Риск №5 — performance degradation из-за трупов.** Решение: sleep/freeze physics и строгий object budget. **Риск №6 — производство 60+ качественных уровней.** Решение: editor tooling должен быть готов до начала массового level production. --- # 66. Главный принцип дизайна Каждый хороший уровень должен отвечать на вопрос: > **«Каким новым способом игрок использует смерть персонажа в этой головоломке?»** Если единственный ответ — «надо снова положить тело на кнопку», уровень не добавляет ценности. Лучшие комбинации строятся примерно так: ```text смерть → положение тела → изменение состояния тела → взаимодействие тела с механизмом → изменение пространства → следующий персонаж ``` Например: ```text персонаж погибает → тело падает на платформу → платформа перемещает его → тело замораживается → становится ступенью → следующий персонаж забирается выше → активирует механизм → третий персонаж достигает цели ``` Это и должно стать ядром всей системы уровней. --- # 67. Что команда должна получить до начала production До масштабной разработки я бы зафиксировал **пакет из 8 документов/артефактов**: 1. **GDD** — правила игры и полный каталог механик. 2. **TDD** — архитектура, классы, события, physics model. 3. **Level Design Bible** — правила построения головоломок. 4. **Art Bible** — визуальный язык и требования к ассетам. 5. **UX specification** — Android controls, меню и HUD. 6. **Content Matrix** — все миры, уровни и вводимые механики. 7. **Technical backlog** — Epics → Stories → Tasks. 8. **Acceptance/QA matrix** — критерии готовности каждой системы и уровня. И только после утверждения vertical slice переходить к производству десятков уровней. **Критически важная развилка:** если задача действительно состоит в официальном Android-порте *Life Goes On: Done to Death* и у вашей команды есть разрешение правообладателя, этот план следует дополнить отдельной **матрицей 1:1 соответствия оригиналу**: каждый уровень, интерактивный объект, физическое поведение, анимация, звук, меню и challenge оригинальной версии → соответствующий Android-компонент. Без лицензии такую 1:1 спецификацию лучше не использовать; безопаснее оставить идентичной игровую идею, а конкретный контент проектировать заново.