在现代复杂游戏中实现成就系统

Question

如今创建的许多游戏都带有自己的成就系统，奖励玩家/用户完成某些任务。 stackoverflow上的徽章系统完全相同。

虽然有些问题我无法找到好的解决方案。

成就系统必须始终关注某些事件，想象一下为例如：战斗提供20到30个成就的游戏。服务器必须检查这些事件（例如：玩家在此战斗中避免了对手的 x 攻击或玩家走 x 英里）所有时间< / em>的

• 如何在不降低速度甚至崩溃的情况下，服务器如何处理大量操作？

成就系统通常需要仅在游戏的核心引擎中使用的数据，如果没有那些令人讨厌的成就，就不需要那些数据（想想例如：每次战斗中玩家跳跃的频率） ，您不希望将所有这些信息存储在数据库中。）。我的意思是，在某些情况下，添加成就的唯一方法是将检查其当前状态的代码添加到游戏核心，这通常是一个非常糟糕的主意。

• 成就系统如何与拥有后来不必要信息的游戏核心互动？ （见上面的例子）

• 他们如何与游戏核心分开？

我的例子似乎“无害”，但想想目前在魔兽世界中可以获得的1000多项成就，以及同时在线的众多玩家。

Answer 1

成就系统实际上只是一种记录方式。对于像这样的系统，publish/subscribe是一种很好的方法。在这种情况下，玩家发布关于他们自己的信息，并且感兴趣的软件组件（处理个人成就）可以订阅。这允许您使用专门的日志记录代码观察公共值，而不会影响任何核心游戏逻辑。

以你的'球员行走x英里'为例。我将实现作为播放器对象中的字段行走的距离，因为这是一个简单的递增值，并且不需要随着时间的推移增加空间。奖励步行10英里的玩家的成就是该领域的订户。如果有很多玩家，则将该值与一个或多个中间经纪人级别进行汇总是有意义的。例如，如果游戏中存在100万玩家，那么您可以将值与1000个经纪人聚合在一起，每个经纪人负责跟踪1000个玩家。然后，成就订阅这些经纪人，而不是直接订阅所有参与者。当然，最佳层次结构和订户数量是特定于实现的。

在你的战斗示例中，玩家可以完全相同的方式发布他们上次战斗的细节。监视战斗跳跃的成就将订阅此信息，并检查跳跃次数。由于不需要历史状态，因此也不会随着时间而增长。同样，不需要修改核心代码;你只需要能够访问一些值。

另请注意，大多数奖励不需要是即时的。这使您可以在管理流量方面有一些余地。在前面的示例中，您可能不会更新经纪人的已发布行程距离，直到玩家总共走了一英里，或者自上次更新以来已经过了一天（在此之前内部递增）。这实际上只是一种缓存形式;具体参数取决于您的问题。

Answer 2

如果您无权访问源代码，甚至可以执行此操作，例如在视频游戏模拟器中。例如，可以编写简单的内存扫描工具来查找显示的分数。一旦你有了这个，你的成就系统就像每帧轮询那个记忆位置一样容易，看看他们当前的“得分”或其他什么都高于他们的最高分。关于视频游戏模拟器的一个很酷的事情是内存位置是确定性的（没有操作系统）。

Answer 3

在普通游戏中有两种方法。

1. 离线游戏：没有像pub / sub那样复杂 - 这是一个巨大的矫枉过正。相反，您只需使用大型地图/字典，并将日志命名为“events”。然后每X帧，或Y秒（或通常：“每次有时死亡，1x在关卡结束时”），你迭代成就并快速检查。当设计人员想要记录一个新事件时，程序员添加一行代码来记录它是微不足道的。

注意：pub / sub不适合这个IME，因为设计师从不想要“当player.distance = 50”。他们真正想要的是“当观看屏幕的人看到的玩家距离似乎已经过了第一个村庄，或者向右移动了至少4个屏幕宽度”时 - 比简单的计数器更加模糊和抽象。

实际上，这意味着逻辑会发生变化（在事件发布之前），这是一种使用pub / sub的糟糕方式。有一些游戏引擎可以更容易地做出“接收时的逻辑”（“子”部分），但它们不是大多数，IME。

1. 在线游戏：几乎完全相同，除了你存储“计数器”（int up up），通常还有：“deltas”（循环缓冲区中发生了什么事情），以及：“事件”（复杂的东西，发生在游戏中，可以硬编码为单个ID加上固定大小的参数数组）。然后通过例如SNMP将其暴露给其他服务器，以便以低CPU成本收集 和异步

即。与上面的1几乎相同，只是你要小心做两件事：

• 固定大小的内存使用量;如果“阅读”服务器暂时离线，那么在这段时间内赢得的成就将需要重新获得（尽管您通常可以让客户支持人员手动浏览主系统日志并确定成就“可能” “赢了，并手动奖励它”
• 开销很低; SNMP是一个很好的标准，我认识的大多数团队最终使用它

Answer 4

如果您的游戏架构为Event-driven，那么您可以使用finite-state machines实施成就系统。