Rails 应用程序中的游戏逻辑在哪里？
（披露：我对 Rails 很陌生）
我正在尝试在 Rails 中制作 RISK 风格的棋盘游戏，尽管这个问题可能适用于任何 MVC 风格的框架。
我有球员和游戏。玩家可以加入游戏，直到游戏满员为止。尝试加入完整的游戏（或同一游戏两次）会发出错误信号，yada yada。
下面是三个游戏逻辑，我不确定放置在哪里，或者至少不确定它们通常放置在哪里。
如果游戏已满，它应该开始并执行相关操作（即向所有玩家发送游戏已开始的消息，在地图上随机分散军队）。
当玩家在他的回合中执行移动时，在控制器中拥有该逻辑似乎是合理的。当他的回合结束并且该向下一位玩家发送消息时该怎么办？该代码是否会与
当玩家在其回合中执行移动时位于同一控制器中，- 假设玩家如果在 24 小时内没有完成该回合，则他将放弃自己的回合。我需要定期查看应用程序中的所有游戏，看看玩家是否在 24 小时前开始玩游戏。这个逻辑会走向何方？
我的问题是：Rails/MVC 应用程序中上述项目的逻辑在哪里？
在某种意义上，我可以将除 3. 之外的所有内容填充到控制器中最后完成的动作。例如，我可以将 1. 的逻辑放置在玩家加入游戏控制器方法中（在每个玩家加入后检查游戏是否已满，如果是，则开始 1.1.1. ）代码>相关逻辑）。这看起来可能是错误的地方，但也许这就是通常的做法。
(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.
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).
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
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 the wrong place, but maybe that's how it is typically done.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Rails 的惯例是“胖模型，瘦控制器”。所以我建议游戏的状态应该由游戏模型来保存。
您的 web 应用程序由零个或多个游戏组成，每个游戏由 1 个或多个玩家组成。
“完整”状态或“游戏开始”状态是游戏的属性，并且应该由该模型保存。
因此，对于 1) 当最终玩家加入时（或者可能是所有当前玩家投票开始游戏），游戏状态（Game 的属性）将设置为“开始”，保存当前活跃玩家的属性将是设置，并且延迟作业将排队向所有玩家发送消息。
对于 2，游戏在游戏控制器中有一个“执行移动”方法，该方法将检查执行移动的玩家是否是当前玩家，然后它将针对游戏模型执行移动。游戏模型内部会知道该举动是否有效、结果是什么以及下一步是什么。它会再次使用诸如延迟作业之类的东西来向下一个玩家发送消息。
对于#3，同样可以设置延迟作业来执行超时。我不是 100% 知道如何安排延迟的工作，或者是否有另一个 gem/插件可以更好地工作。但是，该作业将调用游戏控制器上的方法来在所需的时间检查游戏的状态。如果玩家没有移动，则执行您的 forfit 逻辑，这又是游戏模型中的一个方法。
我想，每个玩家的状态可以保存在 Player 模型中，或者保存在 Game 模型中，具体取决于游戏以及 Player 模型之间可能有多少交互。
在风险游戏的情况下，我认为玩家模型会相当薄弱，因为董事会的状态更多地是关于哪个玩家拥有一个国家，以及他们在那里有多少军队 - 这更多的是游戏的状态，然后是每个球员的状态。我希望风险游戏中的玩家模型更面向有关实际玩家的元数据 - 用户名、胜利/失败、技能水平等。
在像霸权这样的游戏中，玩家拥有资源、核武器等，那么Player 模型中需要存储更多数据。
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.