Буду робити ігри: розповідаю про свою першу участь у геймджемі

Привіт! Я продовжую писати про свій шлях до Indie Game Dev. Цього разу опишу свій досвід участі у GameJam.

Фінальний результат можна подивитись тут — mozokevgen.itch.io/repair-unit-01.

А далі я опишу процес його створення.

Preconditions

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

Є чітке бажання — треба закінчувати і зарелізити проєкт. І тут на допомогу приходять Game Jams.

Продивившись календар на www.indiegamejams.com і itch.io/jams натрапив на джем для початківці. І не довго думаючи взяв участь — *itch.io/...ie-game-dev-beginners-003. *Поки я писав цей пост, джем пропав з itch.io =(

Задум — зробити все самостійно. Пройти весь цикл розробки, зробити реліз, зібрати фідбек, підкорегувати відповідно.

Development

День 1. Тема джему: Robots

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

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

На цьому маємо: переміщення, top down вид і підзарядку батареї. Далі треба придумати ціль.

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

Далі сетинг. Я не прив’язувався чітко до попередньої ідеї саме постапокаліпсису. Але вирішив зробити невеликий, обмежений рівень, десь «на станції». Так можна чітко окреслити gameplay, мінімізувати розмір розробки, і потенційних багів. Що за станція, де ми знаходимось? Вирішив не пояснювати, щоб була невеличка mystery.

Наступне питання: А як саме ми будемо ремонтувати?

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

Колись у мене була ідея для іншого прототипу і там була механіка переміщення об’єктів з «інвентаря» на «ігрове поле». Тож чому ще не додати перевірку розміщених на полі елементів відповідно до шаблону. І отримаємо такий примітивний ремонт. Оскільки ремонтувати треба за допомогою різних інструментів, то у робота, окрім інвентаря, повинен бути вибір інструменту. І тут треба було теж обмежувати себе, щоб точно влізти у час розробки. Тож я відкинув думки про паяльники, викрутки та інші гаєчні ключі...

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

✅ Зробивши декілка ітерацій, прийшов до наступного вигляду:

У робота є інвентар в якому розміщенні елементи/запчастини. Для простоти вони будуть лише пронумеровані 1, 2, 3, 4.
У робота є три інструменти на вибір. Знову ж, для простоти вони будуть помічені кольорами — червоний, синій, зелений.
Для ремонту будемо мати «поле», на яке можна розмістити елементи з інвентаря.
Для кожного приладу, який треба поремонтувати, має бути схема. На ній спрощенно показано, за допомогою якого інструменту який елемент треба розмістити на полі.

❌ Відмовився від:

Детальний список елементів: резистори, транзистори, мікросхеми і т.д.
У робота є два маніпулятори. Один для розміщення елементів. Другий — з інструментами.
Складні схеми, побудовані на багатьох елементах.

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

Далі треба вирішити, що саме ми будемо ремонтувати і як переміщатися.

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

Декілька макетів на папері.

Рівень:

Тут з’явилася ідея з закритими дверима і що їх треба ремонтувати, шукаючи ресурси. Далі це перетворилося у наступну механіку: ремонт станцій буде відкривати відповідні проходи/двері. Але до фіналу дійшли лише одні двері і три станції.

Міні-гра ремонт:

1 — робот (тут ще зображені два окремих рухомих маніпулятори), 2 — поле (у фіналі розмір буде менший), 3 — інвентар, 4 — інструменти (цей блок потім переїде вгору), 5 — схема.

Тож тепер треба перейти до реалізації у рушії. Мій вибір вже якийсь час тому зупинився на defold.com.

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

Зробив стартовий екран з кнопкою старт. І зібрав просту сцену з переміщенням. Додав зарядну станцію для взаємодії.

*Тут має бути скріншот сірої кнопки на чорному екрані, синього кружечка і жовтого квадрату :) Але я його не зробив, тому просто описую :)*

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

Зібрав примітивний рівень з переміщенням:

На цьому етапі ми маємо:

