Сравнение игровых движков с открытым исходным кодом: Godot, Bevy, Stride и O3DE

Для небольшой команды, начинающей работу над обычной 2D- или 3D-игрой, Godot — полезный первый кандидат. Bevy подходит команде с опытом Rust, готовой самостоятельно обеспечивать большую часть инструментов; Stride заслуживает внимания при работе с C#; O3DE стоит оценить, если команда способна поддерживать более масштабный процесс работы с 3D-контентом и сборками. Это отправные точки для проверки, а не рейтинг производительности.

Это сравнение на основе документации предназначено для разработчиков, выбирающих игровой движок. По состоянию на 2 ноября 2026 года проверены материалы о релизах Godot 4.7.2, Bevy 0.20, Stride 4.4 и O3DE 26.05. Исполняемый пример ниже проверяет лишь небольшую функцию движения в Godot; он ничего не доказывает об удобстве редакторов других движков, скорости рендеринга или надёжности экспорта.

Что мы сравниваем?

Все четыре проекта называют себя игровыми движками. Их рабочие процессы различаются: интегрированный визуальный редактор и программный подход на основе ECS оставляют команде разный объём работы по подбору и объединению инструментов. Фреймворк или библиотека рендеринга тоже могут подойти, но недостающие инструменты для сцен, ресурсов и редактирования следует учитывать как работу, которую придётся выполнить команде.

Движок и рассматриваемый релиз	Процесс разработки	Первый вопрос перед выбором
Godot 4.7.2	Редактор сцен и узлов со скриптами	Поддерживает ли выбранный язык экспорт на реальную целевую платформу?
Bevy 0.20	Системы и компоненты на Rust, построенные вокруг ECS	Сможет ли команда поддерживать инструменты и выполнять миграции API?
Stride 4.4	C# и Game Studio	Доступен ли редактор на компьютерах разработчиков?
O3DE 26.05	Расширяемый 3D-редактор и компонентный конвейер	Сможет ли команда собрать проект, импортировать ресурсы и подготовить небольшую сцену к распространению?

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

Какой движок соответствует рабочему процессу команды?

Godot: начните с полного цикла создания игры

Godot — разумная отправная точка, если команда хочет редактировать сцены, добавлять поведение и вносить изменения в одной среде. Его лицензия MIT разрешает создавать проприетарные игры; при распространении движка по-прежнему требуется включать соответствующие уведомления об авторских правах и лицензии. У плагинов, шрифтов, музыки и моделей свои условия.

Проверьте сочетание языка и платформы на раннем этапе. В документации Godot по веб-экспорту сейчас указано, что проекты Godot 4 на C# нельзя экспортировать в веб. Поэтому настольный прототип на C# не подтверждает возможность выпуска для браузера. Для консолей руководство Godot по портированию описывает одобрение платформой, официальные SDK и закрытые шаблоны экспорта либо услуги сторонних поставщиков. Открытый исходный код движка не отменяет этот процесс.

Bevy: выбирайте Rust вместе с ответственностью за инструменты

Bevy — движок, а не просто средство рендеринга. Во введении описаны Rust, ECS и выбор между лицензиями MIT и Apache 2.0. Там также предупреждают о релизах с несовместимыми изменениями API и потенциально сложных миграциях.

Поэтому Bevy интересен команде, которая хочет сделать системы и компоненты основой своей модели разработки. Интеграцию редактора, цикл изменения ресурсов и миграцию версий следует продемонстрировать на проекте команды. Одно лишь знание Rust не доказывает, что цикл создания игры будет быстрее, а параллельная ECS не гарантирует меньшего времени кадра в конкретной игре.

Stride: отделяйте поддержку C# от доступности редактора

В FAQ Stride указаны лицензия MIT и отсутствие роялти за движок. Рабочий процесс на C# может сделать его полезным кандидатом для команды, уже использующей .NET.

В матрице платформ разграничены системы для разработки и целевые платформы игр: Windows полностью поддерживает редактор; Linux и macOS поддерживают сборку и работу только с кодом с оговорками, а нативный редактор вне Windows недоступен. В анонсе 4.4 сообщается об улучшениях сборки вне Windows. Эти улучшения не следует превращать в утверждение, что одинаковая работа в редакторе доступна везде.

