Аутсорсинг разработки игр: какие задачи можно передать внешней команде

Когда аутсорсинг разработки игр особенно полезен

Большая постоянная команда нужна далеко не каждому проекту. В определённый момент студии могут потребоваться дополнительные специалисты всего на несколько месяцев.

Например, перед релизом возникает необходимость срочно увеличить количество разработчиков. На следующем этапе требуется больше QA-инженеров. Позже основная нагрузка может переместиться на art production или LiveOps.

Нанимать постоянных сотрудников под каждый такой пик нагрузки не всегда рационально.

Нужно быстро усилить команду

Поиск и найм разработчиков занимает время. После выхода специалиста ему также требуется onboarding и погружение в проект.

Если задача ограничена определённым этапом production, можно подключить игровых разработчиков к существующей команде без создания новых постоянных позиций.

Такой подход особенно полезен перед релизом, при запуске нового направления или при необходимости закрыть конкретную техническую область.

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

Внутри команды нет нужной экспертизы

Студия может иметь сильную мобильную разработку, но впервые готовить консольную версию. Другому проекту может потребоваться multiplayer, сложный backend или глубокая оптимизация.

Создавать новое направление внутри компании ради одной задачи дорого.

В такой ситуации нужную компетенцию проще привлечь извне. При этом внутренняя команда продолжает заниматься теми областями, в которых обладает максимальной экспертизой.

Нужно разгрузить основную команду

Внутренние специалисты обычно лучше всего знают продукт, его аудиторию и ключевые решения.

Поэтому их ресурсы разумно направлять туда, где эта экспертиза особенно важна.

Часть производственных задач можно передать подрядчику. Например, внутренняя команда продолжает работать над геймдизайном и архитектурой, а внешний партнёр занимается контентом, отдельной системой или тестированием.

В результате не приходится выбирать между поддержкой текущих задач и развитием продукта.

Какие задачи можно передать на аутсорсинг

Аутсорсинг не означает, что подрядчику обязательно нужно отдавать всю игру.

На практике чаще передают отдельное направление, модуль или этап производства.

Чем чётче можно отделить задачу от остального проекта, тем проще определить ответственность и проверить результат.

Программирование

Программирование — одна из наиболее очевидных задач для внешней команды.

Подрядчику можно передать:

• игровые механики;
• UI;
• систему сохранений;
• инвентарь;
• внутриигровой магазин;
• авторизацию;
• платежи;
• аналитику;
• интеграцию SDK;
• multiplayer;
• сетевые функции;
• backend-интеграции;
• инструменты для контентной команды.

Особенно удобно передавать функциональность, которую можно отделить от остальной системы и описать через понятные интерфейсы.

Например, подрядчик может разработать систему инвентаря или отдельную игровую механику. После приёмки модуль интегрируется в основной проект.

Такой подход снижает количество организационных зависимостей.

При этом до начала разработки важно определить технические ограничения, формат интеграции и Definition of Done.

Разработка прототипа

До полноценного production часто требуется проверить игровую гипотезу.

Для этого создают прототип.

С его помощью можно проверить:

• основную механику;
• управление;
• core loop;
• сетевое взаимодействие;
• техническую реализуемость;
• производительность.

Прототипирование удобно передавать отдельной команде, поскольку такая работа обычно имеет конкретную цель и ограниченный срок.

Например, внешний подрядчик может проверить, насколько жизнеспособна новая механика, не отвлекая основную команду от текущего production.

При этом важно не превращать прототип в уменьшенную версию всей игры.

Подробнее о том, что действительно должно входить в такой этап, разобрано в материале «Объём прототипа: что в него входит и что точно не входит».

Аутсорсинг разработки игр на Unity и Unreal Engine

При выборе внешней команды важно учитывать используемый игровой движок.

Для проекта на Unity можно отдельно привлечь специалистов под gameplay, интерфейсы, networking, optimization илиporting. Подробнее направление представлено на странице разработки игр на Unity.

Для Unreal Engine могут потребоваться специалисты по C++, Blueprints, Gameplay Ability System, multiplayer или high-end rendering. Такое направление представлено на странице разработки игр на Unreal Engine.

Однако сам по себе опыт работы с определённым движком ещё не означает, что команда подходит конкретному проекту.

Разработчик мобильной casual-игры и инженер сетевого action-проекта могут работать в Unity, но решать совершенно разные задачи.

Поэтому при выборе команды стоит учитывать:

• жанр;
• целевые платформы;
• архитектуру проекта;
• сетевую модель;
• требования к производительности;
• количество контента;
• графический pipeline;
• особенности релизного процесса.

Если сам движок ещё не определён, полезно сначала оценить требования продукта. Этот вопрос подробнее разобран в статье «Unity или Unreal: выбирать нужно не по картинке».

