Технічне завдання для ігор: документація під ключ

Ми складаємо технічні завдання для ігрових проєктів будь-якої складності — від гіпер-казуалів до MMO. Наш досвід — понад 10 років у геймдеві, понад 70 успішних проєктів, сертифіковані спеціалісти Unity та Unreal. Вартість складання ТЗ починається від $500 для гіпер-казуалу, економія на переробках — до $5000 на середньому проєкті. Гарантія: безкоштовне виправлення помилок у ТЗ протягом 14 днів. Проєкт без ТЗ — це проєкт, де через три місяці з'ясовується, що замовник мав на увазі «мультиплеєр» як «можна грати удвох на одному екрані», а команда зробила повноцінний мережевий матчмейкінг. Або художники малювали UI під роздільну здатність 1920×1080, а гра має працювати на пристроях із 720×1280. Технічне завдання — не формальність, а інструмент синхронізації очікувань, який скорочує бюджет на переробки до 40%. Середня економія на переробках становить 35% бюджету проєкту. Проєкти з ТЗ здаються на 40% швидше, ніж без нього, що відповідає коефіцієнту 1.4. ТЗ підвищує точність оцінки бюджету в 5 разів порівняно з проєктом без ТЗ.

При цьому ТЗ на гру принципово відрізняється від ТЗ на корпоративний сайт. Тут потрібно описувати не лише функціональність, а й технічні характеристики, які безпосередньо впливають на вартість та терміни: цільові платформи, вимоги до продуктивності, мережева архітектура, підтримка контенту. Наші замовники отримують документ, з яким розробник може одразу приступити до реалізації — без уточнень і переписок.

Важливість технічного завдання для ігрового проєкту

ТЗ закриває три питання: що робимо, як це працює технічно і як перевіримо правильність. Хороший документ знижує кількість правок на етапі розробки вдвічі порівняно з усним брифінгом.

Платформи та вимоги до продуктивності. Не просто «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, локалізовані ассети, формат конфігураційних даних.

Що входить у роботу?

• Аналіз концепції (GDD, усний опис, референси)
• Складання технічного документа (15–60 сторінок)
• Рев'ю з командою розробки та замовником
• Фінальна версія з підписаними критеріями приймання
• Консультації щодо реалізації — відповіді на питання протягом 30 днів

Порівняння: проєкт з ТЗ і без

Переведення GDD у технічні вимоги

Більшість клієнтів приходять із Game Design Document (GDD) — описом геймплею, механік, сюжету. Але GDD — це не ТЗ. З нього незрозуміло: на якому рушії робити, який Render Pipeline, як влаштований save/load, чи потрібна аналітика, як працює монетизація на технічному рівні (IAP, реклама, серверна валідація).

Ми беремо GDD або усний опис і переводимо в технічні вимоги. Для кожної ігрової системи визначаємо: стек (бібліотеки, SDK), залежності, edge cases, критерії приймання. Приклад: система досягнень — 50 досягнень, прогрес локально + синхронізація з сервером, підтримка Game Center та Google Play Games. Технічна вимога: AchievementManager з offline-queue, дедуплікація за playerId + achievementId, максимальний час синхронізації — 5 секунд. З цією spec розробник розуміє задачу без додаткових питань.

Які типові прогалини ми закриваємо?

• Відсутність вимог до продуктивності. Вказуємо цільові fps, бюджет draw calls, політику ассетів.
• Невизначена мережева архітектура. Фіксуємо протокол, авторитетність сервера, кількість гравців.
• Прогалини в контентній моделі. Визначаємо pipeline постачання: Addressables, remote config, локалізація.

За даними галузевих досліджень, детальне ТЗ скорочує час розробки на 30–50% за рахунок зниження переробок. Замовте ТЗ — і ви отримаєте документ, який окупиться вже на першому етапі розробки. Чітко описана специфікація гри дає змогу уникнути помилок. Для мобільних ігор ТЗ враховує особливості платформи. Правильна документація ігрового проєкту — запорука успіху.

Як замовити складання ТЗ?

1. Надішліть опис проєкту (GDD або концепцію).
2. Отримайте попередню оцінку вартості та термінів за 2 години.
3. Після ухвалення комерційної пропозиції ми складаємо ТЗ.
4. Проводимо рев'ю з вашою командою.
5. Підписуємо акт приймання після затвердження.

Отримайте консультацію — пишіть, обговоримо деталі.

Планування ігрового проєкту

