在复杂的现代游戏中实现成就系统 [英] Implementation of achievement systems in modern, complex games

问题描述

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

Many games that are created these days come with their own achievement system that rewards players/users for accomplishing certain tasks. The badges system here on stackoverflow is exactly the same.

尽管有些问题我无法找到好的解决方案.

There are some problems though for which I couldn't figure out good solutions.

成就系统必须时刻注意某些事件，想一想一款提供20到30种成就的游戏，例如:战斗.服务器将必须检查这些事件(例如:玩家在这场战斗中避免了对手的 x 攻击，或者玩家走了 x 英里)所有时间.

Achievement systems have to watch out for certain events all the time, think of a game that offers 20 to 30 achievements for e.g.: combat. The server would have to check for these events (e.g.: the player avoided x attacks of the opponent in this battle or the player walked x miles) all time.

• 服务器如何在不减慢甚至崩溃的情况下处理大量操作?

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

Achievement systems usually need data that is only used in the core engine of the game and wouldn't be needed out of there anyway if there weren't those nasty achievements (think of e.g.: how often the player jumped during each fight, you don't want to store all this information in a database.). What I mean is that in some cases the only way of adding an achievement would be adding the code that checks for its current state to the game core, and thats usually a very bad idea.

• 成就系统如何与持有以后不必要信息的游戏核心互动? (请参见上面的示例)

• How do achievement systems interact with the core of the game that holds the later unnecessary information? (see examples above)

它们如何与游戏核心区分开?

How are they separated from the core of the game?

我的示例看似无害"，但请考虑一下魔兽世界中目前可获得的1000多个成就，以及同时在线的众多玩家.

My examples may seem "harmless" but think of the 1000+ achievements currently available in World of Warcraft and the many, many players online at the same time, for example.

推荐答案

成就系统实际上只是日志记录的一种形式.对于这样的系统，发布/订阅是一种很好的方法.在这种情况下，玩家可以发布有关自己的信息，感兴趣的软件组件(处理单个成就)可以订阅.这样一来，您就可以使用专门的日志记录代码查看公共价值，而又不影响任何核心游戏逻辑.

Achievement systems are really just a form of logging. For a system like this, publish/subscribe is a good approach. In this case, players publish information about themselves, and interested software components (that handle individual achievements) can subscribe. This allows you to watch public values with specialised logging code, without affecting any core game logic.

以玩家步行x英里"为例.我会将步行距离实现为玩家对象中的一个字段，因为这是一个简单的值，不需要随时间增加空间.这样，奖励步行10英里的玩家的成就便成为该领域的订阅者.如果有很多参与者，那么将这一价值与一个或多个中间经纪人级别进行汇总是有意义的.例如，如果游戏中存在100万玩家，那么您可以将值与1000个经纪人进行汇总，每个经纪人负责跟踪1000个单独的玩家.然后，成就将订阅这些经纪人，而不是直接订阅所有参与者.当然，最佳的订阅者层次结构和数量是特定于实现的.

Take your 'player walked x miles' example. I would implement the distance walked as a field in the player object, since this is a simple value to increment and does not require increasing space over time. An achievement that rewards players that walk 10 miles is then a subscriber of that field. If there were many players then it would make sense to aggregate this value with one or more intermediate broker levels. For example, if 1 million players exist in the game, then you might aggregate the values with 1000 brokers, each responsible for tracking 1000 individual players. The achievement then subscribes to these brokers, rather than to all the players directly. Of course, the optimal hierarchy and number of subscribers is implementation-specific.

在您的战斗示例中，玩家可以以完全相同的方式发布上一场战斗的详细信息.监视战斗中跳跃的成就将订阅此信息，并检查跳跃数.由于不需要历史状态，因此也不随时间增长.同样，无需修改任何核心代码.您只需要能够访问一些值即可.

In the case of your fight example, players could publish details of their last fight in exactly the same way. An achievement that monitors jumping in fights would subscribe to this info, and check the number of jumps. Since no historical state is required, this does not grow with time either. Again, no core code need be modified; you only need to be able to access some values.

还请注意，大多数奖励不需要是瞬时的.这使您在管理流量方面有一些余地.在上一个示例中，您可能不会更新经纪人发布的行进距离，直到玩家再走一英里，或者自上次更新以来已经过去了一天(此后一直在内部递增).这实际上只是一种缓存形式.确切的参数将取决于您的问题.

Note also that most rewards do not need to be instantaneous. This allows you some leeway in managing your traffic. In the previous example, you might not update the broker's published distance travelled until a player has walked a total of one more mile, or a day has passed since last update (incrementing internally until then). This is really just a form of caching; the exact parameters will depend on your problem.

这篇关于在复杂的现代游戏中实现成就系统的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！