Розроблення технічного завдання на розробку ігор
Проект без технічного завдання — це проект, де через три місяці розробки з'ясовується, що замовник мав на увазі «мультиплеєр» як «можна грати вдвоєм на одному екрані», а команда зробила повноцінний мережевий матчмейкинг. Або художники малювали UI під дозвіл 1920×1080, а гра повинна працювати на пристроях з 720×1280. Технічне завдання на ігровий проект — це не формальність, а інструмент синхронізації очікувань.
При цьому технічне завдання на гру принципово відрізняється від завдання на корпоративний сайт. Тут потрібно описувати не тільки функціональність, але й технічні характеристики, які прямо впливають на вартість та строки: цільові платформи, вимоги до продуктивності, мережева архітектура, підтримка контенту.
Що повинно бути в технічному завданні на ігровий проект
Гарне завдання дає відповідь на три питання: що робимо, як це працює технічно та як перевіримо, що зробили правильно.
Платформи та вимоги до продуктивності. Не просто «Android та iOS», а мінімальні та цільові пристрої. Мінімум Android: Snapdragon 660, 3 ГБ RAM, Android 8.0. Цільовий fps: 60 на цільових пристроях, 30 на мінімальних. Це впливає на весь технічний стек: вибір Render Pipeline, політику LOD, обмеження Draw Calls.
Ігрові системи з поведінковими специфікаціями. Не «система інвентарю», а «інвентар підтримує до 200 слотів, предмети з атрибутами (тип, рідкість, складність до 99), Drag&Drop між слотами, фільтрація за типом, сортування за 3 параметрами». Чим конкретніше опис системи — тим точніше оцінка трудовитрат.
Мережева архітектура (якщо multiplayer). Client-server або P2P. Авторитетний сервер або client-side prediction з reconciliation. Максимальна кількість одночасних гравців у сесії. Вимоги до затримки (100 мс? 50 мс?). Це не просто «ми хочемо мультиплеєр» — це рішення, які формують архітектуру на роки вперед.
Модель контенту. Як додається новий контент: через редактор (розробник), через CMS (геймдизайнер) або через DLC (користувач). Підтримка модифікацій? Це визначає, чи потрібна система Addressables з remote content, локалізовані ассети, формат конфіґураційних даних (JSON, ScriptableObject, зовнішня база даних).
Типові прогалини, які ми закриваємо
Більшість клієнтів приходять з Game Design Document (або його частини) — описом ґеймплею, механік, сюжету. Але GDD — це не технічне завдання. З GDD незрозуміло: в якому движку робити, який Render Pipeline, як буде влаштований save/load, потрібна система аналітики, як монетизація працює на технічному рівні (IAP, реклама, серверна валідація покупок).
Ми беремо GDD або усну опис проекту та перекладаємо його у технічні вимоги. Для кожної ігрової системи визначаємо: технічний стек (бібліотеки, SDK), залежності між системами, граничні випадки та граничні умови, критерії приймання.
Приклад розробки однієї системи. Система досягнень: 50 досягнень, прогрес зберігається локально + синхронізується з сервером, підтримка Game Center (iOS) та Google Play Games (Android). Технічна вимога: AchievementManager повинен забезпечити offline-queue — досягнення, розблоковані без інтернету, надсилаються при наступному підключенні. Дедупліація на сервері за playerId + achievementId. Максимальний час синхронізації — 5 секунд при хорошому з'єднанні. Це вже spec, з яким розробник розуміє завдання.
Структура технічного завдання, яку ми використовуємо
- Загальний опис проекту — жанр, цільова аудиторія, платформи, мова інтерфейсу, строки
- Технічні вимоги до платформи — ОС, залізо, продуктивність, орієнтація екрана
- Архітектура проекту — движок, Render Pipeline, мережева архітектура, backend-сервіси
- Ігрові системи — специфікація кожної системи з функціональними та нефункціональними вимогами
- Інтеграції третіх сторін — аналітика (Firebase, GameAnalytics), монетизація (Unity IAP, AdMob), аутентифікація (PlayFab, GameSparks)
- Вимоги до контенту — формати ассетів, pipeline поставки, обсяги
- Критерії приймання — для кожного модуля: що означає «готово»
Обсяг остаточного документа — від 15 до 60 сторінок залежно від складності проекту. Для простого гіпер-казуального — 15 сторінок достатньо. Для RPG з відкритим світом та мультиплеєром — менше 40 сторінок не обійтись.
| Масштаб завдання | Орієнтовні строки |
|---|---|
| Завдання для гіпер-казуального / прототипу (1–3 системи) | 3–5 днів |
| Завдання для мідкор-гри (5–10 систем) | 1–2 тижні |
| Завдання для складного проекту (MMO, open world, 15+ систем) | 3–5 тижнів |
| Ревізія існуючого завдання + аудит технічних ризиків | 3–7 днів |
Вартість розраховується індивідуально після ознайомлення з концепцією проекту.