1

TL;博士

  • 安卓，棋盘类游戏。
  • 延迟不重要。
  • 通过 LAN/Global 的客户端-服务器，潜在的高分 => 不信任。
  • 未来潜在的蓝牙层 => 完全信任。
  • 移动意味着昂贵的流量，上游比下游更昂贵。
  • PRNG用的很多，一定是确定性的。
  • 用于序列化 + 传输的 kryonet

我和几个朋友正在为 Android 构建我们的棋盘游戏“端口”/“风味”（具有许多不同的事件类型和各种排列），并为其添加联网的多人游戏方面。我们不是加密或网络专家 =)

游戏的默认多人游戏层将基于客户端-服务器（服务器要么是专用主机，要么在安卓设备上运行[以防你和你的朋友在树林里而你没有网络]）。这可能是一个全局服务器或 LAN——这并不重要。但是可能会有一个潜在的高分需要一些反作弊机制因为它是一个回合制的棋盘类游戏，延迟不是问题。

将来，如果我们有时间 - 我们可能会添加一个基于蓝牙的层，但在这种情况下，作弊不是问题，因为假设人们彼此很了解。

由于我们正在处理（很可能）上游比下游更昂贵的移动网络，因此从服务器下载比从客户端发送模型更便宜。

我们可能会使用 kryonet 进行数据的序列化和传输。

游戏会经常使用PRNG，因此需要有一些良好的反作弊和验证逻辑，所以在gamedev&stackoverflow大量搜索和阅读后，我设计了以下逻辑。我需要一些关于该计划的合理性的意见。非常感谢所有提示和建议。

假设/考虑：

  • PRNG 的行为具有确定性（考虑使用 Mersenne Twister）。
  • 正常的游戏玩法不应因反作弊措施而受到惩罚。

方案/计划：

  1. 在“握手”/自“onResume()”之后的第一个连接上 - 从服务器获取 PRNG 种子并存储它。每个玩家在服务器中都有自己的种子。

    1. 还要在同一请求中将游戏状态的哈希发送到服务器，如果不同步，则同步游戏状态。

  2. 在操作/用户输入时，获取下一个随机数 -> 保存到“随机数桶” （因此称为桶 - 桶是您可以添加但永远不会删除的“陷阱列表”）。还将输入 ID/Type/Enum 保存到列表中。

  3. 累积更改直到其他玩家必须知道（即下一个玩家轮到）/ PNR（不归路点）

  4. PNR 已达到

    1. 发送模型的更改 ID/类型/枚举（约 64 位）+ 桶 + 哈希（更改后）。桶 + 哈希是否应该加密，也许是 AES 256（其他更合适的加密技术？）。

    2. 根据 N = size( bucket ) 的 N 个连续随机数检查 bucket。如果不匹配，转到 6，然后转到 7。

    3. 临时更改模型（不承诺完整的游戏模型）。

    4. 计算哈希并检查客户端提供的哈希。如果无效转到 6。

    5. 有效：提交到服务器上的游戏模型。

    6. 无效：要求客户端恢复到服务器发回的状态。

    7. 作弊：禁止（不是 IP [动态 IP...]，而是 MAC 地址或 UID）/从游戏中删除几个作弊。

编辑：另外 - 关于反作弊的另一个问题......对于类似棋盘游戏的 2 个农业高分的机器人团队的反措施有什么好的想法吗？

EDIT2：这是我所做的问题前研究的链接：

调查：

5) 在你的游戏连接上使用一些轻量级的多态编码。

6) 使用一些反调试技术来防止调试器附加到您的进程。谷歌反调试，你应该能找到很多东西。

7) 使用定制的专有 PE 打包程序来防止对您的游戏进行有用的反汇编。

8) 使用哈希作为承诺，然后在满足其他玩家行为的条件时揭示哈希承诺的含义。它很复杂，并且会对性能产生影响，但其中一些想法可能很有用，尤其是对点对点游戏。

9）我认为让破解者更难解决问题的一个好方法是在你的服务器中拥有游戏状态的唯一权威副本，只向客户端发送和接收更新，这样你就可以嵌入通信协议本身客户端验证（它没有被破解，因此检测规则仍然存在）。那，并积极监控发现的新奇怪行为可能会让你更接近你想去的地方。

与实时 FPS 相关，与我们的相关性较低：

差不多就这些了，希望大家给点建议！

4

0 回答 0