中编写多人文本冒险引擎：游戏引擎服务器设计（第 2 部分）

RAHIM26

欢迎来到本系列的第二部分。第一部分，我们介绍了基于  的平台和客户端应用程序的架构，这将使人们能够以团队的方式定义和玩自己的文本冒险。这一次，我们将介绍费尔南多上次定义的模块之一（游戏引擎）的创建，并将重点关注设计过程，以便阐明在开始编码之前需要发生的事情。自己的爱好项目。 经过仔细的考虑和模块的实际实现，我在设计阶段所做的一些定义不得不改变。对于任何曾经与热切的客户合作过的人来说，这应该是一个熟悉的场景，他们梦想着一个理想的产品，但需要受到开发团队的约束。 一旦功能被实现和测试，您的团队将开始注意到某些特征可能与原始计划有所不同，这没关系。只需通知、调整并继续即可。那么，闲话少说，我先来解释一下与原计划相比发生了什么变化。 本系列的其他部分 第 1 部分：简介 第 3 部分：创建终端客户端 第 4 部分：将聊天添加到我们的游戏中 战斗机制 这可能是与原计划相比最大的改变。我知道我说过我会采用 D&D 式的实施方式，其中涉及的每个 PC 和 NPC 都会获得主动值，之后我们将进行回合制战斗。

这是一个好主意，但在基于 REST 的服务上实现它有点复杂 美国手机号码列表  因为您无法从服务器端发起通信，也无法维护调用之间的状态。 因此，我将利用 REST 的简化机制，并用它来简化我们的战斗机制。实施的版本将是基于玩家而不是基于队伍的，并且允许玩家攻击 NPC（非玩家角色）。如果他们的攻击成功，NPC 将被杀死，否则他们将通过伤害或杀死玩家进行反击。 攻击成功或失败将取决于所使用的武器类型和 NPC 可能存在的弱点。所以基本上，如果你想要杀死的怪物对你的武器来说很弱，它就会死。否则，它不会受到影响，而且很可能会非常生气。 触发器 如果您密切关注我上一篇文章中的 JSON 游戏定义，您可能已经注意到场景项上的触发器定义。其中一个具体涉及更新游戏状态 。在实施过程中，我意识到将其作为切换开关提供了有限的自由。您会看到，按照它的实现方式（从惯用的角度来看），您可以设置状态，但无法取消设置它。因此，我用两个新的触发效果替换了这个触发效果：这些将允许您准确定义这些影响何时会发生——如果有的话。我觉得这更容易理解和推理。 这意味着触发器现在看起来像这样：  当拿起该物品时，我们正在设置一个状态，而当放下它时，我们正在将其删除。



这样，拥有多个游戏级状态指示器是完全可能的并且易于管理。 认识图像优化，Addy Osmani 的新实用指南，用于在网络上优化和提供高质量图像。一切尽在一本528 页的书中。 跳转至目录 ↬ 功能面板 实施 随着这些更新的完成，我们可以开始讨论实际的实现。从架构的角度来看，没有任何改变；我们仍在构建一个包含主游戏引擎逻辑的 REST API。 技术堆栈 对于这个特定的项目，我将使用的模块如下： 模块        描述 E        显然，我将使用 Express 作为整个引擎的基础。 温斯顿        与日志记录相关的一切都将由 Winston 处理。 配置        每个常量和环境相关变量都将由 c 模块处理，这大大简化了访问它们的任务。 猫鼬        这将是我们的 ORM。我将使用 Mongoose 模型对所有资源进行建模，并使用它直接与数据库交互。         我们需要生成一些唯一的 ID — 该模块将帮助我们完成该任务。 至于除了  之外使用的其他技术，我们还有MongoDB和Redis。由于缺乏所需的模式，我喜欢使用 Mongo。这个简单的事实使我能够思考我的代码和数据格式，而不必担心更新表的结构、模式迁移或冲突的数据类型。 关于Redis，我倾向于在项目中尽可能地使用它作为支持系统，本例也不例外。我将使用 来处理所有可被视为易失性信息的内容，例如党员编号、命令请求以及其他类型的数据，这些数据足够小且易失性足以不值得永久存储。 我还将使用  的密钥过期功能来自动管理流程的某些方面（稍后将详细介绍）。