以下步骤将作为游戏循环的一部分来运行，这意味着它们将会不断重复，一直到游戏结束。
请求场景。
客户端程序将请求当前场景的元数据。这是循环每次迭代的第一步。
返回元数据。
服务器将发回当前场景的元数据。这些信息中包括一般描述，从中可以找到的对象以及它们彼此之间的关系。
发送命令。
好戏开始。这是玩家的主要输入方式。它包括玩家想要执行的操作，以及可选的操作目标（例如吹蜡烛、抓住岩石等）。
对发来的命令做出响应。
这应该属于第二步，但为了清楚起见，我把它作为额外步骤。主要区别在于第二步可以被认为是这个循环的开始，而这一步考虑到你已经开始进行游戏了，因此，服务器需要了解这个动作将影响谁（单个或所有玩家）。
作为额外步骤，虽然不是流程的一部分，但服务器将通知客户端与它们相关的状态的更新情况。
存在这个额外重复步骤的原因是玩家可以从其他玩家的动作中获得更新。回想从一个地方移动另一个地方的需求；正如我之前所说那样，一旦大多数玩家选择了方向，那么所有玩家都会移动（不需要所有球员的输入）。
不过 HTTP（前面已经提到服务器为REST API）不允许这种类型的行为。所以，我们的选择是：
每隔 X 秒从客户端轮询，
使用某种与客户端-服务器连接通信机制并行工作的通知系统。
根据我的经验，我倾向于选择选项 2。实际上，我会（在本文中）使用Redis来实现这种行为。
下图演示了服务之间的依赖关系。
客户端应用程序与游戏引擎之间的交互
聊天服务器
我将把这个模块的设计细节留给开发阶段（本文不涉及这一部分）。话虽如此，我们仍可以决定一些事情。
我们可以确定的一件事是服务器的限制集合，这将简化我们的工作。如果我们正确地玩牌，最终可能会有一个提供强大界面的服务，从而允许我们去进行扩展甚至修改实现，以提供更少的限制，而不会影响到游戏。
每个组队只有一个房间。
我们不会创建子组队。这和不让组队分裂是相辅相成的。也许一旦以后我们实现了这个增强功能，允许创建子组和自定义聊天室或许是一个好主意。
没有私信功能。
这纯粹是为了简化，但是只有群聊并不够好。目前我们不需要私信。请记住，任何时候只研究你的最小化可行产品，尽量避免掉进不必要功能的陷阱；这是一条危险的道路，很难从困境中摆脱出来。
