Game Bible — це утопія: як структурувати геймдизайн-документацію сьогодні

Впродовж десятиліть Game Design Document (або GDD) був фундаментом, що визначав core розробки гри і синхронізував усіх членів команди й стейкхолдерів у визначеному векторі. Та ринок змінюється, індустрія еволюціонує, і документація, аби залишатись актуальним інструментом, має відповідати сучасному agile-менеджменту ігрового девелопменту.

Разом із геймдизайнерами та project-менеджерами ми дослідили видозміну форми й ролі GDD у сучасній розробці, обговорили, чи дійсно документ може бути інструментом авторського контролю у студіях із більш вертикальною внутрішньою структурою та який це має вплив на питання ownership у команді.

Визначення GDD та його історична роль: від «Біблії» до фіксації контракту

Геймдизайн-документ (Game Design Document) — це повна задокументована концепція гри, що містить заплановані механіки, світобудову та особливості візуального стилю. Наприкінці 1990-х цей документ у розробці ігор був ключовим для «продажу» проєкту інвесторам та паблішерам. Оскільки GDD нерідко ставав частиною фінальних контрактів, розробники часто стикалися з обмеженнями для експериментів поза межами узгодженої документації.

Згодом у розробці ігор відбулося чітке розмежування GDD (Game Design Document), який детально описував механіки та ігровий досвід для синхронізації команди, та Pitch Deck — документа для залучення інвестицій і фінансового прогнозу. Також з’явилися інші форми документації, як-от One-pager і Technical Design Document тощо.

У вільному доступі доступні GDD легендарних ігор, як-от DOOM, Silent Hill 2, Diablo, Bioshock та Fallout: Brotherhood of Steel 2. Ці документи, які інколи називали «Бібліями», об’єднувала безкомпромісність креативного бачення. Однак чи дієва така негнучка формалізація для сучасних динамічних проєктів? Це відкрите питання, оскільки розробка може тривати навіть після релізу. Воно потребує експертної дискусії. Якщо класичний монолітний GDD вже не ефективний, необхідно визначити, які сучасні рішення варто застосовувати.

Еволюція GDD: перехід до модульної та гнучкої документації

Plarium Game Design Team Lead Владислав Гирик зазначає, що класичний GDD нікуди не зник, а радше змінив форму.

Владислав Гирик Plarium Game Design Team Lead

«Підтримувати великий монолітний документ сьогодні складно: вимоги, пріоритети та метрики змінюються занадто швидко. Тому замість одного „центрального“ файлу ми працюємо з набором взаємопов’язаних документів, які краще відповідають завданням. Якщо абстрагуватися від інструментів, суть залишається незмінною — зафіксувати, що саме ми будуємо і як це має працювати».

Водночас тімлід згадує, що, працюючи в інді-студії, він створював класичні GDD — і цього було достатньо для невеликої команди та простішого виробничого циклу. На противагу великим проєктам з десятками людей і паралельними потоками роботи, такий підхід починає давати збої: документ або швидко застаріває, або перетворюється на формальність.

Натомість Остап Довбуш, Senior Game Designer в Ubisoft, стверджує, що класичного GDD як єдиного документа ніколи й не існувало, а в ігровій розробці використовуються десятки типів документів. Кожен із них має власний формат, призначення, а головне — своє місце й час у процесі розробки.

Остап Довбуш Senior Game Designer в Ubisoft

«Колись була популярною ідея так званої Game Bible — документа, який геймдизайнер створює ще до початку активної розробки, детально прописуючи всі системи, сутності, фічі, взаємозв’язки, артстиль, наратив, UI — словом, усе. Після цього команда нібито просто бере документ у роботу й через певний час видає готовий продукт. Це звучить занадто фантастично, щоб бути правдою, і на практиці так не працює».

Остап Довбуш пропонує провести наступний експеримент: «Спробуйте згадати останню гру, у яку ви грали, й подумайте, з яких систем і механік вона складається. Чи могла б вона бути створена без структурованої документації? На моє переконання — це неможливо».

