Наративний дизайн у НРІ або як зробити свою гру.
- Fungaloid Bastards
- 3 дні тому
- Читати 8 хв
Що таке наративний дизайн та з чим його їдять?
Наративний дизайн – це маніпуляція емоційним досвідом гравця за допомогою створення ігрових механік. Зазвичай механіки поділяють на надсистеми, тобто ядро усієї гри, на кшталт внутрішньоігрової системи вирішення конфліктів, та підсистеми, які функціонують як допоміжні модулі, що спираються на основну систему. Це можуть бути механіки подорожей, відновлення ресурсів, взаємодії між персонажами та все інше що підтримає загальну концепцію. Особисто я вважаю, що в настільній рольовій грі з якісним наративним дизайном механіки повинні синергувати настільки, щоб межа між надсистемою та підсистемами майже зникала. У такому випадку система стає схожою на картковий будиночок: прибери один елемент і все розвалиться. Чому це добре? Тому що цілісність механік визначає цілісність досвіду. Перше, що тобі знадобиться для реалізації подібної синергії, це твоя власна обізнаність. Ми живемо в епоху, коли величезна кількість механік вже існує і розкладена по поличках. Безліч ігрових механік для закриття будь-яких потреб вже існують у тій чи іншій формі. На початку шляху я наполегливо рекомендую вивчати все, що потрапляє до рук: НРІ, скірміш-варгейми, бордгейми, карткові ігри будь-яких жанрів. Чим більше механік ти засвоїш, тим легше твоя підсвідомість комбінуватиме їх для вирішення власних задач.
На даний момент я вважаю, що найефективніший метод створення інноваційних НРІ полягає в тому, щоб при крайній поінформованості в ігрових механіках присутніх на ринку, отримувати натхнення поза ігровою індустрією. Так ти зможеш уникнути самокопіювання й, можливо, рано чи пізно натрапиш на щось справді нове у своїй голові.
Зараз я бачу вдалий момент, щоб поговорити про джерела натхнення та використання дизайн-документа у твоєму проєкті. Багато хто рекомендує, створюючи будь-який художній твір, від сценарію фільму жахів до концепту відеоігрового платформера, починати з формулювання концепту. Спробуй укласти синопсис своєї гри у кілька рядків. Не вийшло лаконічно? Не передає суть ідеї? Твоя гра лайно, міняй концепт. Ось кілька прикладів гарних на мою думку концептів:
Грибоподібні чоловічки мандрують психоделічним світом у пошуках слави.
Люди йдуть у прокляті місця з камерою в руках і гинуть.
Влада дивного міста намагається втриматися на плаву.
Стосунки екіпажу іржавого космічного корита під час перельотів.
Полювання за головами у космічному вестерні.
Єдине, що я можу порекомендувати під час написання концепту й загалом у роботі з джерелами натхнення (бо твоя гра в будь-якому разі буде на чомусь ґрунтуватись), ніколи не посилайся на інші ігри, якщо не хочеш перетворити свій проєкт на дешеве самокопіювання. Буде значно краще, якщо, розробляючи концепт про життя в пост’ядерних Штатах, ти надихатимешся не відеоігровою серією Fallout, а тим, чим надихалися її автори, наприклад, культовим Mad Max. Чим глибше копнеш, тим краще для тебе.
Щодо дизайн-документа, то це чудовий інструмент для структуризації проєкту на початкових етапах, а також (якщо прибрати з нього зайве) хороша презентація гри для аудиторії. У тебе може виникнути питання: А як має виглядати дизайн-документ і що туди писати? Така чудова людина як Трой Костісік значно спростив нам життя, розробивши спеціально для настільних рольових ігор шаблон під назвою Power19. Як можна здогадатись з назви, це 19 запитань, відповівши на які ти фактично повністю структуруєш свій проєкт. Далі залишається детально прописати ключові механіки й додати кілька нотаток про те, як і навіщо вони працюють.
Чищення системи від непотрібних елементів
Гаразд, іноді написання дизайн-документа та добра поінформованість щодо призначення ігрових механік усе ж не рятують проєкт від нагромадження непотрібних або щонайменше неоднозначних підсистем. Як бути? Тут тобі на допомогу може прийти метод, який я називаю «чисткою від пилу». Отже, інструкція з порятунку від головного болю та зайвих плейтестів: По-перше, покромсай гру до базового рівня, залишивши лише механіку вирішення конфліктів, тобто надсистему. Як саме ця механіка відображає концепцію твоєї гри? На цьому етапі ти, швидше за все, вже написав про це в Power19. Якщо ж ні, саме час це зробити. Тепер подумай: які проблеми теоретично можуть виникнути під час гри з такою системою? Додай до механіки вирішення конфліктів підсистему, що розв’язує конкретну проблему. Додавай і поєднуй підсистеми в єдину мережу доти, доки вони не перекриють усі слабкі місця. Цілком імовірно, в процесі з’ясується, що механік не потрібні, не працюють як слід або можуть бути об’єднані з іншими в щось нове, більш структуроване й гармонійне.
Я не рекомендую цей метод для деструктуризації великих ігор із важкими правилами. Та й загалом не раджу робити проєкти на 60+ сторінок, бо це, мабуть, одна з найбільших помилок новачка. На початкових етапах украй корисно робити максимально невеликі проєкти, щоб не вигорати як скотина й швидше набивати руку. Загалом, Оптимальний формат це десять-двадцять сторінок А5 для твого маленького журналу, з урахуванням ілюстрацій.
Маленькі ігри дешевші у друці, потребують менше ілюстрацій, швидше створюються, краще продаються й не змушують тебе плакати у ванній кімнаті!
Багатостраждальна "достовірність" ігрового досвіду
Формат маленького журналу значною мірою визначає загальну масу системних правил і рівень навантаження як на ведучого (якщо він узагалі передбачений грою), так і на гравців. Я не бачу сенсу обговорювати “HeavyRule” НРІ в межах статті про наративний дизайн для розробників-початківців, тому нумо розберемося, як розвантажити систему ще більше.
Якщо серйозно, я як автор ніколи не працював із НРІ обсягом понад шістдесят сторінок. Мене такі ігри не цікавлять, і я взагалі не уявляю, як їх розробляють. Це надто довгий процес для мене.
Я давно віддаю перевагу достовірності ігрового досвіду, а не симуляційному реалізму. Реалізм сам по собі не є проблемою, але в нашому випадку зовсім не обов’язково мати серед механік точну економічну модель або систему підрахунку боєприпасів. Враховуючи, що ми вже знаємо про наративний дизайн, механіки повинні давати гравцеві імерсивний, підсвідомий досвід (настільки, наскільки це можливо за столом із п’яними друзями), а не змушувати його математично прораховувати траєкторію польоту кулі, поки персонаж під адреналіном тисне на курок гвинтівки.
До речі, про адреналін і затискання гашетки. Скільки часу гравці витрачають на кидок кубика та супутні розрахунки? Скільки триває твоя «бойовка»? На скільки годин розрахована одна сесія і яка щільність подій за цей час? Ти робиш гру для коротких ваншотів чи для тривалих кампаній? Якщо перше, чи справді потрібна прогресія персонажів? Будь-який ведучий у підсумку витратить приблизно на півтори години більше часу, ніж ти очікуєш. Тож роби систему динамічнішою, ніж планував спочатку. Чим вища динаміка, тим менший розрив між рішенням гравця та його реалізацією, отже, тим вища достовірність твого проєкту.
Важливість візуального дизайну
У чому різниця між грою, написаною в Microsoft Word, і повноцінним проєктом із якісними ілюстраціями? Різниця в тому, що твою гру ніхто не купить lmao. Серйозно. Можливо, я занадто схиблений на «іграх як мистецтві» й візуалі зокрема, але зазвичай я з набагато меншим інтересом дивлюся на проєкти, які мені надсилають у вигляді тексту Times New Roman на білому тлі. Довго міркувати про це не буду, бо маю окрему статтю про те, як зробити прикольний візуал для свого НРІ-проєкту, навіть якщо ти не вмієш малювати.
Хоча, якщо чесно, вона вже трохи застаріла. Я перейшов на Affinity і планую пересісти на інші програми для створення власних шрифтів, тож, мабуть, колись зроблю ще одну оновлену статтю, присвячену візуальному дизайну.
Як утримати увагу, якщо у твоєї аудиторії РДУГ
Насамперед хочу нагадати: ми тут розробляємо не просто ігри, як би дивно це не звучало, а інструментарій для створення власних рольових сесій. Але, попри це, я не хотів би перекладати занадто багато відповідальності за динаміку та утримання уваги на ведучого чи гравців. Так, безумовно, це можливо, і багато систем саме так і працюють. Але особисто я вважаю це поганим тоном. То що ж нам робити? Існує думка, що мимовільна концентрація уваги людини триває в середньому не більше ніж тридцять секунд. А це означає, що без додаткових стимуляторів середньостатистичний гравець із концентрацією трохи кращою, ніж у золотої рибки, вже за тридцять секунд без «екранного часу» почне замислюватися, куди котиться його життя. А тепер трохи конкретики прямо тут ↓↓↓ Щоб підтримувати інтерес, потрібно зайняти його грайливі ручки, а точніше, допитливий мозок багатозадачними конструкціями. Це допоможе ведучому ввести гравця у щось на кшталт «потоку», ака Flow. Цього можна досягти кількома шляхами, по-перше, збільшити кількість лічильників стресу й інших параметрів персонажа, за якими потрібно стежити.
Для особливо недосвідчених та молодих наративних дизайнерів нагадую, що лічильник стресу це не лише про стрес або пункти здоров’я. Це може бути показник голоду, спраги, палива в транспорті, кількості смолоскипів у похідній сумці та взагалі будь-чого, що в теорії може підтримати наратив гри. Також, не варто забувати, що інструментів роботи з лічильниками безліч. Підібрати оптимальну механіку взаємодії з ними є твоїм першочерговим завданням.
По-друге, якщо наратив твого проєкту не передбачає детальне відстеження показників персонажа та/або його спорядження (якщо взагалі передбачає їх наявність, таке теж може бути), можна додати стратигічний елемент. Це не означає перетворювати гру на варгейм. Але буде значно краще, якщо під час того, як ведучий працює з одним гравцем, мозок інших буде чимось зайнятий. Це може бути більш варіативна бойова система (навіть із прихованими механіками), правила побудови маршруту, менеджмент і оптимізація ресурсів, пов’язаних із магією, або будь-що інше, що можна вигадати.
По-третє, формалізація та заохочення певних дій персонажа. Хочеш перетворити свою гру на road movie і змусити персонажів спілкуватися під час подорожей? Або прагнеш, щоб вони активніше відігравали свої ролі між собою? Це можуть бути будь-які штуки! Заохочуй це через механіки! Додавай відновлення життєво важливого ресурсу через подібні дії або дай вагому перевагу за виконання потрібних умов. Формалізуй те, що хочеш бачити в грі. Це лише три приклади того, як можна утримувати увагу гравців, які я зміг згадати, але я впевнений, що ти надалі виявиш більше можливостей для цього. Експериментуй!
Важливо розуміти, що всі вищезгадані приклади навряд чи працюватимуть поза системою заходи-Х → контрзаходи-Y. Заходами я називаю всі антагоністичні елементи механік, що спрямовані на гравців як загрози або щось, що викликає внутрішньоігровий конфлікт. У свою чергу контрзаходи це елементи механік, якими гравці можуть протистояти системі. Якщо є меч-Х, має бути щит-Y.
Ось ще кілька прикладів системи "заходи → контрзаходи":
● Персонаж надто «слабкий» для X → Прогресія через Y.
● Персонажі отримують поранення через X → Можливість захисту через Y.
● Гравці витрачають ресурс на X → Механіка його відновлення через Y.
● Провал під час перевірки X → Інструмент впливу на рандом через Y.
Основи побудови ігрового циклу
Говорячи про контрзаходи в геймдизайні, неможливо не торкнутися їх інтеграції в ігровий цикл, бо це чудова можливість структурувати нашу систему X–Y і чітко зрозуміти, коли, що і навіщо робить гравець. То що це таке? Якщо відповідати коротко, це принцип побудови ігрової механіки, який зазвичай виглядає як потреба → рішення → результат. Тепер детальніше.
Потребою зазвичай є будь-яка метаігрова ціль, викликана тими самими «заходами-Х». Це те, чого хоче гравець, зіткнувшись із певними труднощами, створеними нашою системою. У попередньому розділі я навів достатньо прикладів, які можуть викликати підсвідому потребу в їх вирішенні.
↓ Рішенням, як ти вже міг здогадатися, є так званий «контрзахід-Y». Це та частина системи, яку ми розробляємо буквально для того, щоб гравці могли вирішувати поставлені нами умови. Чим більше механік у системі націлено на закриття конкретної потреби, тим сильніше відчувається фокус на цьому типі геймплею. Пам’ятай: рішення має бути достатньо гнучким і надавати варіативність, щоб утримувати увагу гравця під час повторення ігрового циклу.
↓ Результат ми вже частково розібрали. Це може бути як повне закриття метаігрової потреби гравця, так і заміна однієї потреби на іншу (і це набагато краще, Lol). Створення підсвідомої потреби й надання гравцю гнучких інструментів для її реалізації це основа формування стійкого ігрового циклу.
Довгоочікувані підсумки
Щодо підсумків, я вирішив залишити тут вкрай корисний список із 9 пунктів, що обговорюються в цій статті. Вважатимемо, що все це має бути у твоєму проєкті, щоб під час його огляду я не заблював собі монітор:
⬥ Якщо з твоєї гри прибрати хоч одну механіку, вона не повинна працювати.
⬥ Твоя гра має мати оригінальний, але зрозумілий геймфокус.
⬥ У тебе має бути заповнений Power19 або будь-який дизайн-документ.
⬥ Це має бути невеликий журнал. Мені ліньки читати багато сторінок.
⬥ Система не має бути перевантажена симуляційними механіками.
⬥ Система повинна бути достатньо динамічною, щоб я не заснув.
⬥ Гра повинна мати повноцінні ілюстрації, верстку та шрифти.
⬥ Наявність щільного ігрового циклу максимально необхідна.
⬥ Не пиши сетинг. Благаю. Його ніхто не читатиме.
Коментарі