Создание игр на движке Godot

Основы Godot: редактор, сцены, ноды и ресурсы

Зачем понимать базовые сущности Godot

Godot устроен так, что почти всё в игре собирается из небольших строительных блоков:

Ноды формируют поведение и структуру.

Сцены объединяют ноды в переиспользуемые «заготовки».

Ресурсы хранят данные (текстуры, звуки, материалы, параметры и даже пользовательские структуры данных).

Если вы уверенно различаете эти три понятия, то сможете:

быстрее собирать прототипы

делать переиспользуемые элементы (враги, пули, UI-окна)

поддерживать порядок в проекте и не запутаться в зависимостях

Официальная документация Godot (полезно держать открытой во время обучения): Godot Docs (stable)

Редактор Godot и структура проекта

Project Manager и создание проекта

При запуске Godot сначала открывается Project Manager. В нём вы:

создаёте новый проект

выбираете папку проекта

открываете существующие проекты

Практическое правило: держите проект в отдельной папке без кириллицы и пробелов в пути. Это снижает риск проблем с путями и сборкой.

Главное окно редактора

Обычно в Godot (в режиме 2D или 3D) вы будете работать с четырьмя ключевыми областями:

Viewport (центр) — сцена и объекты в ней

Scene (слева) — дерево нод текущей сцены

Inspector (справа) — свойства выбранной ноды или ресурса

FileSystem (снизу слева) — файлы проекта

Также важны вкладки сверху:

2D / 3D — рабочий режим

Script — редактор кода

AssetLib — библиотека ассетов (если нужна)

Сохранение и импорт ассетов

Godot автоматически импортирует многие форматы (например, PNG, WAV/OGG), создавая рядом служебные импорт-данные.

Практические советы по структуре папок:

scenes/ — сцены (.tscn)

scripts/ — скрипты (.gd)

assets/ — картинки, звуки, шрифты

resources/ — ваши ресурсы (.tres, .res)

Ноды: минимальная единица логики и структуры

Что такое нода

Нода — это объект, который выполняет конкретную роль. Примеры:

Node2D — базовая нода для 2D-объектов с позицией/поворотом/масштабом

Sprite2D — отображение текстуры

CollisionShape2D — форма коллизии

Area2D — зона, которая реагирует на пересечения

CharacterBody2D — удобная основа для управляемого персонажа

Camera2D — камера

CanvasLayer и UI-ноды (Control, Button, Label) — интерфейс

Каждая нода имеет:

свойства (в Inspector)

методы (действия)

сигналы (события, о них ниже)

дочерние ноды (иерархия)

Официальное введение в ноды и сцены: Nodes and Scenes

Дерево нод (иерархия)

Ноды организованы в дерево: у каждой ноды может быть родитель и дети. Это даёт удобство:

трансформации могут наследоваться (в 2D/3D)

можно группировать логику (например, игрок как корневая нода и её части как дочерние)

легко находить элементы сцены

!Схема, показывающая дерево нод и то, как сцены используются как переиспользуемые шаблоны

Скрипт как поведение ноды

Скрипт обычно «вешается» на ноду и расширяет её поведение.

Пример (GDScript), который выводит сообщение при старте:

Важно понимать:

extends Node2D означает, что скрипт добавляет логику ноде типа Node2D

_ready() вызывается, когда нода готова к работе (после появления в дереве)

Сцены: композиция нод и переиспользуемость

Что такое сцена

Сцена в Godot — это сохранённое дерево нод. Обычно файл сцены имеет расширение .tscn.

Сцена может быть:

уровнем

персонажем

врагом

UI-окном

снарядом

любым «компонентом», который удобно переиспользовать

Сильная сторона Godot — композиция: вы собираете сложное из простого.

Корневая нода сцены

У каждой сцены есть корневая нода. Именно она считается «главной» для этой сцены. Её тип влияет на то, как сцену удобнее использовать:

Node2D — универсальная 2D-заготовка

CharacterBody2D — персонаж/враг с движением

Control — UI-сцена

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

Инстансирование сцены

Когда вы «вставляете» одну сцену в другую, вы создаёте инстанс (экземпляр) сцены.

Типичный сценарий:

Enemy.tscn — сцена врага

Level_01.tscn — сцена уровня

уровень создаёт врагов как инстансы (вручную в редакторе или из кода)

Для справки по устройству дерева сцен и запуску: SceneTree

