Розробка технічного стека та вибір модулів ігор
«Беремо Unity, там все є» — це не технічний стек, це відсутність рішення. Unity надає базовий движок. Але вибір Render Pipeline (Built-in / URP / HDRP), підхід до мережевого коду (Netcode for GameObjects / Mirror / Photon / Nakama), система аналітики, backend для збереження, IAP-провайдер, CI/CD інфраструктура — все це потрібно вибрати та обґрунтувати до початку розробки.
Неправильний вибір на старті коштує дорого. Наприклад, URP обраний для мобільного проекту — правильно. Але через три місяці потребувалися кастомні post-process ефекти — і з'ясувалось, що команда використала вбудовані Renderer Features неправильно, несумісні з target API Level. Перехід з URP на Built-in посередині розробки — це 2–4 тижні переробки матеріалів.
Render Pipeline: принципи вибору
Built-in Render Pipeline — legacy, але все ще актуальний для проектів з максимальною сумісністю (WebGL, старі Android, Nintendo Switch через специфічні паттерни). Максимальна екосистема Asset Store-сумісності.
URP (Universal Render Pipeline) — стандарт для мобільних та консольних проектів. Лаконічніший та швидший за built-in. Кастомні Renderer Features для post-processing. Custom Render Pass API. Обов'язковий для проектів з VR/AR (XR Interaction Toolkit працює краще з URP).
HDRP (High Definition Render Pipeline) — для PC/консолей з акцентом на фотореалізм. Ray Tracing, Volume-based lighting, Screen Space Global Illumination. Не для мобільних. Не для WebGL. Мінімальні вимоги: DX12/Vulkan/Metal.
Вибір Pipeline — архітектурне рішення без зворотного шляху без значних витрат. Приймається в самому початку.
Мережевий стек для мультиплеєру
Це те, де помилки коштують дороже всього. Мережевий код пронизує всю гру, і смена мережевої бібліотеки на пізніх етапах — це майже переписування ігрової логіки заново.
Netcode for GameObjects (NGO) — офіційний Unity multiplayer SDK. Підходить для co-op ігор з < 16 гравців, відносно простий у інтеграції. Вимагає Relay-сервер (Unity Gaming Services) або власного транспорту.
Mirror — open source, battle-tested, відмінна документація, велика спільнота. Для незалежних та indie-проектів з власною серверною інфраструктурою. Підтримує велику кількість гравців (з правильною архітектурою — сотні на сцену).
Photon PUN 2 / Fusion — managed cloud рішення. Photon берен на себе інфраструктуру: relay, matchmaking, lobbies. PUN 2 — для turn-based та слабо-пов'язаного real-time. Fusion — для швидкого action з client-side prediction та server reconciliation.
Nakama — open source game server з підтримкою matchmaking, leaderboard, chat, economy, tournaments. Self-hosted або managed cloud. Правильний вибір якщо потрібен повноцінний game backend, а не тільки мережевий код.
PlayFab — Microsoft Azure-based game backend. Аналітика, економіка, player profiles, cloud scripts, matchmaking. Швидкий старт, managed-інфраструктура. Модель ціноутворення залежить від MAU.
Аналітика та монетизація
Для мобільних проектів з монетизацією стек зазвичай виглядає так:
- Аналітика: Firebase Analytics (безплатно, tight integration з Unity) або GameAnalytics (спеціалізований для ігор, воронка, retention cohorts). Обидва через одну інтеграцію.
- IAP: Unity IAP (обгортка над App Store / Google Play, підтримує 20+ магазинів). Серверна валідація покупок обов'язкова — через власний endpoint або PlayFab Cloud Script.
- Реклама: ironSource / AppLovin MAX (медіаційні платформи) замість прямої інтеграції однієї мережі реклами. Медіація автоматизує fill rate та eCPM.
- Push-сповіщення: Firebase Cloud Messaging (FCM) для Android та APNs для iOS, через Unity package або OneSignal.
Як ми проводимо вибір стека
Починаємо з матриці вимог: платформи → це виключає деякі варіанти. Жанр та механіки → визначають вимоги до мережевого коду. Команда → досвід з конкретними технологіями впливає на швидкість розробки. Бюджет операційних витрат → managed services vs self-hosted.
Для кожного ключового вибору готуємо ADR (Architecture Decision Record): проблема, розглядаємі варіанти, обраний варіант, обґрунтування, відомі компромісси. Це документ, до якого повертаємся при сумніві.
Фінальний стек оформляємо в Tech Stack Document з указанням версій, ліцензій та відповідальних за кожен компонент.
| Масштаб завдання | Орієнтовні строки |
|---|---|
| Технічний стек + ADR для нового проекту | 3–7 днів |
| Аудит поточного стека + рекомендації по оновленню | 3–5 днів |
| Смена Render Pipeline у існуючому проекті | 3–6 тижнів |
| Вибір та прототипування мережевого стека | 1–3 тижні |
Вартість розраховується після ознайомлення з вимогами проекту.