Цей допис був написаний мовою оригіналу — італійською — Паоло Гамбарделлою. Його перекладено агентом штучного інтелекту, і він може містити неточності.
Одна з головних відповідальностей ґейм-дизайнера — писати проєктну документацію. Будь-хто може написати документ, але дизайнер займається документацією — а це різні речі.
Документ містить думки, ідеї, що завгодно. Документація ж — це конкретний тип документа про щось реальне. Дослідження гри конкурента. Результат плейтесту. Фіча, яку ми зібрали й побачили в дії. Прототип, що дав відповідь на конкретне питання.
Щоб зрозуміти, чому це правило порушують так часто, корисно подумати про те, як накопичуються знання під час розробки гри.
Concept DOCUMENTS
На початку проєкту майже все невизначено.
- Constraints | Є речі, які ми вже знаємо: цільова платформа, жанр, можливо, бюджет.
- Frontiers | Є питання, на які ми знаємо, що маємо відповісти: як працює core loop, скільки триває типова сесія.
- Risks | Є речі, про які ми ще не знаємо, що не знаємо. Дизайнерські проблеми, які вилазять лише тоді, коли гравець бере контролер до рук. Взаємодії між системами, що на папері здавались очевидними, а на практиці виявляються катастрофою. Припущення, які ніхто ніколи не ставив під сумнів, бо вони здавались настільки само собою зрозумілими, що не заслуговували уваги.
Concept document живе майже повністю в цьому третьому шарі. Це не документація — це знімок уяви команди в конкретний момент.
Game Design DOCUMENTATION
Справжня документація з’являється пізніше. Після того, як ми зробили прототип і виявили, що механіка, яка здавалась блискучою, працює не так, як ми думали. Після того, як ми проаналізували, як інша гра вирішила ту саму проблему. Після того, як ми тестували й спостерігали. Ось тоді нам є що документувати по-справжньому.
Документи і Документація
Документ слугує тимчасовій меті. Нотатки з наради — це документ. Concept doc — це документ. Список ідей, накиданих перед брейнштормінгом, — це документ. Це валідні, необхідні робочі інструменти з природним терміном придатності: вони потрібні зараз, а потім стають архівом.
Документація натомість розрахована на те, щоб залишитись.
- Вона має бути зрозумілою для того, кого не було на тій нараді.
- Вона має бути практичною — довідником, яким реально можна користуватись, а не просто читати.
- Вона має надихати того, хто читатиме її за шість місяців, коли початковий ентузіазм охолов і потрібні конкретні орієнтири.
- І вона має бути привабливою — не як естетична вправа, а тому що якщо ніхто не відкриває документ, цього документа не існує. Я дотримуюсь такої формули: 60% простору мають займати візуальні елементи (діаграми, зображення, відео…). 30% — дані й таблиці. 10% — текст. Документація — це не трактат і не роман для читання!
Не кожен документ є документацією, і проєкт потребуватиме різних типів документів. Але вашій команді потрібна саме документація.
Як виглядає справжня документація
Хороша проєктна документація однозначно відповідає на кілька питань: що це за гра? Чому вона цікава? Яка fantasy, яка емоційна обіцянка гравцеві? Які core-фічі — не всі фічі, а лише ті, що визначають ідентичність продукту? Як саме працює ця система? І достатньо виробничого контексту, щоб документ можна було взяти й використати.
Є один принцип, який я вважаю особливо корисним: якщо команда не може пояснити свою гру чітко й стисло, швидше за все, дизайн ще недостатньо сформований. Чіткість документації відображає чіткість мислення. Об’ємний документ, набитий розділами й підрозділами, що намагаються передбачити кожну можливість, — це часто сигнал того, що ми ще недостатньо знаємо, щоб документувати.
І це повертає нас до правила номер один. Якщо у вас ще немає нічого конкретного для документування — можливо, ще не час писати документацію. Час займатись дослідженням. Збирати прототип. Тестувати. Відповідати на питання, які ви ще не знаєте, що маєте. Вчитись і відкривати.
Це документує те, що існує, чи те, що ми хочемо побудувати?