Типова ситуація: до нас приходить команда після трьох місяців розробки з питанням «чому у нас у репозиторії 40 гігабайт і Git падає при кожному pull?». Відповідь майже завжди одна: PNG-текстури та FBX-файли закомічені безпосередньо без Git LFS, історія репозиторію роздулася до непрацездатного стану. Це вирішується, але переписування історії в живому проєкті — болючий процес, якого можна було легко уникнути. Ми бачимо таке у 90% звернень — наслідок відсутності технічного планування на старті.

Планування ігор — це не про діаграми Ганта. Це про технічні рішення перших двох тижнів, які не стануть проблемами через три місяці. Наш досвід — 7 років у геймдеві, понад 25 реалізованих проєктів під мобільні (iOS/Android), PC та консолі (Nintendo Switch, Xbox). Ми гарантуємо, що після нашого планування ви не зіткнетеся з архітектурними «граблями», на які наступають 90% недосвідчених команд.

Чому планування ігор — це не про Ганта?

Графік робіт — тільки вершина. Справжнє планування ігрового проєкту включає:

• жорстку фіксацію цільових платформ і мінімальних вимог (наприклад, iPhone 11, 60 fps);
• декомпозицію механік до числових параметрів з версіонуванням;
• вибір стеку, від якого залежить вся архітектура (render pipeline, мережа, ECS);
• налаштування інфраструктури до першого коміту з асетами.

Без цього «план» — список завдань без опори. Через місяць з'ясовується, що Unreal-проєкт збірки під мобільні платформи не тягне, а ECS виявився надлишковим для простого раннера. Час витрачено, бюджет пішов на прототипи, які потрібно переписувати. Правильне планування скорочує час релізу в середньому на 2 місяці (економія до 40% продакшен-етапу) і знижує кількість багів на 30%.

Документація: GDD як живий інструмент

GDD (Game Design Document) у поганому виконанні — це 80-сторінковий PDF, який ніхто не читає після другого спринту. GDD у хорошому виконанні — це структурована база знань, яку команда реально використовує щодня.

Що має бути в GDD

Мінімальний набір, без якого не можна починати розробку:

• Геймплейні системи — точний опис кожної механіки з параметрами. Не «персонаж стрибає», а «стрибок: висота 2.4 юніти, час у повітрі 0.6 сек, є 150 мс coyote time, double jump дозволено, приземлення блокує атаку на 200 мс». Числа можуть змінюватися в ході балансування, але вони мають бути зафіксовані та версіоновані.
• Технічні обмеження — цільові платформи, мінімальні вимоги до заліза, обмеження по пам'яті та draw calls. Якщо гра має працювати на iPhone 11 з 60 fps, це обмеження впливає на всі арт-рішення з самого початку.
• Scope та фічі — явний список того, що входить у MVP і що залишається на потім. «Можливо додамо крафтинг» — це не планування, це джерело feature creep.
• Референси — конкретні ігри з конкретними механіками, які беруться за основу. «Як у Dark Souls, але швидше» — це робочий референс для combat designer.

Як ми ведемо GDD

Використовуємо Notion або Confluence — GDD живе як wiki, а не як файл. Зміни видно в історії, можна залишати коментарі, механіки пов'язані між собою перехресними посиланнями. Технічний дизайн і художній дизайн зберігаються окремими розділами, але посилаються один на одного. Кожна механіка має статус: в розробці, готово, на рев'ю, заморожено. Це дозволяє в будь-який момент зрозуміти реальний стан проєкту без дзвінків.

Технічна архітектура

Вибір стеку — не релігія

Вибір між Unity та Unreal розбираємо детально в загальному розділі каталогу. Але на етапі планування є кілька суміжних рішень, критично важливих для проєкту:

• Render pipeline в Unity. URP — для мобільних та VR. HDRP — для PC/консолей. Built-in (Legacy) — тільки якщо берете старий проєкт. Змінювати pipeline в середині розробки — перезбірка всіх матеріалів. Рішення приймається в день першого коміту.
• Архітектура ігрових об'єктів. Класичний MonoBehaviour проти ECS (Entity Component System через Unity DOTS). ECS дає приріст продуктивності до 10 разів на тисячах об'єктів, але різко збільшує складність коду. Для гіперказуальних ігор — надлишково. Для стратегій — необхідно.
• Мережева архітектура. Якщо мультиплеєр планується — рішення приймається до першої ігрової механіки. Single-player і networked code влаштовані принципово по-різному: в мережевій грі кожна зміна стану має бути явною та синхронізованою.