На його думку, найбільш зручним підходом є формат Master Doc —> Feature Doc.

У такій структурі Master Doc — це загальний документ, який виконує роль онбордингу та базового занурення в концепцію гри. Він допомагає новим членам команди швидко зрозуміти продукт, а також слугує орієнтиром протягом усієї розробки. Зазвичай він містить:

• назву та короткий опис;
• жанр і USP;
• опис ключового контенту (персонажі, противники, основні ігрові «інгредієнти», наратив, артстиль, прогресія, metagame);
• продакшн-блок: аналіз конкурентів, таймлайн розробки, ресурси, розбивку на майлстоуни, фінансові очікування.

Натомість Feature Doc — це робочий документ, присвячений конкретній фічі. Це може бути окрема ігрова система, противник, тип зброї, тимчасовий баф — все, що завгодно. Його завдання — бути максимально деталізованим і актуальним, містити всю інформацію, необхідну для імплементації цієї фічі. Часто він включає схеми, таблиці, балансові розрахунки, а до його наповнення можуть долучатися різні учасники команди.

На думку ж Feature-дизайнера Frogwares Матвія Прокопенка, форма документації не така важлива, якщо виконуються дві ключові умови:

1. Усі члени команди знають, де шукати актуальну інформацію.
2. Джерело цієї інформації можна швидко й без зайвої бюрократії оновлювати.

Матвій Прокопенко Feature-дизайнер Frogwares

«Інформація з геймдизайну має бути структурованою, легкодоступною та зрозумілою для більшості членів команди. Оскільки зміни в проєкті часто вносяться неодночасно, модульна wiki-система виграє завдяки можливості ітерувати окремі статті».

Своємю чергою Андрій Годар, Project Manager у GSC Game World, одразу розмежовує підходи до геймдизайн-документу між продуктовими командами та аутсорсом.

Андрій Годар Project Manager у GSC Game World

«Якщо ми говоримо про продуктову розробку — кожна команда формує власні ways of working. Головне, щоб такий підхід до документації органічно підходив саме цій команді. В аутсорсі ситуація інша: орієнтація на стандарти та ринкові практики значно жорсткіша, адже потрібно залишатися зрозумілими й зручними для людей із «зовнішнього світу».

Загальний контекст розвитку індустрії диктує більшу гнучкість при зростанні складності розробки, тож саме тому тренд зміщується в бік модульних GDD.

Складна розробка — це процес, коли гра складається з певної кількості систем і механік, кожна з яких має власний життєвий цикл (доки не увійде в органічне поєднання з іншими або не буде вирізана). А гнучкість необхідна тоді, коли команда точно не знає, що хоче отримати в підсумку.

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

«А тепер уявіть історію правок у GDD такої гри. І повідомлення в загальному каналі: „Будь ласка, перечитайте оновлення на сторінках 85–87, я виділив жовтим“ — по п’ять разів на день», — зауважує Андрій Годар.

Тож дедалі частіше GD-документацію розбивають на частини, враховуючи витрати когнітивного ресурсу членів команди на нерелевантну інформацію при складній навігації масивним документом. Пріоритетом усе ж має залишатися легкість внесення та обговорення змін.

Ключовим моментом у контексті продуктової розробки, на думку проджект-менеджера GSC Game World, є те, що велика фіча часто набуває рис окремого проєкту. Вона планується, менеджиться та документується окремо. А сукупність фіч, із погляду проєктного менеджменту, вже може розглядатися як програма. Тому й GD-документація структурується модульно.

У цьому контексті команда потребуватиме засобів навігації масштабу Big Picture. І тут на арену виходять додаткові інструменти: Miro-борди, агрегувальні макроси Confluence та пропрієтарні рішення, що дають змогу бачити високорівневий зріз усього масиву документації (із взаємозв’язками та індикацією статусів). Чим складнішою є ваша документація, тим важливішою стає роль навігації.

Як це виглядає на практиці?

• структуровані Wiki-сховища;
• активне використання візуальних інструментів на кшталт Miro;
• чіткий поділ за рівнями абстракції.

