Мавпи разом сила: як писати інтерактивну історію командою авторів

Доброго дня, спільното! Мене звати Олександр Чезганов, я засновник Native Games Studio. Сьогодні ми з вами поговоримо про роботу сценарної команди над комплексними, розгалуженими інтерактивними історіями та всім, що з цим пов’язано. Текст базується на доповіді, яку я готував для конференції Games Gathering 2023. Бажаю приємного перегляду!

Про досвід автора

Я є засновником та наративним директором студії NGS. Останні три роки я працюю над free-to-play мобільною візуальною новелою з великою кількістю виборів та розгалуженим сюжетом. Це гра про дейтинг-шоу, де гравець (а частіше гравчиня) бере на себе роль однієї з учасниць, обирає партнера, будує стосунки та змагається з іншими парами. Ми випустили три сезони контенту для цієї гри, із загальним обсягом близько мільйона слів тексту. Кожний сезон є новою історією з новою головною героїнею і новим кастом персонажів.

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

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

Про інтерактивні історії

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

Інтерактивні історії не варто плутати з емерджентними історіями.

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

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

Наприклад, коли ви граєте у симулятори життя як The Sims, чи симулятори колоній як Dwarf Fortress чи Rim World, чи глобальні стратегії, чи виживачі з процедурною генерацією — у цих ігор немає прописаного сценарію, але в них є складні системи. І коли ви взаємодієте з цими системами, історія народжується у вашій голові. Погравши двадцять годин в The Sims, ви можете потім сісти та написати фанфік про життя династії ваших сімів. І це буде цікава історія, що є унікальною для вас і вашого досвіду. Але жоден сценарист цю історію не задумував.

Емерджентні історії це дуже цікавий топік, але сьогодні ми говоритимо лише про інтерактивні історії, які пише сценарна команда.

Про нюанси сценарної роботи у колаборації

Створення будь-якої історії охоплює багато процесів:

• створення сетингу;
• створення персонажів;
• розробка власне сюжету, як послідовності подій, що мають відбутись;
• бренч менеджмент, тобто робота з виборами та розгалуженнями (для інтерактивних історій);
• написання прози*.

Прозою я називаю фактичний текст, який гравець побачить на ігровому екрані.

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

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

Це значить, що райтер Девід зі слайду вище може писати про події вівторка, не маючи перед очами тексту про події понеділка — бо про події понеділка пише райтер Стівен одночасно з Девідом. Але Девіду потрібно знати про події понеділка, бо його текст про вівторок містить наслідки того, що відбувалось у понеділок!

А якщо історія інтерактивна, ситуація ще цікавіша:

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

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

Саме така проблема постала перед нами, коли ми розроблювали другий сезон нашого дейтинг-шоу. Щоб справитись, нам довелось звернутись до наших старих друзів: усталених робочих процесів, розподілу обов’язків та сфер відповідальності, комунікації, координації, документації.

Про наші робочі процеси

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

Для нашої сценарної команди препродакшн — це все, що передує роботі над прозою. Це етап, на якому ми обговорюємо, фіксуємо та документуємо інформацію про нашу історію. Що сюди входить?

Етапи препродакшену:

1. визначення жанру та сетингу;
2. персонажі, сюжети;
3. аутлайни епізодів.

Визначення жанру та сетингу

У випадку коли ви розробляєте нову історію, сетинг це чи не перше, що вам буде необхідно обговорити, прописати, зафіксувати. Якщо дія відбувається у фантастичному чи фентезі світі, то у вас попереду комплексна робота з побудови цього світу (worldbuilding). Якщо дія відбувається у нашому світі, вам достатньо відповісти на питання, коли і де відбуваються події.

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

Чи змінюємо ми правила нашого дейтинг-шоу?

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

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

Чи вводимо ми нові локації?

Локації є частиною сетингу, тож вони визначаються саме тут. Перші два сезоні нашого шоу відбувались у Маєтку Кохання. Для третього сезона ми перенесли дію у море, на Крузер Кохання, і гравці були задоволені такою зміною оточення.

Чи хочемо ми внести зміни в тональності історії чи типи сюжетів у порівнянні з минулими сезонами?