Сигналы: событийная связь без жёстких зависимостей

Сигналы — это механизм событий. Примеры:

кнопка отправляет сигнал pressed

зона Area2D отправляет сигнал при входе тела (body_entered)

Преимущество сигналов:

объект сообщает «что-то произошло», а слушатели решают, что делать

меньше прямых ссылок между объектами

Официальная статья по сигналам: Signals

Ресурсы: данные, которые можно переиспользовать

Что такое ресурс

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

Примеры ресурсов:

текстуры, аудио, шрифты

материалы

Animation (внутри AnimationPlayer)

пользовательские ресурсы (например, описание предмета, параметры оружия)

Ресурсы часто:

разделяются между объектами

загружаются по пути

редактируются в Inspector

Документация по ресурсам: Resources

Встроенный ресурс и внешний ресурс

В Inspector многие поля позволяют выбрать ресурс. У ресурса обычно есть два варианта хранения:

встроенный — ресурс хранится внутри сцены (удобно для уникальных настроек)

внешний — ресурс сохранён отдельным файлом .tres/.res (удобно для переиспользования)

Практическое правило:

если данные должны быть одинаковыми у многих объектов (например, параметры оружия), делайте внешний ресурс

если это уникальная настройка одного конкретного объекта в одной сцене, можно оставить встроенным

Как эти понятия работают вместе

Полезная ментальная модель:

Нода — «поведение/роль» (камера, спрайт, физика, кнопка)

Сцена — «сборка из нод» (персонаж, враг, уровень)

Ресурс — «данные» (картинка, звук, параметры, конфигурация)

Таблица для быстрого сравнения:

| Сущность | Что это | Обычно хранится | Зачем нужна | |---|---|---|---| | Нода | объект в дереве | внутри сцены | структура и логика | | Сцена | дерево нод как шаблон | .tscn | переиспользуемые объекты и уровни | | Ресурс | данные и настройки | .tres/.res или встроенно | переиспользуемые параметры и ассеты |

Частые ошибки новичков

Пытаться делать «один гигантский уровень» в одной сцене без переиспользуемых подсцен.

Дублировать одинаковые настройки в десятках мест вместо вынесения в ресурс.

Связывать всё со всем прямыми ссылками вместо сигналов.

Не следить за порядком в папках (в результате тяжело искать сцены/скрипты/ассеты).

Итог

В этой статье вы разобрали базовые кирпичики Godot:

как устроен редактор и где что находится

что такое ноды и как они образуют дерево

что такое сцены и как они помогают переиспользовать объекты

что такое ресурсы и как отделять данные от логики

зачем нужны сигналы как событийный механизм

В следующих материалах курса на этой базе будет проще переходить к практике: созданию персонажа, управлению, коллизиям, UI и сборке небольшого игрового прототипа.

GDScript: логика игры, сигналы и работа с данными

Зачем нужен GDScript в логике Godot

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

GDScript — основной язык сценариев Godot. Его сильные стороны в контексте движка:

он тесно интегрирован со сценами, нодами, инспектором и сигналами

им удобно описывать игровую логику и события

он хорошо подходит для быстрого прототипирования

Официальная база по языку: GDScript basics

Скрипт как поведение ноды

Чаще всего скрипт прикрепляется к ноде и расширяет ее поведение.

Минимальный пример:

Ключевые идеи:

extends Node2D означает, что скрипт предназначен для ноды типа Node2D (или ее наследников)

func _ready() вызывается, когда нода попала в дерево сцены и готова работать

Полезная справка по жизненному циклу нод: Overridable functions

Переменные, типы и свойства

Переменные и базовые типы

В GDScript можно писать как динамически, так и с явными типами.

Практические рекомендации:

используйте типы в публичных полях и важных местах, чтобы ловить ошибки раньше

для координат и направления в 2D чаще всего используются Vector2 и Vector2i

Константы

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

Свойства в Inspector через экспорт

Чтобы настраивать параметры прямо в редакторе, используйте @export.

Это связывает код с редактором так, что дизайнерская настройка не требует правки скрипта.

Документация по экспорту: GDScript exports

Ссылки на ноды: @onready и Sprite2D

func _ready() -> void: sprite.modulate = Color(1, 0.9, 0.9)

Пользовательские сигналы

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

Как это использовать на уровне:

