Настройка системы контроля версий для игровых проектов

Создание системы контроля версий проекта игр

Вы запускаете игровой проект и сталкиваетесь с тем, что репозиторий разросся до 14 ГБ за пару месяцев, а слить изменения из ветки художника — целая эпопея. Мы, как команда с 10-летним опытом в геймдеве (более 50 успешно настроенных проектов), знаем, как этого избежать. Правильная система контроля версий — основа разработки любой игры. Без неё вы теряете дни на merge-конфликты и ручной бэкап. Мы настроим VCS так, что команда будет работать параллельно, не наступая друг другу на файлы.

Бинарные файлы — главная особенность геймдев-репозитория, которая делает обычный git-workflow нерабочим. Текстуры в PNG/PSD, 3D-модели в FBX, аудио в WAV/OGG, видеоролики — всё это не диффуется, занимает гигабайты и моментально делает git clone невозможным без специальных инструментов.

Git LFS (Large File Storage) — базовое решение, но его настройка в геймдев-проекте требует точного определения: что в LFS, что нет. Если туда попадут скрипты или JSON-конфиги — теряем нормальный diff в code review. Если не туда попадут большие текстуры — репозиторий разрастается до нескольких ГБ за месяц.

Как настроить Git LFS для Unity/Unreal?

.gitattributes для Unity-проекта должен включать:

*.png filter=lfs diff=lfs merge=lfs -text
*.psd filter=lfs diff=lfs merge=lfs -text
*.jpg filter=lfs diff=lfs merge=lfs -text
*.fbx filter=lfs diff=lfs merge=lfs -text
*.wav filter=lfs diff=lfs merge=lfs -text
*.mp3 filter=lfs diff=lfs merge=lfs -text
*.ogg filter=lfs diff=lfs merge=lfs -text
*.mp4 filter=lfs diff=lfs merge=lfs -text
*.asset filter=lfs diff=lfs merge=lfs -text
*.unity filter=lfs diff=lfs merge=lfs -text
*.prefab filter=lfs diff=lfs merge=lfs -text

При этом .cs, .json, .yaml, .asmdef — без LFS: они текстовые, их важно диффовать.

Почему важна Force Text serialization?

Критичная настройка Unity: Force Text serialization. Edit → Project Settings → Editor → Asset Serialization Mode = Force Text. Это переводит .asset, .prefab, .unity из бинарного формата в YAML-текст. Теперь на них можно делать diff и merge. Без этой настройки слияние сцен невозможно — каждый конфликт требует ручного выбора «моя версия или чужая». Мы гарантируем, что после нашей настройки merge-конфликты станут редкими и легко разрешимыми.

Альтернатива для больших студий — Perforce (Helix Core). P4 нативно работает с бинарными файлами, поддерживает exclusive checkout (предотвращает конфликты на бинарных файлах), масштабируется до больших репозиториев (терабайты). Порог входа выше, но для команды 10+ человек с большим объёмом ассетов — оправданный выбор. Unreal Engine сам активно использует Perforce. Подробнее см. официальную документацию Perforce.

Разница между Git LFS и Perforce для игровых проектов

Branching strategy для игрового проекта

Игровой проект имеет специфику по сравнению с веб-приложением: частые ассет-обновления от художников, параллельная работа над уровнями, необходимость поддерживать играбельную версию в любой момент.

GitFlow адаптированный для геймдева:

• main — стабильная версия, всегда запускается без критичных багов
• develop — интеграционная ветка, сюда вливаются фичи
• feature/название-фичи — короткоживущие ветки для конкретных систем
• art/название-ресурса — ветки для больших ассет-обновлений (новый уровень, пак персонажей)
• hotfix/описание — срочные фиксы поверх main

Ветки art/ живут дольше feature/ и мержатся крупными пачками — это уменьшает количество конфликтов при работе художников.

Trunk-based development — альтернатива для небольших команд (2–4 человека). Все работают в main, короткие ветки живут не больше 2 дней. Требует хорошего CI и feature flags для незавершённых фич.

Управление сценами и предпочтениями

