[Mastermind (Быки-коровы)] Описание сценариев

[citerm]

Правила игры Mastermind
На данный момент мне видится разграничение сценариев на 2 группы:

• сценарии действий игроков и игры
• сценарии ограничений (правил), которые обеспечивает игра по отношению к игрокам

[citerm]

Сценарии действий (все замечания и предложения можно дописывать в reply к этому комментарию)

• Игрок 1 может создать игру
• Игрок 1 может пригласить Игрока 2
• Игрок 2 может загадать число
• Игрок 2 может завершить ход, если он загадал число
• Игрок 1 может попробовать отгадать число
• Игрок 2 может проверить попытку Игрока 1
• Игрок 2 может отметить "быками" позиции, в которых стоят совпадающие цифры
• Игрок 2 может отметить "коровами" позиции, в которых стоят цифры, присутствующие в загаданном числе, НЕ на нужном месте
• Игрок 2 может завершить ход, если проверка завершена
• Игрок 1 может завершить игру, если все позиции отмечены "быками"

[citerm]

Сценарии ограничений (все замечания и предложения можно дописывать в reply к этому комментарию)

• Игра запускается, если в игре присутствует 2 игрока
• Игра передает первый ход Игроку 2
• Игра запрещает вводить число с количеством знаков больше 4х
• Игра запрещает вводить число с количеством знаком меньше 4х
• Игра запрещает вводить в позицию цифру, которая уже используется в других позициях
• Игра передает ход Игроку 1, если число загадано
• Игра передает ход Игроку 2, если сделана попытка
• Игра передает ход Игроку 1, если попытка проверена
• Игра запрещает Игроку 1 редактировать позиции, отмеченные "быками"
• Игра запрещает Игроку 2 завершить ход, если хотя бы одна позиция проверена НЕ корректно
• Игра завершается, если Игрок 1 завершил игру

[nergal-perm]

Я правильно понимаю, что сценарии действий в рамках этой Дискуссии - это что-то среднее между конкретной последовательностью конкретных шагов и списком допустимых действий (правда, без указания начального состояния)?

Как думаешь, стоит ли нам определиться с форматом - либо это "предусловия -> набор шагов -> конечный результат" (как в статье про Object Behavior Analysis), либо это "предусловия -> список возможных действий в этом состоянии". Сейчас что-то среднее, хотя и с этим можно работать, конечно.

И, кстати, Markdown поддерживает таблицы :) Создавать и редактировать можно здесь, вот пример:

| Инициатор | Действие               | Участник | Услуга                     |
|-----------|------------------------|----------|----------------------------|
| Игрок 1   | Создает игровую сессию | Игра     | Создание конкретной сессии |

Инициатор	Действие	Участник	Услуга
Игрок 1	Создает игровую сессию	Игра	Создание конкретной сессии

[citerm]

Я вот как раз размышлял, с точки зрения - можно ли применить формат "предусловия -> список возможных действий в этом состоянии" по аналогии с UI "предусловия -> отображение" для системных процессов. Надо поэкспериментировать над формой, но все таки хотелось бы определиться с содержанием - интерпретировать правила конкретной игры в сценарии. Хотя может быть "предусловия -> список возможных действий в этом состоянии" сразу убьет двух зайцев - требования и задел на переход сразу к способностям.
Вариант со сценариями использованиями "предусловия -> набор шагов -> конечный результат", пока не знаю тоже как этот формат адаптировать, я скорее хотел примерить "Initiator -> Action -> Participant -> Service", но это как будто бы уже почти разработческий язык. Мне кажется нужно попробовать одну и ту же функциональность примерить в разных вариантах представления.

[nergal-perm]

Схема "Initiator -> Action -> Participant -> Service" - это формат описания конкретного шага внутри варианта "предусловия -> набор шагов -> конечный результат" :)

[citerm]

Накидай как ты это видишь, так сложно понять. Не просто регламент как мы будем делать, а полностью уже сценарии поведения системы.

[nergal-perm]

Sir, yes, sir!

[citerm]

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

[nergal-perm]

Предусловия:

• Игрок 1 подключен к Системе
• Игрок 2 подключен к Системе
• В Системе нет созданных и доступных Игровых сессий (Игр)

ID	Инициатор	Действие	Участник	Услуга
1	Игрок 1	Создает игровую сессию (Игру)	Система	Создание конкретной сессии (Игры)
2	Игрок 1	Подключается к Игре	Игра	Подключение игроков
3	Игрок 2	Запрашивает список доступных Игр	Система	Предоставление списка доступных Игр
4	Игрок 2	Подключается к Игре	Игра	Подключение игроков
5	Игра	Передает ход Игроку	Правила	Определение очередности хода
6	Игрок 1	Загадывает число	Игра	Сохранить загаданное игроком число
7	Игра	Передает ход Игроку	Правила	Определение очередности хода
8	Игрок 2	Сообщает попытку угадать число	Игра	Сохранить попытку игрока
9	Игра	Передает ход Игроку	Правила	Определение очередности хода
10	Игрок 1	Сообщает исход попытки	Игра	Принять результат попытки
11	Игра	Валидировать исход попытки	Правила	Валидировать результат попытки
12	Правила	Сообщает валидную попытку	Игра	Сохранить результат попытки
13	Игра	Проверяет условия окончания Игры	Правила	Определение завершения игры
14	Игра	Сообщает игрокам исход игры	Игроки	Предоставить информацию об исходе Игры

Примечание: шаги 7-13 повторяются в цикле, пока не будут удовлетворены условия окончания Игры (например, израсходовано кол-во попыток или число угадано).

Итог: Игра завершена, победитель торжествует.

[nergal-perm]

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

[nergal-perm]

Такое ощущение, что у нас должны быть описаны (как ты изначально и предложил):

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

