huncode/goon-game
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
master
goon-game/docs/DEVELOPMENT_PLAN.md
T

40 KiB
Raw Permalink Blame History

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:

Spawn
↓
Idle
├── Run
├── Jump
│   └── Fall
├── Interact
├── Stunned
└── Death
     ↓
    Corpse

После Death живой контроллер отключается и объект переходит в физическое состояние Corpse.

4. Ключевая система — смерть

Это центральная техническая система проекта.

Каждый персонаж должен состоять из двух логических сущностей:

LivingCharacter
CorpseEntity

При смерти:

Damage received
→ определить DeathType
→ заблокировать управление
→ запустить death animation
→ создать/активировать физическое тело
→ перенести позицию/импульс
→ зарегистрировать тело в CorpseManager
→ через задержку породить нового персонажа

Новый персонаж появляется, не уничтожая старое тело.

5. Типы смерти

Система должна работать через универсальный интерфейс.

Например:

public interface IKillSource
{
    DeathType DeathType { get; }
    void Kill(Character character);
}

DeathType:

Spike
Saw
Crush
Fire
Electricity
Freeze
Pit
Projectile
Explosion
Generic

Каждый тип смерти может определять:

  • анимацию;
  • звук;
  • импульс;
  • физическое состояние тела;
  • возможность дальнейшего использования тела.

6. Corpse System

Главное требование: тело погибшего персонажа является полноценным элементом головоломки.

У тела должны быть:

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

Отдельная глобальная система на уровне.

Ответственность:

CorpseManager
├── RegisterCorpse()
├── RemoveCorpse()
├── FreezeCorpse()
├── DestroyCorpse()
├── GetCorpseCount()
├── ResetLevel()
└── SerializeState()

Необходимо заранее установить лимит одновременно существующих ragdoll/physics-объектов.

Для Android важно не оставлять десятки тяжёлых физических объектов с постоянным расчётом.

После полной остановки тело можно переводить:

Dynamic Rigidbody
→ Sleeping Rigidbody
→ Static-like optimized state

При внешнем воздействии оно снова активируется.

8. Система спавна

На каждом уровне находится SpawnPoint.

Последовательность:

Knight dies
↓
Death registered
↓
0.2–0.8 sec feedback
↓
Spawn animation
↓
new character becomes controllable

Уровень не перезагружается после смерти.

Полный restart происходит только:

  • по кнопке игрока;
  • при softlock;
  • при необратимо неправильном состоянии головоломки;
  • после выбора Restart.

9. Определение softlock

Это важная система для такого жанра.

Игрок может физически привести уровень в нерешаемое состояние.

Поэтому UI должен всегда содержать:

Restart level.

Дополнительно можно создать систему:

PuzzleStateValidator

которая определяет очевидные невозможные состояния и предлагает:

Решение стало невозможным. Перезапустить уровень?

Автоматический restart лучше не делать — игрок может использовать неожиданное решение.

10. Базовые препятствия

Первый набор:

Spikes

Убивают персонажа.

Тело остаётся лежать/висеть на шипах.

Несколько тел постепенно создают безопасный проход.

Circular Saw

Убивает или отбрасывает персонажа.

Используется для перемещения тела в другую часть уровня.

Crusher

Раздавливает объект между двумя поверхностями.

Может создавать низкий объект, пригодный как платформа.

Fire

Уничтожает живого персонажа.

Может менять свойства тела.

Electricity

Убивает живого персонажа.

Через тело может активироваться электрическая цепь.

Ice

Замораживает персонажа или тело.

Frozen corpse становится стабильной платформой.

Pit

Мгновенная смерть/потеря тела.

Используется как отрицательное пространство.

11. Кнопки и переключатели

Нужны минимум три типа.

Pressure Plate

Активна, пока на ней присутствует достаточная масса.

Работают:

  • живой персонаж;
  • тело;
  • физический объект.

Toggle Switch

При нажатии меняет состояние:

ON ↔ OFF

Timed Switch

После активации запускает таймер.

Например:

Switch activated
→ Door opens
→ 4 seconds
→ Door closes

12. Двери и ворота

Универсальный компонент:

DoorController

Состояния:

Closed
Opening
Open
Closing
Locked

Door должен получать сигналы через event-систему, а не иметь прямые ссылки на конкретную кнопку.

Например:

PressurePlate
    ↓
PuzzleEventChannel
    ↓
DoorController

Так level designer сможет быстро собирать головоломки.

13. Moving Platforms

Платформы должны поддерживать:

  • циклическое движение;
  • движение A→B;
  • multiple waypoints;
  • activation by switch;
  • остановку;
  • изменение направления;
  • изменение скорости.

Персонаж и тела должны корректно перемещаться вместе с платформой.

14. Физические объекты

Помимо тел:

Box
Rock
Ball
IceBlock
Counterweight
ExplosiveObject

Все должны реализовывать общий интерфейс массы/активации:

IWeightedObject

Это позволит pressure plate не знать, стоит на ней тело, ящик или персонаж.

