Наративний дизайн у НРІ або як зробити свою гру.

Що таке наративний дизайн та з чим його їдять?

Наративний дизайн – це маніпуляція емоційним досвідом гравця за допомогою створення ігрових механік. В основному заведено ділити ігрові механіки на надсистеми, які виступають корінням усієї гри, на кшталт внутрішньоігрової системи вирішення конфліктів, та підсистеми, які є додатковими модулями, що ґрунтуються на основній системі. Це можуть бути допоміжні механіки подорожей, поповнення ресурсів та все інше що спаде тобі на думку. Насправді я вважаю, що в настільній рольовій грі з дійсно хорошим наративним дизайном механіки повинні синергувати настільки, що грань між підсистемами та надсистемою практично стирається. Таким чином, твоя рольова система стає схожою на картковий будиночок — прибереш один елемент і все розвалиться. Чому це добре? Цілісність досвіду, що передається гравцеві.

Перше, що тобі знадобиться для реалізації подібної синергії, це твоя власна обізнаність. Ми живемо в епоху, коли все вже придумано та розкладено по поличках. Безліч ігрових механік для закриття будь-яких потреб вже існують у тій чи іншій формі. Я наполегливо рекомендую на початку свого шляху вивчати все, що потрапить до рук ― НРІ, Скірміш-варгейми, звичайні бордгейми та карткові ігри будь-яких жанрів. Чим більше ти засвоїв механік, тим простіше твоїй підсвідомості видавати контент для закриття саме твоїх потреб.

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

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

Ось кілька прикладів гарних на мою думку концептів:
● Грибоподібні чоловічки мандрують психоделічним світом у пошуках слави.
● Люди йдуть у прокляті місця з камерою в руках та вмирають.
● Влада дивного міста намагається триматись на плаву.
● Відносини екіпажу іржавого космічного корита під час перельотів.
● Полювання за головами у космічному вестерні.

Єдине що я можу порекомендувати при написанні концепту та в цілому при роботі з джерелами натхнення (бо твоя гра у будь-якому випадку буде на чомусь ґрунтуватись), ніколи не посилайся на інші ігри, якщо не хочеш перетворити свій проєкт на якесь дешеве самокопіювання. Буде набагато краще, якщо при розробці концепту про життя в пост-ядерних штатах ти надихатимешся не відеоігровою серією Fallout, а тим, чим надихались автори цієї гри, а саме культовим Mad Max. Чим далі ти зайдеш, тим краще для тебе.

Щодо дизайн-документа, то це чудовий засіб структуризації проєкту на початкових етапах його розробки, а також, якщо прибрати з документа всю зайву інформацію, гарна презентація своєї гри для аудиторії. Як має виглядати дизайн-документ і що туди писати? Така чудова людина як Трой Костісік чудово спростив нам життя у цьому моменті, розробивши спеціально для настільних рольових ігор шаблон документа під назвою Power19. Це як можна здогадатись із назви, 19 запитань, відповівши на які ти фактично повністю структуруєш свій проєкт. Далі можна детально прописати ключові механіки та залишити пару нотаток про те, як і нащо вони працюють.

Чищення системи від непотрібних елементів

Гаразд, іноді написання дизайн-документа та гарна поінформованість про призначення ігрових механік не завжди рятує проєкт від нагромаджень непотрібних, або щонайменше неоднозначних підсистем. Як бути?

Тут тобі на допомогу може прийти метод, який я називаю "чисткою від пилу". Отже, інструкція порятунку від головного болю та зайвих плейтестів: По перше, покромсай гру до базового рівня, залишивши тільки механіку вирішення конфліктів, тобто надсистему. Як ця механіка відображає концепцію твоєї гри? На даному етапі ти, швидше за все, вже написав про це в Power19, якщо ж ні, то саме час написати! Тепер, які проблеми можуть теоретично виникнути при грі з цим? Додай до механіки вирішення конфліктів підсистему, що вирішує цю проблему. Додавай та об'єднуй підсистеми у єдину мережу доти, доки проблеми не перестануть виникати. Цілком ймовірно, в процесі виявиться, що багато ігрових механік не потрібні, не працюють як треба або можуть бути об'єднані з іншими механіками в щось нове, більш структуроване та гармонійне.

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

Маленькі ігри дешевше коштують для друкарні, менше потребують ілюстрування, швидше робляться, краще продаються і не змушують тебе плакати у ванній кімнаті!

Багатостраждальна "достовірність" ігрового досвіду

Формат маленького журналу багато в чому визначає загальну масу системних правил та навантаження як на ведучого (якщо він взагалі враховується твоєю грою) так і на гравців. Я взагалі не бачу сенсу обговорювати "HeavyRule" НРІ в контексті статті з наративного дизайну для розробників-початківців, тому нумо дізнаємось як розвантажити твою систему ще більше.

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

