Технічне написання сценаріїв та діалогових дерев для ігор

Ми пишемо сценарії та діалогові дерева для ігор — не кіносценарії з пробілами під репліки. Це технічний документ зі станами, умовами та розгалуженнями, який одночасно читає наратив-дизайнер і парсить двигун діалогів. У типовій інді-студії наратив-дизайнер пише текст у гуглодоці, програміст переносить у код з прапорцями — і після 10 гілок логіка ламається. Ми вирішуємо цю проблему, створюючи сценарії під ключ: від наративного документа до протестованого діалогового дерева в Unity або Unreal Engine. Досвід — 8 років у геймдеві, 20+ проєктів з діалоговими системами. Гарантуємо логічну цілісність розгалужень.

Як влаштоване діалогове дерево?

Діалогове дерево — це орієнтований граф, де один вузол може мати кілька вхідних зв'язків. Кожен DialogueNode зберігає speaker ID, текст репліки, список вихідних ребер (DialogueEdge[]), опціональні умови входу та actions (тригери ігрового світу). Умови перевіряють ігровий стан: QuestFlag("rescued_merchant") == true, PlayerLevel >= 5, Reputation("thieves_guild") > 30. Якщо жодна умова не виконана — гілка прихована або замінена fallback-реплікою. Actions впливають на світ: видати квест, додати предмет, змінити репутацію. Цей поділ на conditions та actions — основа будь-якої наративної системи, будь то Yarn Spinner, Ink або кастомний редактор.

Який інструмент обрати: Yarn Spinner чи Ink?

Yarn Spinner — текстовий формат з синтаксисом, близьким до Twine. Умови пишуться прямо в скрипті: <<if $player_level >= 5>>. Команди: <<jump NodeName>>, <<set $flag = true>>. Він простий в освоєнні: новачок розбереться за день. Чудово підходить для лінійних діалогів з розгалуженнями. Детальніше про інструмент можна дізнатися в Yarn Spinner.

Ink — потужніша мова з концепцією knots та diverts, підтримкою лічильників відвідувань (visited, visit_count) та weave-структурою для паралельних наративних потоків. Використовується в Disco Elysium, 80 Days, Heaven's Vault. Ink обробляє складні наративи в 2 рази швидше, ніж кастомні C#-системи, але потребує більше часу на освоєння (близько тижня).

Для 200 рядків діалогу в action-RPG достатньо Yarn Spinner; для наративної гри з 100k+ слів і розгалуженою історією — Ink. Ми допомагаємо обрати правильний інструмент під ваш проєкт.

Як писати репліки, які не ламаються технічно?

Кожна репліка має працювати без попереднього контексту. Перевірка: прочитати репліку ізольовано — якщо незрозуміло, про що йдеться, потрібен fallback-контекст. Варіанти відповідей не повинні бути порожніми: «Так», «Ні», «Розкажи більше» — погані варіанти. Замість них використовуйте «Я вже чув про це», «Продовжуй, мені цікаво», «Немає часу — що потрібно?». Ці варіанти передають характер персонажа.

Локалізаційні мітки: кожен рядок отримує унікальний ID на кшталт NPC_MERCHANT_GREETING_01, а не порядковий номер. Так перекладач бачить контекст в ID. Це стандарт при роботі з LocalizationTable в Unity.

Як діалоги вбудовуються в квести?

Один NPC може мати різні репліки залежно від QuestState: NotStarted, InProgress, ObjectiveComplete, Turned In, Failed. Мінімум 5 версій діалогового дерева на квест, або одне дерево з умовними гілками. Типова помилка: забути про Turned In — гравець після здачі квесту чує видачу завдання повторно. Ми перевіряємо всі стани і додаємо fallback-репліки. Економія на правках — до 40% часу QA.

Що входить в роботу?

Процес роботи: етапи

1. Наративний документ — опис персонажів, мотивацій, ключових точок.
2. Структура вузлів в інструменті (Yarn Spinner Visual Editor або Articy:Draft).
3. Чернетка діалогу — текст реплік та варіантів відповідей.
4. Технічне рев'ю на виконуваність умов та actions.
5. Правки та фінальний текст.
6. Тестування всіх гілок вручну з логами (виявлення мертвих гілок та вузлів без виходу).

Типові помилки та як їх уникнути

• Відсутність fallback-реплік при невиконаних умовах — гравець бачить порожні гілки.
• Використання порядкових номерів рядків замість осмислених ID — плутанина при локалізації.
• Занадто довгі «гілки-одноденки», не подумавши про повернення NPC у вихідний стан.
• Ігнорування станів квесту — забувають про Turned In.

Наприклад, у проєкті з 10 квестами та 2000 рядків діалогу ми знаходимо до 15 мертвих гілок та 8 вузлів без виходу. Наше тестування усуває їх до передачі в продакшен.

Як відбувається оцінка проєкту?

Ми аналізуємо наративну структуру, кількість персонажів, розгалужень та цільовий двигун. Оцінка займає 1 день. Результат — точні строки та вартість, розрахована індивідуально. Економія на тестуванні завдяки ретельному логічному аналізу становить до 40%.

Орієнтовні строки

Ми маємо 8+ років досвіду в геймдеві та 20+ реалізованих проєктів. Гарантуємо логічну цілісність діалогів. Зв'яжіться з нами для безкоштовної оцінки вашого проєкту. Отримайте прототип діалогового дерева вже через 2 дні.