2D- и 3D-графика

Game Art — одно из наиболее распространённых направлений аутсорсинга.

Внешней команде можно передать:

• concept art;
• дизайн персонажей;
• окружение;
• игровые предметы;
• оружие и технику;
• UI-графику;
• 3D-модели;
• текстуры;
• риггинг;
• VFX;
• рекламные материалы.

При больших объёмах контента можно подключить отдельную команду игровых художников, не увеличивая постоянный штат студии.

Такой подход особенно удобен для масштабируемого производства ассетов.

Например, проекту может потребоваться несколько сотен объектов окружения. Внутренний art lead сохраняет контроль художественного направления, а внешний подрядчик занимается production.

Однако перед запуском массового производства желательно зафиксировать:

• style guide;
• визуальные референсы;
• технические ограничения;
• требования к текстурам;
• бюджеты полигонов;
• naming;
• форматы исходников;
• процесс review.

В противном случае небольшое расхождение в требованиях может привести к необходимости переделывать десятки готовых объектов.

Отдельно этот процесс разобран в статье «Как передать арт-дирекшен внешней команде».

Анимация

Создание анимаций также можно выделить в самостоятельный производственный процесс.

Подрядчику можно поручить:

• character animation;
• анимацию объектов;
• facial animation;
• motion capture cleanup;
• игровые кат-сцены;
• UI-анимации.

Однако до начала работы необходимо согласовать технические ограничения.

Внешняя команда должна понимать используемый риг, структуру скелета, naming, формат файлов и требования игрового движка.

Если pipeline определён заранее, готовые материалы значительно проще интегрировать в проект.

UI/UX

Внешней команде можно передать и разработку игровых интерфейсов.

Например:

• UX-проектирование;
• wireframes;
• HUD;
• игровые меню;
• инвентарь;
• магазин;
• onboarding;
• настройки;
• адаптацию интерфейса под разные устройства.

Особенно удобно, когда подрядчик отвечает не только за дизайн, но и за техническую реализацию UI непосредственно в игровом движке.

Тогда дизайнеры и разработчики работают внутри одного процесса. В результате возникает меньше расхождений между макетом и тем, что в итоге видит пользователь.

Backend и серверная разработка

Онлайн-игры требуют серверной инфраструктуры.

Это отдельная область разработки, которой внутренняя команда может не заниматься постоянно.

Внешнему подрядчику можно передать:

• пользовательские аккаунты;
• хранение прогресса;
• игровые сессии;
• matchmaking;
• рейтинги;
• leaderboards;
• облачные сохранения;
• игровые события;
• экономику;
• административные инструменты;
• аналитику;
• серверные интеграции.

При этом архитектуру необходимо согласовать заранее.

Важно определить ожидаемую нагрузку, требования безопасности, правила масштабирования и допустимый уровень отказоустойчивости.

Кроме того, ещё до релиза нужно договориться, кто будет отвечать за серверную инфраструктуру после запуска продукта.

QA и тестирование

Тестирование удобно выделять в самостоятельное направление.

Внешняя команда может выполнять:

• функциональное тестирование;
• регрессионное тестирование;
• compatibility testing;
• проверку на разных устройствах;
• тестирование локализации;
• сетевые тесты;
• нагрузочные проверки;
• проверку release candidate.

При необходимости к проекту можно подключить отдельную команду QA и тестирования игр.

Особенно сильно нагрузка на QA возрастает перед релизом.

Разработчики в это время исправляют блокеры и стабилизируют сборку. Поэтому параллельное расширение тестирования позволяет быстрее проверять новые версии.

Однако QA лучше подключать значительно раньше content lock.

Раннее тестирование помогает находить системные проблемы до того, как их исправление начинает затрагивать десятки готовых материалов. Подробнее этот подход описан в статье «QA до content lock: что тестировать раньше».

Оптимизация производительности

Иногда игра уже работает, но не соответствует целевым показателям производительности.

Причины могут быть связаны с:

• высокой нагрузкой на CPU;
• проблемами с GPU;
• большим потреблением памяти;
• загрузками;
• тяжёлыми текстурами;
• шейдерами;
• частыми аллокациями;
• неоптимальной физикой;
• высокой нагрузкой на сеть.

Внешняя команда может провести profiling проекта и определить основные bottlenecks.

После этого специалисты составляют план оптимизации или самостоятельно вносят необходимые изменения.

Для ужеработающего проекта также можно использовать формат улучшения существующей игры.

Такой подход особенно полезен, если нужен независимый технический взгляд на существующую кодовую базу.

Портирование игры на другие платформы