Базовий принцип простий:

• розділити GDD на окремі сутності за рівнями абстракції;
• дозволити кожній сутності «жити» окремо (плануватися, розроблятися, коригуватися);
• зробити кожен документ максимально простим для доступу й перегляду (в ідеалі — 1–2 сторінки);
• визначити напрям і рамки, але не намагатися описати все до дрібниць, залишаючи простір для гнучкості та дискусії.

Готова структура модульного масиву GD-документації може виглядати приблизно так:

1. Concept document (базовий опис гри);
2. Опис сегмента гри;
3. Опис фічі;
4. User Story (високорівневий опис вимог);
   4.1 На нижньому рівні осідають конкретні задачі, які команда розписує в процесі роботи.

Крім цього, вам можуть знадобитися окремі документи, що описують складні системи. Але й розроблятимуться вони, ймовірно, в окремому циклі — не обов’язково адаптивному.

Андрій Годар Project Manager у GSC Game World

«До речі, цей тренд не є новим. Можна згадати історію розробки гри Doom, для якої креативний директор Том Голл розробив величезний монолітний документ (відомий як Doom Bible). Але блискучий технобунтар Джон Кармак, який уже мав на той момент готовий ігровий рушій та прототипи, подивився на цей документ і... відкинув його як занадто складний і перевантажений непотрібними для розробки деталями».

Тоді команда id Software обрала шлях швидких ітерацій, орієнтованих на технічні експерименти та фан для гравця. І дійсно — для невеликої команди вмотивованих професіоналів це спрацювало блискуче. Та геймдев є однією з найбільш різноманітних та динамічних індустрій, і в деяких ситуаціях нам усе ж може знадобитися монолітний документ. До таких випадків можна віднести:

1. Особливі вимоги замовника: замовник звик працювати жорстко, дуже добре знає, чого хоче, або має обмеження, вихід за які для нього небезпечніший, ніж продуктові ризики.
2. Низький рівень невизначеності розробки: дуже проста гра, клон або рескін, який зазвичай потрібно зробити швидко.

Варто зазначити, що окремим ризиком є низька зрілість замовника: «Іноді клієнт хоче „домовитися про все наперед“, щоб далі працювати без стресу. Тут може вийти так, що в результаті ми акуратно, вчасно й не виходячи за бюджет зробимо стабільну гру... у яку буде нецікаво грати. Контракт закрито, гроші отримано. Але чи буде задоволений замовник? Чи повернеться він із новим проєктом?» — ділиться роздумами пан Андрій.

Тож як зрозуміти, що монолітний класичний GDD вам не підходить, навіть якщо ви вже ним користуєтеся?

Однією з ознак є постійне відчуття «незручності». Здається, що ось-ось з’явиться той самий Великий Прекрасний Документ, за яким усі щасливо працюватимуть. Але цей момент ніяк не настає.

Індикатором дисфункції (підходу, пайплайну, організаційної структури тощо) є не «все зупинилося», а саме «постійно незручно». Ми дратуємося через неорганізованість, звинувачуємо себе й інших, підсилюємо культуру «трудових подвигів», але системна проблема нікуди не зникає. Тож якщо ці маркери вам знайомі, то, можливо, дійсно варто розглянути зміну підходів до дизайн-документації.

GDD vs Build-архів: фіксація контексту проти ітерації в динаміці

За декілька днів до релізу першого патчу Hades II, в інтерв’ю відомому стрімеру roguelike-ігор Haelian, Амір Рао (директор Supergiant Games) заявив, що команда не має великих та детальних дизайн-документів для своїх проєктів. Натомість команда обрала більш практичний та ітеративний підхід до розробки.

«Гра і є дизайн-документом. Ми надзвичайно ітеративна студія. Спочатку ми створюємо in-game рішення, завжди залишаючи час на редагування, полішинг чи повне їх видалення, якщо вони не працюють», — ділиться залаштунками розробки Амір Рао.

