Стоит ли писать свой игровой движок? Вопрос обострился после недавних скандалов с Unity. Одни кричат, что надо немедленно переезжать, другие — что на переезд уйдут годы. Третьи советуют собрать всё с нуля. И, как ни странно, все правы: универсального ответа нет, всё зависит от случая. Но, может, создание своего движка — не такая уж магия?
Главная причина затеять свой движок — сбросить груз сомнительных корпоративных решений. Вы получаете полный контроль над архитектурой, производительностью и можете использовать любимый язык. Движок под ваши задачи не будет бесить вас отсутствием фич, которые вы ждали годами. Тут есть важный психологический момент: когда в багах виноваты «глупые разработчики» чужого движка, это дико раздражает. В своём движке баги тоже будут, но винить придётся себя, а это гораздо легче переносится. К тому же это невероятно весело, и вы прокачаете понимание низкоуровневых процессов так, что станете лучше как разработчик, даже если потом выбросите свой движок в мусор.
Но есть и обратная сторона. Это трудно и отнимает время: не ждите, что напишете клон Unreal после трехмесячных курсов по C++. Вы никогда не превзойдёте гигантов индустрии по набору фич, а функциональность вашего детища ещё долго будет куцей. Есть риск утонуть в полировке движка и выгореть, так и не сделав игру. Да и рандомы в интернете будут считать вас идиотом.
Так что же такое игровой движок? Это не какая-то конкретная библиотека вроде SDL2 или OpenGL. Самое точное и одновременно максимально размытое определение: это любой набор инструментов и библиотек, помогающий делать игры. Если пишете 2D-пиксельный платформер, вам не нужны глобальное освещение, сложная физика на основе инверсной кинематики или графы материалов. Нужны лишь ввод, вывод картинки и немного звука. Это от 2 до 30 дней работы. 1% времени. Остальные 99% — создание самой игры. Движки могут и должны быть маленькими.
Что обычно ждут от движка? Окно, игровой цикл, обработку ввода, графику, звук, управление ассетами, иногда физику и скриптинг. В качестве языка подойдёт любой: C++, Rust, C#, Python или Haskell. Автор использует C++, потому что знает его полтора десятка лет и любит, но разницы нет. Движок удобнее всего подавать как библиотеку: подключаете к проекту и используете.
Для создания окна и обработки ввода вместо уродливых платформенных WinAPI-вызовов берут готовые библиотеки — SDL2, glfw или sfml. Они же дают и контекст для графики. Дальше запускается вечный цикл while (gameIsRunning), где каждый кадр опрашиваются события и рисуется картинка. Графика внутри может быть реализована через OpenGL, Vulkan, Direct3D, WebGPU или даже попиксельной записью в буфер. Для вывода текста подойдёт FreeType или harfbuzz. Аудио — снова через библиотеки вроде OpenAL или SDL2_Audio. Автор написал свой аудиомикшер, который оперирует абстрактными потоками, позволяя комбинировать их как угодно.
Ассеты можно запекать прямо в бинарник, хранить файлами в папке или паковать в архивы. Физика нужна не везде: в платформере или RPG столкновения персонажа с миром пишутся вручную и настраиваются под конкретные нужды. Если нужно серьёзное моделирование, берут Box2D или Bullet. Скриптинг на Lua или Python резко повышает продуктивность и упрощает моддинг, но обязателен не для всех. Свой UI автор считает адом и проектирует новую библиотеку, хотя иногда проще переписать интерфейс с нуля под конкретный проект.
В архитектуре не нужно изобретать Unity. Движок автора — это просто набор максимально изолированных библиотек без единого базового класса Object и глобальных менеджеров. Редактор уровня, сравнимый по мощи с IDE, писать не стоит — это сравнимо по сложности с самим движком. А вот маленькие специализированные утилиты, вроде конвертера моделей из Blender в glTF, окупаются. Подумайте и о дистрибуции: просто скомпилированный бинарник на другом компьютере может не запуститься без нужных DLL.
Главное — честно ответить, чего вы хотите. Если цель в скорости выпуска игры — берите готовый движок и будьте счастливы. Если оптимизируете процесс ради долгосрочной гибкости, контроля и роста — пишите свой. Не делайте движок, чтобы казаться «настоящим» разработчиком. Делайте, потому что он вам нужен или вы хотите понять, как всё устроено. Автор три года пилит свой движок в 100 тысяч строк кода, успешно выпускает на нём коммерческие игры и ни разу не пострадал от корпоративных фортелей. Все баги в нём — его личные и решаемые. Это чувство контроля вызывает привыкание. Но единственно верного ответа нет. Просто убедитесь, что вам в кайф.