Перенос проекта на новую платформу также удобно передавать специализированной команде.

Например:

• PC → консоли;
• mobile → PC;
• Android → iOS;
• PC → Steam Deck;
• одна консоль → другая консоль.

Полноценное портирование игры включает намного больше, чем получение сборки под новую платформу.

Обычно необходимо адаптировать:

• управление;
• интерфейс;
• платформенные сервисы;
• систему сохранений;
• достижения;
• производительность;
• memory budget;
• release pipeline.

Для консолей отдельно появляются требования платформодержателя и сертификация.

Поэтому риски желательно выявлять ещё до подготовки release candidate. Некоторые из типовых проблем подробно разобраны в материале «Порт на консоли: что ломается первым».

Поддержка игры после релиза

Релиз редко означает завершение разработки.

Live-проект требует постоянных изменений.

Внешней команде можно передать:

• исправление ошибок;
• выпуск обновлений;
• новый контент;
• техническую поддержку;
• backend;
• интеграцию новых SDK;
• оптимизацию;
• поддержку новых устройств;
• работу с релизным pipeline.

Например,отдельная команда может взять на себя обновления и поддержку игры после запуска.

Так основной состав может переключить часть ресурсов на следующий продукт.

При этом уже выпущенная игра продолжит получать обновления, исправления и новый контент.

Что лучше оставить внутри компании

Несмотря на преимущества аутсорсинга, передавать абсолютно всё необязательно.

Во многих проектах внутри команды стоит сохранять компетенции, которые определяют уникальность продукта.

К ним могут относиться:

• продуктовая стратегия;
• ключевой геймдизайн;
• игровая экономика;
• art direction;
• техническая архитектура;
• управление продуктом;
• аналитика;
• принятие ключевых продуктовых решений.

При этом внешней команде можно передавать отдельные производственные направления.

Например, внутренний technical lead контролирует архитектуру, а подрядчик реализует несколько систем.

Art director определяет визуальный язык, а внешняя команда производит контент.

Такой формат позволяет сохранить контроль над продуктом и одновременно масштабировать production.

Однако это не жёсткое правило.

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

Как организовать аутсорсинг игровой разработки

Сильная внешняя команда сама по себе не решает организационные проблемы.

Чтобы совместная разработка работала эффективно, необходимо подготовить проект к подключению новых специалистов.

Подробный практический список материалов есть в статье «Как передать проект подрядчику и не потерять неделю».

Сначала определите результат

Фраза «нужно сделать multiplayer» слишком абстрактна.

Намного лучше определить:

• количество игроков;
• тип соединения;
• создание комнаты;
• matchmaking;
• reconnect;
• синхронизацию состояния;
• серверную модель;
• требования к latency;
• сценарии отказа;
• критерии тестирования.

Тогда и заказчик, и подрядчик понимают, какой результат должен появиться в конце работы.

Кроме того, такую задачу значительно проще оценить по срокам и бюджету.

Зафиксируйте критерии приёмки

Каждая передаваемая задача должна иметь Definition of Done.

Для технической задачи это могут быть:

• поддерживаемые платформы;
• минимальный FPS;
• memory budget;
• список рабочих сценариев;
• отсутствие blocker-багов;
• формат документации;
• требования к исходникам.

Для art-задачи — количество полигонов, размеры текстур, материалы, naming и формат экспорта.

Чем раньше определены критерии, тем меньше субъективных споров возникает на этапе сдачи.

Подробнее этот вопрос разобран в статье «Критерии приёмки, из-за которых не приходится переделывать».

Разделите проект на этапы

Большую задачу лучше разбить на последовательные блоки.

Например:

• технический анализ;
• прототип;
• основная разработка;
• интеграция;
• тестирование;
• исправления;
• подготовка релиза.

После каждого этапа команда показывает проверяемый результат.

Так заказчик быстрее замечает отклонения и может скорректировать направление до того, как проблема затронет весь проект.

Определите ответственных

Со стороны заказчика должен быть человек, который может принимать решения.

Аналогичный ответственный нужен со стороны подрядчика.

Чаще всего это:

• project manager;
• producer;
• tech lead;
• art lead — для художественного направления.

Если каждый вопрос должен проходить через несколько участников с обеих сторон, скорость работы быстро снижается.

Поэтому желательно иметь одного основного владельца коммуникации по каждому направлению.

Зафиксируйте технические стандарты

До начала разработки стоит согласовать:

• архитектурные ограничения;
• coding conventions;
• Git workflow;
• правила ветвления;
• code review;
• документацию;
• Definition of Done;
• процесс тестирования;
• порядок выпуска сборок.

Если подрядчик подключается к уже работающему проекту, этот этап особенно важен.