Його майндсет стосовно постійного процесу навчання в команді також є примітним. Як він зазначає в інтерв’ю, вони структурують процеси навколо навчання і постійно ставлять собі два важливі питання: що їм потрібно визначити зараз, а що вони можуть дозволити собі вивчити пізніше.

У контексті питання архіву білдів стратегія Supergiant також працює, адже вони активно користуються раннім доступом для аналізу, а потім швидко релізять патчі.

Та уявімо, що команда QC перевіряє певну функціональність у грі. Те, чи працює вона правильно, чи неправильно, залежить від початкових вимог. А з’ясувати ці вимоги без документації (або без прямого діалогу з геймдизайнером) фактично неможливо. Звісно, працювати над грою з документацією чи без — це справа конкретної команди, але наявність білдів все ж не скасовує потреби в документах.

Остап Довбуш Senior Game Designer в Ubisoft

«Плейтести або перевірка функціональності в грі можуть виявити потребу змінити окремі аспекти фічі. І ці зміни починаються з оновлення документації та коректної комунікації всередині команди».

Зазвичай команда працює над однією або кількома фічами паралельно, і регулярні плейтести лише підвищують їхню якість. Водночас результати тестування не завжди можна імплементувати вже наступного дня, тож саме тут процес документації виконує ключову роль моста комунікації між всіма учасниками розробки та фіксує узгоджені зміни до моменту їхньої реалізації.

Використання таких форматів, як gym, zoo та museum, Матвій Прокопенко теж вважає корисним, проте відмовлятися від фіксації інформації про те, «як має бути», він не вважає доцільним.

Матвій Прокопенко Feature-дизайнер Frogwares

«Деякі системи значно простіше описати wiki-схемами, таблицями або текстом. Особливо з огляду на те, що рано чи пізно щось зламається (а воно 100% зламається). І коли це станеться, команда повинна чітко розуміти, що саме пішло не так. Тому, на мою думку, найефективніший підхід — це комбінація in-game інструментів і структурованої wiki-документації».

Game Design Team Lead Владислав Гирик не погоджується з думкою, що архів білдів є кращою альтернативою GDD: «Для мене це не альтернативи, а суміжні інструменти з різним призначенням. Архів білдів — чудовий спосіб перевіряти гіпотези й бачити, як рішення працює в динаміці. Але документація виконує іншу функцію: вона передає знання та фіксує контекст».

Його позицію підтримує Project Manager GSC Game World Андрій Годар. На його думку, архів білдів — це елемент іншого контексту, і конкурувати з GDD він майже ні в чому не може.

Тут можемо підсумувати, що білд може показати, що працює або не працює. Проте він не відповість на запитання: чому було обрано саме таке рішення, які бізнес-цілі воно мало закривати та які метрики вважалися ключовими на момент розробки.

Владислав Гирик Plarium Game Design Team Lead

«Зрештою, це ще й питання фінансів. Перевірка гіпотези на рівні документа майже завжди дешевша, ніж навіть найкоротший цикл розробки. Прототип — потужний інструмент, але він не замінює мислення «на папері».

GDD як інструмент авторського бачення та креативного контролю

На відміну від уже згаданого ітеративного підходу Supergiant, Хідео Коджіма працює над супердеталізованими дизайн-документами, на сторінках яких він втілює свій віжн проєктів.

Окрім уже звичних елементів GDD, його Grand Game Plan для Metal Gear Solid 2 (2001) містить інформацію про режисуру катсцен, розташування камери, музичні референси, ритм сцен та навіть інтонації персонажів. Включення таких деталей свідчить про дуже чітке креативне бачення, що може, з одного боку, забезпечити стилістичну та ідейну послідовність, а з іншого — звузити простір для інтерпретацій усередині команди.

У випадку з проєктами Kojima Productions справедливо буде зазначити, що тенденція до уніфікації авторського бачення продовжилася. Це водночас як підтверджує креативний геній Хідео Коджіми, так і може натякати на специфічну динаміку всередині команди.