gdscript var hud := get_tree().get_first_node_in_group("hud") gdscript func save_game() -> void: var data := { "coins": 12, "level": 3 } var json_text := JSON.stringify(data) var f := FileAccess.open("user://save.json", FileAccess.WRITE) f.store_string(json_text)

func load_game() -> Dictionary: if not FileAccess.file_exists("user://save.json"): return {} var f := FileAccess.open("user://save.json", FileAccess.READ) var text := f.get_as_text() var parsed := JSON.parse_string(text) if typeof(parsed) != TYPE_DICTIONARY: return {} return parsed `

Что важно в этом примере:

FileAccess отвечает за чтение и запись файлов

JSON.stringify превращает словарь в строку

JSON.parse_string возвращает Variant, поэтому проверка типа помогает избежать ошибок

Документация: FileAccess, JSON

!Поток данных при сохранении и загрузке через JSON

Итог

Вы добавили к базовым сущностям Godot (ноды, сцены, ресурсы) слой поведения и данных:

как скрипт расширяет ноду и какие функции вызываются движком

как делать настраиваемые поля через @export и безопасно получать дочерние ноды через @onready

как сигналы помогают строить событийную логику без жестких зависимостей

как хранить игровые данные в коллекциях и выносить параметры в ресурсы

как устроить простое сохранение через user://, FileAccess и JSON

Следующие практические шаги обычно строятся на этом фундаменте: управление персонажем, взаимодействия через Area2D`, UI через сигналы и менеджеры состояния.

2D-геймплей: управление, физика, анимации и камеры

Как эта тема связана с прошлым материалом

В первых статьях вы разобрали, что игра в Godot строится из нод, упакованных в сцены, а поведение задаётся скриптами на GDScript и связывается через сигналы. Теперь соберём базовый 2D-геймплейный цикл:

ввод игрока

физическое движение и столкновения

реакция на события (через Area2D и сигналы)

анимации как отображение состояния

камера, которая делает игру играбельной

К концу статьи у вас будет понятная «скелетная» архитектура 2D-персонажа, которую можно развивать в платформер, топ-даун или экшен.

Минимальная сцена игрока: какие ноды нужны и зачем

Самый практичный старт для управляемого персонажа в 2D в Godot 4: CharacterBody2D.

Типовое дерево нод сцены Player.tscn:

CharacterBody2D (корень, движение и столкновения)

CollisionShape2D (форма коллизии)

AnimatedSprite2D или Sprite2D (визуал)

Camera2D (если камера следует за игроком)

!Дерево нод игрока и назначение каждой части

Справка по CharacterBody2D: CharacterBody2D (Godot Docs)

Управление: Input Map и чтение ввода

Почему важно начинать с Input Map

Вместо проверки конкретных клавиш (например, A/D) лучше работать с действиями:

вы сможете легко поменять клавиши

добавите геймпад без переписывания логики

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

В Project Settings → Input Map добавьте действия (названия примерные):

move_left

move_right

jump

Затем в коде используйте Input.get_axis или Input.get_vector.

Справка по вводу: Input (Godot Docs)

Быстрый вариант для горизонтали

Input.get_axis('move_left', 'move_right') возвращает число от -1 до 1

Физика движения: скорость, гравитация, прыжок

Главный принцип

Физическое движение делайте в _physics_process(delta), потому что этот цикл идёт с фиксированным шагом и предназначен для физики.

Справка по жизненному циклу: Overridable functions (Godot Docs)

Пример: базовый платформенный контроллер

Ниже минимальный контроллер для платформера. Он использует:

velocity как текущую скорость тела

is_on_floor() чтобы понимать, стоим ли мы на земле

move_and_slide() чтобы двигаться и корректно «скользить» по поверхностям

Что здесь важно понять:

jump_velocity обычно отрицательная, потому что в 2D ось Y направлена вниз

delta нужен, чтобы ускорение (гравитация) добавлялось одинаково при разной частоте кадров

move_and_slide() делает большую часть «физической рутины» за вас: перемещение, учёт столкновений, корректировку скорости

Справка по move_and_slide: CharacterBody2D (Godot Docs)

Столкновения и взаимодействия: CollisionShape2D, слои и Area2D

CollisionShape2D и почему без него всё «пролетает»

CharacterBody2D сам по себе не имеет формы столкновения. Форма задаётся дочерней нодой CollisionShape2D, в которой вы выбираете RectangleShape2D, CapsuleShape2D и другие.