Проектування механік: з чого починається чуйне керування

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

Перший біль: вам здається, що керування «дубове», а чому — незрозуміло. Найчастіше проблема не в коді, а у відсутності coyote time та jump buffering. Наприклад, у платформерах без coyote time гравець програє 20% спроб через відчуття «нечесної» смерті. Або в лінійному прискоренні, яке не дає відчуття ваги — замінюємо на криву початкового ривка з подальшим загасанням. Ми це виправляємо на етапі прототипу, скорочуючи подальші правки на 40%.

Окрема категорія — економіка. Без попередньої математичної моделі розвал настає через місяць після релізу. Тому ми починаємо з прогресії: лінійна, експоненціальна або поліноміальна. Наприклад, для RPG використовуємо поліном a * n^b з b=2.0, перевіряючи, скільки годин гравець витратить на кожен рівень. Це дає прогнозований час гри і дозволяє уникнути дисбалансу монетизації.

Які послуги з геймдизайну ми пропонуємо?

Повний цикл: від концепту до вивіреного білду. Під ключ — ви отримуєте геймдизайн-документ (GDD), таблиці балансу, прототип ключових механік на Unity/Unreal, і супровід аж до релізу. Гарантія якості — покрокове узгодження на етапі прототипу, щоб уникнути переробок.

Що входить в роботу (deliverables):

• Документація: GDD, специфікації механік, наративні дерева, API для розробників
• Таблиці балансу: прогресія, економіка, DPS-калькулятори
• Прототипи: інтерактивні сцени з core loop (рух, бій, інвентар)
• Конфігурація в рушії: ScriptableObject, DataTable, анімаційні події
• Проведення плейтестів та ітерацій за метриками (утримання, монетизація, retention)

Оцініть ваш проект — зв'яжіться для розрахунку термінів. Підхід заснований на методології MDA та досвіді 50+ реалізованих проектів, більше 10 років на ринку. Наші замовники економлять від 2 до 3 тижнів на ітераціях завдяки чіткому процесу.

Як спроектувати бойову систему без помилок?

Бойова система — найдорожча помилка: на перший погляд проста, на ділі — пекло з edge cases. Розберемо melee combat.

Вибір методу hit detection

Hitbox — колайдери на зброї. Просто, але при швидких атаках виникає tunneling: зброя пролітає крізь противника за кадр. Рішення — Physics.CCD (Continuous Collision Detection), але це дорого. Raycast/spherecast — кастуємо промені вздовж траєкторії зброї. Точніше, менше залежить від fps. Ми віддаємо перевагу spherecast для action-ігор. Докладніше про методи — у статті про виявлення зіткнень.

Налаштування вікон атаки

Кожна атака — три фази: Startup, Active, Recovery. Довгий startup створює «важкі» удари. Короткий recovery дає агресивний стиль. В Unity аніматор кидає подію через AnimationEvent, код вмикає/вимикає hitbox. Типові таймінги для рукопашного бою: startup 200–400 мс, active 100–150 мс, recovery 300–500 мс. Зміна startup з 400 на 250 мс змінює відчуття з «важкий» на «середній» — це фіксується в метриках.

Побудова state machine

Персонаж — скінченний автомат. Базові стани: Idle, Moving, Jumping, Attacking, Hurt, Dead. Бізнес-логіку виносимо в C#-код, аніматор відповідає лише за переходи анімацій. Ієрархічні state machine (через Override Animator Controller) дозволяють вкладені підстани, не дублюючи переходи.

Чому математична модель економіки критична?

Економіку «на око» не роблять — виходить розвал через місяць після релізу. Базова прогресія: лінійна (нудно), експоненціальна (XP(n) = base * multiplier^n, multiplier 1.5–2.0), поліноміальна (a * n^b, b 1.5–2.5). Ми будуємо таблиці в Google Sheets за 2–3 дні, перевіряючи, скільки годин гравець витратить на кожен рівень.

Потоки валют

Принцип: кожна валюта — явне джерело (tap) і стік (sink). Приклад двовалютної системи:

Однонаправлена конвертація захищає монетизацію. Дисбаланс легко виявити за DPS і TTK: якщо TTK зброї вдвічі нижче за інші — воно стає meta. Ми виявляємо це на етапі прототипу, скорочуючи наступні правки на 40%.

Наратив та левел-дизайн: як навчати без тексту?

Environmental storytelling — розташування об'єктів, звуків, слідів — часто ефективніше за діалоги. Для діалогів використовуємо Ink (інтеграція з Unity). Ink-скрипти читає наративний дизайнер без програміста. Кожен рівень перевіряємо за принципом: гравець повинен зрозуміти механіку дією, а не за підказкою.

Інструменти в процесі

Ітерація та плейтестинг: 2-тижневий цикл

Перший прототип завжди незручний — це норма. Наш цикл: плейтест кожні 2 тижні. Після — список змін з числами: «startup 400 мс → 250 мс». Думки без чисел не приймаються. Фіксуємо відчуття, змінюємо числа, повторюємо. Завдяки цьому середня економія бюджету на етапі ітерацій становить 15–20%.

Зв'яжіться для консультації — ми оцінимо терміни та бюджет вашого проекту. Отримайте прототип core loop за 3 тижні. Сертифіковані фахівці Unity/Unreal гарантують дотримання термінів.