З наведеною тезою погоджується пан Владислав Гирик, який підкреслює, що моделі на кшталт Sid Meier’s Civilization та Kojima Productions демонструють як те, що креативна відповідальність може концентруватися навколо однієї фігури, так і те, що тут документація справді може виконувати функцію фіксації та захисту бачення.

«Я працював на аутсорсі для замовника, який приніс детально розписаний GDD гри для бренду Dyson. Скажу так: креативної розробки з нашого боку не було зовсім. Але чи кожен проєкт потребує авторської моделі — і чи завжди вона масштабована?» — наводить приклад геймдизайн-тімлід Plarium.

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

Розглянемо це питання на інших прикладах, як-от Grand Theft Auto V чи Call of Duty. Малоймовірно, що креативний директор знає всі нюанси меню налаштувань, повний перелік можливостей інвентарю або точні числові параметри балансу кожного противника. За кожну окрему фічу відповідає конкретна підкоманда: геймдизайнер, програміст, продюсер, художник та інші спеціалісти, залучені до реалізації.

«Звісно, геймдизайнеру значно зручніше починати роботу над фічею, маючи на руках документ формату Director’s Vision із чітко окресленими вимогами та обмеженнями. Це справді значно спрощує старт, але в жодному разі не обмежує творчість і сам дизайн-підхід», — каже Senior Game Designer Остап Довбуш.

Звісно, до фактичного початку розробки фічі зазвичай створюється низка проміжних документів: One-pager, прототип, Creative Brief. Кожен із цих етапів проходить погодження з тим самим директором, який формулював початкову візію, і тільки після цього команда переходить до повноцінного Feature Doc.

Та питання ownership чітко простежується в цьому процесі. На думку Андрія Годаря, це і є головним bottleneck модульного Wiki-GDD: «Якщо окремі документи не мають визначених власників або ці люди не готові нести відповідальність, то дуже швидко може відкритися портал у хаос».

Матвій Прокопенко Feature-дизайнер Frogwares

«Також наявність модуля Game Pillars у цій самій wiki може стати якраз тим практичним інструментом, до якого можна звертатися при ухваленні рішень, аби вся команда розуміла та поділяла дирекшн проєкту».

Документація для LiveOps: швидкість та ітерація в умовах постійних змін

У LiveOps-середовищі документ загалом не може бути «завершеним», адже гра регулярно змінюється. LiveOps-документація працює на швидкості та ітерації гіпотез: вона не має описувати core гри, а має лаконічно фокусуватися на конкретному івенті.

Тут ми маємо справу з колекцією менших документів, як-от описи функцій, специфікації подій, документація з налаштування та аркуші конфігурацій. Під час LiveOps-підтримки проєкту більшої ваги набувають production- та LiveOps-документи. Зокрема:

• каденція івентів;
• список сезонного контенту;
• тимчасові гейм-моди або мініігри;
• сезонні Battle Pass;
• модифікатори чи бусти (наприклад, на вихідні);
• знижки, бандли та ротації в магазині.

Остап Довбуш Senior Game Designer в Ubisoft

«Принцип розробки контенту до релізу не відрізняється від створення контенту для post-launch або DLC. Навіть якщо йдеться про тимчасові івенти, сезони чи ротації оферів у сторі, усі вони проходять стандартний пайплайн розробки з фазами креативу, дизайну, імплементації та валідації».

Якщо розглядати GDD як фундамент гри, то LiveOps-документи — це надбудови у вигляді нового контенту. Але сам контент у будь-якому разі повинен уже бути розробленим і готовим до включення/виключення в проєкті. Також не варто забувати, що для правильного оперування фічами й планування подальшого розвитку необхідно підключати телеметрію до кожної випущеної системи. Саме метрики дозволяють зрозуміти, чи спрацювали закладені гіпотези, чи потрібно переглядати дизайн-рішення.

Водночас KPI — не константи, а поведінка аудиторії непередбачувана. Метрики реагують на контекст, економіка коливається, і вподобання аудиторії змінюються. Те, що працювало два тижні тому, сьогодні може працювати інакше. І в такій реальності статичний документ, який оновлюється раз на кілька місяців, швидко втрачає актуальність.