Слои и маски коллизий простыми словами

Layer: где находится объект (каким «типом» он является)

Mask: с чем сталкивается/пересекается объект

Это позволяет, например:

игроку сталкиваться со стенами, но не сталкиваться с монетками

пулям сталкиваться с врагами, но не с игроком

Справка по физике и коллизиям: Physics introduction (Godot Docs)

Area2D для триггеров: монетки, опасности, чекпоинты

Area2D удобна, когда вам не нужно «толкаться» физически, а нужно событие пересечения.

Пример Coin.tscn:

Area2D (корень)

CollisionShape2D

AnimatedSprite2D или Sprite2D

Скрипт монетки с сигналом:

Подключение на уровне (или в менеджере счёта):

Ключевая идея: анимация не живёт отдельно от геймплея, она отображает состояние.

Когда проект вырастет, это обычно превращают в явную конечную автоматику состояний (например, Idle, Run, Jump, Fall, Attack), но на старте полезнее закрепить именно эту связку: физика → состояние → анимация.

Камера: чтобы игрок видел то, что нужно

Базовая настройка Camera2D

Добавьте Camera2D внутрь игрока и включите Current (или сделайте make_current() из кода). Тогда камера будет следовать за игроком автоматически, потому что является дочерней нодой.

Справка: Camera2D (Godot Docs)

!Как Camera2D следует за игроком и какие параметры влияют на ощущение

Параметры, которые реально улучшают ощущения

Position Smoothing: сглаживание движения камеры, чтобы она не дёргалась

Limit: ограничения камеры, чтобы не показывать пустоту за границами уровня

Zoom: приближение и отдаление, влияет на темп и читаемость

Практическое правило:

платформеру часто полезно небольшое сглаживание

топ-дауну полезно подобрать Zoom, чтобы видеть чуть больше пространства вокруг

Важная деталь про несколько камер

Если в сцене больше одной Camera2D, активной будет только одна. Поэтому при переключениях (катсцены, комнаты, прицеливание) важно явно управлять тем, какая камера current.

Мини-чеклист: собрать «ходячий прототип» без лишней магии

Создайте Player.tscn с CharacterBody2D, CollisionShape2D, AnimatedSprite2D, Camera2D.

Настройте Input Map действия move_left, move_right, jump.

Добавьте скрипт движения на _physics_process и используйте move_and_slide().

Сделайте хотя бы одну Area2D-сцену (монетка или триггер) и обработайте её через сигнал.

Привяжите анимации к состоянию: земля/воздух, движение/простой.

Включите камеру как текущую и настройте сглаживание или лимиты.

Итог

Вы собрали фундамент 2D-геймплея в Godot на тех же сущностях, что были в прошлых статьях:

сцена игрока как композиция нод

GDScript как слой логики

сигналы для событий взаимодействия

CharacterBody2D и _physics_process для движения

AnimatedSprite2D/AnimationPlayer для отображения состояния

Camera2D для управляемого кадра

На этой базе дальше естественно переходить к уровню (TileMap), врагам, урону, UI и менеджерам состояния игры.

3D в Godot: сцена, освещение, материалы и навигация

Как 3D продолжает идеи из прошлых статей

Ранее вы разобрали базовые строительные блоки Godot: ноды, сцены, ресурсы, а также логику на GDScript и событийную связь через сигналы. В 3D всё это работает так же, меняются в основном типы нод и набор типовых задач:

вместо Node2D чаще используется Node3D

вместо Sprite2D чаще используется MeshInstance3D

добавляются источники света, окружение и материалы (PBR)

появляется навигация по navmesh для NPC

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

Минимальная 3D-сцена: какие ноды нужны

Для стартовой 3D-сцены удобно создать Main.tscn и собрать базовый набор:

Node3D как корень

Camera3D чтобы видеть сцену

DirectionalLight3D или OmniLight3D для освещения

MeshInstance3D для объектов (пол, стены, препятствия)

StaticBody3D и CollisionShape3D для физического столкновения (если нужно ходить по полу)

WorldEnvironment для атмосферы, тонемаппинга и фонового освещения

Документация по базовым нодам 3D:

Node3D

Camera3D

MeshInstance3D

!Типовое дерево нод для минимальной 3D-сцены и где настраиваются ключевые параметры

Осями и единицами в 3D

В 3D у Godot используются оси:

X: вправо/влево

Y: вверх/вниз

