拼字游戏板上

Question

最好通过创建带有SQL表的云来模拟电路板，从而在不同计算机上的两个拼字游戏板之间进行通信。每次移动都会让你联系服务器并更新本地主板？

Answer 1

听起来不错。 Scrabble不需要实时的毫秒精度，因此使用数据库事务来完善电路板移动听起来就像是一种好方法。

Answer 2

在你的鞋子里，我会尝试将我的状态更正式化。如果你想到它，拼字游戏包括：

• 董事会
• 该板上提供奖金的坐标（x2字母，x3字，等等）
• 可用字母的集合，每个可用字母的数量以及每个字母的分数
• 每个玩家的个人资料
• 每个玩家拥有的一组字母
• 每个玩家所扮演的词语以及他们在棋盘上的位置
• 玩家当前得分
• 允许词汇（针对挑战）的词典

其中很多内容可以存储在SQL数据库中 - 例如，玩家的名字和分数。但是对于诸如电路板坐标以及各种奖励如何映射到各种坐标之类的东西，SQL DB可能太重了。如果你想到它，这些是静态的只读属性，永远不会在游戏之间改变。将它们表示为序列化的二维数组或类似的东西可能是有意义的。允许单词的词典也是如此。在你的鞋子里，我很想从服务器启动时的文本文件中读取字典，将字符串存储到一个不可变的数组中，并手动编写一个超快速的二进制搜索，而不是遭受数据库的开销调用索引表。

同样是抓包：你真的需要一个数据库吗？也许你这样做。也许您决定，因为抓包代表将在所有连接的客户端之间共享的可变状态，您希望利用数据库的锁定机制。或者速度可能会成为一个问题，因此您会发现数组或列表可以更好地为您服务，并且您可以自己管理线程状态。

重点是，在你以一定程度的精确度阐明你正在做的事情之前，你不会知道该选择什么。然后你就可以开始考虑权衡了。

Answer 3

将电路板状态存储在中央数据库中很好 - 并且设计良好。目前还不清楚你是如何计划让每个客户处理通信的，你有几个选择：

1. 客户端1进行移动，将详细信息发送到服务器（DB中的持久状态）
2. 服务器ping客户端2通知他们移动（使用远程技术ping）
3. 与第1步相同，但对于客户2。

或者

1. 客户端1进行移动，将详细信息发送到服务器（DB中的持久状态）
2. 客户端2轮询服务器，直到它注意到轮到它为止。
3. 与第1步相同，但对于客户2。

因此，您必须考虑是否需要双向客户端 - 服务器通信（客户端调用服务器，服务器调用客户端）或是否需要单向客户端服务器通信（客户端调用服务器，包括轮询以确定状态何时改变）。

Answer 4

这里有一些很好的答案，但我会说这完全取决于你有什么。如果您可以假设有一个可用的中央服务器，那么使用它来跟踪游戏状态将是一个好主意，因为它不会将客户端锁定到任何特定的机器 - 他们可以在游戏期间从一个到另一个如果他们愿意的话此处还有一些额外的安全性，因为您可以检测到试图进行非法移动的客户端。而且我相信还有其他好处。最明显的缺点是需要服务器（即第三块硬件，以及网址和托管等）。

如果你不能做出这样的假设，那么将一个客户端作为“服务器”真的没有错。它只是有不同的优点和缺点。

至于使用SQL表，rtperson做了一些很好的观察。