不会保存留言。
换句话说，如果你离开组队，将会丢失这些信息。这将极大地简化我们的任务，因为我们不必处理任何类型的数据存储，也不必浪费时间来优化存储和恢复旧消息的数据结构。它们都存在于内存中，只要聊天室处于活动状态，就会一直存在。一旦关闭，就会简单地对它们说Goodbye！
通过网络套接字进行通信。
可悲的是，我们的客户将不得不处理双重沟通渠道：游戏引擎的 RESTful 和聊天服务器的套接字。这可能会增加客户端的复杂性，但与此同时，它将为每个模块使用最佳通信方法。 （在聊天服务器上强制 REST 或在游戏服务器上强制使用套接字没有任何意义。这种方法会增加服务器端代码的复杂性，这也是处理业务逻辑的代码，所以让我们关注目前的问题。）
这就是聊天服务器。毕竟，它不会很复杂。在开始编码之前还有很多工作要做，但是对于本文来说已经足够了。
客户端
这是最后一个需要编码的模块，它将是最笨重的一个模块。根据经验来看，我更喜欢让客户端笨重，使服务器轻巧。这样为服务器开发新的客户端会更加容易。
这是我们最终应该采用的架构。
最终架构
我们要实现的ClI客户端很简单，不会实现任何非常复杂的东西。实际上，必须要解决的最复杂的部分是 UI，因为它是一个基于文本的界面。
客户端应用程序必须实现的功能如下：
创建一个新游戏。
因为我希望尽可能保持简单，所以这只能通过 CLI 界面完成。实际用户界面只会在加入游戏后被用到，这把我们带到下一个问题。
加入现有游戏。
玩家可以根据由上一条返回的游戏编号来加入游戏。另外，这件事应该能够在没有 UI 的情况下完成，因此这个功能将成为开始使用文本 UI 所需的过程的一部分。
解析游戏定义文件。
我们将对这点进行的讨论，客户端应该能够理解这些文件，以便能够理解要显示的内容，并知道应该如何使用这个数据。
与冒险互动。
基本上，这使玩家能够在任何时间与给出描述的环境进行交互。
为每位玩家维护背包内容。
客户端的每个实例都将在内存中包含一份道具列表。此列表将被备份。
支持聊天。
客户端程序还需要连接到聊天服务器，并使用户登录到组队的聊天室。