Z: вперёд/назад

Практическое правило: договоритесь в проекте о масштабе (обычно 1 unit = 1 метр) и придерживайтесь его, иначе будут проблемы с камерой, физикой и скоростью движения.

Transform в 3D: позиция, поворот, масштаб

У Node3D есть transform:

position (в Godot 4 обычно как global_position или position через transform)

rotation / rotation_degrees

scale

Важный момент: как и в 2D, transform наследуется по иерархии. Если вы сделали Camera3D дочерней нодой персонажа, камера будет следовать за ним автоматически.

Геометрия и физика: что отображает мир и что с ним сталкивается

MeshInstance3D: только визуал

MeshInstance3D отвечает за отрисовку меша (например, BoxMesh, PlaneMesh, импортированный .glb). Но сам по себе он не “твёрдый”. Для столкновений нужна физическая нода.

StaticBody3D, CharacterBody3D, RigidBody3D: кто “участвует” в физике

StaticBody3D: неподвижные объекты (пол, стены)

CharacterBody3D: управляемые персонажи (игрок, враг с контроллером)

RigidBody3D: физические тела (ящики, бочки), которые двигаются силами

Документация:

StaticBody3D

CharacterBody3D

RigidBody3D

Коллизии: CollisionShape3D

Чтобы объект участвовал в столкновениях, добавьте CollisionShape3D и выберите форму (BoxShape3D, CapsuleShape3D и другие). Типовая сборка пола:

StaticBody3D

дочерний CollisionShape3D

дочерний MeshInstance3D

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

Освещение: что реально важно для хорошей 3D-картинки

В 3D свет почти всегда важнее “красивых моделей”. В Godot базовая схема строится из:

источников света

окружения (WorldEnvironment)

материалов (о них дальше)

Документация:

Lights and shadows

WorldEnvironment

Виды источников света

DirectionalLight3D: свет “как солнце”, параллельные лучи, хорошо для улицы

OmniLight3D: лампочка, свет во все стороны, хорошо для комнат

SpotLight3D: прожектор, конус света

Практическое правило:

для внешней сцены начните с одного DirectionalLight3D

для интерьера добавляйте OmniLight3D и SpotLight3D точечно

!Сравнение типов света и их визуального эффекта

Тени: качество против производительности

Тени делают сцену читаемой, но стоят дорого. Настройка обычно включает:

включение теней у конкретного источника света

выбор размера карты теней и фильтра

Практическое правило: включайте тени только там, где они действительно улучшают восприятие. Для прототипа достаточно теней от одного главного света.

WorldEnvironment: “воздух” и базовая яркость

WorldEnvironment управляет:

фоном (небо/цвет)

постобработкой

тонемаппингом

окружающим светом

Для быстрого улучшения картинки:

Добавьте WorldEnvironment.

Создайте ресурс Environment в Inspector.

Настройте Background (например, Sky) и Ambient Light.

Материалы: почему PBR важен и как не запутаться

В Godot 4 типовой материал для 3D — StandardMaterial3D (PBR). Он описывает, как поверхность взаимодействует со светом.

Документация:

StandardMaterial3D

3D materials

Главные параметры PBR, которые нужно знать

Albedo: базовый цвет или текстура поверхности

Metallic: насколько поверхность “металлическая”

Roughness: насколько поверхность “шероховатая” (чем выше, тем меньше блеск)

Normal Map: имитация мелкого рельефа без усложнения геометрии

Практическое правило:

не делайте объект одновременно сильно металлическим и сильно шероховатым “наугад”: сначала добейтесь хорошего результата на одном эталонном объекте, потом переносите подход

Материал как ресурс: переиспользование и порядок в проекте

Материал — это ресурс, а значит вы можете:

хранить его встроенно в сцене

сохранить как внешний .tres и применять в разных местах

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

Material Override и поверхности меша

У MeshInstance3D есть два частых способа назначить материал:

Material Override: принудительно один материал на весь меш

материалы по поверхностям (если у меша несколько surfaces)

Практическое правило: для простых прототипов используйте Material Override, чтобы меньше отвлекаться.

ShaderMaterial: когда стандартного материала мало

ShaderMaterial нужен, когда вам требуется нестандартный эффект (например, растворение, подсветка контура, процедурные текстуры). На старте достаточно знать, что это тоже ресурс и он так же назначается мешу.

Документация:

ShaderMaterial

