[Mastermind (Быки-коровы)] Детализация действий и операций (22.04.21)

[citerm]

Общие моменты:

• состояние знает какие валидаторы нужно подключить чтобы проверить доступность запрашиваемого действия
• состояние знает как обработать и применить запрашиваемое действие если оно доступно
• состояние знает какие действия/операции доступны в данный момент
• состояние выполняет доступные операции если у игроков нет доступных действий
• состояние реализуется для каждой игры
• действия (Action) совершаются игроком по собственной воле и атомарно изменяют состояние (change state) и формируют доступность следующих действий/операций
• операции (нужно название) совершаются автоматически если они доступны от имени игроков к которым относятся, но без их непосредственного участия

Пример (наиболее показательный для понимания):

• Игрок бросил кубик, выпала 1, состояние изменилось: текущий бросок приобрел значение 1, фаза броска изменилась на фазу подсчета красных карточек, активный игрок сдвинулся против часовой стрелки от текущего
• Игра может (и делает): в фазе красных карточек подсчитывает все сыгравшие красные карточки у активного игрока и применяет их эффект по отношению к текущему игроку (передает средства из баланса текущего на баланс активного), игра сдвигает активного игрока
• Игра может (и делает): в фазе красных карточек подсчитывает все сыгравшие красные карточки у активного игрока и применяет их эффект по отношению к текущему игроку (передает средства из баланса текущего на баланс активного), игра сдвигает активного игрока (и так далее пока активный снова не будет равен текущему - тогда игра сдвигает фазу на подсчет синих карточек)
• Игра может (и делает): в фазе синих карточек подсчитывает все сыгравшие синие карточки у активного игрока и применяет их эффект по отношению активному игроку (передает средства из баланса банка на баланс активного), игра сдвигает активного игрока
• Игра может (и делает): в фазе синих карточек подсчитывает все сыгравшие синие карточки у активного игрока и применяет их эффект по отношению активному игроку (передает средства из баланса банка на баланс активного), игра сдвигает активного игрока (и так далее пока активный снова не будет равен текущему - тогда игра сдвигает фазу на подсчет зеленых карточек)
• Игра может (и делает): в фазе зеленых карточек подсчитывает все сыгравшие зеленые карточки у активного игрока и применяет их эффект по отношению активному игроку (передает средства из баланса банка на баланс активного), игра сдвигает фазу на подсчет фиолетовых карточек)
• Игра может (и делает): в фазе фиолетовых карточек подсчитывает все сыгравшие фиолетовые карточки у активного игрока и применяет их эффект по отношению ко всем другим игрокам (передает средства из баланса других игроков на баланс активного), игра сдвигает фазу на покупку карточки
• Игрок может купить карточки со стола, на которые у него хватает баланса
• Игрок покупает карточку, игра сдвигает текущего игрока по часовой стрелке
• Текущий игрок может бросить кубик

Жень, все что смог, прости :(

[nergal-perm]

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

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

состояние знает как обработать и применить запрашиваемое действие если оно доступно

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

состояние знает какие действия/операции доступны в данный момент

Полностью согласен.

состояние выполняет доступные операции если у игроков нет доступных действий

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

состояние реализуется для каждой игры

Полностью согласен.

действия (Action) совершаются игроком по собственной воле и атомарно изменяют состояние (change state) и формируют доступность следующих действий/операций
операции (нужно название) совершаются автоматически если они доступны от имени игроков к которым относятся, но без их непосредственного участия

Терминологические трудности :) Может быть, в качестве рабочих рассмотрим варианты Действие (для волеизъявления игрока) и Изменение для атомарного изменения состояния? Одно Действие может приводить к нескольким Изменениям, а ход игрока может состоять из нескольких Действий?