[citerm]

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

[citerm]

Попробовал вчера вечером рассмотреть игру в рамках нашей концепции действий-состояний. Вот что получилось (пока не очень структурировано).
Действия:

• создать_игру (1)
• запросить_число (2)
• загадать_число (3)
• сделать_попытку (4)
• завершить_игру (5)

Состояния (будут рассматриваться путем перехода из предыдущего состояния посредством действия):

• А - стартовое состояние (игрок еще не создал игру)
• Б = А + (1) - игрок добавил в игру бота (который будет загадывать число) и создал игру
• В = Б + (2) - игрок запросил у бота число
• Г0 = В + (3) - бот загадал число через единый интерфейс действий (это состояние мы обозначим как Г0 - то есть число загадано, но попыток игрока еще не было)
• ГN = Г0 + (4) * N - игрок сделал N-ное количество попыток и в результате угадал число
• А* = ГN + (5) - игрок завершил игру, и может начать новую (возможно это пока надуманное ограничение с количеством экземпляров игры на одного игрока)

Способности:

1. Состояние А

• Игрок

• создать_игру (1)

• запросить_число (2)

• загадать_число (3)

• сделать_попытку (4)

• завершить_игру (5)

2. Состояние Б

• Игрок

• создать_игру (1)

• запросить_число (2)

• загадать_число (3)

• сделать_попытку (4)

• завершить_игру (5)

• Игра

• создать_игру (1)

• запросить_число (2)

• загадать_число (3)

• сделать_попытку (4)

• завершить_игру (5)

• БОТ

• создать_игру (1)

• запросить_число (2)

• загадать_число (3)

• сделать_попытку (4)

• завершить_игру (5)

3. Состояние В

• Игрок

• создать_игру (1)

• запросить_число (2)

• загадать_число (3)

• сделать_попытку (4)

• завершить_игру (5)

• Игра

• создать_игру (1)

• запросить_число (2)

• загадать_число (3)

• сделать_попытку (4)

• завершить_игру (5)

• БОТ

• создать_игру (1)

• запросить_число (2)

• загадать_число (3)

• сделать_попытку (4)

• завершить_игру (5)

4. Состояние Г0

• Игрок

• создать_игру (1)

• запросить_число (2)

• загадать_число (3)

• сделать_попытку (4)

• завершить_игру (5)

• Игра

• создать_игру (1)

• запросить_число (2)

• загадать_число (3)

• сделать_попытку (4)

• завершить_игру (5)

• БОТ

• создать_игру (1)

• запросить_число (2)

• загадать_число (3)

• сделать_попытку (4)

• завершить_игру (5)

5. Состояние ГN

• Игрок

• создать_игру (1)

• запросить_число (2)

• загадать_число (3)

• сделать_попытку (4)

• завершить_игру (5)

• Игра

• создать_игру (1)

• запросить_число (2)

• загадать_число (3)

• сделать_попытку (4)

• завершить_игру (5)

• БОТ

• создать_игру (1)

• запросить_число (2)

• загадать_число (3)

• сделать_попытку (4)

• завершить_игру (5)

6. Состояние А*

• Игрок

• создать_игру (1)

• запросить_число (2)

• загадать_число (3)

• сделать_попытку (4)

• завершить_игру (5)

• Игра

• создать_игру (1)

• запросить_число (2)

• загадать_число (3)

• сделать_попытку (4)

• завершить_игру (5)

• БОТ

• создать_игру (1)

• запросить_число (2)

• загадать_число (3)

• сделать_попытку (4)

• завершить_игру (5)

Так как я явно выделил БОТа, чтобы он мог загадывать число через единый интерфейс действий (мы обсуждали это в дискуссии про случайные значения и тестирование), то мне сразу же пришла идея, почему бы не дать игроку (создающему игру) выбрать другого игрока вместо БОТа - тогда они смогли бы загадать другу числа (один игрок запрашивает число у другого и тот получает способность загадывать, а второй наоборот запрашивает у первого число и тем самым предоставляет тому возможность загадывать - таким образом игроки загадывают, пока не будут загаданы каждому по числу, и игра переходит в режим попыток - игроки делают попытки, и дальше побеждает тот, кто сделает меньше попыток))) подумай, так мы сразу сможем не просто десктоп игру для одного сделать, а заложить мультиплеер - либо реализовать с ботом, а потом добавить функционал мультиплеера. При желании мы можем сделать AI и бот тоже будет запрашивать у игрока число и отгадывать.
На основании такого разбиения можно выделить бизнесовые фазы:

1. Фаза создания

• Оба участника (игрок или бот) могут запросить и загадать числа (если противник запросил), после того как запросили или загадали у них способность запрашивать и загадывать исчезает
• Игра разрешает запрашивать и загадывать числа (пока конкретное действие не будет выполнено обоими участниками)

2. Фаза ходов

• Оба участника могут делать ходы пока не угадают число, после того как угадают у них способность угадывать исчезает
• Игра разрешает делать попытки, пока оба игрока не отгадают

3. Фаза завершения

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

Ход моих рассуждений:

[citerm]

про коньяк и ром не обращай внимания, эт я к днюхе готовлюсь для поездки на дачу)))

[citerm]

Мне кажется нам нужен интуитивно понятный, но при этом формальный алгоритм выделения достаточного набора действий и состояний между ними, которые легко сложить в граф. Я открыл документация по мастермайнду в вики, и мне сложно читать такую спецификацию - это при том, что у нас игра состоящая из 2 правил и 5-6 действий. А если мы доберемся до агриколы, то проектирование нас просто убьет. ИМХО документация должна описывать алгоритм игры, таблицы сами себя будут документировать с точки зрения способностей, а код в подсистеме "правил" будут сам документировать алгоритм действий. Что думаешь?