~2 мин чтения

Зачем веб-разработчику Godot

Open-source движок с другой философией — что это даёт разработчику из мира TS/React.

Если Unity ощущается как корпоративная IDE с подпиской (потому что так и есть), то Godot — это нечто другое. MIT-лицензия, 0% роялти, ~100 МБ редактор, который запускается быстрее, чем VS Code. Своя экосистема, свой язык, и для веб-разработчика — местами куда более интуитивная модель.

Эта энциклопедия параллельна Unity-энциклопедии: те же концепции, тот же подход “через веб-аналоги”, но движок другой. Можно читать обе, можно одну.

Что Godot делает иначе

Главное архитектурное отличие от Unity: в Godot одна сцена — это и есть префаб. Любой объект, сделанный в редакторе как сцена, можно инстанциировать в другую сцену, наследовать от него, переопределять отдельные узлы. Никакого разрыва “Scene vs Prefab” нет.

Веб

React-компонент — это и страница, и виджет. <App /> может содержать <Page />, который содержит <Modal />. Одна и та же ментальная модель на всех уровнях.

Unity

В Unity Scene и Prefab — разные сущности с разной семантикой. В Godot и то и другое — это PackedScene. Дерево узлов внутри файла .tscn, сериализованное в текстовый формат (читается как JSON — diff’ится через git без боли).

Что вас может удивить (приятно)

  1. Один скрипт на узел, а не сколько угодно компонентов. Поведение собирается композицией дочерних узлов, а не нагромождением компонентов. Это ближе к “цепочке HOC’ов” в React, чем к Unity-стилю.
  2. Signals — встроенный pub-sub в каждом узле. Объявляете signal damaged(amount: int), эмитите damaged.emit(10), подписываетесь из любого места. Без UnityEvents и без своего event-bus.
  3. GDScript — простой и быстрый, синтаксис похож на Python. Опциональная статическая типизация ускоряет код в 1.5–2 раза.
  4. @export var hp: int = 100 — это эквивалент [SerializeField] в Unity, но одной строкой и с поддержкой подсказок типа в Inspector.
  5. await signal_name — корутины и асинхронность встроены в язык как ключевое слово.
  6. Текстовые форматы сцен (.tscn) и ресурсов (.tres) — diff в git осмыслен. Слияние веток без ритуала “кто закоммитил .meta-файлы”.

Что вас может удивить (неприятно)

  1. 3D-возможности уступают Unity HDRP / Unreal: нет нативного аналога Nanite/Lumen, hi-end рендеринг скромнее. Это видно на крупных проектах с фотореализмом.
  2. Консоли — только через платных партнёров (W4 Games). Никакой “одной кнопки Build for Switch”.
  3. C# доступен, но требует отдельной сборки движка (“Godot .NET edition”) и не работает на вебе. Для веба — только GDScript.
  4. Меньше платных ассетов и плагинов, чем в Unity Asset Store. Asset Library / Godot Asset Store работает, но “тяжёлых” коммерческих решений уровня Cinemachine — мало.
  5. Меньше job market — индустрия по-прежнему сильно на Unity и Unreal.

Когда Godot — правильный выбор

  • 2D-игры: первоклассный 2D pipeline, не имитация через 3D-камеру. TileMaps с авто-тайлами, pixel-perfect, parallax, lighting2D.
  • Малая команда / соло-разработка: быстрый старт, открытый исходник, MIT.
  • Образование и прототипирование: ниже порог входа, чем Unity.
  • Веб-игры с GDScript: Godot экспортируется в HTML5/WASM прямо из коробки.
  • Open-source / free software проекты: нет vendor lock-in.
  • Если для вас важна возможность форкать движок и фиксить баги самостоятельно.

Когда лучше остаться на Unity

  • AAA-уровень 3D-графики — HDRP/Unreal всё ещё впереди.
  • Console publishing — нужно через middleware, стоит денег и времени.
  • Большие команды с готовым tooling-стеком для Unity — миграция дорогая.
  • Готовые SDK и интеграции (mobile ads/mediation, real-time analytics, asset providers).

Куда дальше

В следующем разделе — короткий обзор стека Godot: версии, языки (GDScript и C#), рендер-пайплайны и сопутствующие инструменты. После этого — главная глава про 3D-разработку.