Навигация: как заставить NPC идти к цели в 3D

Навигация в 3D обычно строится вокруг навигационной сетки (navmesh): поверхности, по которым разрешено ходить.

Ключевые компоненты:

NavigationRegion3D: хранит навигационную сетку для области

NavigationAgent3D: компонент на персонаже, который запрашивает путь и помогает двигаться по нему

Документация:

NavigationRegion3D

NavigationAgent3D

Navigation (3D)

!Понятная схема: где navmesh, где агент, куда строится путь

Сборка навигации в редакторе

Один из типовых вариантов для прототипа:

Создайте NavigationRegion3D.

Добавьте/укажите navmesh (ресурс NavigationMesh).

Выполните запекание navmesh по геометрии уровня.

Важно: navmesh должен “лежать” на поверхностях, по которым вы хотите ходить, и обходить препятствия.

Как агент получает путь

NavigationAgent3D работает так:

Вы задаёте цель (target position).

Агент вычисляет путь по navmesh.

Вы в своём контроллере берёте следующую точку пути и двигаете тело.

Ниже пример упрощённого контроллера NPC для CharacterBody3D. Он не использует анимации и сложное избегание столкновений, а показывает сам принцип.

Что важно в этом примере:

NavigationAgent3D не двигает персонажа сам по себе, он подсказывает куда идти

CharacterBody3D двигается вашим кодом через velocity и move_and_slide() (аналогично идее из 2D)

обнуление y нужно, чтобы агент не пытался тянуть вектор вверх/вниз в простом “наземном” поведении

Отладка навигации: что проверять первым

Если NPC “не идёт”, чаще всего причина одна из следующих:

Агент не стоит на navmesh или цель вне navmesh.

Navmesh не запечён или запечён не на той геометрии.

Неверные масштабы: персонаж больше, чем проходы navmesh.

Вы двигаете тело не в _physics_process, а в _process, и получаете нестабильность.

Практическая связка с предыдущими темами курса

Чтобы 3D-проект не превратился в хаос, используйте те же принципы, что и в 2D:

упаковывайте объекты в сцены (Player3D.tscn, Enemy3D.tscn, Level_01.tscn)

параметры выносите в @export (скорость NPC, ссылки на target, материалы)

события оформляйте сигналами (например, reached_target, took_damage)

материалы, navmesh и environment храните как ресурсы и переиспользуйте

Итог

Вы собрали базовую картину 3D в Godot:

как устроена минимальная 3D-сцена на Node3D с камерой и мешами

чем отличается визуальная геометрия (MeshInstance3D) от физики (тела и CollisionShape3D)

как освещение строится из источников света и WorldEnvironment

как работают PBR-материалы через StandardMaterial3D и почему материалы стоит переиспользовать как ресурсы

как настроить 3D-навигацию через NavigationRegion3D и вести NPC по пути с NavigationAgent3D

UI, звук, сохранения, оптимизация и экспорт проекта

Зачем эта тема нужна после 2D и 3D

В предыдущих статьях вы собрали фундамент Godot: ноды, сцены, ресурсы, скрипты на GDScript, событийность через сигналы, а также базовый 2D- и 3D-геймплей. Следующий шаг, чтобы прототип стал игрой, обычно включает пять практических блоков:

UI: меню, HUD, настройки, экран паузы

Звук: эффекты, музыка, микс через аудио-шины

Сохранения: прогресс игрока и настройки

Оптимизация: профилирование и устранение узких мест

Экспорт: сборка билда под нужную платформу

Эта статья показывает типовые решения в Godot 4, которые хорошо масштабируются: UI собирается как переиспользуемые сцены, звук управляется через шины и менеджер, сохранения изолируются в отдельном слое, а оптимизация и экспорт опираются на инструменты движка.

UI в Godot: Control-ноды, контейнеры, сигналы и темы

Базовая модель UI: Control и дерево интерфейса

UI в Godot обычно строится на нодах, наследниках Control. Такие ноды рисуются в 2D-интерфейсе и имеют систему якорей, размеров и контейнеров.

Control задаёт основу UI-элемента и его размещение

Label, Button, TextureRect, ProgressBar и другие дают готовые элементы

Container-ноды автоматически раскладывают дочерние элементы

Документация:

Control

Container

Практическое правило: делайте UI отдельными сценами, чтобы их можно было инстансировать и переиспользовать (например, HUD.tscn, PauseMenu.tscn, SettingsMenu.tscn).

