Все що треба знати про геймдизайн-документацію. Поради спеціаліста

Всім привіт! Мене звуть Богдан Павленко, я Game Designer у компанії Pingle Studio і сьогодні я спробую розповісти все, що необхідно знати про геймдизайн-документацію. Звісно, у мене не вийде описати кожен можливий момент, але я спробую зробити цю статтю достатньо інформативною для всіх, хто цікавиться геймдевом.

Для чого потрібна документація

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

Отже, навіщо потрібна документація?

1. Загальна інформація про проєкт. Документація містить загальну інформацію про проєкт та надає можливість у будь-який момент порівняти те, що написано у документації, з тим, у якому стані знаходиться проєкт. Можливо, якісь заплановані фічі ще не були імплементовані, або щось працює не за дизайном, або механіка перероблювалась 100 разів, а дизайн-документ забули оновити тощо. Без нормальної документації ці проблеми будуть віднімати купу часу та сильно впливати на загальну якість проєкту.
2. Опис фічей для розробників. Фічі та механіки потребують дизайну та детального опису, для цього геймдизайнери створюють документи, які містять всю необхідну інформацію для розробників та тестувальників. Якщо документ написано правильно, розробник буде розуміти, що саме йому потрібно робити, які параметри потрібно винести для налаштування з боку ГД, а тестувальник зможе швидко перевірити, чи відповідає реалізація розробника дизайну, прописаному у документі, і чи правильно механіка або фіча поводить себе у різних випадках.
3. Онбордингнових людей. У команді можуть з’являтися нові люди, або виникає потреба показати вашу гру людям, які нічого про неї не знають. У таких випадках документація допомагає швидкому онбордингу та розумінню загальної концепції гри.
4. Естімація. Детально прописані дизайн-документи допомагають розробникам правильно естімувати час, який вони витратять на реалізацію відповідних фічей та механік.

Це не вичерпний список, але він допомагає розуміти важливість ведення якісної документації на проєкті.

Типи геймдизайн документів

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

Pitch та Elevator Pitch

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

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

• Загальна інформація. На початку документу варто написати про наступні речі:
  • Жанр;
  • Ігровий рушій, на якому гра буде розроблятися;
  • Назва проєкту (може бути кодовою);
  • Платформи, на яких планується випуск гри.
• Elevator pitch — пітч гри, який ви можете презентувати потенційному інвестору за час поїздки у ліфті. Це 2-3 речення, які мають дуже коротко розписати основні ідеї гри, та зацікавити тих, хто читає цей документ.
• Features and mechanics — після elevator pitch можна по пунктах описати основні фічі та механіки. Розписуйте тільки ті моменти, які є унікальними або дуже важливими для вашої гри.
• USP (Unique Selling Points) — унікальні особливості гри, за рахунок яких, на нашу думку, вона буде продаватися та буде цікавою для потенційної аудиторії. Зазвичай 2-3 USP на пітч.

Concept

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

Основні моменти, про які варто написати у концепті:

• Загальна інформація. Сюди входить:
  • Назва проєкту (хоча б тимчасова);
  • Жанр та сетинг гри;
  • Бізнес-модель;
  • Платформи, на яких планується випустити гру (PC, консолі, мобілки);
  • Технологія, яку ми використовуємо для розробки гри (Unity, Unreal тощо);
  • Цільова аудиторія нашої гри.
• Загальний опис гри — короткий опис про що наша гра, особливості геймплею тощо.
• Геймплей — тут знаходиться більш детальний опис геймплею, бажано з прикладами того, як це буде відбуватися з боку гравця. Тут же знаходиться опис core gameloop.
• Механіки та фічі — бажано мати короткий опис основних механік та фічей, які будуть використовуватись у грі, та того, як вони будуть взаємодіяти.
• Сюжет/Сетинг — в якому світі відбуваються події нашої гри, які правила та особливості цього світу? Якщо у гри буде сюжет, то з чого він розпочнеться, яка буде фінальна ціль?
• Арт-стиль — в якому стилі буде наша гра, бажано з прикладами та референсами.
• Key features — не обов’язково унікальні фічі, але ті, яким буде приділено найбільше уваги. Наприклад, якщо ми хочемо зробити дуже красиву гру, тут можна написати про красиву графіку або атмосферні локаціїтощо.
• USP — з попереднього пункту ви вже знаєте, що це таке. Зазвичай перелік USP відбувається під кінець концепту.
• Порівняння з конкурентами — у цьому пункті бажано виділити декілька ігор у схожому жанрі, або дуже схожих на нашу гру в цілому. Можна навести приклад як дуже успішної гри, так і невдалої, та порівняти чому одна гра злетіла, а інша отримала погані відгуки. Цей пункт потрібен для того, щоб оцінити, чи є потреба у схожих іграх на ринку, які проблеми можуть виникнути, які платформи краще вибрати, якими рішеннями з інших ігор ми можемо скористатись тощо.

