Как организовать структуру игры Монополия на ECS?

Question

[siRius32]

Игра аналогичная монополии с поочередными ходами игроков, каким образом составить структуру сущностей, компонентов, систем и обеспечить пошаговость в игре. Хотелось бы примерно понять правильное направление, т.к. попытки написания заводят в тупиковые ситуации. Игра на libgdx + Ashley. p.s. возможно уже есть какая то реализация подобных игр на github?

Comments

[freeExec]

Зачем вам ECS, вы бы ещё пасьянс на нём решили написать?

[siRius32]

Чем это плохо? Такая же turn-based игра, вполне можно.

Answer 1

[Евгений Шатунов]

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

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

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

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

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

Comments

[siRius32]

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

События - это тоже сущности?

а лишь свойства игроков и активов являются сущностями

Какие например свойства являются сущностями?

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

т.е. из всей игры, ecs лишь маленькая часть, которая обрабатывает правила игры?

получается есть класс игрок со ссылкой на сущность, в этой сущности все его данные и способности, а самим классом управляет уже не ecs, а другая система, в частности пользователь через ui, соответственно ai игроком управляет скрипт? ecs разве не может это делать?

обезличивание сущностей значит игрок != entity, мы не можем сказать что у этой сущности такой то набор компонентов, значит это игрок?

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

[Евгений Шатунов]

siRius32,

т.е. из всей игры, ecs лишь маленькая часть, которая обрабатывает правила игры?

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

получается есть класс игрок со ссылкой на сущность, в этой сущности все его данные и способности, а самим классом управляет уже не ecs, а другая система, в частности пользователь через ui, соответственно ai игроком управляет скрипт? ecs разве не может это делать?

Вопрос не в том, что может или не может делать ECS, а в том, зачем что-то добавлять в мир ECS. Если какое-либо поведение обосновано в рамках мира ECS, то это можно добавить. Важно просто следовать ограничениям и не размывать архитектуру.
Чем ИИ отличается от устройства ввода игрока? А ничем. ИИ для мат.модели лучше всего представить как еще одно устройство ввода/вывода, такое же как и игрок. Если создать строгое разделение методов контроля игрока и ИИ, это сделает сущности уникальными, а компоненты игрока и ИИ несвязными.
С другой стороны, если игрок и ИИ - это просто устройства ввода, они могут вводить свои команды в данные компонента перемещения своих сущностей. Далее этот компонент может обрабатывать система перемещения, для которой уже нет разницы между ИИ и игроком.

обезличивание сущностей значит игрок != entity, мы не можем сказать что у этой сущности такой то набор компонентов, значит это игрок?

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

Какие например свойства являются сущностями?

Собственно, ты сам все и описал:

сущность, в этой сущности все его данные и способности

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

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

События не могут быть сущностями, т.к. это механики игры. События - это одна или несколько систем событий, в зависимости от деталей событий. События с моментальным или отложенным эффектом, события с таймером или на количество ходов, события с условием и без условий.

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

[siRius32]

Евгений Шатунов, Благодарю за подробные ответы. Сколько ни читал мануалы, нигде суть не раскрывается. Да, я тоже об этом подумал ecs хороша где много сущностей.
p.s. пойду делать монополию с новыми знаниями, обязательно покажу вам готовую)
спасибо!