CanvasLayer: как отделить UI от мира

Если у вас камера двигается по уровню, UI обычно должен оставаться на месте. Для этого удобно держать интерфейс в CanvasLayer.

мир (2D/3D) живёт в обычных нодах сцены

UI размещается внутри CanvasLayer и не «ездит» вместе с камерой

Документация: CanvasLayer

Якоря и контейнеры: что выбирать

В Godot есть два основных подхода к адаптивной раскладке UI:

Anchors (якоря) полезны для простых элементов: например, закрепить счёт в правом верхнем углу

Containers полезны для меню и списков: они автоматически управляют размером и позициями дочерних элементов

Типовые контейнеры:

VBoxContainer для вертикального меню

HBoxContainer для горизонтальных панелей

GridContainer для сеток (инвентарь)

MarginContainer для внутренних отступов

Сигналы в UI: кнопки и события без жёстких связей

UI идеально сочетается с сигналами, потому что кнопка должна сообщать о событии, а логика игры решает, что делать.

Пример подключения pressed у кнопки:

Документация по смене сцен: SceneTree

!Как UI через сигналы связывается с игровой логикой

Темы и единый стиль

Чтобы интерфейс выглядел цельно, используйте Theme.

тема хранит шрифты, размеры, цвета, стили кнопок и полей

тему можно применить ко всему UI или к отдельной ветке интерфейса

Документация: Theme

Практическое правило: если вы меняете шрифт и цвета «вручную» в каждом элементе, проект быстро станет трудно поддерживать. Лучше иметь одну тему и изменять стиль в одном месте.

Пауза и меню паузы: важная деталь про Process Mode

Пауза часто делается через остановку дерева сцены:

Но тогда многие ноды перестанут обрабатываться. Для меню паузы обычно нужно, чтобы UI продолжал работать.

Практический подход:

мир ставится на паузу через get_tree().paused = true

нода меню паузы получает Process Mode = When Paused (в инспекторе), чтобы кнопки реагировали

Документация: Node

Звук: AudioStreamPlayer, шины, микс и менеджер

Какие ноды отвечают за звук

В Godot есть несколько типовых вариантов проигрывания:

AudioStreamPlayer для обычного (непозиционного) звука, например музыки и UI-кликов

AudioStreamPlayer2D для позиционного 2D-звука

AudioStreamPlayer3D для позиционного 3D-звука

Документация:

AudioStreamPlayer

AudioStreamPlayer2D

AudioStreamPlayer3D

Практическое правило: музыку и UI лучше вести как непозиционные звуки, а эффекты шагов/выстрелов делать позиционными, если это улучшает восприятие.

Аудио-шины: как управлять громкостью групп

Аудио в Godot идёт через Audio Buses (шины). Это микшер, где вы:

объединяете звуки по категориям

ставите эффекты (компрессор, реверберация)

делаете настройки громкости для игрока

Типовая структура шин:

Master

Music

SFX

UI

Документация: Audio buses

!Как звук маршрутизируется через шины и где настраивается громкость

Как назначить шину конкретному плееру

У AudioStreamPlayer есть поле bus. Если вы установите bus = "SFX", звук будет идти через эту шину.

Пример: UI-клик на шину UI.

Практическое правило: не создавайте десятки постоянных плееров на каждый чих. Для коротких звуков удобно создавать временный AudioStreamPlayer и удалять его после finished.

Менеджер звука и настройки громкости

Чтобы не размазывать звук по проекту, часто делают AudioManager.

он знает названия шин

он умеет проигрывать музыку и эффекты

он применяет настройки громкости из сохранения

Для управления громкостью шин используйте AudioServer.

Документация: AudioServer

Идея настройки:

в меню настроек HSlider меняет значения music_volume, sfx_volume

эти значения сохраняются

при запуске игры применяются к шинам

Сохранения: прогресс, настройки и версия данных

Где хранить файлы сохранения

Для данных пользователя используйте путь user://. Это специальная папка, которую Godot выбирает корректно для каждой платформы.

Документация: Data paths

Практическое правило: не пишите сохранения в res://, потому что ресурсы проекта могут быть упакованы и недоступны для записи.

Что именно сохранять

Разделяйте данные на две группы:

настройки: громкость, язык, чувствительность, раскладка

прогресс: пройденный уровень, инвентарь, очки, открытые способности