ScriptableObjects як конфігураційний шар

В Unity використовуємо ScriptableObject-орієнтований підхід для зберігання ігрових даних. Конфігурація зброї, параметри ворогів, налаштування рівнів — все це ScriptableObject-асети, а не захардкоджені значення. Це дозволяє гейм-дизайнеру змінювати баланс без участі програміста та без перезбірки проєкту.

Версіонування та робота з асетами

Це та область, де більшість невеликих команд втрачає час найприкрішим способом.

Git + Git LFS

Стандартний Git не призначений для бінарних файлів. Текстура 4K в PNG важить 20–50 MB. Якщо її комітити як звичайний файл, історія репозиторію роздувається катастрофічно швидко. Git LFS зберігає бінарні файли окремо, а в Git-історію кладе тільки покажчики. Налаштовується один раз у .gitattributes:

*.png filter=lfs diff=lfs merge=lfs -text
*.fbx filter=lfs diff=lfs merge=lfs -text
*.psd filter=lfs diff=lfs merge=lfs -text
*.unitypackage filter=lfs diff=lfs merge=lfs -text
*.mp3 filter=lfs diff=lfs merge=lfs -text
*.wav filter=lfs diff=lfs merge=lfs -text

Це має бути налаштовано до першого коміту з асетами. Після — болюча міграція, яка може коштувати значних витрат часу розробників. Використання Git LFS замість звичайного Git пришвидшує операції з репозиторієм у 5 разів, коли обсяг асетів перевищує 10 ГБ.

Perforce

Альтернатива для великих Unreal-проєктів. Epic Games самі використовують Perforce. Краще працює з дуже великими репозиторіями (сотні гігабайт), нативна підтримка в Unreal Editor. Вища вартість інфраструктури та складність налаштування.

Гілкування

Для ігрових проєктів використовуємо спрощений Git Flow: main, develop, feature/*, release/*. Правило: в main ніколи не комітиться нічого, що не пройшло QA. Його порушення призводить до того, що «остання стабільна версія» стає терміном без змісту.

CI/CD для ігрових проєктів

Автоматична збірка при кожному пуші вирішує проблему «у мене на машині збирається, у тебе ні». Pipeline включає:

1. Активація Unity ліцензії (headless)
2. Запуск тестів (Unity Test Runner)
3. Збірка під Android (APK/AAB)
4. Збірка під iOS (Xcode проєкт)
5. Збірка під PC (Standalone)
6. Завантаження артефактів в S3 або Firebase App Distribution

Час збірки — 15–40 хвилин. Команда отримує свіжу збірку без ручної роботи.

GameCI — GitHub Actions для Unity. Unity Cloud Build — хостинг від Unity, простіше налаштування, дорожче при великій кількості збірок. Jenkins — повний контроль, використовується для консольних платформ.

Що входить у роботу

• Документація: технічне завдання, GDD (MVP-scope), архітектурна схема, моделі даних.
• Налаштування репозиторію: Git + LFS, правила гілкування, шаблон проєкту, угоди про код.
• CI/CD: конфігурація збірок під всі цільові платформи, автоматичне тестування.
• Доступи: до репозиторію, CI/CD, баг-трекеру; навчання команди роботі з інструментами.
• Підтримка: супровід протягом першого місяця розробки — відповіді на питання, коригування налаштувань, рев'ю архітектурних рішень.

Часові рамки планування

Разом до початку повноцінного виробництва: 4–6 тижнів. Це не бюрократія — це страховка від переписування, яка економить до 40% часу на етапі продакшену.

Як планування ігор запобігає технічному боргу?

Помилка в плануванні на першому спринті обходиться в 10 разів дорожче, ніж виправлення на прототипі. Неправильний вибір стеку або відсутність LFS призводять до перезбірки архітектури, втрати комітів та демотивації команди. Грамотне планування ігор — це інвестиція, яка окупається зниженням багів на 30% і прискоренням релізу в середньому на 2 місяці.

Оцінимо ваш проєкт — зв'яжіться з нами, щоб отримати консультацію та детальний план перших кроків. Замовте планування ігрового проєкту та уникніть типових граблів, які ми бачимо в 90% звернень. Скористайтеся нашим досвідом — ми сертифіковані партнери Unity та Unreal Engine, і гарантуємо працездатну архітектуру з першого коміту.