Я вже давно віддаю перевагу достовірності ігрового процесу, ніж симуляційному реалізму. Реалізм це не завжди погано, хоча у нашому випадку необов'язково мати серед ігромеханік проєкту точну економічну модель та систему підрахунку боєприпасів. Враховуючи, що ми вже знаємо про наративний дизайн, механіки твоєї гри повинні давати гравцеві саме імерсивно-підсвідомий досвід (принаймні наскільки це можливо у грі за столом з п'яними друзями), а не змушувати його математично прораховувати траєкторію польоту кулі, поки його персонаж під адреналіном тисне на курок своєї гвинтівки. It's so much fun, Jan!

До речі про адреналін та затискання гашетки. Скільки гравці витрачають часу на кидок кубика та супутні розрахунки? А скільки часу займає твоя "бойовка"? На скільки годин розрахована одна сесія твоєї гри та яка щільність подій за цей час? Ти робиш гру для коротких ваншотів чи тривалих кампаній? Якщо перше, чи потрібна прогресія персонажів? Будь-який ведучий буде витрачати в цілому на 80 хвилин більше часу, ніж ти. Роби систему динамічнішою, ніж хотів спочатку. Чим вища динаміка, тим менший у гравця розрив між прийняттям рішень та реалізацією задуманого, а отже вища достовірність твого проєкту.

Важливість візуального дизайну

У чому різниця між грою написаною на Microsoft Word та нормальним проєктом з гарними ілюстраціями? Різниця в тому, що твою гру ніхто не купить.
Серйозно, можливо я занадто схиблений на "ігри як мистецтво" і візуалі зокрема, але я зазвичай з менш вираженим інтересом дивлюся на проєкти, які мені відсилають звичайним Times New Roman на білому папері. Довго міркувати про це не буду, бо маю цілу окрему статтю про те, як зробити прикольний візуал для свого НРІ проєкту, навіть якщо не вмієш малювати. Read&develop yourself.

Як утримати увагу, якщо у твоєї аудиторії РДУГ

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

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

А тепер трохи конкретики прямо тут ↓↓↓

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

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

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

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

Важливо розуміти, що всі вищезгадані приклади навряд чи працюватимуть поза системою заходи-Х → контрзаходи-Y. Заходами я називаю всі антагоністичні елементи механік, що спрямовані на гравців як загрози або щось, що викликає внутрішньоігровий конфлікт. У свою чергу контрзаходи це елементи механік, якими гравці можуть протистояти системі. Якщо є меч-Х, має бути щит-Y.

Ось ще кілька прикладів системи "заходи → контрзаходи":
● Персонаж гравця надто "слабкий" для Х → Прогресія персонажа через Y.
● Персонажі гравців отримують поранення через X → Персонажі можуть захищатись за допомогою Y.
● Гравці повинні витрачати ігровий ресурс на Х → Гравці можуть відновлювати ресурс через Y.
● Провал під час перевірки X → Вплив на рандом під час перевірки через Y.

Основи побудови ігрового циклу

Говорячи про контрзаходи в геймдизайні неможливо не торкнутися його інтеграції до ігрового циклу, бо це чудова можливість структурувати нашу систему X-Y і чітко зрозуміти, коли що та навіщо робить гравець. То що це таке? Якщо відповідати коротко, то це принцип побудови ігрової механіки, який зазвичай виглядає як потреба → рішення → результат. Тепер детальніше.

Потребою зазвичай є будь-яка метаігрова мета, викликана тими самими "заходами-Х". Це те, чого хоче гравець, зіткнувшись з певними труднощами, викликаними нашою системою. У попередньому розділі я навів достатньо прикладів, які можуть викликати підсвідому потребу у гравців до їх вирішення.
↓
Рішенням як ти вже міг здогадатись є так званий "контрзахід-Y". Це та частина системи, яку ми розробляємо буквально для того, щоб гравці могли вирішувати поставлені нами умови. Чим більше механік у системі націлено на вирішення конкретної потреби, тим більше відчувається фокус на цьому типі геймплею. Пам'ятай, що рішення має бути досить гнучким та надавати різноманітність, щоб утримувати увагу гравця при повторенні ігрового циклу.
↓
Результат ми вже частково розібрали. Це може бути як повне вирішення метаігрової потреби гравця, так і заміна однієї потреби на іншу (це набагато краще лол). Створення підсвідомої потреби у чомусь і надання гравцю гнучких інструментів її реалізації є основним для формування стійкого ігрового циклу.

Довгоочікувані підсумки

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

⬥Якщо з твоєї гри прибрати хоч одну механіку, вона не буде працювати.
⬥Твоя гра має оригінальний, але досить зрозумілий геймфокус.
⬥У тебе має бути заповнений Power19 або будь-який дизайн-документ.
⬥Це має бути невеликий журнал, мені ліньки його читати.
⬥Система не має бути перевантажена симуляційними механіками.
⬥Система повинна бути достатньо динамічною, щоб я не заснув.
⬥Гра повинна мати повноцінні ілюстрації, верстку та шрифти.
⬥Наявність щільного ігрового циклу максимально необхідна.
⬥Не пиши сеттинг, благаю, його ніхто не читатиме.