One-Pager

One-pager — це документ дещо схожий на пітч, він ще менший за пітч (з назви — на одну сторінку максимум) і призваний розповісти загальну ідею гри у декількох реченнях, а також виділити Key Features та USP.

GDD

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

На мою думку, такі документи не є дуже ефективними, та скоріш є пережитком минулого. На це є декілька причин:

• Постійні зміни. Якщо гра проходиться більше ніж за 30 хвилин, то заздалегідь описати її повністю неможливо. Звісно, у вас може бути бачення того, як ви хочете щоб гра виглядала. Але у процесі розробки багато механік будуть змінюватися, якісь фічі будуть викинуті, а нові, навпаки, будуть додаватися, тому цей документ перестане бути релевантним через тиждень після розробки.
• Розмір. Навігація документами таких розмірів є дуже важкою, навіть якщо організовано все ідеально. Буде витрачатися багато часу на пошуки того самого абзацу, де описана одна потрібна фіча.
• Зайва інформація. Для багатьох членів команди цей документ може містити зайву інформацію. Художникам не цікаво буде знати про те, як працюють якісь механіки, а розробники можуть не захотіти дивитися на арт-стилістику та концепти.

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

Prototype Concept

Prototype Concept або Prototype Definition — це документ, який призваний описати вашу гру на етапі прототипу, в який вже можна буде грати. Це мінімальний список контенту та фічей які необхідні для того, щоб Core gameloop працював в прототипі або демо-версії вашої гри. Так для чого потрібен сам прототип? Я виділив декілька пунктів, які можуть перетинатися:

• Зосередження зусиль. Прототип допомагає зосередити зусилля на невеликій кількості механік та речей, що ви хочете показати. Вам не треба розподіляти зусилля на збільшення масштабів гри, ваша ціль — зробити максимально фановий геймплей з тими механіками та ассетами, що ви встигли зробити для прототипу.
• Демонстрація геймплею. Прототип має демонструвати одну чи кілька ключових механік за короткий час (зазвичай 10-15 хвилин, на проходження всього прототипу). Потім цей прототип можна показати замовнику, дати пограти команді або людям не з проєкту, щоб отримати дуже багато корисного для вас фідбеку.
• Отримання фідбеку. Однією з ваших задач після створення прототипу будет збирання фідбеку. Чим більше фідбеку — тим краще, але його треба також правильно опрацювати і зробити висновки, що вам треба покращити, яким фічам треба приділити більше уваги і тд.
• Оцінка проєкту. Прототип має показати, чи вдалося вам створити фановий геймплей? Чи працюють ваші механіки на базовому рівні? Чи є у вашому дизайні якісь проблеми? Іншими словами, чи варто продовжувати створювати гру на основі вашого дизайну? Бо якщо гравці не отримують фан під час гри у демку, то повноцінна гра з тими ж механіками навряд зможе виправити ситуацію. Ідеальних результатів від прототипу не треба чекати (на те він і прототип), але варто зазначити, що провальний прототип може стати приводом до закриття проєкту.

Отже прототип є дуже важливим етапом багатьох проєктів. Щодо Prototype Concept, зазвичай, цей документ містить наступні пункти (варто пам’ятати що це приклад, вигляд документу може відрізнятися в залежності від вашої гри):

• Тривалість проходження прототипу,
• Основні механіки та фічі які будуть демонструватися,
• Що взагалі може робити гравець в рамках прототипу, його абілки, мувмент і тд.,
• Сценарій проходження прототипу:
  • З чого стартує гравець,
  • Опис локацій, які є у прототипі,
  • Опис ворогів які є у прототипі,
  • Які об’єкти може знайти гравець, як він може з ними взаємодіяти,
  • На чому закінчується прототип.

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

Design-Brief

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

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

