Где логика игры идет в приложениях Rails?

Question

(Раскрытие информации: я очень новичок в Rails)

Я пытаюсь создать настольную игру в стиле RISK в Rails, хотя этот вопрос может относиться к любой среде в стиле MVC.

У меня есть игроки и игры.Игроки могут присоединяться к играм, пока игра не заполнится.Попытка вступить в полноценную игру (или дважды в одну и ту же игру) сигнализирует об ошибке, yada yada.

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

1. Если игра заполнена, она должна начаться и сделать что-то связанное с этим (т. Е. Отправлять сообщения всем игрокам о начале игры, случайным образом распределять армии по карте).

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

3. Предположим, что игрок теряет свой ход, если он не завершает его в течение 24 часов.Мне нужно периодически просматривать все игры в моем приложении и проверять, начал ли игрок ход более 24 часов назад.Куда пошла бы эта логика?

Мой вопрос: куда идет логика для элементов, подобных приведенным выше, в приложении Rails / MVC?

В каком-то смысле я мог вставить все это, кроме 3., в контроллеры для последнего выполненного действия.Например, я мог бы поместить логику для 1. в методе player-joins-game controller (проверьте, заполнена ли игра после каждого присоединения игрока, если это так, начните 1. связанную логику).Кажется, что это может быть не то место, но, возможно, именно так это и делается.

Answer 1

Соглашение Rails - «толстая модель, тонкий контроллер».поэтому я хотел бы предложить, чтобы состояние игры поддерживало модель Game.

Ваше веб-приложение состоит из нуля или более игр, а каждая игра состоит из 1 или более игроков.

состояние «полный» или состояние «начата игра» являются свойствами игры и должны поддерживаться этой моделью.

Так для 1) Когда присоединяется последний игрок (или, возможно, все текущие игроки)голосования, чтобы начать игру), состояние игры (свойство Game) будет установлено как «начатое», свойство, содержащее текущего активного игрока, будет установлено, а отложенное задание будет поставлено в очередь насообщение всем игрокам.

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

Для # 3, опять же, отложенное задание может быть установлено для выполнения тайм-аута.Я не на 100% о том, как планировать отложенные задания, или если есть другой гем / плагин, который будет работать лучше.Но задание вызовет метод на игровом контроллере для проверки состояния игры в нужное время.Если игрок не сдвинулся, выполните логику форфита, которая снова будет методом в модели игры.

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

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

В такой игре, как Supremacy, где у игрока есть ресурсы,ядерное оружие и т. д., тогда в модели проигрывателя будет больше данных для хранения.