5

Система игровых событий⁠⁠

В Unity известен подход ко взаимодействию объектов посредством событий.

Объявляется Action с необходимыми параметрами. Какие-то объекты на него подписываются, кто-то это событие вызывает и все подписчики исполняют методы, которыми подписались на это событие. Такой подход уменьшает связанность объектов, что есть хорошо.

Однако важно подписки вовремя добавлять и убирать, чтобы не происходило утечек памяти или объекты не подписывались на событие несколько раз. Обычно это делают в методах OnEnable и OnDisable. В каждом подписчике нужно рутинно прописывать подписку/отписку и если событий набралось много, то это может вылиться в простыню кода.

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

Game Events System

Добавляйте необходимые события, выбирайте типы аргументов, группируйте события в логические "каналы" и жмите "Generate".

Сгенерируются классы по каналам со статическими событиями.
Если в качестве аргумента события необходимо указать типы, объявленные в других пакетах в проекте, то включите галочку "Include packages".

Использование

Вызов событий происходит обычным способом:

MenuChannel.OnPause?.Invoke();

Чтобы подписаться на событие, нужно добавить соответствующий атрибут к колбек-методу:

[MenuChannel.OnPause]
public void Pause()
{
// Event handling logic here
Time.timeScale = 0;
// ...
}

Вот и все, вся остальная логика по подписке/отписке сделана за вас.

Ссылка на репозиторий с пакетом:
https://github.com/IRKhabibullin/com.jarmallnick.gameeventss...

Чтобы добавить пакет к проекту нужно:
1) Скопировать ссылку на проект
2) В Unity зайти в Window -> Package Manager
3) Нажать на + и выбрать загрузку по git url

В пакет добавлена сцена с примерами использования

Буду благодарен за фидбек и идеи улучшения системы.

Unity

268 постов2.7K подписчиков

Правила сообщества

• Запрещается постить вопросы, мемы и прочую ерунду - для этого есть форумы и другие специализированные ресурсы.


• Распространение и обсуждение пиратского ПО, кейгенов, ключей и прочих пиратских файлов запрещено.


• Соблюдайте сетевой этикет. Оскорбительное поведение и мат (в том числе сокращенный или завуалированный) караются баном.


• Запрещается разводить полемики на тему "какой движок круче". Здесь мы обсуждаем только Unity.


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

Автор поста оценил этот комментарий
Я решил запилить кастомный пакет с решением, которое поможет создавать события через удобный UI и избавит от рутины ручной подписки/отписки на них, что немного облегчит разработку.

Это какая-то пизда.


1. Подписка на события только в енабле/дисабле.

2. Необходимость ебаться с интерфейсом, выкликивая параметры.

3. Необходимость постоянно наследоваться от какого-то басесубскрибера.


Почему не пошел по какому-нить стандартному пути, какой-нить условный евентбас, аля евентсервис? Делаешь параметры в виде структур со всеми необходимыми данными, дженерик интерфейс подписчика с этими параметрами.

В авайке просто указываешь, "сервис, зарегай этот класс", этот сервис собирает с класса все интерфейсы подписки, кеширует их, и заносит в свою базу. Посылаешь евенты через этот же сервис. Для отписки, сервис просто вешает на объект свой мнобехавиор, который с увеличенным ексекъютив_ордером отписывает объект сам от сервиса. Блять, этож база.

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

Во-первых, попрошу "базу" писать не транслитом, а то мозг сломал пока пытался прочитать)


Во-вторых, можешь обозначить чем твой подход лучше?

Подписка на события только в енабле/дисабле.
Что не так с этим, в каком сценарии это может не работать? В твоем варианте трогать execution order как-то не хочется - не надежно, банально если в проекте кто-то еще будет его трогать. И что делать если нужно не объект дизейблить, а только компонент-подписчик?

Необходимость ебаться с интерфейсом, выкликивая параметры.
Интерфейс на то и придуман, что с ним меньше ебаться, чем писать код и он гораздо удобочитаем.


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


Ну и попрошу продолжить общение не в стиле "Бъерн Страуструп отчитывает нерадивого студента", а с конструктивной критикой и с указание минусов моего подхода и плюсов твоего

показать ответы

Темы

Политика

Теги

Популярные авторы

Сообщества

18+

Теги

Популярные авторы

Сообщества

Игры

Теги

Популярные авторы

Сообщества

Юмор

Теги

Популярные авторы

Сообщества

Отношения

Теги

Популярные авторы

Сообщества

Здоровье

Теги

Популярные авторы

Сообщества

Путешествия

Теги

Популярные авторы

Сообщества

Спорт

Теги

Популярные авторы

Сообщества

Хобби

Теги

Популярные авторы

Сообщества

Сервис

Теги

Популярные авторы

Сообщества

Природа

Теги

Популярные авторы

Сообщества

Бизнес

Теги

Популярные авторы

Сообщества

Транспорт

Теги

Популярные авторы

Сообщества

Общение

Теги

Популярные авторы

Сообщества

Юриспруденция

Теги

Популярные авторы

Сообщества

Наука

Теги

Популярные авторы

Сообщества

IT

Теги

Популярные авторы

Сообщества

Животные

Теги

Популярные авторы

Сообщества

Кино и сериалы

Теги

Популярные авторы

Сообщества

Экономика

Теги

Популярные авторы

Сообщества

Кулинария

Теги

Популярные авторы

Сообщества

История

Теги

Популярные авторы

Сообщества

Недвижимость и ремонт

Теги

Популярные авторы

Сообщества