Системы событий в играх: триггеры, условия, действия

Система событий — это то, с помощью чего игра заставляет объекты реагировать на происходящее, и строится она из трёх частей: триггер, условие и действие. Триггер — это то, что случилось: началось или закончилось столкновение, нажата клавиша, таймер дошёл до нуля, враг вошёл в зону, нажата кнопка, либо сработало событие, которое вы определили сами («побеждён босс»). Условие — дополнительная проверка, которая тоже должна быть верной, например «и у игрока нет щита». Действие — реакция: отнять жизнь, воспроизвести звук, загрузить следующий уровень. Вместе правило события читается как предложение: когда происходит это, если верно то, делаем вот это. А в основе лежит паттерн «наблюдатель», или «издатель — подписчик»: один объект порождает событие, а откликаются на него сколько угодно слушателей, и источнику знать, кто именно слушает, не нужно.

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

Три части правила события#

Любое событийное правило в игре — будь то строка листа событий в Construct или блок кода — сводится к одним и тем же трём частям.

• Триггер (событие) — то, что случилось. Столкновение началось или закончилось, нажата клавиша, таймер дошёл до нуля, враг вошёл в зону, нажата кнопка или сработало пользовательское событие, которое вы завели сами. Триггер отвечает на вопрос когда.
• Условие — проверка, которая тоже должна пройти до того, как сработает реакция. «Только если у игрока нет щита», «только если здоровье больше нуля», «только если враг смотрит влево». Условия отвечают на вопрос выполнять ли. У правила может не быть условий вовсе, быть одно или несколько, и обычно они соединяются через И (должны пройти все) либо ИЛИ (достаточно любого).
• Действие — что происходит в ответ. Отнять жизнь, воспроизвести звук ранения, породить частицы, приложить силу, загрузить уровень, задать переменную. Действие — это затем. Правило может выполнить несколько действий подряд.

Собранное вместе правило — это предложение: когда игрок пересекается с шипом и у него нет щита, отнимаем жизнь и воспроизводим звук ранения. Это и есть вся модель. Если хотите увидеть, какие движки делают её основным способом строить логику, сравнение движков визуального программирования расставляет их по местам.

Паттерн под капотом: публикация и подписка#

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

• Издатель владеет событием и порождает (публикует, рассылает) его, когда что-то происходит.
• Подписчики (слушатели, наблюдатели), проявившие интерес к этому событию, получают уведомление и в ответ выполняют свои обработчики.
• Издатель не знает, кто его подписчики, сколько их и что они будут делать. Он лишь сообщает: «это произошло».

Последний пункт — и есть причина существования паттерна: ослабление связей. Когда игрок получает урон, объекту игрока не нужно знать ни о полоске здоровья, ни о звуковой системе, ни о частицах, ни о системе сохранения. Он просто порождает событие «игрок ранен». Кто заботится об этом — интерфейс, звуковой менеджер, отслеживание достижений, — тот сам слушает и реагирует. Добавить новую реакцию (новое достижение, новый эффект тряски экрана) — значит подписать нового слушателя, а не править объект игрока.

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

Как движки выражают одну и ту же идею#

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

Листы событий (Construct, GDevelop). Здесь модель «триггер — условие — действие» выражена буквально. Каждая строка — правило: триггер слева, условия рядом, действия справа. Чтение листа сверху вниз — это чтение правил игры. Это самая читаемая форма событийной логики для человека без опыта программирования.

Узловые события (Unreal, Unity). В узловом редакторе узел события и есть триггер: начало пересечения, событие удара, пользовательское событие или узел нажатия клавиши. Из него провода ведут в узлы ветвления (условия) и в узлы действий (реакция). Граф — это то же правило, только нарисованное, а не выписанное списком. Как именно читаются такие графы, подробно разбирает статья о редакторе узлов.

Сигналы (Godot). Godot называет свои события сигналами. Узел объявляет сигнал (например, «здоровье изменилось») и порождает его, когда нужно; другие узлы подключаются к нему и выполняют функцию при срабатывании. Система сигналов Godot — это классический паттерн «наблюдатель», и отчасти благодаря ей движок смог отказаться от визуального программирования в версии 4.0: событийная модель и в коде остаётся чистой. (Сравнение по ссылке выше разбирает это решение подробно.)

Обработчики в коде (везде). В текстовом коде то же самое — это функция обратного вызова, делегат или метод, привязанный к сообщению. Unity использует сообщения вроде обработки начала столкновения и входа в триггер, а также события и делегаты C#. Форма та же: когда происходит икс, выполняется эта функция.

	Триггер	Условие	Действие
