Where does game logic go in Rails apps?

(Disclosure: I'm very new to Rails)

I am trying to make a RISK-style board-game in Rails, though this question may apply for any MVC-style framework.

I have players and games. Players can join games until the game is full. Trying to join a full game (or the same game twice) signals an error, yada yada.

Below are three pieces of game logic that I am unsure where to place, or at least where they are typically placed.

1. If a game is full, it should start and do things related to that (ie, messaging all players that the game has begun, randomly disperse armies across the map).

2. When a player executes moves during his turn it seems reasonable to have that logic in the controller. What about when his turn ends and it is time to message the next player? Would that code go in the same controller as

3. Suppose that a player forfeits his turn if he does not finish it within 24 hours. I'd need to periodically look at all the games in my app and see if a player started a turn more than 24 hours ago. Where would this logic go?

My question is: Where does logic for items like the above go in a Rails/MVC app?

In one sense I could stuff all of it except 3. into the controllers for the last-done-action. For instance I could place the logic for 1. in the player-joins-game controller method (check if the game is full after every player join, if it is, commence 1. related logic). This seems like it might be th开发者_C百科e wrong place, but maybe that's how it is typically done.

Rails' convention is "fat model, thin controller". so I would suggest that the state of the game should be held by the Game model.

You webapp consists of zero or more games, and each game consists of 1 or more players.

The state of "full", or the state of "game begun" are properties of the game, and should be held by that model.

So for 1) When the final player joins (or perhaps, all current players vote to start the game), the game state (a property of Game) would be set to "begun", the property that holds the currently active player would be set, and a delayed job would be queued to message all the players.

For 2, the game has a "execute move" method in the Game controller that would check that the player executing the move is the current player, then it would execute the move against the Game model. The Game model internally would know if the move is valid, what the result is, and what the next step(s) would be. It would, again, use something like a delayed job to message the next player.

For #3, again, a delayed job could be set to execute the timeout. I'm not 100% on how to schedule delayed jobs, or if there's another gem/plugin that would work better. But, the job would call a method on the Game controller to check the status of the game at the required time. If the player has not moved, then execute your forfit logic, which would, again, be a method in the Game model.

The state of each player could be held in the Player model, or in the Game model, I suppose, depending on the game, and how much interaction between Player models there might be.

In the case of a risk game, I would think the player model would be rather thin, as the state of the board is more about which player owns a country, and how many armies they have there - that's more a state of the game, then a state of each individual player. I would expect the Player model in a risk game to be more oriented towards metadata about the actual player - username, wins/losses, skill level, etc.

In a game like Supremacy, where the player has resources, nukes, etc., then there's more data to store in the Player model.