Comments 5
Системы не должны хранить ничего, в этом суть парадигмы. Это я про PlayerInputSystem. Там лучше сделать цикл foreach по фильтру, вместо хранения энтити и проверки на has.
Системы могут хранить какие-то служебные данные, которые не нужны игре. В данном случае хранить сущность игрока просто удобнее чем писать цикл.
Система инпута, знающая о игроке и скорости передвижения игрока это изначально неправильно. Она должна только создать эвент инпута. Дальше соответствующие системы его уже обработают как им нужно. Иначе когда вы появится саб-маханика со схожими инпутами, например навигация при открытии карты, то придется городить условия в уже существующей системе, что противоречит идеологии ецс.
Вы всё правильно говорите, ещё можно было бы вынести функционал "убивания" юнитов в отдельную систему и создать для этого отдельный компонент. Это бы имело смысл, если бы кто-то кроме врагов имел возможность умереть, или как вы говорите была бы ещё какая-то механика использующая инпут. В данном случае я считаю это излишним усложнением, систем и компонентов будет больше, но ничего от этого не изменится.
Ecs достаточно просто рефакторить и если вы видите что можно разделить одну систему чтобы её использовали разные фичи это нужно делать, но по факту, иначе вы потратите уйму времени на обдумывание того какой универсальной могла бы быть система и не напишите ни строчки кода.
Игра из оф. уроков Годо))
Первая игра на LeoEcsLite