Код мобильной игры: архитектура, движки и примеры реализации

Из чего состоит код мобильной игры

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

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

Игровой цикл: сердце любой мобильной игры

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

// Упрощённый цикл: Unity, C#
void Update()
{
    float dt = Time.deltaTime;   // сколько прошло с прошлого кадра

    input.Tick(dt);              // 1. ввод и UI
    world.Step(dt);              // 2. логика и анимация
    renderer.Draw(world);        // 3. отрисовка
}

Проблема такой схемы — переменный шаг. На слабом устройстве кадр может занять 40 мс вместо 16, и физика «прыгнет» вперёд, ломая коллизии. Надёжнее разделить два ритма: логику считать фиксированными шагами, а отрисовку — как получится, с интерполяцией между состояниями.

accumulator += frameTime;

while (accumulator >= FIXED_DT) {   // FIXED_DT = 1/60 с
    physics.Step(FIXED_DT);          // детерминированный шаг
    accumulator -= FIXED_DT;
}

alpha = accumulator / FIXED_DT;      // доля «недоигранного» шага
renderer.Interpolate(alpha);         // плавная картинка без рывков

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

Движки и языки: чем пишут код мобильных игр

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

Отдельная ветка — нативная разработка на Swift и Kotlin с графикой через Metal, Vulkan или OpenGL ES. Она оправдана, когда нужен предельно маленький вес, мгновенный запуск и нестандартный рендер: например, аркада с процедурной графикой или утилита-анимация.

Как организовать код мобильной игры внутри движка

Движок даёт инструменты, но не диктует структуру. Три подхода встречаются чаще всего, и у каждого своя зона комфорта.

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

struct Position { float x, y; };
struct Velocity { float x, y; };

// Данные — рядом друг с другом, обход — линейный
void MovementSystem(float dt)
{
    for (int i = 0; i < activeCount; ++i) {
        positions[i].x += velocities[i].x * dt;
        positions[i].y += velocities[i].y * dt;
    }
}

// Плохо: вызов каждые 100 мс порождает мусор в куче
Instantiate(bulletPrefab, muzzle.position, rotation);

// Хорошо: объект берётся из заранее созданного пула
Bullet b = pool.Rent();
b.Reset(muzzle.position, rotation);

// ... и возвращается обратно
pool.Return(b);

Бюджет кадра: куда уходит время на среднем смартфоне

При 60 кадрах в секунду на всё про всё отводится около 16,6 миллисекунды. Распределение ниже — усреднённая картина для 2D-проекта среднего масштаба.

Размер приложения как часть кода

Вес пустой сборки — это плата за инструмент. Чем выше столбик, тем больше пользователей отвалится на этапе загрузки из магазина.

iOS и Android: где код ведёт себя по-разному

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

Что проверяют перед выпуском