Нещодавно ми опублікували інтерв’ю із замовником Ярославом Р., у якому він поділився досвідом розвитку стартапу на Freelancehunt. Нагадаємо, що Ярослав має 10-річний досвід розробника в напрямках веб, ігри, backend/frontend. Сьогодні розкажемо деталі про його новий проєкт — розробку гри.
Бонус: про свою частину роботи над проєктом також розповіли фрилансери сервісу, які співпрацювали із замовником.
Наталія Сиротюк
Про гру та її особливості
Ярослав, замовник:
Merge House — це гра, яка дозволяє об'єднувати та перетворювати звичайні будинки на кращі будинки більшого рівня та отримувати за це нагороди.
Історія проєкту почалася, коли я шукав ідею для гри, чогось цікавого і простого на базі вже готового. Тоді я знайшов шаблон гри і придбав за $100 на сторонньому сайті. Вона була про мерж будинків на двигуні Construct 3. Гра так захопила мене та мою сімʼю, що стало цікаво реалізувати її.
Я спробував довести її до пуття, шукаючи виконавців, але на жаль двигун не виявився популярним. Тому прийняв рішення шукати розробників на більш популярному двигуні Unity та створити ігри вже на базі готових.
Unity-розробник Юрій про деякі технічні особливості:
У цієї гри досить цікавий підхід щодо взаємодії клієнта застосунку, який користувач встановлює на пристрій, із сервером. Взаємодія гри із сервером будується на запитах — гравець щось питає у сервера, а він надсилає відповідь. Гра логічна, і суть у тому, що логіки гри на клієнті немає взагалі. Тобто гра просто не знає, як у неї треба грати, вся ця логіка лежить на сервері.
Коли людина робить крок — торкається пальцем — гра відсилає певні запити на сервер з інформацією: «Людина взяла таку клітинку і зробила з нею таке. Що має бути далі?». Тоді сервер надсилає інструкції, що далі треба відтворити. Виходить, що сама гра на телефоні — ніби плеєр, який відтворює все, що скаже сервер. Звісно, у рамках загальної архітектури. Якби сервер просто надіслав чергу команд, то гра могла б грати сама в себе. Це досить цікаво і зручно для тестування, бо ігрові проєкти потребують багато тестів. Майже кожне натискання на якусь кнопку передбачає, що клієнт спілкується із сервером, отримує від нього інструкції й тоді вже щось відтворює для користувача.
Також часто ці запити не одиничні: один запит складається з кількох комплексно, як конструктор. Саме цей сервер має дуже зручний інтерфейс користування, який зроблений модульно. Можна надсилати купою запити й отримувати купою відповіді в тому самому порядку, в якому надходили запити.
Можливі ситуації, що на якомусь запиті виникає помилка — дані пошкодилися на шляху чи сервер виявив логічну несумісність у процесі й просто видав код помилки на запит. Але оскільки надсилається цілий набір запитів, то не вся черга запитів збивається, а гравець отримує відповідь, на якому конкретно кроці й чому щось пішло не так. Такий підхід дозволяє покроково отримати інформацію на кожен надісланий запит у кожній відповіді. Це не дуже цікаво виглядає для неспеціаліста, але технічно дуже круто 😃.
Спеціалісти, залучені до розробки гри
Розробка гри складалася з кількох етапів. До роботи були залучені такі спеціалісти:
- GD — гейм-дизайнер: будує документацію та описує основні екрани, механіки гри, взаємодію гравця.
- UX/UI-дизайнер: реалізує задум геймдизайнера за документацією та робить зручний інтерфейс і красиву графіку.
На проєкті працювали 2 фрилансери для 2 різних концепцій гри — основної та скіна. - Unity-розробник: імплементує екрани згідно з GD документацією у вигляді логіки та двигуна гри.
- Backend-розробник: створює необхідну логіку, яка обчислює гру на сервері.
- Тестувальник: перевірка результатів та опис сценаріїв.
Фрилансери поділилися своїм досвідом у створенні цього проєкту.
Олексій Чміль, геймдизайнер
Етапи роботи над грою
Моя робота на проєкті складалася з таких етапів:
1. Зрозуміти для початку ідею гри, яку хоче втілити замовник.
2. Скорегувати її так, щоб вона підходила до ЦА: сеттинг (набір умов, в яких відбувається дія), механіки, монетизацію тощо.
Перед запуском проєкту замовник має чітко уявляти свою ЦА, бо від цього залежатимуть рамки як у геймплею та динаміці гри, так і в сеттингу й монетизації.
Спочатку ми проаналізували, хто є переважною ЦА в жанрі Merge. Ми уявляли, о котрій годині дня приблизно люди грають у такі ігри, що їх мотивує грати.
Потім продумували, який геймплей та сеттинг більше підійде обраній ЦА.
3. Після розуміння концепції починається етап написання дизайн-документу (GDD) — максимально повного опису гри. Якоїсь чіткої структури написання GDD поки не існує. Кожен геймдизайнер сам вирішує, якою буде архітектура GDD. У мене, наприклад, написання GDD для мобільних ігор починається з малювання у Photoshop скринів HUD (прозорого екрана, розташований поверх основного ігрового екрана) та інших ігрових вікон, як-от профіль гравця, меню, магазин тощо.
Нижче під картинкою я роблю таблицю з двох колонок. В одній пишу «Що бачимо», в іншій — «Що це». Приклад:
Так іншим спеціалістам, які беруть участь у розробці гри, зручніше читати GDD та розуміти геймплей гри.
Такий метод написання GDD я сформував за перші 2 роки кар’єри геймдизайнера. Зараз активно його покращую та підлаштовую до різних проєктів.
З боку геймдизайну найбільш важливо вирішити ігровий цикл (кор-геймплей) та сеттинг гри, бо це перше, на що дивитиметься та оцінюватиме гравець. Далі потрібно правильно зробити розрахунок балансу та економіки гри із закладенням «гачків» для монетизації. На це витрачається чимало часу.
Оксана К., UX/UI сайту гри та UX/UI альтернативної графіки для гри
Навички, які знадобилися для роботи над проєктом
Мене завжди приваблювала можливість розглянути внутрішні механізми ігор та їх функціонування. Мої проєкти переважно спрямовані на вебсайти та мобільні застосунки, тому розробка геймдизайну стала новим викликом, який вимагав додаткових навичок. Ось декілька ключових навичок, які допомогли мені опанувати геймдев:
- Освоєння ігрових механік: розуміння того, як працюють та взаємодіють між собою різноманітні ігрові механіки, як-от рівні, завдання, системи нагород тощо.
- Графічний дизайн: навички у створенні й редагуванні графічних елементів, інтерфейсів та ілюстрацій. Охоплює використання графічних програм, наприклад. Photoshop, Illustrator.
- 3D-моделювання: в основному наша візуальна частина була спрямована на елементи, які включають 3D.
Особливості роботи
Спочатку ми визначали основну концепцію гри та ключові елементи. Акцентували на інтуїтивно зрозумілих та зручних для гравців елементах. Наприклад, розмістили кнопки керування у таких місцях, які природно виглядають для гравця та доступні під час гри. Це особливо важливо для мобільних ігор, де простота та зручність використання на сенсорному екрані є критичними факторами успіху. Використовували відомі символи й інтерактивні елементи, щоб гравці могли легко розуміти, як взаємодіяти з грою, — стрілки для переміщення персонажа чи кнопки з піктограмами для видалення.
Для гри обрали популярний стиль kawaii, відомий м'якими формами та приємним естетичним відчуттям.
Для візуалізації нашої концепції створили концепт-арт 3D-персонажів. Для цього використовували 3D-моделювання. Основна програма для створення персонажів — Blender. Це доволі складна програма, яка має широкий набір функцій та інструментів, а його інтерфейс здається заплутаним для новачків. Тож перед створенням персонажів мені знадобився час, щоб ознайомитися з основними елементами інтерфейсу та їх функціями. Проте освоєння базових функцій інструменту дозволило створити моделі.
За час роботи над проєктом я здобула багато нових навичок. Ефективна комунікація, створення прототипів для перевірки концепцій та постійний аналіз результатів дозволили покращити продукт.
Замовники, які прагнуть успішно завершити проєкт, мають звернути увагу на кілька важливих моментів. По-перше, чітко визначте вимоги та очікування щодо результатів роботи. По-друге, забезпечте регулярний зворотний зв'язок та спілкування, що допоможе розв'язувати проблеми оперативно.
Вікторія Сорокіна, UX/UI-дизайнер
На проєкті я займалася створенням UI і трохи UX. В основному UX було завданням геймдизайнера, але я також вносила свої пропозиції та ідеї. Ще створювала анімацію.
Детальніше про етапи роботи
- Зазвичай робота починається з аналізу ніші та аудиторії, з'ясування цілі гри. Для цього проєкту було небагато вимог. Це проста казуальна гра, спрямована на те, щоб користувач відпочив і, звісно, витратив гроші). Отже, усі елементи гри мають допомагати втілювати ці цілі.
- Наступний етап — пошук схожих ігор, конкурентів, їх оцінка, пошук того, що хотілося б перейняти та що можна покращити.
- Далі підбір референсів — тобто знайти роботи, стиль яких хотілося наслідувати. Також це допомагає узгодити бачення із замовником. У цьому разі було побажання мінімалістичної стилістики.
- Процес створення UI починається з головних компонентів, ігрового екрана, ігрових елементів, узгодження із замовником.
- Поступово створюємо інші екрани, вікна, і нарешті анімацію. Насправді за всієї своєї простоти було багато етапів змін і покращень.
Еволюція екрана гри
Детальніше розкажу про роботу над екраном гри та його еволюцію. Ось найперший прототип для ігрового екрана. Я зробила фон, ігрове поле, намалювала перший будинок і намітила кнопки.
Далі ми зрозуміли, що хочемо бачити пласкі, а не об’ємні клітинки на полі. Спробували іншу кольорову варіацію. Я створила всі будинки (основні ігрові елементи) і перший варіант дизайну кнопок.
Але в такому варіанті будинки не виділяються, милить очі. Тоді ми вирішили, що у кожного будинку має бути клітинка власного кольору, а вільні клітинки мають бути нейтральними. Також зробили кнопки простішими.
Уже виглядає значно краще.
У цій грі чим вищий рівень, тим крутіший будинок має бути. Спочатку для найвищого рівня я зробила будиночки палацевого типу. Але хоча це і відповідало головній концепції, разом з іншими вони не виглядали цілісно. Тоді ми замінили їх на будинки більш сучасного дизайну.
Далі на екран додалося ще багато нових елементів. Ми пробували грати самі й залучали близьких та знайомих. Отримали користувацький фідбек: багатьом людям було незрозуміло, який будиночок ставитиметься наступним. І тоді зробили на ньому більший акцент, а інші будиночки в черзі заховали під скляний купол та додали текстове роз’яснення.
Далі етап фіналізації: спростили і водночас зробили ще зрозумілішими іконки на бонусах (нижні кнопки), фіналізували інші елементи. До речі, те віконечко з текстом — результат тестування гри на собі. Коли закінчується місце на полі, то закінчується гра, але гравець може не помітити, що зараз займе останнє вільне місце. Дуже неприємно програти через свою неуважність, отже ми його повідомляємо й одразу спонукаємо купити якісь бонуси для очищення поля.
Або ось вікно закінчення гри — чудовий приклад, як UX/UI впливають на користувацький досвід.
Один з мотивів продовжувати грати — це певний змагальний дух, який рухає гравцем. Треба зробити якомога більше з’єднань, щоб підвищити рівень турнірного кубка і піднятися вище в рейтингу. Якщо все-таки гра закінчилась, зʼявляється сумне вікно з доволі сухою статистикою, яка ніякої цінності не несе.
Хоча й гравець бачить, скільки заробив за цю ігрову сесію, але це не радує, бо водночас втрачається кубок з якимось високим рівнем, якого він досягнув. Усе це впливає на загальний настрій.
І ось протилежність — в кінці гри бачимо, як багато рівнів досягли, отримуємо приз і можливість викупити свій кубок у наступній грі. І все радісно світиться. Від цього екрана вже немає відчуття поразки й хочеться продовжувати гру.
В UX/UI-дизайні гри найбільш важливо, щоб усі компоненти допомагали досягати основних цілей проєкту, а кожен елемент спрощував і покращував користувацький досвід. Треба керувати увагою гравця, спрямовувати її туди, куди потрібно. Завжди варто обирати шлях, де гравцю треба зробити найменшу кількість дій для досягнення певної мети.
До речі, у гри є як альбомний, так і портретний режим — усе для зручності гравців.
Юрій Шмигля, Unity-розробник
Про аспекти роботи
Розробка гри включає багато аспектів і сфер спеціалістів:
- Є графічний дизайн — персонажі, оточення тощо. Його малює художник-дизайнер.
- Є дизайн інтерфейсу — кнопки, панелі, віконця — для взаємодії користувача з грою. Це робить UI/UX-дизайнер, тобто інший спеціаліст.
- Є звуки, тому може бути людина, яка займається звуковим оформленням.
- Є людина, яка придумує ігрові механіки — як усе має працювати, які будуть правила. Скажімо так, придумує правила гри, а також чисельні значення для балансу: скільки здоров’я в якого ворога має бути, яка зброя якої шкоди завдає і т. д. Це game-дизайнер.
- Є ще програміст — розробник, який технічно зв’язує всі ці сфери разом. На основі документів від game-дизайнера та графічних файлів від дизайнерів збирає разом у якомусь середовищі.
Я працюю в Unity і роблю так, щоб ці графічні файли та вся логіка запрацювала, оживляю це все. Пишу певний програмний код, який потім реалізує логіку, щоб усе виконувало свої функції.
Приймаю від спеціалістів їхню роботу, а на виході віддаю замовнику готовий файл. Також займаюся тестуванням, апдейтами, відстежую та виправляю баги й помилки.
Як проходила робота над грою
На початковому етапі замовник формував своє бачення того, як все має працювати, і що він чекає від гри. У текстовому документі він детально та зрозуміло занотував побажання. Далі під час спілкування ми відразу вносили в документ уточнення чи побажання щодо покращення.
Ефективна розробка включає також використання наявних готових рішень та їх адаптацію, а не намагання все робити з нуля. Це економить час і гроші замовника.
Після того, як ми сформували загальне бачення, під час первинної співпраці розробляли окремий модуль для цієї гри. Він відповідав за взаємодію контенту гри із сервером, щоб гра не просто тримала в собі весь необхідний контент, а з власного сервера підтягувати оновлення. Наприклад, на Новий рік ми замінили файли на сервері. Людина відкриває гру перед Новим роком, а там новорічна атмосфера. І для цього не треба оновлювати гру через маркет.
Мені зручно кожне завдання розбивати на підзавдання, а потім з них формувати майлстоуни — невеликі ділянки роботи. Далі я працюю в межах цих майлстоунів. Після виконання певного обсягу роботи ми із замовником дивимося, чи правильно все рухається і чи виходить очікуваний результат. Тільки після погодження і закриття цього етапу переходимо далі.
Замовник постійно контролює перебіг виконання робіт, тримає руку на пульсі, завжди розуміє, що відбувається, і першим має можливість побачити, коли щось починає йти не зовсім так, як би йому хотілося. Тобто виключаються ситуації, коли виконавець зробив багато, а замовник в кінці сказав, що взагалі не це мав на увазі.
У такому ключі ми працювали до кінця проєкту. У процесі роботи я також комунікував з іншими технічними спеціалістами, якщо мені щось було потрібно. Це значно спрощує роботу та підвищує ефективність співпраці.
Під час роботи завжди доводиться опановувати нові інструменти. Не буває точки, коли ти дійшов до певного рівня знань і цього достатньо. Практично кожен проєкт — це якісь нові речі.
Інколи дрібні, коли достатньо просто 20-30 хв скористатися Google, самому затестити, як працює. А буває, що це може бути якась нова сфера, і ти просто розбираєшся практично, робиш тести, шукаєш рішення від інших людей. Починаєш з пошуку готового рішення і можливості адаптувати його під потреби проєкту. Якщо немає — шукаєш відповіді в суміжних питаннях, де можна частково взяти ідеї, використовуєш свій досвід, щоб сформувати щось власне.
Найчастіше — це синтез: знаходяться готові рішення, додається щось своє і виходить унікальне в конкретному проєкті.
Також час від часу з’являються нові інструменти. У моїй роботі дуже часто використовуються нові плагіни — невеликі готові модулі. Замовник купує їх у магазині, а мені за документацією треба розібратися, як це працює, та опанувати, як активно використати для проєкту й інтегрувати.
Кілька порад замовникам для успішного результату
Найперше — замовнику треба чітко розуміти, що він хоче, намагатися детально уявити фінальний результат. Інколи люди мають загальну ідею, але бачення фінального результату немає. Під час консультацій з виконавцями треба якомога детальніше викласти всі свої думки та побажання щодо майбутнього проєкту, знайти референси (зображення, відео, текст), щоб фрилансер сформував правильне уявлення про завдання.
Виконавець — не чарівник, йому треба зрозуміти, що від нього хочуть. Чим менше ви надали інформації, тим більше фрилансер змушений робити від себе. І тоді фінальний результат може відрізнятися від того, що очікує замовник.
І тут ми приходимо до чіткого ТЗ. Чим більше замовник витратить часу і сил на технічне завдання, тим менше він потім часу і грошей втратить під час роботи. А для виконавця це буде більш ефективна та приємна співпраця.
Що важливо: постійно комунікувати з виконавцем, найбільш детально викладати свої думки й побажання, контролювати процес виконання робіт у розумних межах, давати максимально повну інформацію щодо проєкту. Якщо технічний спеціаліст викладає свої поради та думки, варто до них прислухатися, бо людина має досвід у цій сфері, тому може підказати хороші рішення.
Ярослав Р., замовник
Мені подобається працювати з нашими фрилансерами, серед них багато талановитих людей. Деякі люди інвестують в акції, а я із цим награвся і вирішив інвестувати у технології, у себе, у знання, які потім зможу передати чи поширити. Також у будь-який момент я здатен це масштабувати. Якщо з’явиться можливість інвестування третьою стороною, то у мене є цінні контакти, люди й надійна схема роботи з ними.
З деякими фрилансерами я також розробляю певні технічні рішення, щоб на базі них робити потім ще інші стартапи. Це інвестиція у свою технологію, яку потім можна використати для побудови інших бізнесів. Своєрідна адмінпанель, яка містить всі проєкти, які я робив.
Є цікаве завдання? Відкрийте проєкт і отримайте десятки пропозицій від фрилансерів сервісу, які виконають його швидко та якісно!