«Нещодавно я переглядав документацію восьмої ітерації (за останні декілька місяців) для LiveOps-фічі. І якби це був просто базовий статичний GDD, у мене б пішло значно більше часу на аналіз ситуації в динаміці. LiveOps — це не аргумент проти документації, це аргумент проти повільної документації», — ділиться досвідом Game Design Team Lead Владислав Гирик.

З огляду на сучасні реалії індустрії, розробка стала процесом, що ніколи не закінчується, і поки гра залишається «живою», вона триватиме.

Андрій Годар Project Manager у GSC Game World

«Тож структура геймдизайн-документації має бути адаптованою до такого середовища. Вона повинна відповідати архітектурі, у якій будь-яка частина може змінюватися непропорційно та розвиватися в іншому темпі, ніж усе інше».

Фіксація відповідальності та ризики memory-driven підходу

Уявімо ситуацію: під час загального плейтесту open world гри QC стикається з п’ятьма різними open world активностями, кожну з яких розробляла окрема команда. Якісна документація має одразу дати відповіді на ключові запитання. Але навіть якщо з певних причин вона неповна, список оунерів допоможе швидко вибудувати горизонтальні зв’язки між розробниками та уникнути тривалих комунікацій через менеджерів.

Список оунерів конкретної фічі також суттєво спрощує комунікацію з QC-департаментом, фахівці якого можуть знайти баг у будь-якому місці проєкту й за допомогою документації швидко вийти на команду розробки саме цієї фічі для уточнення очікуваної поведінки.

«GDD систематизує всю комунікацію та креатив навколо фічі. Він відповідає на питання, що саме розробляє команда і для чого — якою є кінцева мета тієї чи іншої фічі. Це не статичний документ, який пишеться один раз і після цього існує як незмінне джерело істини. Це живий матеріал, який постійно ітерується паралельно з процесом розробки», — підкреслює Senior Game Designer Остап Довбуш.

В команді надзвичайно важливо бути відкритими до прямих запитань від будь-якого учасника щодо ваших напрацювань. Якщо в документації визначений оунер, є контроль версій, зафіксовані зміни й конкретна людина, яка відповідає за систему (фічу, тест чи будь-що інше), тоді документ дійсно працює як механізм захисту ownership. Він робить рішення прозорими й фіксує відповідальність.

Та навіть після завершення роботи над проєктом є сенс приводити документацію до максимально актуального й повного стану, адже ніколи не знаєш, кому і коли вона знадобиться знову. Очевидно, що дизайнер ніколи не працює у вакуумі, і жоден елемент розробки не існує окремо в єдиній системі. Будь-які рішення є сукупністю всіх обговорень, плейтестів і взаємодії як із командою, так і з гравцями. Тож і ownership систем може органічно змінюватися впродовж розробки, а рішення — адаптуватися кількома людьми. Таким чином питання конкретного володіння процесом дедалі дужче заплутуються.

Feature-дизайнеру Frogwares Матвію Прокопенку складно погодитися з тим, що в команді має існувати ownership конкретних елементів чи механік: «У грі все або працює на покращення цілісного досвіду, або ні. Не існує окремо геніальних механік — для дизайнера ключовим є розуміння проєкту загалом. Іноді окремі рішення доводиться спрощувати або навіть відмовлятися від них, щоб зберегти фокус на головному».

У вимірі memory-driven підходу контекст часто живе в чатах, мітингах та неформальній комунікації. Це стає сприятливим середовищем для виникнення розмитості: хто саме прийняв рішення, чому воно було таким і чи актуальне воно досі.

Владислав Гирик Plarium Game Design Team Lead

«Ми в команді часто жартуємо: „Не записали — значить не домовилися“. Але це не про бюрократію. Це про збереження контексту та відповідальності. І в цьому сенсі GDD — не просто опис фічі, а інструмент фіксації рішень».

Підписуйтеся на Telegram-канал @gamedev_dou, щоб не пропустити найважливіші статті і новини