应用错误收集

这个问题的背景是：

用于双人多人回合制纸牌游戏的Google App Engine后端
游戏围绕着不同的牌组合，在游戏中产生不同的分数

显然，人们会将游戏状态存储在GAE数据存储区中，但我不确定游戏逻辑本身的设计方法。看来我可能有两个选择：

使用密钥存储数据存储区中的条目，该密钥是可以作为播放器的有效卡组合的排序列表。然后，这些将映射到分数值。当玩家尝试播放卡片组合时，服务器端python会对组合进行适当排序并查找密钥。如果成功，它可以对分数进行必要的更新，如果失败则组合无效。
将有效组合存储为写入服务器端代码的python字典，并执行与上述相同的查找以测试有效性/获得分数，但无需访问数据存储区。

从成本的角度来看（数据存储区查找不是免费的），选项2似乎会更好。但是后来有实例本身的性能 - 启动时间，处理时间，内存使用量是否会开始让我付出更大的代价？

还有构建Python字典的代码维护问题，但我可以将一些脚本捆绑在一起，以帮助我在逻辑发生变化的不常见的情况下为其编写代码。我认为，如果这有助于任何想要量化问题的人，那么将会有大约1000张牌组合（可以产生一个得分）的2到6张牌。

我开始使用这种设计，上面的总结是将这种游戏的静态逻辑存储在数据存储区中是否合理，或者只是将其作为CPU绑定逻辑的一部分？这两种方法的优点和缺点是什么？

如果逻辑已修复，请将其保存在代码中。也许你可以在程序上生成启动时的dicts。如果逻辑中存在动态组件（您想要经常更新的东西），数据存储可能是更好的选择，但听起来这不适用于此。除非组合数量超过数百万，并且您希望以更低的内存占用速度进行交易，否则请坚持将其放入应用程序本身。

只是为了与上述信息进行比较：

在标准牌组中有52张独特牌。手中有5张牌，可以获得2,598,960手牌。

    Here's a break down of the combinatorial math:

      n = 52 cards total
      r = 5 cards in hand

    number of combinations = n! / (r! - (n-r)!)
      = 52! / (5! * 47!)
      = (52 * 51 * 50 * 49 * 48) / (5 * 4 * 3 * 2 * 1)
      = 2,598,960

为了简化示例，让我们将数字与5张扑克牌进行比较。扑克有9种不同类型的“得分”牌（皇家同花顺，同花顺，四种，满屋，同花顺，直，三种，两对，一对）。

你手上什么都没有的几率是50.11％您拥有上述任何组合的几率为49.89％。

5张卡片中可能的手牌组合数量巨大，卡片只有4套，卡片上有13个号码，9种不同的“得分”组合类型

我希望这个例子清楚地说明在数据库中生成和存储5张卡片的所有可能的“评分”组合将是一项巨大的任务。

这对您意味着什么：

由于我不了解游戏规则，因此您需要考虑的主要事项是不同“得分”组合类型的数量。

您并未真正指定游戏中可能的得分组合的独特/不同。组合类型的数量越接近组合的数量，就越有自定义的“评分”规则。

使用上面的52卡片组示例，如果每个独特的手牌拥有自己独特的分数，您将很快拥有超过300万个数据库条目。在这种情况下，我会建议您获得许多支持MapReduce查询功能的数据库（例如Cassandra + Hadoop），这样您就可以轻松扩展基础架构以缩短查询时间。我认为拥有300万个独特的得分组合是不太可能的。这会使游戏规则变得非常复杂，并可能使你的游戏无法播放。

既然你说过你的游戏将拥有大约1000个手牌组合的2-6张牌，那么让我们简化一下这个例子并得到一个球场号码。尽可能使用最大的牌（6张牌），12张牌中有3,003张牌。假设不同组合类型，套装和编号卡的数量均匀分布（这里有一些幻想数学），您正在考虑拥有大约1,500个“得分”组合。

底线：

为游戏“获得”获胜手所需的应用程序逻辑与游戏玩家为了玩游戏需要理解的逻辑完全相同（假设此游戏需要任何技能/理解，并且它并不纯粹依靠运气）。它越复杂，游戏对玩家来说就越难。我只能假设游戏逻辑并不复杂。

我发现你的牌组中你不可能只有16张牌。拥有几百张具有多种分组类型用于唯一性的卡片似乎是合理的（例如，在扑克牌上适合，或者在Magic the Gathering卡上使用法术力类型）。假设你有比基本扑克游戏更多的牌和组合类型，那么得出结论认为存储各种组合需要花费更多精力而不是在游戏中包含游戏逻辑似乎是非常合理的。此外，每次添加新规则时，您的存储要求都会以数量级跳跃，而不是线性扩展。

由于您将不可避免地开发出实现纸牌游戏规则所需的代码，您可能还需要花费多长时间来“获得”任意一张纸牌。我会提醒您不要过早优化，并建议您对设计进行原型设计。我建议您使用可配置的逻辑模块，以便您根据需要轻松更改游戏规则。一旦规则得到巩固且不太可能改变，那么我会根据需要优化您的应用程序代码。从可维护性的角度来看，将所有应用程序逻辑存储在数据库中是很疯狂的（我认为大多数维护程序员都会同意我的意见）。在您尝试“修复”（例如，规范化，迁移，转换）由几个脚本生成的数据后，您只需“捣乱”（您的话语），您最终会将头撞入键盘。

就GAE定价而言，您需要的实例数量将取决于您的用户/需求。通常，扩展系统的限制因素是磁盘IOPS而不是CPU。从长远来看，我敢打赌，通过将所有应用程序逻辑存储在数据库中，您将在性能和定价方面受到更大的打击。

来源：

1）组合计算器：http://www.calculatorsoup.com/calculators/discretemathematics/combinations.php

B）扑克赔率：http://www.durangobill.com/Poker.html

在哪里保存游戏逻辑的静态信息？

2 个答案:

只是为了与上述信息进行比较：

这对您意味着什么：

底线：

来源：