游戏客户端的 UI 设计
这就是我们的目标。 一旦达成这个目标，将会得到截图而不是简单和肮脏的模型。 所以，需要了解这个过程。首先要介绍的就是整体设计；然后介绍我将用来编码的相关工具；最后我将向你展示一些核心代码（当然，还有指向完整代码库的链接）。
希望到最后，你能够自己创造一个新的文字冒险游戏，并与朋友一起乐在其中！
设计阶段
在设计阶段，我将描述这个游戏的整体蓝图。 我会尽力不让你觉得无聊，不过我认为在给你展示第一行代码之前，很有必要先搞清楚幕后的一些工作。
我想接下来介绍的这四个组件能够提供相当多的细节：
- 引擎
- 这将成为游戏的主服务器。游戏规则会在这里实现，它将为任何类型的客户端提供技术无关接口。本项目中我们将实现终端类型的客户端，但是你可以用Web客户端或者你喜欢的任何其他类型。
- 聊天服务器
- 因为它的复杂性足以再写一篇文章了，所以这项服务也会拥有自己的模块。聊天服务器负责让玩家在游戏的过程中彼此通信。
- 客户端
- 如前文所述，这将是一个终端类型的客户端，在理想情况下，它看起来与之前的模型类似。它将利用引擎和聊天服务器所提供的服务。
- 游戏（ JSON文件 ）
- 最后，我将介绍实际游戏的定义。这部分的重点是创建一个可以运行任何游戏的引擎，只要你的游戏文件符合引擎的要求即可。所以，即使这不需要编码，我也将解释如何构建冒险文件以便将来编写我们自己的冒险规则。
引擎
游戏引擎或游戏服务器将会是REST API，并提供所有必需的功能。
我选择REST API只是因为（对于这种类型的游戏）HTTP造成的延迟以及他的异步特性不会造成任何麻烦。 但是，我们必须为聊天服务器采用不同的路线。 在开始定义 API 之前，先需要定义引擎的功能。 所以，让我们来看看吧。
| 特性 | 描述 |
|---|---|
| 加入游戏 | 玩家可以通过指定的游戏ID来加入游戏。 |
| 创建一个新游戏 | 玩家还可以创建新的游戏实例。 引擎应该返回一个ID，以便其他人可以使它来加入游戏。 |
| 返回场景 | 此功能应返回玩家所在的当前场景。 基本上，它将返回描述，包含所有相关信息（可能的操作、其中的对象等）。 |
| 与场景互动 | 这将是最复杂的一个，因为它将从客户端获取命令并执行该操作——例如移动，攻击，获取，查看，读取等等。 |
| 检查库存 | 虽然这是与游戏互动的一种方式，但它与场景并没有直接关系。 因此，检查每个玩家的库存将被视为不同的操作。 |