Лист событий	Строка «при столкновении»	Ячейка условия	Ячейка действия
Узловой граф	Узел события	Узел ветвления	Узел действия
Сигнал Godot	Порождённый сигнал	Проверка if в обработчике	Код обработчика
Обработчик в коде	Сообщение срабатывает	Оператор if	Тело обработчика

Выберите любую строку и переведите её в любую другую — смысл не изменится.

Как правило события соотносится с кодом#

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

• Триггер — это срабатывание события: подан сигнал, отправлено сообщение, вызван обратный вызов.
• Условие — это проверка if внутри обработчика.
• Действие — это вызов функции (или несколько вызовов), выполняемый, когда проверка if проходит.

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

Где событийная логика сильна#

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

• Ослабление связей. Источник события остаётся в неведении о своих слушателях. Новые возможности крепятся как новые подписчики, а не как правки существующего кода.
• Отзывчивость. Логика выполняется, когда что-то происходит, а не по расписанию. Не нужно проверять одно и то же условие каждый кадр.
• Читаемость. Правило, выраженное как «триггер — условие — действие», читается как поведение, которое оно порождает, и помогает дизайнеру рассуждать об игре.
• Повторное использование. Одно событие может запускать множество независимых реакций: единственный триггер «враг побеждён» способен обновить счёт, выбросить добычу и проверить завершение уровня, каждое — в собственном обработчике.

Где она путается#

У событийной логики есть один главный сценарий провала, и его стоит назвать прямо. Когда событие порождает обработчик, который порождает другое событие, а тот — ещё одно, цепочку становится трудно отследить: проблема спагетти из событий, близкий родственник спагетти-кода. Понять, почему что-то произошло, означает пройти по цепочке издателей и подписчиков, разбросанных по всей игре.

Несколько привычек удерживают это в рамках:

• Один ясный владелец у каждого события. Знайте, какому объекту разрешено порождать конкретное событие.
• Внутри системы — прямые вызовы, между системами — события. Два класса, которые и так знают друг о друге, не нуждаются в шине событий между ними.
• Избегайте каскадов. Если обработчик существует лишь затем, чтобы породить ещё одно событие, перенесите работу в исходный обработчик.
• Убирайте подписки. Слушатель, которого так и не удалили, становится висячим обработчиком и утечкой памяти.

Как Egmatic работает с событиями#

Egmatic — это 2D-редактор и движок поверх рантайма MonoGame, и его узловая логика в основе событийная. Вы задаёте триггеры — столкновение, ввод, таймер, пользовательское событие игры — и через условия соединяете их с действиями в визуальном графе, который расположен рядом с редактором сцен в реальном времени. Модель «триггер — условие — действие» здесь — родной способ строить поведение, а не слой-переводчик над текстовым кодом.

Для 2D-игр, где логика по большей части именно такой формы («когда игрок касается шипа, теряем жизнь»), событийный граф читается как правило, которое он представляет. По той же причине листы событий так хорошо работают в Construct и GDevelop: модель идеально подходит для такой задачи. Более широко о визуальной стороне читайте в материалах о логике игр на узлах и о создании игр без кода.

Заключение#

Система событий в игре — это паттерн «наблюдатель», применённый к геймплею и выраженный через три части: триггер (что случилось), условие (что ещё должно быть верным) и действие (реакция). Под капотом издатель порождает событие, а откликаются на него сколько угодно подписчиков, что и сохраняет чистую независимость источника события от каждой части игры, которой это событие важно. Движки открывают ту же идею через листы событий (Construct, GDevelop), узловые события (Unreal, Unity) и сигналы (Godot) — разные интерфейсы, одинаковый смысл.

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

---

Источники#

1. Паттерн «наблюдатель» (определение и назначение: издатели, подписчики, ослабление связей) — Википедия: Наблюдатель (шаблон проектирования)
2. Шаблон «издатель — подписчик» (событийный обмен сообщениями) — Википедия: Издатель-подписчик (шаблон)
3. Событийно-ориентированное программирование (реакция на события, триггеры и обработчики) — Википедия: Событийно-ориентированное программирование
4. Узлы событий в Unreal Blueprints (событие удара, начало пересечения, пользовательские события) — Unreal Engine docs
5. Сигналы Godot (порождать, подключать) как система по паттерну «наблюдатель» — Godot docs: Using signals
6. События GDevelop (условия и действия как логика игры) — GDevelop wiki: Events
7. Движки визуального программирования и то, как они открывают событийную логику — блог Egmatic