Как подписаться на событие unity
Unity События (UnityEvents)
UnityEvents это способ позволяющий поддерживать управляемую пользователем функцию обратного вызова от момента редактирования до момента запуска без необходимости дополнительного программирования и конфигурации скриптов.
UnityEvents полезны для целого ряда вещей:
Содержит управляемую пользователем функцию обратного вызова
Постоянная функция обратного вызова
Предварительно настроенные события вызова
UnityEvent s have similar limitations to standard delegates. That is, they hold references to the element that is the target and this stops the target being garbage collected. If you have a UnityEngine.Object as the target and the native representation disappears the callback will not be invoked.
Вот несколько шагов по настройке обратного вызова в редакторе:
Выберите иконку +, чтобы добавить слот для функции обратного вызова
Выберите объект UnityEngine.Object к которому вы хотите обратиться посредством функции обратного вызова (Для этого вы можете использовать селектор объектов)
Выберите функцию, которую вы хотите вызвать
Вы можете добавить больше одной функции обратного вызова к событию
Во время настройки UnityEvent в инспекторе, вам доступно два типа поддерживаемых функций вызова:
По умолчанию UnityEvent в Monobehaviour связывает динамически функции без аргументов. Это не обязательно должно быть так, потому что UnityEvents поддерживает связь функций содержащих до 4-х аргументов. Чтобы сделать это, вам необходимо переопределить стандартный класс UnityEvents как поддерживающий множественные аргументы. Сделать это довольно просто:
Потом это может быть вызвано с помощью вызова функции Invoke со ‘строкой(string)’ в качестве аргумента.
UnityEvents могут быть переопределены с наличием до 4-х аргументов в их общем определении.
Добавление экземпляра этого класса к вашему, вместо базового UnityEvent, даст возможность функции обратного вызова связывать динамические строковые функции.
Работа с EventSystem в Unity. Базовые вещи в работе с UI
Всем привет! Давно ничего не писал, но сейчас захотелось рассказать про очень удобную штуку, о которой многие не знают. Это Event System в Unity. Многие, для задач в которых EventSystem очень удобен, используют обычный Raycast. Я расскажу про то, как пользоваться частью функционала EventSystem (его на самом деле очень много) и как этот инструмент позволяет быстро решать многие задачи связанные с обработкой событий интерфейсов и объектов. Как всегда с репозиторием с примерами. Если вам интересно — добро пожаловать под кат!
В данной статье я разберу и предоставлю примеры работы с событиями IPointerEnterHandler, IPointerExitHandler, IPointerDownHandler, IPointerUpHandler, IPointerClickHandler, IDragHandler, IBeginDragHandler, IEndDragHandler (полный список событий можно посмотреть тут).
Что же такое EventSystem? EventSystem — это система отвечающая за обработку разных событий в сцене. В основном она позволяет:
С точки зрения рейкастов в EventSystem доступны три основных компонента:
Начнём с самого простого — с UI системы. С ней EventSystem работает проще всего и лучше всего. Дело в том, что при создании Canvas юнити сразу добавляет на сцену все необходимые компоненты, такие как сам EventSystem и Graphic Raycaster.
В случае с UI, событийная система позволяет легко создавать свои кнопки и базовые взаимодействия с разными UI элементами. Для примера разберём IPointerEnterHandler, IPointerExitHandler, IPointerDownHandler, IPointerUpHandler, IPointerClickHandler, IDragHandler, IBeginDragHandler, IEndDragHandler.
Чтобы UI элемент реагировал на события входа (IPointerEnterHandler), выхода (IPointerExitHandler) курсора мыши необходимо имплементировать эти интерфейсы в необходимый объект. Это помогает во многих случаях, когда нужно что-то выбрать, подсветить и т.п. На примере с тестовой сценой и Image это позволяет сделать интеракции вроде такой в несколько строк кода:
Для обработки событий нажатия на UI элемент есть два других интерфейса IPointerDownHandler, IPointerUpHandler.
Их имплементация позволяет в удобном виде обрабатывать события нажатия на объект мышью или тача на мобильных платформах:
EventSystem работает с любым компонентом UI системы, который может быть RaycastTarget. Для примера Text и событие клика IPointerClickHandler (важно, это событие похоже на IPointerUpHandler, то есть срабатывает в момент поднятия мыши, но отличие заключается в том, что “отпускание” курсора должно происходить строго в границах объекта):
Самыми интересными ивентами на мой взгляд, являются те, что позволяют удобно делать Drag. Это набор интерфейсов IDragHandler, IBeginDragHandler, IEndDragHandler. С ними так же всё очень просто. Визуальный эффект сильно зависит от способа обработки, но эти три события позволяют делать самые разные взаймодействия за несколько минут. В случае, если элемент, который вы собираетесь двигать состоит из разных UI элементов, важно отключать галочку RaycastTarget на тех элементах, которые не являются интерактивными. (Важно: в случае с UI системой нужно использовать screenPosition из PointerEventData которая приходит во всех методах событийной системы связанных с мышью/тачем)
В общем то по UI системе всё, на самом деле там есть ещё несколько полезных штук с точки зрения Event System, но про них я может напишу в будущих статьях.
В общем EventSystem крутой и удобный инструмент, который позволяет многие вещи делать в разы быстрее нежели обычными рейкастами. Кроме того в EventSystem есть очень много полезного функционала вроде того, что там можно переопределять инпуты (к примеру вас интересует специфичный контроллер, скажем Leap Motion) и многое другое, о чём я может напишу в будущих статьях.
H Простая система событий в Unity в черновиках Из песочницы
Что это такое, и для чего это нужно?
Пусть у нас есть игра — шутер. При нажатии на кнопку прицеливания игрок переходит на шаг, включается камера прицела, выполняется сотня других действий. А при нажатии кнопки стрельбы — создание пули, просчет полета и т.д. Все это выльется в огромную кашу с кучей связей и программировать все это станет очень тяжело (см. картинку в первой статье), особенно если нет точной картины всей логики в голове и на схеме.
Другой важный момент — для разных платформ управление будет сильно различаться и придется править кучу скриптов, содержащих в себе ввод, и события — один из способов решения этой проблемы.
С использованием событий схема приобретет такой вид:
InputAggregator слушает ввод и как только игрок нажал клавишу/тапнул экран, говорит в эфир: «Игрок нажал кнопку Х!». Об этом сразу узнают скрипты, подписанные на это событие (а точнее методы в этих скриптах) и выполняются указанные методы. Причем эти методы могут вызываться разными событиями, например, метод «Умереть» вызывается как при получении критического урона, так и, к примеру, при выходу за границы уровня.
Обратите внимание, что нам не важно, какую клавишу нажал игрок, важно лишь то, что произошло событие. Т.е. для подгонки управления для другой платформы нам не надо лезть в 10 скриптов и все их править, достаточно будет модифицировать InputAggregator.
Зачем нужен EventController — смотрите ниже.
Как это реализовать?
Забудем про шутер и пули, давайте поставим себе простую задачу:
Мы хотим при нажатии кнопки Space сдвинуть левую сферу вверх, а нижнюю — вниз. И если какая-то из них уходит слишком далеко, вернуть их обратно.
Но для начала сделаем только первую часть, без преодоления границ:
Перво — наперво создадим скрипты сфер, содержащие методы телепортов и повесим их на сферы:
Аналогично для другой сферы.
Создадим скрипт EventController и повесим его куда-нибудь (я повесил на камеру).
В нем создадим делегат MethodContainer():
Если очень грубо, делегаты — это указатели на методы или контейнеры методов. Для событий делегат используется как тип и с ним самим ничего делать не надо, поэтому особо вникать в механику делегатов необязательно (но знания лишними не бывают). Важно только знать, что к делегату подходят только методы, соответствующие его сигнатуре. В нашем случае это методы, не возвращающие значений (void) и не имеющие параметров (). Соответственно и методы, вызываемые нашими событиями, должны иметь такой вид.
Ну и создадим в нем линки на наши сферы, в редакторе не забываем указать, какой линк к чему относится (вы должны уже уметь это делать, если читаете эту статью), они нам понадобятся.
Теперь создадим скрипт InputAggregator. Создадим в нем событие типа MethodContainer, вызывающее телепорт сфер:
Т.е. наш делегат мы указываем в качестве типа. Обратите внимание, что создавать линк на EventController не нужно.
В методе Update() вызовем наше событие:
Все, теперь если мы нажмем пробел, то активируется событие OnTeleportEvent. Осталось только указать, какие методы он должен вызывать.
Вернемся в EventController и в методе Awake() (вызывается при старте игры, похож на Start()) подпишем на наше событие методы TeleportUp() и TeleportDown(). Делается это при помощи оператора +=:
Готово! Теперь при нажатии пробела вызывается событие OnTeleportEvent, которое вызывает два метода в скриптах на сферах.
Теперь попробуем сделать обработку границ.
В скрипты обеих сфер добавим событие выхода за границы (по одному на каждую):
В методах телепортов вызываем событие:
И добавим методы телепорта назад (можно назвать одними именами):
А в Awake() EventController’a подписываемся:
Все, теперь наши сферы исправно двигаются и не убегают далеко.
Также важно знать, что если на событие никто не подписан, то его вызов повлечет за собой ошибку, поэтому если есть такая вероятность, лучше проверять его на нуль.
Заключение
Это был простейший пример. Разумеется, для двух сфер воротить события абсолютно не нужно, но когда у вас в проекте больше двадцати скриптов, события приходят на помощь.
Это только начало, представляете, как было бы сложно делать подобное для десятков скриптов без событий? А тут все аккуратно, видно, что на что подписано.
Надеюсь, статья была полезной, буду рад комментариям и замечаниям. Большое спасибо авторам двух указанных мною в начале статей, без них я сам бы не разобрался.
Хочу выразить благодарность всем пользователям, отписавшимся в комментариях. Благодаря ним статья стала лучше, да и я сам лучше понял события.
Удачи вам в ваших проектах!
P.S. Небольшое дополнение
У вас наверняка возник вопрос, как вызвать событие из другого скрипта, ведь если попытаться сделать что-нибудь вроде
то компилятор выдаст ошибку. Это ограничение можно обойти, если в скрипте, в котором описано событие, создать метод, вызывающий это событие, например
И тогда вызвать это событие из другого класса можно будет банальным
Немного массивно по синтаксису, но неудобств почти не добавляет.
Система сообщений или “мягкая связь” между компонентами для Unity3D
Введение
В данной статье будут затронуты темы, связанные с реализацией возможности “мягкой связи” компонентов игровой логики на основе системы сообщений при разработке игр на Unity3D.
Ни для кого не секрет, что в подавляющем большинстве случаев средств, которые предоставляет движок в базовом виде, недостаточно для полноценной реализации систем обмена данными между компонентами игры. В самом примитивном варианте, с которого все начинают, мы получаем информацию через экземпляр объекта. Получить этот экземпляр можно разными способами от ссылки на объект сцены, до функций Find. Это не удобно, делает код не гибким и заставляет программиста предусматривать множество нестандартных поведений логики: от “объект исчез из сцены”, до “объект не активен”. Помимо прочего может страдать и скорость работы написанного кода.
Прежде, чем приступить к рассмотрению способов решения проблемы, остановимся подробнее на ее предпосылках и базовых терминах, которые будут упомянуты ниже. Начнем с того, что подразумевается под “мягкой связью”. В данной случае — это обмен данными между компонентами игровой логики таким образом, чтобы эти компоненты абсолютно ничего не знали друг о друге. Исходя из этого, любые ссылки на объекты сцены или же поиск объекта в сцене по имени или типу дают нам “жесткую связь”. Если эти связи начнут выстраиваться в цепочки, то в случае необходимости изменения поведения логики программисту придется все перенастраивать заново. Как не сложно догадаться, гибкостью здесь и не пахнет. Конечно, можно написать расширение редактора, которое будет автоматически заполнять ссылки, но это не решит другую проблему – покомпонентное тестирование игровой логики.
Остановимся более подробно на базовом принципе реализации “мягкой связи”. Как было сказано выше, чтобы “мягко” связать два компонента, мы должны передать данные от одного к другому, так, чтобы они не знали ничего друг о друге. Для того, чтобы это обеспечить, нам нужно получить данные не по запросу (имея на руках экземпляр объекта), а использовать механизм уведомлений. Фактически это означает, что при наступлении каких-либо событий в объекте/компоненте, мы не спрашиваем этот объект о его состоянии, объект сам уведомляет о том, что в нем произошли изменения. Набор таких уведомлений формирует интерфейс (не путать с interface в C#), с помощью которого игровая логика получает данные о нашем объекте. Наглядно это можно представить следующим образом:
Таким образом любой компонент системы через интерфейс уведомлений может получить необходимые данные об объекте игровой логике, при этом наличие самого объекта для тестирования связанных с ним компонентов необязательно, нам достаточно реализовать интерфейс, а затем подменить его на рабочий экземпляр.
Рассмотрим более подробно способы реализации описанного выше механизма, а также их плюсы и минусы.
Система сообщений на основе UnityEvents/UnityAction
Данная система появилось сравнительно недавно (в 5 версии движка Unity3D). Пример того, как реализовать простую систему сообщений можно посмотреть по этой ссылке.
Плюсы использования данного способа:
Классическая система C# на Event/Delegate
Самый простой и достаточно эффективный способ реализации связи компонентов на основе уведомлений — это использование пары event/delegate, которая является частью языка C# (подробнее можно почитать в статьях на habr’е или msdn).
Есть много разных вариантов реализации системы сообщений на основе event/delegate, некоторые из них можно найти на просторах интернета. Я приведу пример, на мой взгляд, наиболее удобной системы, однако для начала хочу упомянуть об одной важной детали, связанной с использованием event’ов. Если у события (event) нет подписчиков, то при вызове этого события произойдет ошибка, поэтому перед использованием обязательна проверка на null. Это не совсем удобно. Конечно можно написать обертку для каждого event, где будет проводиться проверка на null, но это еще более не удобно. Перейдем к реализации.
Как видно из примера, подписка происходит в методе OnEnable, а отписка в OnDisable и в данном случае она обязательна, иначе гарантирована утечка памяти и исключения по нулевой ссылке (null reference exception), если объект будет удален из игры. Саму подписку можно осуществлять в любой необходимый момент времени, это не обязательно делать только в OnEnable.
Легко заметить, что при таком подходе, мы можем без каких-либо проблем тестировать работу класса GUILogic, даже в отсутствии реальной логики GameLogicObject. Достаточно написать имитатор, использующий интерфейс уведомлений и использовать вызовы вида GameLogicObject.StartEvent ().
Какие плюсы дает нам данная реализация:
Reflection система сообщений с идентификаций на string
Прежде чем приступить к описанию системы и ее реализации, хотелось бы остановиться на предпосылках, которые толкнули на ее создание. До прихода к этим мыслям в своих приложениях я использовал описанную выше систему на основе event/delegate. Те проекты, которые мне пришлось разрабатывать на тот момент, были относительно простые, в них требовалась скорость реализации, минимум багов на тестах, исключение по максимуму человеческого фактора в фазе разработки игровой логики. Исходя из этого, родился ряд некоторых требований относительно обмена данными между компонентами:
GlobalMessanger.MessageHandler – атрибут, который указывает нам, что метод является обработчиком события. Для того, чтобы определить тип события, которое данный метод обрабатывает, существует два способа (хотя на самом деле может быть и больше):
Как видно, данная обертка содержит в себе два метода, которые позволяют подписываться и отписываться от события (тип события забирается из имени метода). Они необходимы в случае, если нам нужно осуществить подписку на событие по ходу работы логики. Автоматическая подписка осуществляется в методе Awake. Отписка от событий осуществляется автоматически, но об этом чуть позже.
Класс GlobalMessanger является обычным компонентом Unity, доступ к которому осуществляется на основе Unity-синглетона. При этом, для этого компонента создается отдельный объект сцены, который существует только внутри нее и будет удален, когда сцена будет выгружена. Поскольку у нас события идентифицируются на основе строк, то информацию о событиях и подписчиках я решил хранить в хеш-таблице.
Как видно, при вызове события происходит проверка на существование объекта и на активность объекта. В первом случае, удаленный объект убирается из подписчиков, во втором же игнорируется при вызове методов обработки события. Таким образом, следить за отпиской событий у удаленного объекта не требуется, все осуществляется автоматически. При этом, если объект был временно деактивирован, то не осуществляется отписка от событий и повторная подписка, а также при вызове наличие подписчиков на событие не обязательно.
Легко заметить, что описанная выше система не представляет из себя ничего сверхординарного и не несет в себе откровений, однако она проста и удобна и хорошо подходит для относительно небольших проектов.
Думаю, сразу заметно насколько сократился код по сравнению с event/delegate, что меня лично радует.
Какие плюсы дает нам данная реализация:
Reflection система сообщений с идентификаций на типах данных
В предыдущем разделе была описана система более удобная (на мой взгляд) по сравнению с event/delegate, однако она все также имеет ряд недостатков, которые сильно влияют на гибкость нашего кода, поэтому следующим шагом было ее развитие с учетом этих факторов.
Итак, нам нужно сохранить все плюсы предыдущей системы, но сделать ее гибче и более устойчивой к возможным изменениям в игровой логике. Поскольку основная проблема — это изменения имени события и передаваемых параметров, то возникла идея идентифицировать события именно по ним. Фактически это означает, что любое событие, которое возникает в компоненте характеризуется ничем иным, как данными, которые оно передает. Поскольку мы не можем просто привязаться к стандартным типам (int, float и т.п.), потому что в логике такие данные могут передавать многие компоненты, то логичным шагом было сделать обертку над ними, которая была бы удобной, легко читаемой и однозначно интерпретирующей событие.
Как видно, у событий появились атрибуты. Это дает нам возможность получить отладочную информацию, в случае, если событие требует подписчика, а в коде его по каким-то причинам нет.
Метод вызова событий Call (и его перегрузки), который ранее у нас был частью класса GlobalMessanger, теперь является статическим и находится в GEvents.BaseEvent и принимает теперь в качестве параметра экземпляр класса, описывающего тип события.
Подписка и отписка на события, осуществляется тем же самым способом, что и ранее, через атрибуты методов, однако теперь идентификация типа события происходит не по строковому значению (имя метода или параметр атрибута), а по типу параметра метода (в примере это классы StartEvent, ChangeHealthEvent и DeathEvent).
Таким образом, используя описанную выше реализацию, мы получили максимально возможную гибкость в коде, поскольку теперь мы можем как угодно менять передаваемые данные в событиях без значительных затрат, нам достаточно изменить тело обработчика под новые параметры. В случае же, если мы захотим изменить имя события (имя класса), компилятор скажет нам в каких местах кода используется старый вариант. При этом необходимость менять имя метода обработчика полностью отпадает.
Я постарался описать в этой статье все возможные на мой субъективный взгляд способы построения систем обмена данными между компонентами на основе уведомлений. Все эти способы были использованы мной в разных проектах и разной сложности: от простых мобильных проектов, до сложных PC. Какую систему использовать в вашем проекте – решать только вам.
PS: я намеренно не стал описывать в статье построение системы сообщения на основе SendMessage-функций, поскольку по сравнению с остальными она не выдерживает критики не только по удобству, но и по скорости работы.
Как работает Event System в Unity?
В этой статье мы поговорим о Event System – «Системе событий», состоящей из трех компонентов, один из которых мы и рассмотрим сегодня, а именно – Raycasters. Для начала определение. Вот что говорит нам мануал Unity:
Event System (Система событий) – способ отправки событий к объектам в приложении, основанный на вводе с клавиатуры или мыши; с помощью касаний или персональных устройств. Система состоит из нескольких компонентов, работающих вместе. Эта система с помощью «лучей добра» Unity определяет, что находится под указателем. Но для ее работы требуется два условия: в сцене должен присутствовать объект Event System, а на объекте, с которым мы хотим взаимодействовать с помощью этой системы, класс с интерфейсами событий.
Приступим. Для начала нам надо добавить в сцену Event System:
Game Object=> UI=>Event System
Затем добавим в сцену объект. Например, Image:
Game Object=> UI=> Image
Ну, и, наконец, создадим скрипт, который назначим на наш Image.
Подготовка закончена, и мы переходим к написанию скрипта. Откроем наш свежесозданный скрипт в редакторе, у меня это Visual Studio. Для этого дважды кликнем на скрипте. Первое, что нам надо сделать, это добавить библиотеку Event System. В шапке скрипта напишем строку:
using UnityEngine.EventSystems;
Отлично. Теперь мы можем работать с Event System прямо из скрипта. Первое, что мы рассмотрим, это метод OnPointerEnter. Он отслеживает находиться ли курсор или касание над объектом.
Полностью этот метод выглядит так:
public void OnPointerEnter(PointerEventData eventData)
Добавим в него функцию для наглядности, к примеру, смену цвета:
GetComponent ().color = Color.red;
Здесь мы получаем компонент Image нашего объекта и меняем его цвет на красный. И в целом наш метод будет выглядеть так:
public void OnPointerEnter(PointerEventData eventData)
GetComponent ().color = Color.red;
Теперь главное – не забыть добавить интерфейс, требующийся для работы метода OnPointerEnter. Возвращаемся в начало скрипта и после MonoBehaviour через запятую добавляем IPointerEnterHandler. Должно получиться, что-то вроде этого:
public class MyScript : MonoBehaviour, IPointerEnterHandler
Сохраняем наш скрипт и проверяем. В редакторе жмем Play и наводим мышку на наш объект.
Отлично. При наведении курсора наш объект меняет цвет на красный, но, увы, когда курсор покидает объект, цвет остается тем же. Давайте добавим еще один метод, который будет назначать цвет объекту, когда его покидает курсор:
public void OnPointerExit(PointerEventData eventData)
GetComponent ().color = Color.white;
И не забудем добавить еще один интерфейс – IPointerExitHandler
Проверяем. Опять сохраняем скрипт и жмем Play.
Все прекрасно работает, и мы переходим к событиям нажатия кнопки на объекте.
public void OnPointerClick(PointerEventData eventData)
GetComponent ().color = Color.blue;
public void OnPointerDown(PointerEventData eventData)
GetComponent ().color = Color.green;
public void OnPointerUp(PointerEventData eventData)
GetComponent ().color = Color.black;
Для каждого из них требуется добавить свой интерфейс:
IPointerDownHandler, IPointerUpHandler, IPointerClickHandler
Добавляем все в скрипт, сохраняем и опять Play.
И напоследок рассмотрим еще одну очень интересную возможность, предоставляемую нам EventSystems. А именно – возможность перетаскивать мышкой элемент UI, чем и является наш Image. Первый метод отслеживает перемещение курсора при зажатой кнопки мыши или при таче на экран устройства:
public void OnDrag(PointerEventData eventData)
В нем мы пишем строку, которая собственно и будет перемещать Image:
transform.position = eventData.position;
В ней все просто. Позиция Image равна позиции курсора или тача в экранных координатах. То есть, Image будет перемещаться за курсором. Вместе все это выглядит так:
public void OnDrag(PointerEventData eventData)
transform.position = eventData.position;
И второй метод отслеживает момент, когда мы перестаем перетаскивать объект. Либо остановив движение мыши, либо перестав нажимать на кнопку. Вот и он. Какой либо функции в нем сейчас нет. Да и не нужна она. Но не упомянуть о нем было бы неправильно:
public void OnEndDrag(PointerEventData eventData)
Сохраняем скрипт и жмем Play. Отлично.
Все работает. В дополнении хотим добавить, что event data так же хорошо работает с физическими объектами. Достаточно добавить компонент PhysicsRaycaster на основную камеру EventSystems на сцену и Collider со скриптом на объект в сцене, с которым мы планируем взаимодействие.
С другими компонентами Event System, такими как Input Modules и Messaging System, мы ознакомимся в следующих материалах.