Комментарии 14
Как предполагается работать с динамически создаваемыми объектами? Например, со спауном врагов, препятствий и тп.
Если я правильно понял ваш вопрос, то лично у меня объекты спавнятся из префабов.
У каждого префаба уже есть прикреплённый компонент Events, который на старте сразу понимает, «кто он» и начинает реагировать на соответствующие эвенты.
У каждого префаба уже есть прикреплённый компонент Events, который на старте сразу понимает, «кто он» и начинает реагировать на соответствующие эвенты.
Но по сути это та же максимальная жесткая связность, о которой было написано в начале поста. Мы не можем что-то поменять посередине, не можем изменить апи, не поломав все префабы.
А приведите, пожалуйста, пример такого ломающего изменения?
Когда, например, захочется передавать 3 GameObject-а в качестве параметров в обработку или еще какие-то другие данные. Как только меняется сигнатура метода / типа — все линки на префабах ломаются и приходится их перенавешивать заново.
В теории объекта и субъекта эвента должно быть достаточно для любой ситуации при условии, что остальные параметры хранятся в них самих и доступны извне.
Например, моб может обрабатывать ситуацию, в которой игрок атакует другого моба, и, проверив «дружественность» этого моба (который хранится в таргете у игрока и доступен извне), агриться на игрока.
Или игрок кастует АОЕ-спелл, задевая несколько мобов: каждый из них создаст свой собственный эвент, и подписанные на него объекты их обработают.
Однако, я с удовольствием выслушал бы альтернативные пути решения подобных задач!
Мне очень импонирует ECS (во всяком случае то, как она звучит в концепции), но её текущая реализация в Unity показалась мне очень ограниченной и сложной.
Например, моб может обрабатывать ситуацию, в которой игрок атакует другого моба, и, проверив «дружественность» этого моба (который хранится в таргете у игрока и доступен извне), агриться на игрока.
Или игрок кастует АОЕ-спелл, задевая несколько мобов: каждый из них создаст свой собственный эвент, и подписанные на него объекты их обработают.
Однако, я с удовольствием выслушал бы альтернативные пути решения подобных задач!
Мне очень импонирует ECS (во всяком случае то, как она звучит в концепции), но её текущая реализация в Unity показалась мне очень ограниченной и сложной.
Мне очень импонирует ECS (во всяком случае то, как она звучит в концепции), но её текущая реализация в Unity показалась мне очень ограниченной и сложной.
Есть альтернативные реализации на чистом шарпе без завязки на unity, например, тот же Entitas.
Да, я слышал, но как-то руки не доходили поковырять — хотелось нативного решения.
Но Вы меня вдохновили, и вчера ночью я написал собственную ECS на базе Юнити :)
При всей своей примитивности(в моей дилетантской реализации) она очень радует меня своей структурой данных и удобством работы.
Мне сложно оценить эффективность работы, но вот на моём макбуке(1,2 GHz Intel Core m3) система, меняющая координаты компонентам в методе Update(), начинает захлёбываться ближе к 100.000 объектов с таким компонентом, до того выдавая вполне сносные 30 fps.
Несколько сотен тысяч обращений к компонентам в секунду мне для моих целей вполне должно хватить.
Но Вы меня вдохновили, и вчера ночью я написал собственную ECS на базе Юнити :)
При всей своей примитивности(в моей дилетантской реализации) она очень радует меня своей структурой данных и удобством работы.
Мне сложно оценить эффективность работы, но вот на моём макбуке(1,2 GHz Intel Core m3) система, меняющая координаты компонентам в методе Update(), начинает захлёбываться ближе к 100.000 объектов с таким компонентом, до того выдавая вполне сносные 30 fps.
Несколько сотен тысяч обращений к компонентам в секунду мне для моих целей вполне должно хватить.
Ну тогда можно еще и вот это посмотреть.
почему эвент —
Я тоже сейчас ищу слабо связную архитектур и кое что нашел. Это в разы проще и удобнее и независимо от контекста. www.youtube.com/watch?v=raQ3iHhE_Kk&t=1748s
Я сейчас активно занимаюсь доработкой и пишу свой фреймворк на её основе. Если заинтересовало, то пиши мне в вк. vk.com/pro_unit
Ну и все желающие тоже, буду рад рассказать =)
Я сейчас активно занимаюсь доработкой и пишу свой фреймворк на её основе. Если заинтересовало, то пиши мне в вк. vk.com/pro_unit
Ну и все желающие тоже, буду рад рассказать =)
Как я понял в любом случае у нас идет обращение к инстансу, то есть реализуется сингтон, то есть смысл ивентов теряется напрочь. Что мешает отправлять обычные функции в этот инстанс (антипаттерн мега-класс), зато соблюдается инкапсулирование.
Смысл эвентов в том, что на них подписаны все, кому оно надо.
В моем случае — вообще все, но это элементарно разбивается на отдельный компонент для каждого вида объектов: плодим классы CharacterEvents, MobEvents, etc, различаюшиеся по сути только набором эвентов, которые они слушают, и хэндлеров к ним, и аттачим их к соответствующим префабам.
В моем случае — вообще все, но это элементарно разбивается на отдельный компонент для каждого вида объектов: плодим классы CharacterEvents, MobEvents, etc, различаюшиеся по сути только набором эвентов, которые они слушают, и хэндлеров к ним, и аттачим их к соответствующим префабам.
А у Unity разве нету нативной реализации какого нибудь аналога сигналов и групп как в Godot например, мне казалось в UE4 и Unity давно уже изобретен велосепед, со слабо связаностью сигналов или observe паттерна?
В Godot ты можешь просто вызвать connect между сигналом источника и методом таргета обьекта.
Если же надо обратиться к группе обьектов, или выполнит бродкаст, то один вызов get_group_nodes(«Group») выдаст тебе список всех обьектов, а значит можно либо напрямую обратиться, либо создать какой нибудь event brodcast, который ловит сигналы, и по ним рассылает бродкасты определенной группе.
События кстати какие то примитивные, с привязкой к enum. Почему бы не сделать какой нибудь handler, принимающий правила и пусть он сам по себе и является событием.
Функция и будет обработчиком, которая определит правило поведения.
Но если идти дальше. То пусть event будет обьектом. В нем пусть хранится ссылка на источник и набор правил. Тогда мы автоматически отвязываемся от типов ивентов
Почему бы внутри обьектов не создать компонент, который накапливает полученные события.
А уже компонент, в свой цикл вызова Update/Tick/etc… обрабатывает все накопленные ивенты.
Если идти дальше. Еще и подсчитывать прошедшее время, что бы остановит обработку, если она затянется.
Обработчик событий должен только, и только отправлять/принимать события, не больше. Сами события пусть обрабатывают уже обьекты в свое время выполнения. Что бы не вызывать всеобщи фриз, когда у нас 100500 обьектов, которые друг другу кастят события
В Godot ты можешь просто вызвать connect между сигналом источника и методом таргета обьекта.
Если же надо обратиться к группе обьектов, или выполнит бродкаст, то один вызов get_group_nodes(«Group») выдаст тебе список всех обьектов, а значит можно либо напрямую обратиться, либо создать какой нибудь event brodcast, который ловит сигналы, и по ним рассылает бродкасты определенной группе.
События кстати какие то примитивные, с привязкой к enum. Почему бы не сделать какой нибудь handler, принимающий правила и пусть он сам по себе и является событием.
Функция и будет обработчиком, которая определит правило поведения.
Но если идти дальше. То пусть event будет обьектом. В нем пусть хранится ссылка на источник и набор правил. Тогда мы автоматически отвязываемся от типов ивентов
Почему бы внутри обьектов не создать компонент, который накапливает полученные события.
А уже компонент, в свой цикл вызова Update/Tick/etc… обрабатывает все накопленные ивенты.
Если идти дальше. Еще и подсчитывать прошедшее время, что бы остановит обработку, если она затянется.
Обработчик событий должен только, и только отправлять/принимать события, не больше. Сами события пусть обрабатывают уже обьекты в свое время выполнения. Что бы не вызывать всеобщи фриз, когда у нас 100500 обьектов, которые друг другу кастят события
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Организация системы эвентов в Unity — глазами геймдизайнера