Початкове меню із кнопкою старт.
Одна сцена з рівнем.
На рівні кімната зі стінами і один коридор.
Робот, яким можна керувати за допомогою WASD. Робот рухається не з постійною швидкістю, а має прискорення 100 * dt, dt — час від минулого кадру. Максимальна швидкість 400 * dt.
У робота є заряд. Просто число від 0 до 10. Під час руху заряд зменшується. За кожні 2 секунди руху заряд зменшується на одиницю.
В кімнаті знаходиться зарядна станція. Вона може бути робоча, або не робоча.
Робот взаємодії зі станцією підїзжаючи до неї.
Якщо станція робоча, то починається зарядка робота. Кожні 2 секунди заряд збільшується на одиницю.
Якщо станція не робоча, то викликається екран з відповідною мінігрою.

У міні-грі ми обираємо інструмент, переміщуємо елементи:

Зліва — поле, на якому треба розмістити елементи-деталі. В центрі інвентар з деталями і вибір інструменту (червоний, зелений, синій). Праворуч — схема, яку треба повторити викладаючи елементи на поле.

Міні-гра з ремонтом все ще складається з сірих квадратиків на чорному фоні. Шукаючи асети по тегам sci-fi наштовхнувся на чудовий піксель-арт. Ще від початку я хотів мати таку графіку. І думав, що асети від Kenney будуть тимчасовими. Але немає нічого більш постійного, ніж тимчасові рішення :) Нові асети менш яскраві і мають mystery вайб.

Тож для міні-гри з ремонтом я почав збирати сцену в дещо іншому стилі.

Задній фон:

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

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

twitter.com/...tatus/1642210819143266304

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

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

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

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

Ось так виглядає частина рівня:

На скриншоті вже є додаткові елементи і позначки, які були додані значно пізніше.

Йшов день 3 або 4.

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

Пам’ятаєте той mystery вайб. Для нього мені ще потрібен бекграунд саундтрек. Тут у пригоді став він. За запитами «sci-fi» та «mystery» я знайшов декілька треків, які при одночасному програванні поєднуються в ембієнт-саундтрек на задній фон.

Але доріжки мають зависокий бітрейт, у Defold є обмеження на 16bit і sampling rate 44’100. А ще одна з доріжок мала не дуже приємний і досить гучний «писк». Він для музики на тло був занадто відовлікаючим. Тож згадавши, що я колись чув про Audacity, пішов розбиратися, як можна це виправити. Тут я через маленьку шпарину подивився на світ роботи з аудіо, і мав відчуття, ніби дебажу звук)

twitter.com/...tatus/1642896550513836035

Результат:

https://soundcloud.com/velias-1/sets/repair-unit-01-background/s-wY8oFqouGx4?si=60db18a8e03b440d9d0111dfa624f8c7&utm_source=clipboard&utm_medium=text&utm_campaign=social_sharing

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

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

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

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

Release & Feedback

Зібрав білд під HTML5, щоб точно будь-хто і на будь-чому міг його запустити.

Завантажити гру на itch.io вийшло доволі просто. Процес доволі прямий і зрозумілий.

Скинув друзям, щоб пограли.

І тут почався фідбек...

По-перше, нічого не зрозуміло :)) Що робити, куди їхати і нашо все це?

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

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

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

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

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

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

За останні півтора дні зробив додаткові допрацювання, «поліруванням» назвати це буде досить голосно:

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

В підсумку маємо:

Гра зроблена вчасно. Подана до списку Game Jam.

Далі тільки очікування результатів. А ще грати у багато проєктів від інших розробників. І тут мене почав накривати Impostor syndrome, бо деякі проєкти були прям дууже хороші. Наприклад, мій особистий фаворит.

Після етапу голосування моя гра посіла 21 місце. Результатом я не був повністю задоволений, але для першого разу вийшло доволі непогано :)

Як висновок:

Це був дуже цікавий і корисний досвід. В результаті я пройшов повний цикл розробки і зарелізив свою першу демку для свого першого Game Jam.

А ще мені давно не було так весело просто програмувати!

Що було добре:

Обраний малий скоуп проєкту.
Більше обмеження — більше творчості.
Брати шматочки старих ідей.
До закінчення сроку здачі провести плейтести серед друзів.

Що було погано:

Мало підказок для гравця.
Мало часу виділив на pen-and-paper.
Менше тексту, більше показувати.
Оцінка, на що йде час гравця і що буде основною механікою.
Треба більше досвіду використання інструментів (game engine, graphics, audio).
Робити скріншоти в процесі, щоб потім додати їх в блог для розбавлення суцільного полотна тексту.

Теми: game jam, gamedev, indie