就像浏览器游戏一样。用户建造建筑物，并为特定日期/时间设置计时器以完成建造并生成建筑物。
我想象有一个像恶魔这样的东西，但那会如何工作呢？对我来说，旋转+轮询似乎不是要走的路。我查看了async_observer，但这适合这样的事情吗？
sjmulder
问问题
410 次
4 回答
1
如果您只需要拥有的玩家可以看到该事件，那么模型可以按需报告其更新状态，我们完成了，继续前进，这里没有什么可看的。
另一方面，如果它需要在计划创建时对任何人都可见，那么问题就更有趣了。
我会说你需要两件事。一个队列，您可以在其中放置定时事件（数据库表会很好）和一个后台进程，无论是连续运行还是频繁重新启动，它都会提取自上次执行以来计划发生的事件（或者那些即将发生的事件，我想）和行动他们。
查看Rails wiki 上的选项列表，似乎还没有一个真正的解决方案。让我们希望其中一个符合要求。
于 2009-01-30T16:53:23.623 回答
1
我刚刚为我正在开发的 PBBG 做了这件事（Big Villain，你可以在 MadGamesLab.com 上看到正在进行的工作）。无论如何，我使用了一个命令表，其中每个用户命令只生成一个条目，以及一个事件表，每个命令包含一个或多个条目（链接回命令）。使用脚本/运行程序运行的辅助守护程序启动它会定期轮询事件表并运行时间已过的事件。
到目前为止，它似乎工作得很好，除非我在大量用户使用它时发现一些问题，否则我不打算更改它。
于 2009-02-05T21:35:28.807 回答
0
在一定程度上，这取决于您的前端有多少逻辑，以及您的模型中有多少。如果您知道在某件事发生之前将经过多少时间，您可以将大部分逻辑保留在前端。
我会使用您的模型来确定事物的状态，并且根据特定请求，您可以检查它是否已构建。我不明白为什么你需要一个后台工作人员。
于 2009-01-30T13:52:21.353 回答
0
我会使用 AJAX 来启动一个计时器（参见Periodical Executor）来更新你的 UI。在模型方面，只需跟踪您的建筑物的 created_at 列，并且仅在其构建时间已过时才允许使用它。这样你就不必每隔几秒钟就去你的数据库看看你的建筑是否完成了。
于 2009-01-30T16:47:24.933 回答