最好的IPC为分散的roguelike？

Question

我有一个项目要创建一个罗格利埃，它在某种程度上从引擎中抽象UI，从地图创建、站点线等抽象出引擎。为了缩小焦点，我首先想让UI (播放器的客户端)和引擎工作。

我目前的想法是使客户基本上是一个程序，决定什么角色(玩家，怪物)将为其回合和等待直到它可以再次移动。每个怪物都有一个客户，玩家也是如此。播放器的客户端打印地图，等待输入，将其发送到引擎，并告诉播放器发生了什么。怪物的客户端也是如此，除了没有打印地图和使用AI代替键盘输入之外。

在我走得更远之前，如果这似乎是一种模糊的做事方式，我的目标是学习，而不是写一个长袍。这是旅程，不是目的地。

因此，我需要选择哪种形式的ipc最适合这个模型。

1. 我第一次尝试使用管道是因为它们是最简单的，我为播放器编写了一个UI，并编写了一个程序，用于在诸如放置地图和播放器的位置等指令中进行管道传输。虽然这样做有效，但它只允许一个客户端-通过stdin和out进行通信。
2. 我已经考虑过让引擎成为一个守护进程，在这个后台程序中，当客户端启动时，创建唯一的每个客户端临时文件，以便向引擎发出指令并接收反馈。
3. 最后，我用套接字做了一些介绍性的编程。他们似乎是走的路，并将允许游戏可能有一天会在网上运行。如果可能的话，我想使用一个更简单的解决方案，而且由于我对它们不熟悉，所以更容易出错。
4. 我总是乐于接受建议。

Answer 1

我一直在尝试使用这些组合来解决类似的问题(多个客户端通过本地框上的单个守护进程进行交谈，其中大部分智能都被推入客户端)。

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

总的来说，我喜欢以这种方式将事情分解成单独的可执行程序--例如，它可以使测试变得更容易。我认为方法的选择取决于使用模式--消息有多大，它们中的数据需要有多持久，你能负担一条基于套接字的消息通过网络栈进行多次旅行的费用吗？您坚持使用Linux的事实使得事情在可用方面变得简单--例如，您不需要担心消息队列的可移植性。

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