Так, ми вже починаємо оговорювати сюжет та персонажів, але ми поки що не займаємося ними, а скоріше створюємо запит до них. Ми визначаємо, яку історію розкажемо цього разу. Сетинг та жанр задають запит на певні сюжети та певні архетипи персонажів. Чи хочемо ми, щоб цього разу наша історія була теплою та комфортною, чи наповненою пристрастями та драмою? Чи буде зрада? Наскільки гострими будуть конфлікти? Чи буде у нас в цьому сезону сюжетна лінія «friends to lovers» або «enemies to lovers»? А може, обидві?

Персонажі. Сюжети.

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

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

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

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

Створення документації для продакшну (episode outlines)

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

Що ми тримаємо в такій документації:

• список сцен епізоду;
• детальний опис всіх подій, що відбуваються у кожній сцені;
• основні вибори, які гравець робить в цьому епізоді;
• Інформація, яку гравець дізнається в цьому епізоді (або канонічно, завжди; або опціонально, тільки за умови певних виборів).

Саме наявність таких документів, як аутлайни епізодів дозволяє нашим геймрайтерам працювати паралельно над різними частинами історії. Коли я пишу, скажімо, епізод 40, у мене немає перед очима фактичного сценарного тексту епізоду 39. Але є дещо краще! В мене є документ, в якому описано все, що відбувається в епізоді 39. Звичайно, може статись, що той райтер, який пише епізод 39, внесе в нього якісь зміни порівняно з тим, що вказано в документі. Але в таких випадках в його обов’язки входить оновити документ та попередити всіх інших райтерів через робочий чат.

Продакшн

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

1. написання прози;
2. перенос тексту в ігровий редактор в Unity engine*;
3. revision (редагування-тестування-редагування);
4. реліз — збір фідбеку — редагування.

* В деяких випадках, перший етап пропускається і текст пишеться напряму в Unity. Ми збираємо сцени в нашому кастомному редакторі нодів (на базі опенсорсного Node Editor Framework), і я, наприклад, пишу напряму в ньому. Але іншим авторам зручніше писати текст більш класичних форматах і потім переносити його в Unity.

В будь-якому місці між вказаними вище етапами відбувається оновлення документації. На цьому плавно переходимо до розмови про неї рідненької :)

Про документацію

Для вашої сценарної документації підійде будь-який сервіс, який дозволяє:

• створити ієрархію сторінок;
• робити гіперпосилання;
• роздавати ролі для редагування документів.

Фактично, вам треба створити свою вікі. Ми користуємось сервісом Notion. Можу також порекомендувати Coda чи Confluence, але впевнений, що якщо пошукати, можна знайти десяток гідних варіантів.

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

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

Ми тримаємо п’ять робочих розділів на сезон:

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

Поза сезонами ми тримаємо розділ з гайдлайнами:

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

В нашому основному рулбуці прописані:

• опис сетінгу та всі основні концепти, про які треба знати автору;
• правила форматування тексту;
• як ми працюємо з інтерактивністю;
• заборони: що ми не згадуємо, які теми обходимо стороною;
• як ми підходимо до написання персонажів.

Звичайно, чим складніший ваш проєкт і ваша історія, тим комплексніша буде ваша документація. Але ніколи не нехтуйте правилом зручності та доступності. І ще одна важлива річ, про яку хочу наголосити:

Тримайте свою документацію в одному місці.

Я раніше писав технічні завдання на арти та аутлайни епізодів напряму в таск менеджері, в картках із завданнями, бо так було типу швидше. Але потім, коли мені знадобилось повернутись до них, мені довелось шукати потрібну картку десь в архіві і це було вже дуже незручно.

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

Розробка документації це не головний біль. Головний біль — її підтримка та оновлення. Ніхто не любить оновлювати документацію, всі ліняться та забувають це робити.

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

Про розподіл відповідальності

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

Відповідальність за персонажів

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

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

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

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

Відповідальність за епізоди

Як я зазначав, основною структурною одиницею гри є епізод. За кожний епізод відповідає один з гейм-райтерів. Відповідальний райтер:

• прописує аутлайн цього епізода і затверджує його з лідом;
• пише цей епізод: самостійно або з допомогою фрілансера;
• збирає цей епізод в редакторі в юніті та здає його ліду для тестування та реліза.

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

