Як написати диздок



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

Про те, як написати диздок, який існує у великих компаніях (автор цих рядків працював з документацією Obsidian Entertainment, Тільки Team, Raven Software, The Workshop, Slightly Mad Studios, викладає курс проектної документації в геймдизайні у Вищій школі бізнес-інформатики НДУ ВШЕ на програму професійної перепідготовки Менеджмент ігрових інтернет-проектів), і буде ця коротка стаття. Зрозуміло, кому-то описане в ній може здатися очевидним. Вона розрахована на тих, хто якраз шукає відповіді на питання «як написати диздок» або хоче влаштуватися працювати геймдизайнером у велику компанію-розробника. :)

Проектна документація зараз являє собою не великий дизайн-документ, не набір файлів MS Office, і навіть не файли в Google Docs. Майже завжди це вікі-движок. Найбільш популярний Atlassian Confluence, але можна зустріти і MediaWiki, як правило, з безліччю плагінів і використовується в «старих» компаніях, і DocuWiki для невеликих pet-project'ів або для маленьких студій. Тому готовність роботи з документацією великих проектів варто починати з уміння працювати з прийнятим на проекті вікі-движок. Те, що описується як «диздок», зазвичай замінено трьома окремими документами в вікі:
  • Концепт-документ – короткий виклад самої ідеї гри. Виду «У нас буде онлайн-гра про запуск і перехоплення ядерних ракет з нескінченним геймплеєм, видовищними спецефектами і асинхронним PvP!». У ньому описується ідея і основні складові ігрового процесу (дуже коротко), а також пара самих ключових USP («unique selling point», те, що «продасть» ідею гравцеві і унікально на ринку).
  • Vision – це вже більш розгорнутий документ, що описує те, що хочеться отримати в результаті. Не сам ігровий процес, а всю гру, як кінцевий бізнес-продукт.
  • Feature List (може бути обгорнутий в інші документи в залежності від моделі розробки) – список з коротким описом фичей, того, з чого складається гра. Наприклад, складання ядерних ракет, аркадний перехоплення, асинхронне PvP, кланова система, система досягнень, і так далі, як правило, з посиланнями на окремі документи з детальним описом геймдизайну (про це далі). Також в ньому кожної фиче виставляється пріоритет, вартість і послідовність розробки.


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

Тепер переходимо до Vision. Цей документ вже масштабніше, і звичайно включає в себе наступні елементи:
  1. Короткий опис гри. Тут вже не тільки основна ідея, а гра в цілому.
  2. Жанр ігри.
  3. Цільова аудиторія та дослідження ринку.
  4. Приклади подібних ігор на ринку і відношення до них: конкуренти вони чи ні, є перетин аудиторії, запозичення чи протиставлення ідей.
  5. USP (Unique Selling Points) ігри – те, що виділить гру на ринку, і що використовують маркетинг для залучення трафіку / нових гравців.
  6. «Формула успіху» – які елементи гри будуть самими якісними / важливими. Це може бути революційна графіка, чесна фізика і т. д. Тут на відміну від USP потрібна не унікальність, а якість.
  7. Складові геймплея, коротко.
  8. Сеттінг і стиль гри. Наприклад, жорстокий кіберпанк в жовто-сірих тонах, світле епічне фентезі в аніме-стилі, тільки куди детальніше і з прикладами арту;
  9. Бізнес-модель, в тому числі монетизація.
Послідовність і мети написання тут очевидні: написавши концепт-документ, геймдизайнер визначає основну ідею. Далі в Vision він описує, як і чому ця ідея буде працювати: на якій аудиторії, за рахунок яких елементів проект буде користуватися успіхом, і як він буде заробляти гроші. При цьому, написання концепту і Vision – ітеративний процес. Написавши концепт, можна спробувати продати запропоновану в ньому ідею (інвестору, начальству, на крайній випадок – самому собі) і покращувати його до тих пір, поки ідея не буде продана. Написавши Vision, можна оцінити, чи є у гри шанси на популярність і комерційний успіх, і переробляти його, змінюючи USP, сеттінг, стиль та інші змінні, поки не буде хоч якась впевненість в результаті.

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

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

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