• Оновлення. Дизайн-бріфи потребують періодичного оновлення. У проєкті постійно будуть траплятися якісь зміни, що впливатимуть або взаємодіятимуть з фічею, яку ви описали в дизайн-бріфі, тому варто підтримувати їх в оновленому стані.
• Сортування. Краще сортувати дизайн-бріфи за тими фічами та механіками, що вони описують, щоб не загубитися в них. Наприклад, бріфи, які стосуються ворогів, в одну папку, бріфи щодо ресурсів і економіки — в другу, бріфи про абілки персонажа — в третю.
• Стандартизація. Всі дизайн-бріфи бажано писати в одному форматі, одним і тим самим шрифтом, використовуючи одну мову. Таким чином буде зручніше орієнтуватися в ваших документах.
• Уніфікування. Дизайн-бріф повинен містити інформацію тільки про конкретну фічу. Він може посилатися на інші дизайн-бріфи, але сам по собі документ не повинен мати значного впливу на інші аспекти гри. Наприклад, якщо ви описуєте у дизайн-бріфі боса, то не варто у цьому ж бріфі описувати, які є абілки у гравця, щоб блокувати атаки боса — це має бути описано у окремому документі.

Дизайн-бріф зазвичай складається з наступних пунктів:

• Feature Name — назва фічі, що буде описана у документі.
• Creative Objectives — у цьому пункті гейм-дизайнер розписує загальне бачення фічі. Це може бути декілька коротких речень про основні пункти, які повинні виконуватися у рамках цієї фічі.
• Design Objectives — у цьому пункті більше детально описується, що конкретно повинна робити фіча. Тут ми маємо відповісти на наступні запитання:
  • Що робить ця фіча?
  • Для чого вона потрібна?
  • Як вона буде працювати та взаємодіяти з іншими фічами та механіками?
  • Які елементи ми повинні мати можливість налаштовувати?
• Components — у цьому пункті ми розписуємо компоненти, з яких створюється наша фіча. Тут ми маємо описати наступні моменти:
  • Всі можливі параметри фічі;
  • Як ця фіча буде взаємодіяти з іншими фічами та механіками.

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

Spreadsheets

Таблиці досить часто використовуються при створенні проєкту для тих чи інших речей, є важливою частиною документації вашої гри. Для створення таблиць зазвичай використовують Excel або Google Spreadsheets. То для чого нам можуть знадобитися таблиці і як їх використовувати?

• Економіка. Це найважливіший пункт, бо економіка присутня майже у кожній грі. За допомогою таблиць ви можете порахувати все, що завгодно, починаючи з шансу випадання зброї з лутбоксу, закінчуюючи підрахуванням часу, який знадобиться гравцеві, щоб скрафтити все можливе спорядження у грі. Якщо витратити достатньо зусиль на створення таблиці з економікою, можна отримати універсальний інструмент, який допомагатиме протягом всього процесу розробки гри.
  • Таблиці для економіки не обов’язково мають щось рахувати, це також може бути зручним місцем, де будуть знаходитися більшість параметрів гри. Дивитись та налаштовувати ці параметри в таблиці значно зручніше, ніж робити те саме в ігровому рушії. Але для цього бажано мати розробників, які зроблять інструмент, що буде автоматично переносити значення з таблиці до рушія.
• Баланс. Цей пункт дещо перетинається з попереднім, але тут я хотів приділити увагу саме балансуванню параметрів зброї, ворогів тощо. Таблиці дуже допомагають, коли треба зрозуміти: Яка зброя сильніша? Який ТТК у зброї? Скількох ворогів зможе здолати гравець на 10-му рівні? Таких питань буде безліч, і мати на них швидку, а, головне, обґрунтовану відповідь вам дуже знадобиться. Баланс у проєкті налаштовується завжди, тому такі таблиці мають стати невід’ємною його частиною.
• Створення списків. Це ще одна область, де можуть знадобитися таблиці. За допомогою таблиць можна створювати зручні списки, наприклад, абілок персонажу, робитики короткий опис до кожної абілки, id цієї абілки, посилання на JIRA тікет, у рамках якого була створена ця абілка, та інше. Я навів лише один приклад, але насправді можливості тут безмежні. Сюди ж можна додати створення таблиць для планування майлстоунів, оцінки кількості годин на створення фічі, оцінку розміру команди на кожний місяць тощо.

Conclusion

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

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