去中心化 Roguelike 的最佳 IPC 形式？

Question

我有一个项目来创建一个roguelike，它以某种方式从引擎中抽象出 UI，并从地图创建、站点线等中抽象出引擎。为了缩小焦点，我首先只想让 UI（玩家的客户端）和引擎工作。

我目前的想法是让客户端基本上是一个程序，它决定一个角色（玩家、怪物）轮到它做什么，并等待它再次移动。所以每个怪物都有一个客户，玩家也是如此。玩家的客户端打印地图，等待输入，将其发送到引擎，然后告诉玩家发生了什么。怪物的客户端除了不打印地图和使用 AI 代替键盘输入外，也是一样的。

在我继续之前，如果这似乎是一种模糊的做事方式，我的目标是学习，而不是写一个 roguelike。这是旅程，而不是目的地。

所以我需要选择哪种形式的ipc 最适合这个模型。

1. 我第一次尝试使用管道，因为它们最简单，我写了一个 播放器的 UI 和一个程序来输入指令，例如 放置地图和播放器的位置。虽然这有效，但它只允许 一个客户端——通过标准输入和输出进行通信。
2. 我考虑过让引擎成为一个查看线轴的守护进程 客户端在启动时创建每个客户端唯一的临时文件以 向引擎发出指令并接收反馈。
3. 最后，我做了一点关于套接字的介绍性编程。 他们似乎可能是要走的路，并且会允许游戏 也许有一天会被网碾过。如果可能的话，我想使用 一个更简单的解决方案，由于我对它们不熟悉，所以它更 容易出错。
4. 我总是乐于接受建议。

Answer 1

我一直在尝试使用这些组合来解决类似的问题（多个客户端通过本地机器上的单个守护程序进行通信，大部分智能都被推送到客户端）。

• mmap 用于共享大型数据 blob，使用 unix 域套接字、消息队列或命名管道进行通知
• 相同，但使用每个 blob 的单个文件，而不是在 mmap 中将它们全部组合在一起
• 相同，但没有文件或 mmap（换句话说，更像传统消息传递）

总的来说，我喜欢以这种方式将事物分解为单独的可执行文件的想法——例如，它确实使测试更容易。我认为方法的选择归结为使用模式——消息有多大，它们中的数据需要有多持久，你能负担得起多次通过网络堆栈获取基于套接字的消息的成本吗？的事情。坚持使用 Linux 的事实使事情变得容易，例如，您不必担心消息队列的可移植性。

这个也适用：https://stackoverflow.com/a/1428542/1264797