Услуги по разработке игр — Создание сайтов, мобильных приложений, парсеров, игр | Настоящие Технологии | TRUETECH

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

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

Что мы делаем

Полный цикл: от идеи и GDD до сборок в сторах. Unity (C#), Unreal Engine (C++ и Blueprints), WebGL для браузерных игр. Мобильные, PC, консоли, VR/AR. Мультиплеер на Photon и Mirror. Оптимизация под слабое железо. Интеграция с PlayFab, Firebase, Steam SDK.

Направления:

• Гейм-дизайн — механики, экономика, баланс, нарратив, GDD
• Планирование и архитектура — техническое проектирование, CI/CD, версионирование ассетов
• 3D-арт — моделирование в Blender и Maya, текстурирование в Substance Painter/Designer, риггинг
• 2D-арт и концепт — концепт-арт, иллюстрации, UI/UX, стайл-гайды
• Анимация — скелетная анимация, Spine для 2D, Animator Controller в Unity, Sequencer в Unreal
• VFX — Unity VFX Graph, Unreal Niagara, шейдеры через ShaderGraph и HLSL
• VR/AR — XR Interaction Toolkit, AR Foundation, пространственный UI, оптимизация под гарнитуры
• Мультиплеер — авторитетный сервер, предсказание на клиенте, синхронизация состояния
• Оптимизация — профилирование, batching, LOD-системы, управление памятью

Как устроен наш процесс

Предпроектная фаза

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

На этом этапе:

• Анализируем референсы и определяем технически сложные места
• Выбираем движок под конкретный тип игры (не «мы всегда работаем на Unity», а почему именно Unity или Unreal для этого проекта)
• Составляем первичный GDD или помогаем структурировать существующий
• Оцениваем объём ассетов и выстраиваем pipeline производства контента
• Настраиваем Git с LFS для бинарных ассетов, CI/CD через GameCI или Jenkins

Без этой фазы — не беремся. Это не бюрократия, это страховка от переписывания архитектуры на третьем месяце.

Производство

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

Типичная структура команды на mid-size проекте:

• Геймдизайнер / левел-дизайнер
• 2–3 Unity/Unreal разработчика
• 3D-художник + технический художник
• 2D-художник / концептер (в зависимости от стиля)
• Аниматор
• QA-инженер

На небольших проектах роли совмещаются. Мы не продаём людей — мы продаём результат.

Релиз и поддержка

Сборка под iOS, Android, PC, консоли — в зависимости от платформ. Прохождение сертификации, интеграция аналитики, настройка crash reporting. После релиза — поддержка, патчи, контентные обновления.

Два аспекта, которые определяют судьбу проекта

Архитектурное решение: выбор движка

Это тот вопрос, который задают почти все клиенты в самом начале — «а какой движок лучше?». Ответ всегда зависит от типа игры, но есть несколько практических ориентиров, которые мы используем.

Unity — наш основной инструмент для мобильных игр, казуальных проектов, VR/AR, 2D-игр и прототипов. C# быстрее осваивается, Asset Store сокращает время на типовые задачи, IL2CPP даёт приемлемую производительность на мобилках. Новый render pipeline (URP/HDRP) закрывает большинство графических задач. Минус — производительность рендера при очень большом количестве объектов уступает Unreal без серьёзной работы с ECS/DOTS.

Unreal Engine — когда нужна кинематографическая картинка из коробки, крупный open world, или команда уже знает C++. Nanite и Lumen — реальные инструменты, а не маркетинг, они действительно убирают часть ручной работы с LOD и освещением. Минус — порог входа выше, итерации дольше, сборки тяжелее, мобильная оптимизация требует больше усилий.

WebGL — браузерные игры, корпоративные симуляторы, демо-версии без установки. Unity хорошо компилируется в WebGL, хотя есть ограничения по памяти и отсутствие многопоточности.

Таблица ориентиров:

Мультиплеер: где большинство проектов ломается

Мультиплеер — это не «добавим потом». Это архитектурное решение, которое должно быть принято до написания первой игровой механики. Если начать с single-player кодом и попытаться «добавить сеть» через полгода — это почти всегда переписывание с нуля.

Принципиальный вопрос — авторитетный сервер или peer-to-peer. Для любой игры с конкурентной составляющей ответ однозначный: авторитетный сервер. Клиент не должен доверять себе. Это защита от читов и основа честного геймплея.

Мы работаем с двумя основными стеками:

Photon (PUN2 / Photon Fusion) — хостинговое решение, быстрый старт, хорошо для казуальных мультиплеерных игр, battle royale среднего масштаба, мобильных проектов. Photon Fusion предоставляет State Authority model с предсказанием на клиенте — это значительно упрощает разработку игр, где важен отзывчивый input.

Mirror — open source, разворачивается на собственных серверах. Больше контроля, ниже операционные расходы при масштабировании. Подходит для MMO-сегмента и проектов с нестандартными требованиями к серверной логике.

Ключевые технические задачи в мультиплеере:

• Предсказание на клиенте (Client-Side Prediction) — игрок видит мгновенную реакцию на свои действия, пока подтверждение от сервера ещё в пути
• Reconciliation — когда сервер корректирует состояние, клиент должен плавно принять коррекцию без видимых телепортаций
• Lag compensation — для шутеров: сервер отматывает состояние назад во времени, чтобы честно обсчитать попадания при высоком пинге
• Синхронизация физики — самая болезненная часть; детерминированная физика требует одинакового порядка операций на всех клиентах

Это не исчерпывающий список, но именно эти четыре точки чаще всего становятся причиной «почему игра нормально не работает в сети».

Оптимизация: работа с реальным железом

Ещё один аспект, который часто недооценивают на старте. Оптимизация — это не финальная полировка перед релизом. Это процесс, который идёт параллельно с разработкой.

Для мобильных проектов на Unity:

• Draw call batching — Static Batching и Dynamic Batching для объектов без анимации, GPU Instancing для повторяющейся геометрии
• LOD Group — обязателен для 3D-объектов дальше 10 метров
• Texture atlasing — объединение текстур снижает количество смен материалов
• Occlusion Culling — не рендерить то, что не видно камере
• Memory management — Addressables вместо Resources.Load, контроль за пулингом объектов

Для Unreal:

• Nanite закрывает часть LOD-работы, но не всё — динамические объекты всё ещё требуют ручной оптимизации
• Level Streaming для больших миров
• Material complexity — количество instruction в шейдере напрямую влияет на GPU time

Мы профилируем с первых сборок. Unity Profiler, Memory Profiler, Unreal Insights — стандартные инструменты рабочего процесса, не экзотика.

Технологический стек

С чего начать

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

Если у вас уже есть команда, но проект встал — делаем технический аудит существующего кода и ассетов, после чего предлагаем конкретный план действий.

Если вы ищете усиление для конкретного направления (арт, сетевой код, оптимизация) — работаем в формате аутстаффинга по отдельным специализациям.