Как связать игровое клеточное поле в Entity Component System?
===============================================================

 Подскажите правильное направление как реализуется клеточное игровое поле в ECS? Собственно игра: игровое поле n на m клеток, с типами местности, с юнитами, поочередными ходами. Если с юнитами более менее понятно, сущность с набором компонент, то что из себя представляет игровое поле и как связывается в системах с позициями юнитов? 

 Вообще, пространство игрового поля не очень хорошо выражать в терминах ECS. Игровое поле - это, как правило, монолитный участок логики, для которого лучше подошел бы подход [CBSE(COP)](https://en.wikipedia.org/wiki/Component-based_software_engineering). Обычно игровое поле представляется композицией нескольких пространств, в которых работают механики игры. Такие пространства удобнее выражать компонентами из CBSE, а не компонентами из ECS.  

  

Однако, не смотря на это все, есть хороший способ реализации игрового поля терминами ECS. Особенно если игровое поле дискретно.  

Чтобы начать думать в этом направлении, сперва требуется изучить клеточные автоматы: [[1](https://en.wikipedia.org/wiki/Cellular_automaton)], [[2](https://en.wikipedia.org/wiki/Component-based_software_engineering)].  

Когда с принципами работы клеточных автоматов станет понятнее, стоит обратить свое внимание на шаблон [инверсии контроля](https://en.wikipedia.org/wiki/Inversion_of_control). При прямом контроле всем твоим миром руководит квант времени, который спускается с главного цикла до каждой сущности. Такой подход неприемлем на игровом поле в терминах ECS.  

  

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

В терминах ECS это все решается компонентами. Возбужденная клетка игрового поля имеет компонент возбужденности, спокойная - не имеет его. У каждой клетки есть компонент с соседними клетками. Если компонента нет - клетка - это остров.  

  

И теперь самое интересное. Игровые сущности теперь тоже являются компонентами игрового поля. И за счет все той же инверсии контроля игровые сущности теперь обновляться могут только для возбужденных клеток поля. Если клетка спокойна, стоящий на ней персонаж не получает квант обновления. Это - важное правило, которое требуется соблюдать чтобы не нарушать целостность реализации игрового поля через ECS.  

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

  

Касательно сущностей. Для дискретного поля сущностью является клетка. При этом, согласно терминологии ECS сущность - это эфемерный объект, лишь идентифицирующий свои компоненты. Иными словами, клетка дискретного поля может быть выражена идентификатором своих координат. Запрашивая тот или иной компонент, запуская квант системы или ссылаясь на сущность через идентификатор ее координат, мы всегда будем точно знать геолокацию своих действий в игровом поле. Однако, для реализации такого механизма требуется разработать собственную реализацию ECS.  

Сущностью ECS может быть и не только одна клетка игрового поля, а, скажем, один чанк 16х16 клеток, в котором сохраняются все правила клеточного автомата.  

  

Через такой подход вполне возможно реализовать что-нибудь вроде Factorio. 

 По координатам N и M