siRius32

В разных файлах при модульной разработке как у вас возможны. Это независимые блоки.
В случае обычной разработки на JavaScript, когда вы 2 файла просто объединяете методом конкатенации в один, в таком случае это превращается просто в один большой файл, тогда нет, т.к. две константы появляются в одном коде на одном уровне.

Самой главной ошибкой начинающих работать с ECS людей является попытка засунуть в ECS сразу и вообще всё.

У тебя игра по типу монополии. Что есть в монополии?
В игре заявлены игроки, дискретное поле, активы и события. Еще могут быть заявлены дополнительные правила.
Игроки и активы имеют свои эффекты и могут быть деактивированы событиями. Собственно, это и есть сущности игрового ECS-мира.

И тут важно понять, что не сами игроки и активы являются сущностями ECS, а лишь свойства игроков и активов являются сущностями.
Сами игроки являются внешними к ECS, для каждого игрока в ECS заводится сущность, идентификатор которой сразу прикрепляется к объекту игрока. Теперь игрок может взаимодействовать с миром игры через данные своей сущности. Точно так же делается и для активов.

Дискретное поле игры тоже является внешним относительно ECS-мира, у него чуждая для ECS логика работы. Но сущности мира ECS будут ориентироваться в пространстве дискретного мира через логику связанной с этим миром системы.

По своей сути, в монополии ECS будет выполнять задачу документооборота между сущностями. Добавить компонент владения, убрать компонент владения, зачислить деньги, списать деньги, добавить компонент активности, убрать компонент активности. ECS управляет только общими свойствами между полностью обезличенными сущностями, где между игроком и купленным им активом нет фактической разницы.
Механизм перевода хода тоже является полностью отдельным от ECS, он может только опираться на набор компонент игроков и данные компонент.

ECS является подходом декомпозиции не только логики и данных, но и подходом отказа от агрегации и наследования в пользу косвенной композиции. Явной композиции в ECS тоже не предусматривается, а косвенная композиция не намекает на связность или структурированность данных. Косвенная композиция обозначает только наличие каких либо данных по некоторым косвенным признакам.
Более того, в рамках ECS сторонний код и с данными нормально работать не способен. Для стороннего кода в ECS предусматривается уровень абстракции для чтения и записи данных.

Это все должно говорить о том, что ООП возможно применять только рядом с ECS и отдельно от ECS, но не вместе с и не внутри модели данных ECS.

К примеру есть сущность игрок с набором компонентов наследованная от Entity,

Нет, это сразу будет не ECS. Сущность игрок - это и есть entity, являющаяся эфемерной единицей в мире ECS.
И методов у entity быть не может. Вся логика сущностей распределена по системам и сильно зависит от имеющихся у сущности компонент.
Более того. Если ты говоришь о том, что в твоем мире может существовать сущность с характеристикой игрока, таких сущностей в твоем мире может быть до 100% всего ECS мира. Если игрок у тебя должен быть представлен единичной сущностью, значит это уже не сущность, а внешний объект, по ошибке введенный в ECS мир.

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

Про состояния, пустые компоненты добавлять удалять в entity как флаги что сущность в каком либо состоянии, и отдельные системы для обработки каждого состояния это нормальный подход ?!

Битовые компоненты - это рядовая оптимизация для хранения пустых компонент. Да, так делают и обеспечивают правильную работу систем, чтобы фильтры компонент одинаково обрабатывали как полноразмерные компоненты, так и битовые тоже.