15. Система физики

Ключевая цель — предсказуемость, а не реализм.

Для puzzle-game одинаковое действие должно давать практически одинаковый результат.

Нужно избегать чрезмерно свободного ragdoll.

Лучше использовать:

гибридную модель.

При смерти:

  1. проигрывается контролируемая animation;
  2. задаётся предсказуемый импульс;
  3. тело переходит в ограниченную physics simulation;
  4. после остановки фиксируется.

Это значительно уменьшит случайные провалы головоломок.

16. Управление Android

Базовая схема:

[ ← ] [ → ]                 [ Jump ]

Вариант 2:

Virtual joystick             Jump

Для такого жанра предпочтительнее отдельные кнопки направления — они точнее.

Дополнительные элементы:

Restart
Pause

Не следует размещать больше 4–5 интерактивных зон на основном HUD.

17. Требования к мобильному управлению

Обязательно:

  • multitouch;
  • возможность держать направление и одновременно прыгать;
  • регулируемый размер кнопок;
  • configurable opacity;
  • вибрационная обратная связь;
  • dead zone;
  • защита от случайных повторных прыжков.

Добавить:

InputBuffer = ~100–150 ms
CoyoteTime = ~80–150 ms

Значения должны быть вынесены в конфиг, а не захардкожены.

18. Камера

Основной тип:

side-view tracking camera.

Функции:

Follow character
Look ahead
Vertical damping
Camera bounds
Room transitions
Camera shake
Focus target

Камера не должна напрямую повторять каждый пиксель движения персонажа.

Добавить look-ahead:

character runs right
→ camera shifts slightly right

чтобы игрок видел будущую часть уровня.

19. Устройство уровня

Каждый уровень содержит:

LevelRoot
├── SpawnPoint
├── Goal
├── StaticGeometry
├── Hazards
├── PuzzleObjects
├── MovingPlatforms
├── Triggers
├── CameraBounds
├── Decorations
└── LevelController

20. Level Controller

Хранит:

LevelID
WorldID
TargetDeaths
TargetTime
Collectible
SpawnPosition
CurrentDeaths
CurrentTime
PuzzleState
CompletionState

Отвечает за:

Start
Restart
Complete
Pause
Checkpoint
Statistics

21. Завершение уровня

Игрок должен добраться до финального объекта.

Например:

Goal / Artifact / Portal / Crown / Relic

После контакта:

Character reaches Goal
↓
disable controls
↓
completion animation
↓
calculate result
↓
save progress
↓
result screen

22. Дополнительные цели

Для replayability на каждом уровне можно использовать три испытания.

Например:

Casualty target

Complete with ≤ 5 deaths

Time target

Complete in ≤ 45 sec

Optional collectible

Найти скрытый объект.

Результат:

✓ 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

Комбинируются:

body positioning
+ timing
+ electricity
+ ice
+ moving platforms
+ multiple switches

Новые механики почти не вводятся — проверяется владение уже изученными.

24. Формула дизайна уровня

Для каждого уровня дизайнер сначала пишет solution graph.

Например:

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. Персонажи

Создать модульную систему:

Character
├── Body
├── Helmet
├── Face
├── Weapon
├── Cape
└── Accessory

Каждый новый персонаж может получать случайную комбинацию.

Например:

Name = random
Helmet = random
Cape = random
Accessory = random

Так очередная жертва визуально ощущается новым персонажем без необходимости создавать сотни моделей.

28. Анимации

Минимальный набор:

Idle
Run
JumpStart
JumpLoop
Fall
Land
Turn
Fear
Celebrate
Spawn
DeathGeneric
DeathSpike
DeathElectric
DeathFire
Freeze
Crush
GoalInteraction

29. Sound Design

Отдельные категории:

Movement
Environment
Puzzle mechanisms
Deaths
UI
Music
Voice reactions

Смерти требуют нескольких вариантов каждого звука, иначе повторение станет раздражать.

Например:

DeathVoice_01
DeathVoice_02
...
DeathVoice_12

Выбор должен исключать немедленное повторение предыдущего клипа.

30. Музыка

Не нужна отдельная композиция на каждый уровень.

Оптимально:

World 1 track
World 2 track
World 3 track
World 4 track
Finale
Menu

Каждый игровой трек должен иметь длинный ненавязчивый loop.

31. UI

Основные экраны:

Splash
Main Menu
World Select
Level Select
Gameplay
Pause
Level Complete
Settings
Statistics
Credits

Gameplay HUD:

Deaths: 4
Timer: 00:42
Restart
Pause

Не перегружать HUD дополнительными кнопками.

32. Главное меню

Continue
Play
Settings
Achievements
Credits

После первого запуска Continue скрывается.

33. Level Select

Представление:

World
 ├─ 01 ★★★
 ├─ 02 ★★☆
 ├─ 03 ★★★
 └─ 04 🔒

Игрок сразу видит:

  • завершён ли уровень;
  • выполнены ли challenges;
  • найден ли collectible.

34. Save System

