functional-programming - 功能/ Actor 处理 WorldState 中的先有鸡还是先有蛋

Question

我读过“纯函数式逆向游戏”系列

http://prog21.dadgum.com/23.html

它讨论了一些有趣的技术来构建(半)纯游戏世界更新循环。

但是，我有以下附带说明，我似乎无法理解:

假设您有一个系统，其中每个敌人和每个玩家都是独立的参与者或独立的纯函数。

假设他们都得到一个“WorldState”作为输入，并输出一个新的 WorldState(或者，如果您从 Actor 的角度考虑，将新的 WorldState 发送给下一个 Actor ，例如以“游戏渲染” Actor 结尾).

那么，有两种方法可以解决这个问题:

1. 要么您从一个 Actor (即玩家)开始，然后向他提供“当前世界”。然后，你将新世界喂给下一个敌人，依此类推，直到所有参与者都转换了世界。然后，最后一个世界就是您可以提供给渲染循环的新世界。 (或者，如果您按照上面的文章操作，您最终会得到一个世界上发生的事件列表，可以对其进行处理)。

2. 第二种方法是同时为所有参与者提供当前的 WorldState。它们会产生任何可能发生冲突的变化(例如，两个敌人和玩家可以在同一动画帧中拿硬币)-> 由游戏系统通过处理事件来解决这些冲突。通过处理所有事件，游戏参与者创建新世界，用于下一个更新帧。

我有一种感觉，我只是遇到了完全相同的“竞争条件”问题，我希望通过使用具有不可变数据的纯函数来避免这种情况。

这里有什么建议吗？

Answer 1

我没有读过这篇文章，但是通过硬币示例，您正在创建一种全局变量:您将世界状态的副本提供给所有参与者，并且假设每个参与者都会评估游戏、做出决定并期望他们的行动会成功，而不管最后阶段是解决冲突。我不会将其称为竞争条件，而是“盲目条件”，是的，这是行不通的。

我想您采用此解决方案是为了允许并行性，这在解决方案 1 中不可用。在我看来，问题在于责任。

硬币必须像应用程序中的任何东西一样属于参与者(充当资源管理器的服务器)。这个 Actor 是唯一负责决定硬币会发生什么的人。

所有请求(是否有东西要捕获、捕获它、放下东西......)都应该发送给这个 Actor (每个单元格、每个 map 、关卡或任何对游戏有意义的分割一个 Actor )。

然后你将如何管理它取决于你:按接收顺序处理所有请求，缓冲它们直到同步消息到来并做出随机决定或优先级决定......在任何情况下服务器都能够由于服务器进程在单个内核上运行(至少在 erlang 中)并一次处理一条消息，因此在没有任何竞争条件风险的情况下回复所有参与者成功或失败。