Вітаю, спільното Друкарні!
В цьому циклі постів я розповім вам про процес розробки гри, що була створена мною та двома моїми друзями, Вітею Кульковим та Вікою Степановою, для 7-денного геймджему. Конкретно в цьому пості ви зможете ознайомитись з:
сутністю геймджему (для тих, хто не в курсі);
процесом підготовки до геймджему;
використаними тулзами.
Якщо є бажання пограти в Victory Access до того, як прочити цей пост, рекомендую пройти за посиланням. Також буду вдячний, якщо оціните гру та залишите свій фідбек у коментарях.
Що таке геймджем?
Геймджем - це захід, на якому збираються розробники ігор для створення власного проєкту за певний проміжок часу. Зазвичай, основою будь-якого джему є його тема, котрої учасники мають дотримуватись при створенні гри. Учасники збираються в команди, в котрих зазвичай представлені програмісти, геймдизайнери, артисти та інші спеціалісти геймдев напрямку, після чого вони намагаються створити цікавий та оригінальний проєкт, котрий завоює любов голосуючих.
Як геймдизайнер-початківець, я не знаю заходу краще, де б можна було відточити свої навички створення ігор. Геймджем майже завжди ставить досить чіткі та жорсткі оригінальні обмеження, котрі дають змогу проявити свою максимальну креативність. З кожною створеною для геймджему грою, я відчуваю, що стаю краще. Так, за 5 пройдених джемів, я навчився:
розуміти різницю між своїми ігровими вподобаннями та вподобаннями інших;
створювати ігри, що зрозумілі та доступні гравцю;
розуміти базову формулу цікавої та якісної гри;
та багато чому іншому.
Тож цього разу я брав участь у джемі, що проходив серед працівників компанії, де я працюю. Темою джему стало слово NET (воно ж мережа).
Важливо зазначити!
Тему джему учасники можуть інтерпретувати як завгодно. Деякі учасники сприймали слово мережа з технічної точки зору, а інші - як мережу, що створена павуком. В нашому випадку, ми намагались створити гру, що відповідала б темі в обох значеннях.
Особливість цього джему полягала в тому, що, окрім теми, учасникам також довелось дотримуватись обмеження, котре стало відомим на старті заходу. Цим обмеженням став один рівень: гравцям необхідно було вкласти цікавий ігровий досвід лише, власне, в один рівень.
Отже, перед командами геймдев-спеціалістів стояла задача створити гру за 7 днів, котра б відповідала темі мережа та обмеженню один рівень. До завершення терміну розробникам необхідно було сабмітнути свою гру, після чого відкривались два голосування: серед учасників та серед всіх працівників компанії. Учасники джему оцінювали ігри за п'ятибальною системою в п'яти категоріях:
Fun: наскільки гра цікава;
Innovation: наскільки гра унікальна;
Theme: наскільки гра відповідає темі;
Graphics: наскільки гра цікаво виглядає;
Audio: наскільки гра цікаво звучить.
Оцінки по кожній категорій виводились в середнє арифметичне, після чого складався рейтинг усіх ігор. Перші три гри вважались призерами джему.
Голосування серед всіх працівників проводилось інакше. Звичайні гравці обирали лише гру, котра їм сподобалась найбільше, без можливості оцінити кожну по категоріях. Таким чином, в результаті голосування, гра, що набрала найбільшу кількість голосів, ставала переможцем номінації People's Choice.
Підготовка до геймджему
Так як в нашій компанії працює дуже багато кваліфікованих геймдев-спеціалістів, було очевидно, що в соло буде досить важко створити конкурентоспроможну гру. Саме тому було прийнято рішення зібрати команду з декількох учасників - так до мене доєднались Вітя та Віка. Всі ми троє - звичайні тестувальники, що не мають професійного досвіду в продакшні. Проте, кожен з нас володіє деякими навичками та має інтерес до кожної геймдев галузі:
Віка взялась за арт;
Вітя - за роботу в двигуні та програмування;
я - за геймдизайн.
За два тижні до початку джему нам було відомо тільки про тему - як я казав, обмеження було анонсовано на початку заходу. Проте, вже на етапі підготовки ми мали приблизне уявлення того, що ми будемо робити:
2D гра: легше програмувати, швидше робити
Pixel Art стиль: не те, щоб простіше, але дозволяє в перспективі швидше створювати рівні та анімації
Ігровий цикл: отримати здібність -> подолати перешкоду -> пройти рівень
Зважаючи на нашу малу досвідченість і відсутність командної єдності, переді мною постала задача створити простий тестовий проєкт, аби згуртувати команду, засвоїти мінімально необхідні навички в усіх областях та побачити, на що варто розраховувати від кожного учасника. Хочу зазначити, що це дуже корисна практика, адже таким чином ви зможете отримати мінімальне уявлення про те, як ви будете працювати на джемі: на що варто розраховувати, які слабкі сторони має ваша команда та як їх нівелювати. Не варто концентруватись на тому, аби завершити підготовчий проєкт, але він дасть змогу в майбутньому набагато швидше просуватись в перші дні геймджему (наприклад, швидше засетапи проєкт, роздати перші таски, зробити перші ігрові об'єкти та їх базову логіку тощо).
Отже, незважаючи на те, що геймджем розрахований на обмежену кількість днів (в нашому випадку - на тиждень), ви можете вільно готуватись до заходу до його фактичного початку. Звісно, не варто сабмітити на джем проєкт, котрий ви почали розробляти до старту самого заходу, але створити пробник, на якому ви покращите або закріпите свої знання та навички, а також скооперуєтесь як команда, - абсолютно нормальна і навіть бажана практика.
Які тулзи варто використовувати на джемі?
Варто зазначити, що набір тулзів для геймджему залежить від ваших особистих вподобань та потреб. Так, наприклад, хтось може вважати, що одній людині не потрібна трекінгова система для розробки гри на джем (з чим я особисто не погоджуюсь, але на то воно й особисте). Загалом, якщо ви працюєте над проєктом для геймджему в команді, я рекомендую використовувати такі тулзи:
Трекінг система: для менеджменту команди (постановка задач, встановлення дедлайнів, відслідковування прогресу тощо);
Документаційна система: для геймдизайнерських процесів (брейншторм, дизайн фічей, ігровий флоу тощо);
Ігровий двигун: для безпосередньої розробки проєкту;
Git: для кооперативної розробки та страховки під час розробки;
Графічний редактор: для створення візуалу гри;
Редактор звукових файлів: для створення музики та звукових ефектів.
Далі я коротко розповім про конкретні програми, що ми використовували під час джему.
В якості трекінг системи ми використовували Trello. Це максимально простий і в той же час зручний варіант керування процесами на вашому проєкті. На імпровізованій дошці ви можете створити статуси фічей та створити для кожної індивідуальну картку з описом задачі, переліком завдань, дедлайнами тощо. Базового функціоналу в безкоштовній версії з головою вистачає для того, аби зробити командою до 5 осіб невеличкий проєкт для геймджему.
Для документаційної системи підходить безліч програм: від Microsoft Office до візуальних дошок. Цього разу вперше та востаннє я використовував Miro. Насправді дуже зручна тулза для створення документації, орієнтованої на візуал, але, на жаль, після джему я дізнався про те, що програма була зроблена росіянами.
До речі!
Якщо знаєте гарні альтернативи Miro, діліться в комментарях. Також буду вдячний, якщо порадити альтернативи Notion, котрий також відносно нещодавно потрапив в скандал за надання своїх послуг росіянам.
Загалом, документаційна система потрібна вам для того, аби фіксувати ваші геймдизайнерські рішення, що дозволяє не тільки створювати технічні завдання для арту та програмування, а також банально не запам'ятовувати ваші попередні рішення. Як я вже казав, для цього підійдуть і всім відомі Word, Excel та PowerPoint.
В якості двигуна ми використовували Unity. Альтернатив йому також досить багато, тому давайте коротко відповім, чому не:
Unreal Engine 5: вважаю, що він не годиться для традиційних 2D ігор інді формату;
Godot: дійсно легкий старт для початківців (саме в ньому я створив свої перші ігри), але принципи роботи доволі сильно відрізняються від вже засвоєного мною та Вітею Unity;
будь-який інший двигун з візуальним програмуванням (GameMaker Studio 2 та йому подібні): ми вже володіємо основами програмування, достатніми для створення невеличких проєктів.
Загалом, великим плюсом Unity є його висока популярність, що забезпечує його користувачам велику кількість навчальних матеріалів. І хоча далеко не всі з них корисні і не на все можна знайти необхідні відповіді, туторіалів на тому ж YouTube набагато більше, ніж для будь-якого іншого двигуна.
Для того, аби всі мали на своїх комп'ютерах доступ до проєкту, а також могли вносити свої зміни без шкоди для сумісної розробки, ми використовували GitHub Desktop. Насправді, небагато можу тут додати, окрім як заклику використовувати системи контролю версій. Вона убезпечить вас від втратити проєкту, а також дасть можливість відкатитись на декілька кроків назад у випадку, якщо ви створили якийсь критичний баг, у котрого не бачите кінців.
В якості графічного редактора ми обрали Aseprite - як на мене, ідеальна тулза для створення ассетів в стилі Pixel Art: проста, зрозуміла та доступна (має безкоштовний аналог). Ми використовували її для створення ігрових об'єктів, тайлсетів карти, а також анімацій та візуальних ефектів. В цілому, для створення такого простого, але чудового візуального стилю Вікі знадобилось відносно мало часу (два тижні вона засвоювала інструментарій, і за днів 5 намалювала все, що ви можете побачити у грі).
Для звукових ефектів ми використовували Audacity - також доволі проста програма, котра дозволила Вікі проста записати свій голос, а також різні маніпуляції з папірцем або попкорном, аби отримати гармонійні звуки для пересування, смерті, активації тощо. Але для музики ми використовували Bosca Ceoil - як на мене, ідеальна програма для геймдевів, котрі взагалі не розуміються в музиці. Інтерфейс трошки складний при знайомстві, але загалом дозволяє простими кліками створити фонову мелодію.
Думаю, також варто зазначити, що ми майже не використовували штучний інтелект для створення нашої гри. Коли я кажу "майже", я маю на увазі два запити в ChatGPT, котрі ми обговоримо в наступному довгочиті цієї серії. Загалом, я не побачив необхідності використовувати штучний інтелект в нашому випадку, адже:
з точки зору геймдизайну ШІ мало чим міг мені допомогти з настільки абстрактною темою та обмеженням (принаймні з моїм вмінням спілкування з ШІ на сьогоднішній день);
з точки зору арту Віка мала всі навички, аби створити той візуальний стиль, на котрий ми розраховували;
з точки зору програмування в мене було гарне уявлення архітектури проєкту, аби сапортити Вітю під час виконання його задач.
Отже, під час розробки вашого проєкту дуже важливо визначитись із трекінговою та документаційною системами, ігровим двигуном та системою контролю версій до нього, а також графічним та музикальним редакторами. Цих інструментів буде достатньо для зручного створення вашого успішного проєкту.
На завершення
Якщо ви хочете створювати ігри, закликаю вас брати участь у геймджемах. Це неодмінно цікавий досвід, який допоможе застосувати теорію на практиці, а також надасть вашим навичкам значний буст у розвитку. Незважаючи на те, що захід обмежений за часом, ніхто не забороняє вам завчасно підготуватись до нього - це дозволить вам зекономити час безпосередньо на джемі, адже ви вже знатимете, як підходити до розробки.
Особливо рекомендую визначитись із інструментарієм, котрий ви будете використовувати під час джему. Підберіть рішення під себе та засвойте мінімально необхідну базу, аби не припускатись банальних помилок, котрі або заберуть багато дорогоцінного часу, або значно вплинуть на якість вашого проєкту в негативному плані. Так, наприклад, одна із команд забула виключити візуалізацію колізії в Godot, через що у фінальному проєкті напівпрозора синя заливка на платформах повністю вбила увесь візуальний стиль їх проєкту - банальна та проста помилка, котра коштувала команді дуже дорого.
В наступній серії поговоримо про геймдизайн, а саме про те, як в нашої команди народилась загальна ідея Victory Access і як я поглиблював її до того результату, з котрим ви можете ознайомитись за посиланням.
Дякую за те, що прочитала пост до кінця. До зустрічі!
