Написати код — не означає зробити гру: мій рік інді-розробки, асети, ШІ і переписане ядро

Всім привіт! Мене звати Олександр, я Unity Developer. Останній рік я працюю над своєю інді-грою War Pawns, а приблизно пів року — вже досить активно. І за цей час зрозумів одну дуже неприємну річ: реальні проблеми починаються після завершення роботи над прототипом.

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

Я досить консервативний у своїх ігрових вподобаннях і більшість часу перепроходжу старі ігри. До нових релізів ставлюся скептично, а PvP у Stronghold і Age of Empires ми з братом уже затерли до дірок. У якийсь момент виникла ідея зробити щось своє: гру, у яку цікаво було б грати з іншими, але без настільки жорсткого мікроконтролю, як у класичних RTS.

Мені також імпонують настільні ігри й сетинг Другої світової війни. Так поступово й сформувалася War Pawns — покрокова тактична стратегія в сетингу WWII. Назва для мене теж не випадкова: вона постійно нагадує мені шахи, де важливий кожен маневр, а кожен хід може стати вирішальним для долі матчу.

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

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

Саме тут для мене почалася найболючіша частина розробки.

Коли ти програміст, контент сам себе не зробить

Я ніколи не позиціонував себе як 3D-художника. У мене є мінімальний досвід роботи з Blender, але цього точно недостатньо, щоб спокійно закривати всі потреби гри в моделях чи анімаціях. Так само не дуже добре в мене і зі створенням 2D-арту.

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

Не склалося. Принаймні не так, як я собі це уявляв.

Основне вузьке місце виявилося не лише технічним, а й моральним та фінансовим. Уже близько пів року я без роботи, тому не можу дозволити собі просто найняти 3D-художника чи окремо людину на 2D та інтерфейс і сказати: «Зробіть мені все красиво».

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

У якийсь момент просто розумієш: коли ти програміст із мінімальним досвідом у створенні 2D- і 3D-контенту, питання вже не в тому, чи буде проблема, а в тому, де знайти контент, який закриє поточні й майбутні потреби гри. І ще зробити так, щоб усе це виглядало стилістично цілісно.

Куплені асети: найшвидший старт, але не безмежна свобода

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

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

Ранній вигляд War Pawns

Те, як гра виглядає зараз

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

Тому так: куплені асети дуже добре вирішують питання швидкого старту, але дуже швидко створюють проблему масштабування.

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

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

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

Що я робив сам

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

Найкращий приклад — гекси для поля бою. Моделі я зробив у Blender. Я не великий спеціаліст, але накидати просту геометрію можу. Це не персонажі й не складні об’єкти, але це елемент, який дуже сильно впливає на загальне відчуття гри, і тут я хотів мати хоча б якийсь контроль.

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

Інтерфейс я переробляв рази зо три. Навіть зараз не певен на сто відсотків, що це фінальна версія.

Одна з попередніх версій інтерфейсу

Поточний варіант інтерфейсу

Ну і, звісно, окремо робив різний медіаконтент: капсули, трейлер і все, що стосується візуального представлення гри назовні.

Мабуть, саме тут я найкраще відчув різницю між «купити» і «зробити самому».

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

Із плюсів тут не лише контроль, а й відчуття. Відчуття, що ти не просто «закрив задачу», а реально зробив щось так, як воно мало бути і як ти це бачив у своїй уяві. Саме в такому контенті, мабуть, і відчуваєш найбільшу впевненість.

ШІ у продакшені: не магія, а дуже обмежений інструмент

Окрема тема — це ШІ. Я знаю, що вона поляризує людей, тому мені цікаво говорити про неї не теоретично, а з позиції людини, яка реально намагалася цим користуватися в роботі над грою.

У моєму випадку ШІ використовувався насамперед для 2D-арту й для модифікації голосу, щоб зробити різну озвучку.

Якщо щодо голосу питань майже не було — там усе вдалося зробити досить швидко, і короткі репліки юнітів лягли в гру органічно, — то з 2D-артом у мене була зовсім інша історія.

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

Не готово.

На практиці все вийшло майже навпаки.

Генеративний ШІ може видати окрему картинку більш-менш пристойної якості. Але проблема в тому, що грі майже ніколи не потрібна «одна окрема красива картинка». Грі потрібен набір елементів в одному стилі, які виглядають як частина одного продукту.

Саме тут я, мабуть, і витратив найбільше часу дарма. Протягом останніх пів року я постійно повертався до генерації й перегенерації: пробував добитися хоча б якоїсь стилістичної цілісності, вручну редагував результат у Photoshop, знову генерував, знову правив. У підсумку результат можна назвати «більш-менш робочим», але точно не таким, щоб сказати: «О, ШІ швидко й дешево закрив мені задачу».

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

Хоча я також допускаю, що просто не сформував правильний робочий підхід до використання ШІ.

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

Найдорожча помилка була не в арті

Цікаво, що найбільший факап за весь цей час був не пов’язаний з асетами.

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

І тут стало очевидно, що частина базової функціональності не була закладена достатньо гнучко. У результаті довелося переписувати ядро гри.

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

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

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

До чого я прийшов зараз

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

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

Поточний стан гри: юніти, редактор карт

Поточний стан гри: юніти, редактор карт

І якщо спробувати звести весь досвід до кількох практичних висновків, то вони були б такими.

По-перше, якщо ти не моделлер і в тебе немає бюджету на повноцінного спеціаліста, готові 3D-асети — це нормальне рішення. Не ідеальне, але цілком робоче.

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

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

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

Якщо вам цікаво, як War Pawns виглядає зараз, ось сторінка гри в Steam. Буду радий фідбеку.

І тому мені справді цікаво почути досвід інших.

А як ви закриваєте питання контенту в грі, якщо ви соло-розробник і насамперед програміст? Купуєте готові асети, замовляєте арт, шукаєте однодумців у команду чи поступово тягнете це самостійно?

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