Як написати геймдизайн-документ: структура, поради та популярні помилки

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

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

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

«Поганий диздок — це той, який не відповідає на головні питання: що? навіщо? і чому?. Не можна, щоб після ознайомлення з документацією у команди, яка займається реалізацією, залишились якісь глобальні питання», — каже Євген Чувичін, Lead game designer студії VOKI Games.

У нашому матеріалі ми розповімо про те, як сформувати ефективний ГДД, який буде зрозумілим і доступним з усякого погляду.

Отже, де ж почати писати головний мануал проєкту? Існує багато популярних сервісів для організації документів (Confluence і т.п.), але оформити інформацію можна і в Google Docs.

Обсяг ГДД залежить виключно від масштабів проєкту. Для простої гіперказуальної гри, можливо, вистачить і 3-5 сторінок. Але якщо ви взялися за реалізацію чогось більш глобального, з великою кількістю рівнів, сюжетних ліній, фічей і екранів — документ може відчутно «розростися». Головне — описати все точно, а не красиво. Адже необхідно, щоб навігація по документу була зручна навіть тим, хто відкрив його вперше.

Будьте готові, що ГДД буде змінюватися з кожним оновленням гри. Якісь процеси будуть оптимізуватися, з’являтися нові фічі та персонажі, змінюватися шляхи подачі інформації, тощо..

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

• Зміст
• Вступ
• Наратив
• Геймплей
• Інтерфейс
• Фічі
• Аналітика

Зміст: тут варто описати ієрархію проєкту, посилання для навігації по документу.

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

Наратив: історія місця і події, лор, інформація про персонажів, квестові елементи.

Геймплей: ігровий процес з усіма його механіками та способами взаємодії із гравцем.

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

Також рекомендуємо розбити структуру на пункти та списки, де це можливо.

Наприклад:

Гравцеві пропонується поставити в особняку новий предмет меблів

1.1. Якщо гравець має достатньо зірок — він купує предмет

1.2. Якщо у гравця недостатньо зірок — йому пропонується пройти рівень з пошуку предметів.

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

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

Наприклад:

Ні: «персонаж підстрибує на місці, піднявши руки вгору, злякавшись шуму в каміні»;

Так: «персонаж лякається».

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

Аналітика: A / B тести, статистика з різних джерел і відстеження метрик.

Ще кілька корисних порад:

• Не соромтесь ілюструвати інформацію картинками. Дивно описувати вікно або персонажа, не доклавши до тексту його зображення;
• великі файли з референсами (картинки, відео) сильно «обтяжують» документ, та якість цих файлів відчутно псується. Картинки можна завантажити на файлообмінник або винести в окремий документ, а відео — залити на YouTube, додавши в ГДД тільки посилання;
• пропозиції повинні бути короткими та інформативними. Пам’ятаємо — ми пишемо не роман, а керівництво до дії;
• в документі повинен бути порядок: текст охайно оформлений, а кожне посилання — в потрібному місці з підписом.

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

Проте, не варто гнатися за ідеальним диздоком. Дозвольте йому оптимізуватися й оновлюватися паралельно з розвитком вашого проєкту!