Документація - основа гри

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

Бажання зробити гру у нас було давно, і спроб робилося багато. Ми брали різні ідеї, збиралися з духом і сідали їх реалізовувати. І кожен раз розробка тривала не більше місяця. А все тому, що ми робили одну і ту ж велику помилку.

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

Все проходило неорганізовано, ніхто не мав уявлення про те, чим зайняті інші учасники проекту. І, природно, ні до чого хорошого такий підхід не приводив. Ентузіазм швидко згасав, бажання робити незрозуміло що за просто так пропадало абсолютно. Жоден з таких проектів не був реалізований.

Однак рік тому ми отримали цінний досвід, створюючи свою квест-кімнату (escape room). Щоб не втратити вкладення, довелося все планувати, організовувати, встановлювати терміни і доводити проект до реалізації. Тільки докладний опис кожної загадки і ретельне продумування деталей дозволило завершити проект.

І ось, використовуючи отриманий досвід, цієї зими ми почали робити свою гру. З самого початку ми вирішили підійти до процесу розробки ґрунтовно і спершу підготувати документацію.

Дизайн документа

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

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

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

У нашому випадку жанром стали 3d аркадні битви з видом зверху. Короткий опис виглядає так: аркадні мережеві битви на човнах. Гру вирішено було робити на PC з можливістю зібрати версію під Mac і Linux. В якості ігрового движку ми вибрали Unreal Engine 4.

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

Ігровий об'єкт гарпун

Загальний опис:

"На носі човна знаходиться гармата з якої стирчить гарпун. До гарпуну причеплена мотузка, яка з'єднує його з човном ".

Параметри, що використовуються:

• Максимальна відстань;
• Сила притягування;
• Час перезарядки;
• Час дії гака;
• Кількість використань.

Поведінка гарпуну:

• Повертається навколо своєї осі в напрямку прицілу;.
• При пострілі - у напрямку прицілу вилітає гурпун, тягне за собою мотузку;.
• Якщо довжина троса більше або дорівнює максимальній відстані, він рветься, кількість використань зменшується на 1 і відбувається перезарядка;.
• Якщо снаряд натикається на скелі або береги - притягує човен до них;.
• Якщо снаряд натикається на об'єкт оточення (колоди, інші човни) - притягує їх до човна, а човен до них;.
• Після закінчення часу дії трос гарпуну рветься. Після цього кількість використань зменшується на 1 і відбувається перезарядка;.
• Коли кількість використання гака стає рівною 0, поточний бонус у човна замінюється на відсутній..

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

Заключну главу наповнили відомості про маркетинг і аналіз конкурентів. Це дозволяє вже на ранніх етапах розуміти, які кроки і коли слід робити для просування гри. Так, наприклад, щоденник розробника і групу проекту можна створити і заповнювати практично відразу після початку розробки.

Опис для художника, моделлера і аніматора

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

Спершу ми сформували детальне уявлення того, як повинна виглядати гра.

Кожному ігровому об'єкту (якому був потрібен концепт-арт), ми присвятили окремий пункт у документі. Там описували свої уявлення про об'єкт, докладали фотографії або зображення, які допомагали краще передати наші думки.

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

Начерки варіантів персонажів

Фінальний концепт персонажа

Приклад концептів зброї та персонажа в човні

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

Модель двигуна човна

Коротка інформація:

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

Кількість полігонів: 1000-1500;

Текстури: Diffuse. Роздільна здатність: 512x512;

Анімації: Не потрібні.

Деякі моделі потребують анімації. Кожен опис анімації містив тривалість, тип (одиночна або зациклена) і максимально докладне наше її подання Наприклад так описаний удар веслом:.

Удар веслом

Персонаж лівою рукою відпускає двигун, бере правою рукою весло, яке лежить у човні праворуч від нього. Бере за самий край, щоб зробити удар якомога далі, привстає, замахується веслом за спину. Перед початком атаки (після замаху) кумедно підстрибує для більшої сили удару і б'є навідмаси вниз-вперед. Кінець анімації - правою рукою кладе весло назад у човен, лівою рукою береться за двигун. Анімація одиночна. Тривалість 0.5 - 1 сек.

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

Опис композитора і звуковика

Документація з музики і звуків гри, має багато спільного з описом анімацій. Кожен ігровий об'єкт має свою таблицю. У них записувалися назва звуку, тип (одиночний або зациклений), тривалість і опис того, де і коли буде програватися цей звук. Для зручності роботи музиканта і щоб звуки краще поєднувалися з анімаціями, були записані короткі відеоролики з ігровими ситуаціями, в яких цей звук повинен відтворюватися.

Звуки для ігрового об'єкта весло

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

Ув'язнення

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

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

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

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