Далі райтер писатиме прозу для свого епізода, хоча і не обов’язково сам. Наприклад, у нас є така штука як рутові сцени (від «route» — «маршрут») . У гравчині сцена побачення з її партнером, а партнером може бути будь-який з десяти доступних персонажів. Одному райтеру писати десять унікальних варіантів однієї сцени — це можна головою поїхати. Тому деякі рути він делегує іншим райтерам, кожен з них пише варіанти побачення для тих персонажів, за яких відподає, і надсилає відповідальному по епізоду.

Що дає такий розподіл відповідальності:

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

Про комунікацію та таск менеджмент

Наш розподіл комунікації виглядає так:

• 50% в робочому чаті;
• 25% гілками коментарів в документації;
• 25% зустрічі чи зідзвони.

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

Як ми зустрічаємось на етапі предпродакшну:

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

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

Як ми зустрічаємося під час продакшну

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

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

Важливо розуміти, що зустрічі грають позитивну роль як мінімум в тому, що тримають команду в тонусі та допомагають вашому ментальному здоров’ю.

Таск менеджмент

Це дуже банальна штука, такий трюізм, але все одно я проговорю: таск менеджери для роботи команди — необхідна штука. Ними треба користуватись. Якщо писати дедлайни, ставити та відслідковувати завдання по чатах, ви дуже швидко зіткнетесь з тим, що у вас в команді плутанина та бардак. Сервісів мільйон, користуйтеся тим, який вам буде зручний. Ми використовуємо Neemb, це український таск-менеджер, на кшталт Trello. Дозволяє трекати час виконання тасок та пристосований до постановки цілей за методикою OKR.

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

Про редагування

Одже. Ми провели свій препродакшн, заповнили документацію, комунікували в процесі написання нашої складної історії і маємо готовий текст на руках. Чи все в нас ідеально? Ще ні. Коли ви (в даному випадку ви — це наративний лід чи випускаючий редактор) зберете докупи всі написані складові історії, ви обов’язково знайдете проблемні моменти.

Приклад № 1: райтер забув додати перевірку на розгалуження і персонажі тепер згадують речі, які у гравця ніколи не відбувались, або в сцені присутні персонажі, які на його руті вибули з з шоу.

Приклад № 2: райтер в процесі роботи змінив фінал епізода, не оновив документацію і нікого не попередив. Тепер один епізод закінчується кліфхенгером, а в наступному про нього вже ніхто не згадує.

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

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

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

Для наративного ліда процес редагування виглядає так:

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

Райтери також можуть редагувати тексти один одного в декількох випадках:

• райтер, що є відповідальним за епізод, перевіряє рутові сцени, які для нього писав інший райтер;
• епізоди залиті на сервер для релізу; райтери долучаються до їх тестування в ранньому доступі, шукають системні чи технічні помилки, одруківки, стилістичні чи лексичні помилки (у нас фінальне тестування на девайсах все ще є черговим етапом вичитки та редагування текстового матеріалу — на девайсі з артом текст сприймається як новий, тож це дозволяє виловити те, що пропустилось при перевірці у Unity).

Про реліз

Незалежно від того, чи ви випускаєте епізоди на якусь тестову групу, чи одразу в прод — останнім етапом є реліз. Реліз може статись один раз (як, наприклад, коли ви випускаєте гру в Steam), а може бути вашим постійним гостем. Ми практикуємо поступовий випуск контенту, по одному шоу-дню (3 епізоди) раз на один-два тижні. Тривалість сезону становить 15 днів, тож стільки релізів ми і проходимо.

Але в будь-якому випадку, реліз — це час, коли ви збираєте фідбек від гравців, аналізуєте результати своєї роботи, проводите ретроспективу, фіксуєте отримані уроки... і починаєте все спочатку!

Опціонально, пишете статтю на Gamedev DOU та ділитесь вашим досвідом з колегами. Дуже дякую за вашу увагу та бажаю вам захоплюючих історій!❤️

Підписуйтеся на Telegram-канал @gamedev_dou, щоб не пропустити найважливіші статті і новини