Comments 6
Компонент Player слишком раздутый. Он агрегирует сразу большое количество серьезных классов. И не все системы используют эти классы. Получается, что системы декомпозированы, а компонент нет. И он, я так понимаю, будет разрастаться и разрастаться. И вскоре в нем будут располагаться данные, которые затрагивают половину логики игры. Это привносит опасность свалиться, в какой-то момент, в серьезную реструктуризацию. Что нивелирует заявленные возможности подхода ECS.
Действительно, наличие подобных компонентов (своего рода "God class"-ов из ООП), которые будут только разрастаться и разрастаться, может лишить разработчика гибкости, которую дает паттерн ECS.
Но я решил оставить его. Пока что нет необходимости разбивать компонент на несколько. Да, скорее всего, она появится позже на практике (в последующих частях, например), и вот тогда мы сможем без проблем это исправить благодаря еще одному преимуществу ECS - быстрому рефакторингу. Мы можем легко склеивать несколько компонентов/систем в одно целое или наоборот разбивать на несколько более атомарных частиц.
Помещать, например, поле Health в компонент Player действительно не стоит, так как это свойство, которым обладают многие сущности в игре. Логика, которая связана с этим компонентом, будет работать для всех одинаково, а поэтому имеет смысл вынести Health в отдельный компонент.
Не работал с Лео, но код Get1(i) Get2(i) итд... выглядит ужасно. Ещё и с var.
Представляю, как трудно будет разбираться в большом и сложном проекте который так написан, разработчику который пришел со стороны.
На самом деле, к этому быстро привыкаешь. Особенно учитывая то, что в большинстве случаев сами фильтры небольшие.
Можно посмотреть LeoEcsLite - здесь с этим проблем нет и четко видно, какой компонент ты получаешь.
Я вот одного не понимаю. Ладно, ECS работает когда у нас, например, один тип логики для одного действия. Ну, как тут: мы ходим - мы обновляем позицию. А если их несколько? Ну, мы же можем управляться как напрямую, так и получать данные сервера, например. В одном случае заниматься интерполяцией и прочим надо, в другом - нет. И что, разбивать на 2 разных компонента?
А какая разница? Просто добавьте корректирующую систему, которая внесет изменения посередине. Сетевые пакеты - еще одна система ввода, которая сгенерирует новый ивент или поправит данные напрямую.
В этом и смысл работать ивентами - они могут возникать откуда угодно: хоть с клавомыши, хоть с тачпада, хоть от ИИ, хоть по сети.
Создание шутера с LeoECS. Часть 1