🏗️ Cell-Based Architecture и EventBus 🚌

🏗️ Cell-Based Architecture и EventBus 🚌

Уровень материала: 🐥 #middle
Сейчас будет немного спорный контент: так и не смог ёмко и лаконично выразить мысль, а раздувать статью из этого не хочется. Но всё же. Просматривал небольшую обзорную статью про Cell-Based Architecture из своего бэклога. И глаз зацепился об одну занятную мелочь.

Эта мелочь — EventBus. Про него можно посмотреть, например, тут и тут. Что я хотел отметить: обрати внимание на положение EventBus'а на схеме. Сейчас маленько «сову на глобус», но замени клетки на отдельные логические модули из своего игрового проекта — у них, как и у клеток, тоже должен быть высокий Cohesion (и низкий Coupling по GRASP'у). Это могут быть, например, CoreGame и MetaGame или Presentation-слой и Business-слой. И посмотри на положение EventBus'а ещё раз.

EventBus — это не способ построения архитектуры приложения. Это один из способов коммуникации между модулями. Он «связывает» большие самодостаточные модули между собой, обеспечивая им низкий Coupling, что позволяет им быть отдельными переиспользуемыми образованиями, а не одним большим неразрывным «куском кода».

Он не находится внутри модуля. У модуля есть только тычка Events для общения с EventBus. А внутри модуля коммуникация производится более явно. В т.ч. через «классические» события, которые не требуют дополнительных слоёв абстракций, как в EventBus.

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

Но EventBus — не для того, чтобы в проекте всё подряд сделать несвязанным. Если всё не связано — значит, связано всё, только неявно, что ещё хуже.

Чтобы убедиться, достаточно самостоятельно «сунуть пальцы в розетку». Вот инструкция:

  • сделать проект на >5000 строк собственного кода на основе EventBus,
  • запланировать масштабную геймплейную фичу,
  • забыть о проекте на две недельки,
  • вернуться в проект и сделать эту фичу,
  • оценить пережитый опыт от 0 до 10 по шкале «спасибо, до свидания».

EventBus — это не плохо, если использовать по назначению. Это инструмент для связи того, что быть связанным напрямую не должно. И чем такого будет меньше, тем лучше. Поэтому подход неплохо приживается на более верхних слоях, где элементов взаимодействия меньше. Но на более низких — часто превращает проект в очень запутанную и сложно контролируемую историю.

Есть исключения. Не всё так просто. Бывают кейсы, где и игровую логику удобно сделать на EventBus. Только название у этого будет более контекстное, а область использования — ограничена этой игровой логикой. Т.е. это будет не совсем EventBus, а иная структура, по реализации похожая на EventBus.

————————————

1111
18 комментариев

Это шиза устраивать в игре микросервисы с коммуникационной шиной. Делайте нормальный монолит

2
Ответить

Делайте нормальный монолитты уверен, что это подходит для любой игры?

1
Ответить

Как говорилось в статье, EventBus имеет один очень серьезный недостаток - явные зависиомсти делать неявными (запутывая поток управления). Но этот недостаток можно занчительно смягчить, если слушатели EventBus вместо push модели событий, будут использовать pull модель.

1
Ответить

Слушатели с пуш моделью это как?

Ответить

Я не понимаю это что то про Сталкер 2 ?

1
Ответить

Да. Про то, почему там с производительностью проблемы 🙂

Ответить

может такое лучше на хабре постить

1
Ответить