如何用 Node.js 去完成一个多人游戏服务端引擎的制作

admin

如何用 Node.js 去完成一个多人游戏服务端引擎的制作

你听说过冒险游戏这个词吗？如果你足够大（像我一样），你可能听说过甚至玩过《回到过去》。在本文中，我将向您展示整个写作过程。这不仅是一款文字冒险游戏，也是一款文字冒险游戏引擎，让你可以和朋友一起玩，执行任何剧情。是的，我们将通过添加多人功能来增加它的兴趣。
冒险一词是最早的RPG游戏之一。回到没有图形图像的时代，你只能在黑色背景下阅读CRT显示器上的描述，并依靠你的想象力来推动游戏情节的发展。
如果你想怀旧，也许世界上第一个单词冒险游戏叫做“洞穴探险”。
是的。
用node.js编写一个多人游戏服务端引擎。
是的。
今天的文字冒险游戏。
今天的文字冒险游戏。
上面的图片是你实际看到的游戏图片，这是远远不是我们的顶级AAA冒险游戏了。不过，它们玩起来很好玩，很容易让你上百个小时都死掉，因为只有你一个人坐在显示器前，想办法突破它。
可以理解的是，多年来，冒险这个词已经被更好的视觉效果所取代，特别是在过去的几年里，游戏的协作性越强，你就越能和朋友一起玩。这就是原始文本冒险游戏所缺少的，也是我在本文中要提到的。
我们的目标。
正如您可能已经从标题中猜到的，本文的重点是创建一个文本冒险引擎，并让您与朋友一起玩，这样您就可以与他们合作，就像玩游戏“龙与地牢”。
创建引擎时，聊天服务器和客户端会做很多工作。在本文中，我将向您展示设计思想，解释引擎背后的体系结构，客户机如何与服务器交互，以及游戏规则。
为了让你对我的目标又一个直观的感受，先上一张图：.
。
用node.js编写一个多人游戏服务端引擎。
是的。
游戏客户端的界面设计。
这是我们的目标。一旦实现了这一点，你将得到截图，而不是简单和肮脏的模型。所以你需要了解这个过程。我首先要讨论的是总体设计；然后我将讨论用于编写代码的工具；最后我将向您展示一些核心代码（当然，还有到完整代码库的链接）。
希望在这一天结束之前，你可以创建一个新的文字冒险游戏，并与你的朋友一起享受它！。
设计阶段。
在设计阶段，我将描述游戏的总体蓝图。我尽量不让您厌烦，但我认为在向您展示第一行代码之前，有必要先了解一些幕后工作。
我认为接下来的四个组件可以提供很多细节。
引擎。
这将是游戏的主服务器。游戏规则将在这里实现，它将为任何类型的客户端提供一个独立于技术的接口。在这个项目中，我们将实现终端类型客户机，但您可以使用web客户机或任何其他类型的您喜欢的。
聊天服务器。
由于编写另一篇文章的复杂性，该服务还将有自己的模块。聊天服务器负责允许玩家在游戏期间相互通信。
客户。
如前所述，这将是一个终端类型的客户端，理想情况下，它看起来与前一个模型类似。它将利用引擎和聊天服务器提供的服务。
游戏（JSON文件）。
最后，我将介绍实际游戏的定义。本节的重点是创建一个可以运行任何游戏的引擎，只要您的游戏文件满足引擎的要求。所以，即使这不需要编码，我也将解释如何构建一个冒险文件来编写我们自己的冒险规则。
引擎。
游戏引擎或游戏服务端将提供rest API和所有必要的功能。
我之所以选择rest API，仅仅是因为HTTP（对于这种类型的游戏）造成了延迟，而且它的异步特性不会造成任何麻烦。但是，我们必须为聊天服务器采用不同的路由。 在开始定义 API 之前，先需要定义引擎的功能我们来看看。
功能描述玩家可以通过指定的游戏ID加入游戏。创建新玩家也可以创建游戏的新实例。引擎应该返回一个ID，以便其他人可以加入游戏。返回场景这个函数应该返回到播放器的当前场景。基本上，它将返回包含所有相关信息（可能的操作、其中的对象等）的描述。与场景交互是最复杂的场景之一，因为它将从客户端接收命令并执行操作，如移动、攻击、获取、查看、读取等。盘点是一种与游戏互动的方式，但它与场景没有直接关系。因此，检查每个玩家的库存被认为是一个不同的操作。
关于搬家。
我们需要一种在游戏中测量距离的方法，因为玩家在游戏中可以采取的核心动作之一就是移动。我们需要用这个数字来衡量时间，以简化游戏。考虑到这类游戏有回合式的动作，比如战斗，用实际的时钟来测量时间可能不是最好的。所以我们要用距离来测量时间（这意味着8的距离要比2的距离花费更多的时间，这样我们就可以做一些事情，比如给玩家添加一些持续一定数量“距离点”的效果）。
思考体育运动的另一个原因是一个人是否在玩这个游戏。为了简单起见，引擎不允许玩家随意组队（尽管这在未来可能是一个有趣的改进）。该模块的初始版本只允许个人在大多数参与者决定的地方移动。因此，行动必须以协商一致的方式进行，这意味着行动的每一步都将等待多数人提出要求后再行动。
战斗。
格斗是这个游戏的另一个非常重要的方面，我们必须考虑将它添加到引擎中，否则我们最终会失去一些乐趣。
老实说，它不需要重新发明轮子。基于回合制，团队斗争已经存在了几十年，所以这里只实现了这种机制的简单版本。我们会把它和《龙与地牢》中的“主动”概念混合起来，生成一个随机数，使战斗更具活力。
换句话说，就是参与战斗的每个人的行动顺序将会被随机化，其中包括敌人.
最后（尽管我将在下面详细介绍这一点），您可以使用设置了“攻击力”值的项。这些是你可以在战斗中使用的道具。如果道具没有此属性，只能对敌人造成0点伤害。当你试图用这样的道具战斗时，我们可能会添加一条消息，让你知道你想做的是没有意义的。
客户机-服务器交互。
现在让我们看看客户机是如何基于前面定义的函数与服务器交互的（端点还没有被考虑，但我们稍后将讨论这个问题）。
是的。
用node.js编写一个多人游戏服务端引擎。
是的。
客户机和服务器之间的交互。
客户端和服务器之间的初始交互（从服务器的角度来看）是新游戏的开始，步骤如下：。
创建一个新游戏。
客户端请求服务器创建新游戏。
创建聊天室。
虽然没有明确的解释，但服务器不仅在聊天服务器中创建聊天室，还设置了允许一组玩家玩游戏所需的一切。
返回游戏的元数据。
一旦服务器为玩家创建了游戏和聊天室，客户端将在随后的请求中使用此信息。这是一组ID，客户端可以使用它们来标识自己和要添加的游戏实例。
**手动共享游戏ID**。
这一步必须由玩家自己完成。我们可以想出某种共享机制，但我会把它留在我的愿望清单上，以备将来改进。
加入游戏。
这很简单。每个人都有一个ID，客户可以通过它加入游戏。
加入聊天室。
最后，玩家的客户端程序将通过游戏元数据加入相应的聊天室。这是比赛开始前的最后一步。一旦所有操作完成，玩家就可以开始在游戏中冒险了！.
。
用node.js编写一个多人游戏服务端引擎。
是的。
游戏的操作说明。
一旦满足了先决条件，玩家就可以开始游戏，通过聊天室分享他们的想法，并推动故事向前发展。上图显示了所需的四个步骤。
以下步骤将作为游戏循环的一部分来运行，这意味着它们将会不断重复，一直到游戏结束.
请求场景。
客户端程序将请求当前方案的元数据。这是循环每次迭代的第一步。
返回元数据。
服务器将发送回当前场景的元数据。此信息包括对可以找到的对象及其相互关系的一般描述。
发送命令。
戏开始了。这是玩家的主要输入方法。它包括玩家想要执行的动作，以及可选的动作目标（比如吹蜡烛、抓石头等）。
响应命令。
这应该是第二步，但为了清楚起见，我将把它作为额外的一步。主要的区别是，第二步可以看作是循环的开始，而这一步考虑到您已经开始游戏，因此服务器需要知道谁（单个或所有玩家）的行动将影响。
作为另一个步骤，虽然不是过程的一部分，服务器会通知客户端其相关状态的更新。
这个额外重复的原因是玩家可以从其他玩家的动作中获得更新。回想一下从一个地方移动到另一个地方的必要性；如我之前所说，一旦大多数玩家选择了方向，所有玩家都将移动（不需要所有玩家的输入）。
但是，HTTP（如前所述，服务器是rest API）不允许这种行为。所以，我们的选择是：。
每x秒从客户端轮询一次，。
与客户机-服务器连接通信机制并行工作的通知系统。
以我的经验，我更喜欢选择2。实际上，我将使用redis（在本文中）来实现这种行为。
下图说明了服务之间的依赖关系。
是的。
用node.js编写一个多人游戏服务端引擎。
是的。
客户端应用程序和游戏引擎之间的交互。
聊天服务器。
我将把这个模块的设计细节留给开发阶段（本文中没有介绍）。也就是说，我们仍然可以决定一些事情。
我们可以确定的一件事是服务器上的一组限制，这将简化我们的工作。如果我们正确地玩牌，最终可能会有一个提供强大界面的服务，从而允许我们去进行扩展甚至修改实现，以提供更少的限制，而不会影响到游戏.
每个小组只有一个房间。
我们不会创建子团队。这是对不允许团队分裂的补充。也许在我们稍后实现此增强后，最好允许您创建子组并自定义聊天室。
没有私信功能。
这纯粹是为了简化，但群聊还不够好。我们现在不需要私人信件。记住，在任何时候只研究最低可行的产品，是避免陷入不必要功能陷阱的危险方法；很难摆脱困境。
将不保存邮件。
换言之，如果你离开团队，你将失去这些信息。这将大大简化我们的任务，因为我们不必处理任何类型的数据存储，也不必浪费时间优化存储和恢复旧消息的数据结构。它们都存在于记忆中，只要聊天室是活跃的，它就永远存在。一旦关闭，简单地说再见他们！.
通过网络套接字通信。
遗憾的是，我们的客户将不得不处理两种通信渠道：游戏引擎的restful和聊天服务器的socket。这可能会增加客户端的复杂性，但同时它将使用最好的通信方法为每个模块。在聊天服务器上强制rest或在游戏服务端上强制sockets是没有意义的。这种方法增加了服务器端代码的复杂性，这也是处理业务逻辑的代码，所以让我们关注当前的问题。）
这是聊天服务器。毕竟，这并不复杂。在开始编写代码之前有很多工作要做，但这对本文来说已经足够了。
客户。
这是最后一个要编码的模块，它将是最重的。根据经验，我更喜欢使客户机大而服务器轻。这使得为服务器开发新客户机变得更容易。
这是我们最终应该采用的架构。
是的。
用node.js编写一个多人游戏服务端引擎。
是的。
最终架构。
我们要实现的CLI客户端非常简单，不会实现任何非常复杂的东西。事实上，需要解决的最复杂的部分是UI，它是一个基于文本的界面。
客户端应用程序必须实现的功能如下：.
创建新游戏。
因为我想让它尽可能简单，所以只能通过CLI界面来完成。实际的用户界面只有在加入游戏后才能使用，这就给我们带来了下一个问题。加入现有的游戏。
玩家可以根据上次返回的游戏编号加入游戏。此外，这应该在没有UI的情况下完成，因此此功能将是开始使用文本UI所需的过程的一部分。
分析游戏定义文件。
正如我们将要讨论的，客户机应该能够理解这些文件，以便他们能够理解要显示的内容并知道如何使用数据。
与冒险互动。
基本上，这允许玩家在任何时候与给定的环境交互。
为每个玩家维护包内容。
客户端的每个实例在内存中都有一个道具列表。将备份此列表。
支持聊天。
客户端还需要连接到聊天服务器，并允许用户登录到分组聊天室。
稍后将详细描述客户端的内部结构和设计。同时，让我们完成设计阶段的最后一部分：游戏文件。
游戏：JSON文件。
这就是它变得有趣的地方，因为到目前为止。