Сцены в Unity — главный источник merge-конфликтов. Стандартный подход: каждый разработчик не трогает чужую сцену без договорённости. Лучше: разбить уровни на Subscenes (через Multi-Scene Editing или Addressables Scene Loading). Художник работает над Art-подсценой уровня, программист — над Logic-подсценой. Конфликтов нет, потому что это разные файлы.

В Unreal — World Partition с Level Streaming. Каждый стример-регион может редактироваться независимо.

Типичные ошибки при настройке VCS:

• Неправильный .gitattributes: скрипты в LFS теряют дифф.
• Бинарные сцены: без Force Text merge невозможен.
• Отсутствие веток art/: художники мержат в develop и ломают сборку.
• Не настроен exclusive checkout на бинарные файлы (в Perforce).
• Игнорирование .gitignore: попадают Library, Temp, Logs.

Инструменты для команды

Помимо собственно VCS — настраиваем интеграции:

• GitHub / GitLab / Bitbucket — hosting + code review workflow (Pull Requests, branch protection rules)
• Unity Version Control (Plastic SCM) — альтернатива Git LFS от Unity, с нативным GUI в редакторе. Удобнее для нетехнических участников команды (художники, дизайнеры уровней)
• Conventional Commits — стандарт сообщений коммитов: feat(combat): add parry mechanic, fix(ui): inventory count overflow on 3-digit numbers

Что входит в настройку

1. Аудит текущего репозитория и оценка объёма.
2. Настройка .gitattributes, LFS и Force Text serialization.
3. Разработка branching strategy под ваш проект.
4. Интеграция с CI/CD (GitHub Actions, GitLab CI).
5. Обучение команды (1 час вебинар).
6. Документация процесса и чек-лист.
7. Пост-настройка поддержка (2 недели).

Реальная ситуация, которую решаем: стартап, 5 человек, git без LFS, сцена в бинарном формате. Репозиторий вырос до 14 ГБ за 3 месяца, clone занимает 40 минут, merge сцен — ручной выбор один из двух вариантов. Миграция заняла 4 дня: git-lfs migrate import для всех бинарных файлов, включение Force Text serialization, настройка .gitattributes, обучение команды. Итог: репозиторий 1.2 ГБ (без LFS-объектов), clone за 5 минут, экономия на простое команды составила несколько тысяч долларов в месяц.

Стоимость настройки рассчитывается индивидуально после анализа текущего состояния репозитория и команды. Закажите консультацию — получите детальный план и сроки. Мы гарантируем, что репозиторий станет лёгким, merge-конфликты исчезнут, а команда сможет параллельно работать без простоев. Свяжитесь с нами, чтобы обсудить ваш проект.

Планирование игрового проекта

Типичная ситуация: к нам приходит команда после трёх месяцев разработки с вопросом «почему у нас в репозитории 40 гигабайт и Git падает при каждом pull?». Ответ почти всегда один: PNG-текстуры и FBX-файлы закоммичены напрямую без Git LFS, история репозитория раздулась до неработоспособного состояния. Это решается, но переписывание истории в живом проекте — болезненный процесс, которого можно было легко избежать.

Планирование игр — это не про диаграммы Ганта. Это про технические решения первых двух недель, которые не станут проблемами через три месяца.

Почему планирование игр — это не про Ганта?

График работ — только вершина. Настоящее планирование игрового проекта включает:

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

Без этого «план» — список задач без опоры. Через месяц выясняется, что Unreal-проект сборки под мобильные платформы не тянет, а ECS оказался избыточным для простого раннера. Время потрачено, бюджет ушёл на прототипы, которые нужно переписывать.

Документация: 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 даёт порядки производительности на тысячах объектов, но резко увеличивает сложность кода. Для гиперкажуальных игр — избыточно. Для стратегий — необходимо.
• Сетевая архитектура. Если мультиплеер планируется — решение принимается до первой игровой механики. 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

Это должно быть настроено до первого коммита с ассетами. После — болезненная миграция, которая может стоить до 200 000 руб. времени разработчиков.

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% обращений.