O3DE: оцените конвейер до демонстрационных возможностей

O3DE стоит включить в список кандидатов команде, готовой самостоятельно поддерживать расширяемый конвейер для 3D. Его файл лицензии устанавливает Apache 2.0 по умолчанию с возможностью выбора MIT и отдельно указывает сторонние компоненты. На странице загрузки перечислены пакеты для Windows/Linux и существенные требования к компьютеру разработчика. Это требования к системе разработки, а не общий список целевых платформ экспорта игр.

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

Означает ли «бесплатно» открытый исходный код или создание игры без затрат?

Нет. Доступ к исходному коду и нулевая цена покупки не подтверждают наличие открытой лицензии. Например, Defold сейчас описывает себя как source available; оцените его конкретную лицензию, а не относите его автоматически к той же группе, что и четыре движка выше.

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

Что должен проверить небольшой прототип?

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

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

Диаграмма показывает один вызов advance. Приведённая ниже тестовая обвязка повторяет вызовы и проверяет результаты; она не считывает клавиатуру и не отображает персонажа. В справочнике Vector2 описаны операции с векторами. Это отделяет проверенное поведение от утверждений о продуктивности работы в редакторе или производительности игры.

Если стандартный исполняемый файл редактора Godot 4.7.2 доступен как godot, сохраните project.godot и movement.gd в одном каталоге. После установки движка для запуска скрипта не нужны сцена, внешние ресурсы, пакеты или доступ к сети.

project.godot:

config_version=5

movement.gd:

extends SceneTree

const SPEED := 120.0
const LIMIT := Vector2(640.0, 360.0)

func advance(pos: Vector2, direction: Vector2, delta: float) -> Vector2:
    var bounded := direction.limit_length(1.0)
    var next := pos + bounded * SPEED * delta
    return next.clamp(Vector2.ZERO, LIMIT)

func _initialize() -> void:
    var cases := [
        [Vector2(100, 100), Vector2.ZERO, 0.5, Vector2(100, 100)],
        [Vector2(100, 100), Vector2.RIGHT, 0.5, Vector2(160, 100)],
        [Vector2.ZERO, Vector2(1, 1), 1.0, Vector2(84.852814, 84.852814)],
        [Vector2.ZERO, Vector2(0.5, 0), 1.0, Vector2(60, 0)],
        [Vector2(639, 100), Vector2.RIGHT, 1.0, Vector2(640, 100)],
        [Vector2(5, 100), Vector2.LEFT, 1.0, Vector2(0, 100)],
        [Vector2(100, 359), Vector2.DOWN, 1.0, Vector2(100, 360)],
        [Vector2(100, 100), Vector2.RIGHT, 0.0, Vector2(100, 100)],
    ]
    for sample in cases:
        var actual := advance(sample[0], sample[1], sample[2])
        if not actual.is_equal_approx(sample[3]):
            push_error("movement mismatch")
            quit(1)
            return
    var split := advance(advance(Vector2(100, 100), Vector2.RIGHT, 0.25), Vector2.RIGHT, 0.25)
    if not split.is_equal_approx(advance(Vector2(100, 100), Vector2.RIGHT, 0.5)):
        push_error("time-step mismatch")
        quit(1)
        return
    print("movement cases=9")
    quit(0)

Запустите его из этого каталога через интерфейс командной строки Godot. В macOS замените godot путём Godot.app/Contents/MacOS/Godot внутри установленного приложения, если он отсутствует в PATH.

godot --headless --no-header --path . --script movement.gd --quit-after 1

Пример был выполнен локально в macOS с Godot 4.7.2. Он выдал:

movement cases=9

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

Как принять окончательное решение?

Выберите кандидата, который обеспечивает необходимые игре рабочий процесс и сборку для целевой платформы при приемлемой для команды нагрузке по сопровождению. Если в приоритете визуальное редактирование, начните прототип с Godot. Если команда осознанно хочет работать с Rust/ECS и отвечать за этот процесс, проверьте затраты на инструменты и миграции Bevy. Команде C# стоит проверить Stride на реальных компьютерах для работы с редактором. Для более масштабного 3D-конвейера проверьте цикл работы O3DE с ресурсами и сборками, прежде чем полагаться на демонстрационную функцию.

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