Розробка ігор — це інженерне завдання
Найпоширеніша помилка — витратити півроку та бюджет на фрілансерів, а потім переробляти архітектуру з нуля. Ігровий проект влаштований інакше, ніж веб-додаток: рішення перших двох тижнів — двигун, структура сцен, мережевий код — визначають 80% вартості. Ми в Game Development понад десять років, пройшли через більшість граблів і навчилися їх уникати.
Чому 80% стартапів переписують архітектуру з нуля?
Причина майже завжди одна: неправильний вибір двигуна або відсутність технічного брифу. Клієнти починають з прототипу на випадковому двигуні. Коли проект розростається, впираються в обмеження, які не можна обійти без переписування. Ми бачили проекти, де мобільна гра на Unreal вимагала 10 секунд завантаження на iPhone 12. Навпаки — карткова гра на Unity жерла 2 ГБ оперативної пам'яті через неправильний Asset Pipeline. Щоразу це можна було запобігти на старті.
Що входить у розробку ігор
Ми здаємо не просто код, а працюючий продукт з документацією та підтримкою. Ось стандартний обсяг за більшістю проектів:
- GDD (Game Design Document) — детальний опис механік, економіки, балансу
- Архітектурний план — вибір стеку, CI/CD, система версіонування асетів, план сцен і станів
- Робочі збірки кожні два тижні — іграбельний білд для платформи клієнта
- Вихідний код, всі асети у форматованому вигляді, проект у Git або Perforce
- Технічна документація — опис архітектури, мережевого протоколу, інструкція з деплою
- Інтеграції — аналітика (GameAnalytics, Firebase), реклама, Steam SDK, IAP, Leaderboards
- Сертифікація — проходження App Store / Google Play / консольних рев'ю
- Навчання команди — якщо замовник планує розвивати проект самостійно
- Підтримка після релізу — мінімум місяць: багфікс, патчі, моніторинг кражів
Ми не продаємо години — ми продаємо результат. Замовте консультацію, і ми оцінимо ваш проект за годину. Зв'яжіться з нами — отримайте попередню оцінку протягом 24 годин.
Як ми будуємо розробку ігор: від ідеї до релізу
Аудит і планування (від 2 до 4 тижнів)
Перед першим рядком коду — технічний аудит ідеї. Інженер розмовляє з вами або продюсером: які референси, які складні місця, який цільовий фреймрейт. Вибираємо двигун (не «ми працюємо тільки на Unity», а «для вашої 2D-гри з мультиплеєром низький поріг входу дає Mirror на Unity»). Складаємо GDD, оцінюємо пул асетів, налаштовуємо Git LFS, CI/CD (GameCI або Jenkins). Без цього етапу не беремося — це страховка від переписування. Такий підхід скорочує час виходу на ринок у 2 рази порівняно з типовою розробкою без планування.
Спринти з білдами (в середньому 4–8 місяців)
Двотижневі ітерації. Кожні 14 днів — іграбельна збірка. Ви бачите прогрес і коригуєте курс до того, як неправильне рішення обросло трьома шарами залежностей. Типова команда на mid-size проекті: геймдизайнер, 2–3 розробники (C#/Unity або C++/Unreal), 3D-художник, технічний художник, аніматор, QA. На невеликих проектах ролі поєднуються.
Полірування та оптимізація (від 2 до 6 тижнів)
Оптимізація — не фінальне полірування, а наскрізний процес. На перших білдах ми вже дивимося профілювальник: Unity Profiler, Memory Profiler, Unreal Insights. Ось що робимо для мобільних проектів:
- LOD Group обов'язковий для 3D-об'єктів далі 10 метрів
- Static/Dynamic Batching + GPU Instancing — скорочуємо draw calls до 150 на мобілці (у 2-3 рази менше ніж без batching)
- Texture atlasing — об'єднання текстур, зниження числа змін матеріалів
- Addressables замість Resources.Load — контролюємо пам'ять: пікове споживання знижується в 3 рази
- Occlusion Culling — не рендеримо невидиме
Для Unreal: Nanite закриває частину LOD, але динамічні об'єкти вимагають ручної роботи. Level Streaming для світів. Material complexity — кількість інструкцій у шейдері прямо б'є по GPU time, тому ми тримаємо їх до 50 на мобільних пристроях.
Реліз і підтримка
Збірка під iOS, Android, PC, консолі. Проходження сертифікації, інтеграція аналітики, налаштування crash reporting (Firebase, Sentry). Після релізу — патчі, контентні оновлення. Ми залишаємося на зв'язку мінімум місяць, усуваємо критичні баги. Середній бюджет на mid-size гру — від 2 до 10 мільйонів залежно від складності.
Як вибрати двигун для гри?
| Тип проекту | Рекомендований двигун | Причина |
|---|---|---|
| Мобільна казуалка / гіперказуал | Unity | Швидкий ітераційний цикл, відмінна підтримка iOS/Android |
| AA/AAA PC або консоль | Unreal | Графіка, Nanite, великі відкриті світи |
| VR/AR | Unity | XR Interaction Toolkit, AR Foundation, широка підтримка гарнітур |
| 2D гра | Unity | Нативна 2D-фізика, Spine, Tilemap |
| Браузерна гра | Unity WebGL | Простота деплою, не вимагає встановлення |
| Симулятор з точною фізикою | Unreal або Unity + кастомна фізика | Залежить від вимог до детермінізму |
Client-Side Prediction — не розкіш, а необхідність для будь-якого мультиплеєра з реактивним геймплеєм. Без нього гравці бачать затримки в півсекунди і кидають гру.
Мультиплеєр: чому це архітектурне рішення, а не фіча
Мультиплеєр не можна «додати потім». Якщо почати з single-player і спробувати натягнути мережу через півроку — майже напевно переписування. Принциповий вибір: авторитетний сервер або peer-to-peer. Для будь-якої конкурентної гри відповідь — авторитетний сервер. Клієнт не повинен довіряти собі.
Ми працюємо з Photon (PUN2 / Fusion) і Mirror. Photon Fusion надає State Authority model з передбаченням на клієнті, що значно спрощує розробку чуйного input (Photon Fusion Documentation).
Mirror — open source, розгортається на своїх серверах, більше контролю, нижчі операційні витрати при зростанні кількості гравців.
Чотири технічні задачі, на яких ламаються проекти:
- Client-Side Prediction — гравець бачить миттєву реакцію, поки підтвердження в дорозі
- Reconciliation — плавна корекція стану без телепортацій
- Lag compensation — для шутерів: сервер відмотує час, щоб чесно обрахувати попадання
- Синхронізація фізики — детермінована фізика вимагає однакового порядку операцій на всіх клієнтах
Що ми гарантуємо
- 10+ років на ринку, понад 50 реалізованих проектів
- Кожен проект — технічний документ і працюючий прототип, а не «код на коліні»
- Всі вихідники та документація передаються клієнту
- Ми не кидаємо проект після релізу — мінімум місяць підтримки
- Економія часу до 40% за рахунок готових pipeline і правильного вибору стеку на старті
Типові помилки на старті — перевірте себе:
- почали розробку без GDD і технічного плану
- вибрали двигун «тому що модно», а не під задачу
- не налаштували CI/CD з першого спринту
- намагаєтеся додати мультиплеєр після написання одиночного GameLoop
- не профілюєте з першої іграбельної збірки
- використовуєте Resources.Load замість Addressables / Asset Bundles
- зберігаєте асети в Git без LFS
Технологічний стек
| Напрямок | Інструменти |
|---|---|
| Двигуни | Unity LTS, Unreal Engine 5 |
| Мови | C# (Unity), C++ / Blueprints (Unreal) |
| 3D-моделювання | Blender, Maya |
| Скульптинг | ZBrush |
| Текстурування | Substance Painter, Substance Designer |
| 2D-анімація | Spine, Unity 2D Animation |
| VFX | Unity VFX Graph, Unreal Niagara |
| Шейдери | ShaderGraph, HLSL, Material Editor (Unreal) |
| XR | XR Interaction Toolkit, AR Foundation, OpenXR |
| Мультиплеєр | Photon PUN2 / Fusion, Mirror |
| Backend | PlayFab, Firebase, власні сервери |
| CI/CD | GameCI, Jenkins, Unity Cloud Build |
| Версіонування | Git + Git LFS, Perforce (великі Unreal-проекти) |
Як почати
Якщо у вас є ідея — пишіть, ми оцінимо ваш проект за годину. Жодних складних комерційних пропозицій, тільки технічний розбір: що можна зробити, який бюджет реалістичний, які ризики. Якщо проект вже початий, але зупинився — робимо аудит коду та асетів, даємо план дій. Якщо потрібно посилити конкретний напрямок (арт, мережевий код, оптимізація) — працюємо у форматі аутстафінгу.
Замовте консультацію — отримайте реалістичну оцінку та план робіт. Зв'яжіться з нами — ми зробимо швидкий аналіз вашої ідеї.