现在创建的许多游戏都有自己的成就系统，奖励玩家/用户完成某些任务。stackoverflow 上的徽章系统是完全一样的。
虽然有一些问题我无法找到好的解决方案。
成就系统必须时刻注意某些事件，想想一个提供 20 到 30 个成就的游戏，例如：战斗。服务器必须一直检查这些事件（例如：玩家在这场战斗中避免了对手的x次攻击或玩家走了x英里）。
成就系统通常需要仅在游戏核心引擎中使用的数据，如果没有那些令人讨厌的成就，无论如何都不需要从那里拿出来（想想例如：玩家在每场战斗中跳跃的频率，你不需要'不想将所有这些信息存储在数据库中。）。我的意思是，在某些情况下，添加成就的唯一方法是将检查其当前状态的代码添加到游戏核心，这通常是一个非常糟糕的主意。
成就系统如何与拥有后来不必要信息的游戏核心交互？（见上面的例子）
它们是如何与游戏核心分离的？
我的例子可能看起来“无害”，但想想魔兽世界目前可获得的 1000 多项成就以及同时在线的许多玩家。
成就系统实际上只是一种记录形式。对于这样的系统，发布/订阅是一个很好的方法。在这种情况下，玩家发布关于他们自己的信息，感兴趣的软件组件（处理个人成就）可以订阅。这允许您使用专门的日志记录代码查看公共值，而不会影响任何核心游戏逻辑。
以您的“玩家步行 x 英里”为例。我会将行走的距离作为玩家对象中的一个字段来实现，因为这是一个简单的递增值，并且不需要随着时间的推移增加空间。奖励步行 10 英里的玩家的成就就是该领域的订阅者。如果有很多参与者，那么将这个值与一个或多个中间经纪人级别相加是有意义的。例如，如果游戏中有 100 万玩家，那么您可以将这些值与 1000 个经纪人汇总，每个经纪人负责跟踪 1000 个单独的玩家。然后成就订阅这些经纪人，而不是直接订阅所有玩家。当然，最佳层次结构和订阅者数量是特定于实现的。
在您的战斗示例中，玩家可以以完全相同的方式发布他们上一场战斗的详细信息。监控跳跃战斗的成就将订阅此信息，并检查跳跃次数。由于不需要历史状态，因此它也不会随时间增长。同样，无需修改核心代码；您只需要能够访问一些值。
另请注意，大多数奖励不需要是即时的。这使您在管理流量方面有一些回旋余地。在前面的示例中，您可能不会更新经纪人公布的行进距离，直到玩家总共走了一英里，或者自上次更新以来已经过去了一天（在此之前在内部递增）。这实际上只是一种缓存形式；确切的参数将取决于您的问题。
如果您无法访问源代码，您甚至可以执行此操作，例如在视频游戏模拟器中。例如，可以编写一个简单的内存扫描工具来查找显示的分数。一旦你有了这个，你的成就系统就像每帧轮询那个内存位置一样简单，看看他们当前的“分数”是否高于他们的最高分数。视频游戏模拟器最酷的地方在于内存位置是确定的（没有操作系统）。
在普通游戏中有两种方法可以做到这一点。
注意：pub/sub 不适合这个 IME，因为设计者从不想要“当 player.distance = 50”。他们真正想要的是“当观看屏幕的人感知到的玩家距离似乎已经经过第一个村庄，或者向右至少 4 个屏幕宽度时”——即比简单的计数器更模糊和抽象。
在实践中，这意味着逻辑发生在更改发生的位置（甚至在事件发布之前），这是使用 pub/sub 的一种糟糕方式。有一些游戏引擎可以更容易地执行“逻辑在接收点”（“子”部分），但它们不是大多数，IME。
即与上面的 1 几乎相同，除了你小心地做两件事：