Внешняя команда должна встроиться в существующий production, а не создавать параллельный процесс, который затем придётся объединять с внутренним.

Как выбрать внешнюю команду разработки

Цена не должна быть единственным критерием.

В первую очередь стоит оценивать релевантный опыт подрядчика.

Посмотрите:

• с какими проектами команда работала;
• какие платформы знает;
• какие движки использует;
• есть ли опыт с нужным жанром;
• как организует code review;
• как тестирует результат;
• как работает с чужой кодовой базой;
• как передаёт исходники;
• как документирует решения;
• как сообщает о рисках.

Полезно обсудить несколько реальных технических сценариев.

По ответам часто можно понять уровень команды значительно лучше, чем по презентации.

Отдельно стоит проверить процесс коммуникации.

Сильный подрядчик не должен исчезать между контрольными точками. Заказчик должен понимать состояние проекта, существующие проблемы и последствия принимаемых решений.

Аутсорсинг разработки игр или расширение штата

Оба подхода решают разные задачи.

Постоянный найм подходит, когда специалист нужен компании надолго.

Особенно это касается core-компетенций продукта.

Аутсорсинг удобнее, если требуется временная команда или специализированная экспертиза.

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

После релиза потребность в таком составе исчезнет. В этой ситуации временное усиление может оказаться рациональнее расширения постоянного штата.

Возможна и смешанная модель.

Внутренняя команда отвечает за продукт и архитектуру. Внешняя — за отдельные системы, контент, QA или портирование.

Для многих игровых проектов именно такая схема оказывается наиболее гибкой.

Какие риски нужно учитывать

У аутсорсинга есть и потенциальные сложности.

Их желательно учитывать ещё до начала работы.

Недостаточная прозрачность

Заказчик должен понимать текущее состояние проекта.

Для этого нужны:

• общий backlog;
• регулярные сборки;
• демо;
• отчётность;
• понятные критерии готовности;
• прозрачный список рисков.

Если состояние работы становится понятно только в конце месяца, проблемы обнаруживаются слишком поздно.

Плохая документация

Критические знания не должны оставаться только у отдельных разработчиков.

Код, архитектурные решения и процессы необходимо документировать.

Это особенно важно, если после завершения работ поддержку проекта продолжит внутренняя команда.

Хороший результат аутсорсинга — это не только работающая функция, но и возможность безболезненно поддерживать её дальше.

Сложная интеграция команд

Внешние специалисты должны понимать процессы заказчика.

При этом интеграция не должна превращаться в ежедневный микроменеджмент подрядчика.

Поэтому зоны ответственности и способы коммуникации лучше определить до начала production.

Например, можно заранее установить:

• формат постановки задач;
• регулярность синхронизаций;
• формат демо;
• правила code review;
• ответственных за приёмку.

Права на результат

Юридические условия также необходимо определить заранее.

В договоре следует закрепить:

• права на исходный код;
• права на графику;
• передачу исходных файлов;
• используемые лицензии;
• правила применения сторонних ассетов;
• конфиденциальность;
• порядок передачи результата после завершения проекта.

Это особенно важно при работе с кодом, уникальными ассетами и внутренними инструментами компании.

Когда передача разработки внешней команде работает лучше всего

Аутсорсинг разработки игр особенно эффективен, когда задача имеет понятную границу.

Хорошими кандидатами для передачи являются:

• отдельная игровая механика;
• модуль;
• прототип;
• vertical slice;
• производство ассетов;
• QA;
• оптимизация;
• backend;
• портирование;
• поддержка после релиза.

Чем проще описать ожидаемый результат, тем легче оценить объём работы и контролировать качество.

Сложнее передавать задачи, которые ежедневно меняются вместе с продуктовой концепцией.

Однако и такой формат возможен.

В этом случае подрядчик должен быть глубоко интегрирован в production и фактически работать как продолжение внутренней команды.

Итоги

Аутсорсинг позволяет расширять возможности команды без постоянного увеличения штата.

Подрядчику можно передать программирование, прототипирование, Game Art, UI/UX, backend, QA, оптимизацию, портирование и поддержку после запуска.

При этом необязательно передавать весь проект.

Часто наиболее эффективна смешанная модель. Внутренняя команда сохраняет продуктовые и архитектурные компетенции, а внешние специалисты закрывают отдельные производственные направления.

Ключевое условие успешной работы — заранее определить ответственность, критерии приёмки и процесс коммуникации.

При таком подходе аутсорсинг разработки игр становится не просто способом закрыть нехватку специалистов. Он превращается в инструмент масштабирования production.

Если проекту требуется отдельная экспертиза или полноценная внешняя команда, можно обсудить задачу с NoPanic Studio и определить подходящий формат подключения.