Хранить:

{
  "saveVersion": 1,
  "currentWorld": 2,
  "levels": {
    "1_01": {
      "completed": true,
      "bestDeaths": 3,
      "bestTimeMs": 34100,
      "collectible": true
    }
  }
}

Обязательно добавить saveVersion, чтобы будущие обновления могли выполнять миграцию сохранений.

35. Архитектура проекта

Для Unity-подобной архитектуры:

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. Основные программные модули

GameManager
LevelManager
CharacterController
CharacterSpawner
DeathSystem
CorpseManager
PuzzleSystem
CameraController
InputManager
AudioManager
SaveManager
UIManager
SceneLoader
AnalyticsManager

Не превращать GameManager в класс, управляющий всем проектом.

Каждая система должна отвечать только за собственную область.

37. Event Architecture

Системы связывать событиями:

CharacterDied
CharacterSpawned
CorpseCreated
SwitchActivated
DoorOpened
LevelRestarted
LevelCompleted
CollectibleFound

Например:

DeathSystem
→ CharacterDied
→ CorpseManager
→ HUD
→ Audio
→ Analytics

Это намного удобнее, чем жёсткие зависимости между компонентами.

38. Data-driven mechanics

Параметры опасностей должны находиться в данных.

Например:

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

Показывает:

switch states
door states
trigger bounds
corpse colliders
physics velocity

40. Restart Architecture

Restart должен занимать минимум времени.

Не рекомендуется каждый раз полностью перезагружать приложение/главную сцену.

Использовать:

Level initial snapshot
↓
restart
↓
destroy runtime entities
↓
restore puzzle states
↓
spawn character

Или быструю асинхронную перезагрузку только level scene.

Целевое UX-требование: игрок нажимает Restart и практически сразу снова управляет персонажем.

41. Производительность Android

Цель:

60 FPS на средних устройствах, с возможностью режима 30 FPS для слабых.

Контролировать:

Draw calls
Physics bodies
Particles
Dynamic lights
Transparent materials
Overdraw
Audio voices
Garbage allocations

Особенно внимательно — физика тел.

42. Object Pooling

Пули, частицы, эффекты смерти и некоторые персонажи не должны постоянно создаваться через Instantiate/Destroy.

Создать:

ObjectPool<T>

Pools:

DeathFX
DustFX
ImpactFX
AudioSource
Projectile
Character visual

43. Physics Optimization

Отдельный budget на уровень:

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 тестировать минимум на:

16:9
18:9
19.5:9
20:9
tablet ratios

Игровая область не должна зависеть от конкретной ширины экрана.

Использовать safe areas.

46. Android lifecycle

Обязательно обработать:

application pause
incoming call
screen lock
app background
app resume
low memory

При уходе приложения в background игра автоматически ставится на паузу.

47. Analytics

Если аналитика используется, нужны события:

level_start
level_restart
character_death
death_type
level_complete
level_abandon
challenge_complete
session_start
session_end

Особенно полезно:

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

Автоматизировать минимум:

Save serialization
Level unlock logic
Challenge calculation
Death counter
Timer
Puzzle signal propagation
Settings persistence

51. Integration tests

Например:

Spawn
→ death
→ corpse created
→ new character spawned

И:

Corpse enters pressure plate
→ switch activated
→ door opened

52. Content production pipeline

Каждый уровень проходит стадии:

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

Команда:

1 gameplay programmer
1 game designer

Создать только:

character controller
death
corpse
respawn
spikes
pressure plate
door
goal
restart

Без финальной графики.

Exit criteria: дизайнер способен создать минимум пять разных головоломок только из этих элементов.

55. Этап 2 — Vertical Slice

Добавляются:

final art direction
Android controls
camera
audio
UI
save system
5–6 mechanics
8–10 polished levels

Exit criteria: игру можно дать внешнему тестировщику без объяснений.

56. Этап 3 — Production

Параллельные потоки:

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

Требования:

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. Состав команды

Для полноценного коммерческого производства:

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-команда:

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 проект можно сразу разбить на:

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 считается готовым только если:

✓ работает
✓ работает после restart
✓ взаимодействует с corpse
✓ корректно сохраняет/сбрасывает state
✓ имеет sound feedback
✓ имеет visual feedback
✓ не создаёт GC spikes
✓ работает на Android
✓ имеет prefab
✓ задокументирован
✓ проверен QA

64. Definition of Done для уровня

✓ существует проверенное решение
✓ нет 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. Главный принцип дизайна

Каждый хороший уровень должен отвечать на вопрос:

«Каким новым способом игрок использует смерть персонажа в этой головоломке?»

Если единственный ответ — «надо снова положить тело на кнопку», уровень не добавляет ценности.

Лучшие комбинации строятся примерно так:

смерть
→ положение тела
→ изменение состояния тела
→ взаимодействие тела с механизмом
→ изменение пространства
→ следующий персонаж

Например:

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

Это и должно стать ядром всей системы уровней.

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

Reference in New Issue View Git Blame Copy Permalink