1782 lines
40 KiB
Markdown
1782 lines
40 KiB
Markdown
# 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<T>
|
||
```
|
||
|
||
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 спецификацию лучше не использовать; безопаснее оставить идентичной игровую идею, а конкретный контент проектировать заново.
|