Это помогает:

не ломать прогресс при сбросе настроек

проще мигрировать формат (например, прогресс меняется чаще)

Простой формат: JSON

JSON удобен на старте, потому что:

он читаемый

легко дебажить

хорошо подходит для словарей и простых структур

Минусы:

надо аккуратно проверять типы при загрузке

нельзя напрямую хранить сложные типы без дополнительной сериализации

Ниже пример минимального слоя сохранения настроек.

Документация:

FileAccess

JSON

Настройки через ConfigFile

Если вы сохраняете в основном настройки (параметры и секции), полезен ConfigFile.

формат похож на ini

удобно хранить по секциям: audio, graphics, controls

Документация: ConfigFile

Версия сохранения и совместимость

Как только вы меняете структуру данных, старые сохранения могут перестать читаться. Минимальная защита:

храните version в словаре сохранения

при загрузке делайте ветку миграции

Практический пример подхода:

version = 1 в первой версии

добавили новое поле, сделали version = 2

при загрузке version = 1 дополняете словарь значениями по умолчанию

Оптимизация: что замерять и что чинить в первую очередь

Оптимизация начинается с измерений

Прежде чем что-то «ускорять», нужно понять, что именно тормозит:

CPU (скрипты, физика, логика)

GPU (отрисовка, тени, постэффекты, количество объектов)

память (текстуры, аудио, большие сцены)

Точка входа в документацию по производительности: Performance

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

Типовые причины просадок и быстрые меры

Ниже список самых частых проблем в учебных и инди-проектах.

#### Скрипты и логика

не делайте тяжёлые циклы в _process без необходимости

не ищите ноды через get_node() каждый кадр, используйте @onready кеширование

используйте сигналы вместо постоянного опроса состояния, когда это уместно

#### Физика и коллизии

используйте простые CollisionShape2D/3D

настройте слои и маски, чтобы лишние объекты не проверялись друг с другом

не плодите большое число активных Area и тел без необходимости

#### 2D-отрисовка

следите за количеством уникальных текстур на экране

по возможности используйте атласы или единый спрайт-лист для множества мелких объектов

#### 3D-отрисовка

тени очень дорогие, особенно от нескольких источников

материалы и большое количество уникальных мешей увеличивают нагрузку

избегайте лишней детализации там, где она не видна

Практический мини-чеклист перед релизом

отключить или скрыть отладочные визуализации

проверить, что в релизе нет лишних логов и тестовых сцен

проверить, что ассеты не имеют неоправданно большого размера (текстуры 4K там, где нужно 512)

проверить, что нет утечек нод (например, временные AudioStreamPlayer удаляются)

Экспорт проекта: от пресета до готового билда

Главная идея экспорта

Godot экспортирует ваш проект через Export Presets. Для каждой платформы вы настраиваете:

целевой формат (Windows, Linux, macOS, Android, Web)

параметры сборки

какие файлы включать

Документация: Exporting projects

Экспортные шаблоны

Чтобы экспортировать, обычно нужны export templates (шаблоны экспорта).

Godot предложит скачать их при первом экспорте

шаблоны соответствуют версии движка, поэтому важно, чтобы версии совпадали

Пошаговый процесс экспорта

Откройте Project → Export....

Добавьте пресет нужной платформы.

Укажите путь и имя итогового файла.

Настройте опции (иконки, подписи, разрешения, ориентация и другое).

Экспортируйте Debug и Release и сравните поведение.

Частые ошибки при экспорте

разные версии движка и шаблонов экспорта

забыли добавить нужные файлы (например, JSON-конфиги, шрифты)

сохранения пишутся не в user://, и в релизе перестают работать

не проверили экспорт на чистой машине (без ресурсов редактора)

Минимальная проверка качества билда

запуск с нуля и создание сохранения

проверка настроек громкости через шины

проверка разрешения, масштабирования UI и читаемости

проверка производительности на целевом устройстве

Итог

Теперь у вас есть «производственный» слой поверх геймплея:

UI на Control с контейнерами, темами и сигналами, часто внутри CanvasLayer

звук через AudioStreamPlayer и Audio Buses, с централизованным управлением

сохранения в user:// через FileAccess, JSON или ConfigFile, с версией данных

оптимизация через измерения и устранение конкретных узких мест

экспорт через пресеты и шаблоны, с обязательной проверкой Release-сборки

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