Однак у будь-якої великої компанії потрібно поєднувати три речі:
  • Шаблони. Так, шаблони і творчість можуть здаватися важко сумісними, але якщо на проекті кілька геймдизайнер, і кожен пише, як йому заманеться, продюсерам і виконавцям це радості не додасть.
  • Зв'язки з іншими документами, фічами і завданнями. Кожен диздок – це не просто сферичний текст у вакуумі. Він входить в якусь групу (наприклад, PvP-фічі), посилається на інші документи, що містить в собі перелік завдань (в JIRA/Bugzilla/Trello/GitHub/...), оцінки готовності, посилання на звіти тестерів і результати плейтестов.
  • Власне, фан і геймплей! За всіма верствами структури диздока важливо не втратити те, що гра все-таки повинна бути цікавої і захоплюючої, фіча повинна працювати в плюс всій грі, а не просто виконувати відірвану від загальної ідеї задачу.
Що ж варто описати в диздоке? Крім просто описів самої фічі, є чимало інших елементів:
  • Автор і статус (чернетка, в роботі зроблено, відмовилися, застаріло). Коли на вікі сотні диздоков, і за довгі роки працювали десятки геймдизайнер, без цих простих розділів зрозуміти, який диздок актуальне, важко.
  • Поточна завдання. Що хочеться отримати. Приміром, забезпечити гравців розвагою, поки тренуються війська в казармах.
  • Причини виникнення завдання та необхідності вирішення. Важливий пункт, наявність якого рятує від фичей «щоб круто було» або «у конкурентів є». Останнє – бич багатьох геймдизайнер, коли фічі копіюються дочиста, навіть незважаючи на те, що багато їх елементи в розробляється грі зайві, не будуть працювати або працюють в мінус, навіть якщо у конкурента це USP і приносить величезний дохід.
  • Короткий опис рішення. Щоб можна було охопити загальну ідею.
  • Розгорнутий дизайн. Детальний опис реалізації.
  • Очікуване поведінка гравця, типова сесія. Потрібна для того, щоб відповісти на питання «А як це грати?» з позиції гравця. Без цього легко отримати фічу, яка начебто і має сенс, але гравці на форумах пишуть "І що це взагалі таке?".
  • Місце фішки в грі та зв'язок з іншими фічами. Очевидно, фіча повинна підтримувати і доповнювати інші фічі або загальний геймплей гри, а не повторювати або пригнічувати їх собою.
  • Завдання на реалізацію і ассет лист. Список того, що потрібно зробити, щоб фіча запрацювала: які функції на рівні коду, що намалювати художнику, потрібно написати тексти реплік персонажів сценаристу і т. д. Іноді це становить продюсер, але нерідко і сам геймдизайнер.
  • Необхідна статистика. Яку інформацію збирати і аналізувати з плейтестов і серверів. Як багато часу гравці проводять в геймплеї фічі? Їздять вони на конях або автомобілях в фиче про засоби пересування, стріляють з Сайги або Вепра в ближньому бою шутера?
  • Потрібне тестування (+ edge cases). На що QA-відділу звернути особливу увагу при перевірці фічі. QA можуть таке складати і самі, але нерідко тільки геймдизайнер може відразу сказати, що «якщо раптом гравець експлойтів типу складання еліксирів набере 1000 навички Торгівлі, то зможе продати товар дорожче, ніж купив, і зламає всю економіку! Тому потрібно переконатися, що таке неможливо навіть теоретично».
  • Deployment і оперування. Розділ для оператора. Як описати фічу в patch notes? Потрібно викласти про неї статтю в енциклопедії гри? Чи потрібно щось відібрати у гравців і видати компенсацію для запуску фічі?
  • Плани на майбутнє. Власне, всі ідеї, які можуть поліпшити фічу в майбутньому.
Звичайно, цей список може змінюватися в залежності від фічі, роботодавця і ступеня терміновості написання дизайну. Тим не менше, там, де це потрібно і можливо, бажано не забувати про таких пунктах. Як правило, після всіх цих пунктів диздока, геймдизайнера чекає останній пункт… коментарі! Більшість вікі-движків мають таку функцію, і чимало колег — від інших геймдизайнер до програмістів і тестерів — з радістю поділяться своїми міркуваннями з приводу вашого геймдизайну. :)



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

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.