【笔记】关于RMMV制作高即时性联机游戏（一）: 实践报告

刺夜之枪

（刺夜之枪 2017）

---

关于RMMV制作高即时性联机游戏（一）:

实践报告【缓慢更新中】

私用学习笔记，分享一下实践的成果和报告-

---

关键词： RPG-Maker-MV 高即时性 网游化 HTML5 Node.js Express.js Socket.io WebSocket  

前言

        近日鄙人从两个Github开源项目、叶劲峰推荐的游戏开发者必读书单，还有若干YouTube教程视频中习得了HTML5网络游戏开发的一些基本概念。经过研究和整理过后，决定进行RPG Maker MV网优化的实践工作。由于在下一直以来就对单机联机游戏很感兴趣，但早期由于基础知识的薄弱，鄙人一直没有找到合适的有关资料、合适的渠道进行系统化高质量地学习。故，经过一段时间的补习以及摸索-当然最重要的是实践-整理出了一套比较完善的MV网络化的框架和思路的总结，并在此发布首先作为自己私用的学习笔记；其次，由于吾深刻意识到瞎几把自学+瞎几把摸索导致的极其低效地开发工作所造成的资源和时间的浪费，亦希望此贴可以为后续开发者报告一些实践的策划，过程，以及成果，以示前车之鉴，避免走入弯路。
        另注，本帖的定位不是教程贴， 暂不保证能手把手教会读者，仅供参考！鄙人以及默认你已经有了一定的RPG Maker项目开发经验以及面向对象编程(OOP)的基础知识，甚至网络通信的相关知识。否则的话，理解起来因人而异可能会比较困难。当然也许我以后有时间可以再科普一些这样的内容。
        另另注，楼主依然在实践学习的过程中，发帖的时候依然处于摸索阶段，帖子以后会不定期更新修正成果。

---

上述中提到的灵感资料：

• 叶劲峰推荐的职业游戏开发者必读书单
          英文版： https://rpg.blue/forum.php?mod=viewthread&tid=397686
• Github 开源项目：
          BrowserQuest:      一个HTML5全平台网页游戏    https://github.com/mozilla/BrowserQuest
          RealtimeMultiplayerNodeJs:  本帖重点参考项目   https://github.com/onedayitwillmake/RealtimeMultiplayerNodeJs
• YouTube 教程视频:
          RainingChain    频道 HTML5  教程    https://www.youtube.com/channel/UC8Yp-YagXZ4C5vOduEhcjRw
          Traversy Media 频道 Node.js 教程    https://www.youtube.com/channel/UC29ju8bIPH5as8OGnQzwJyA
  

---

目录

• 概述：本帖中主讲的思路的独特之处
• 基础知识：
  
  • 服务端/客户端
  • Node.js
  • 套接字（Socket）
    
• 即时性网游开发思路
  
  • 网络模块：设计模式、思路
  • 游戏逻辑：设计模式、思路
    
• 实践报告：
  
  • 成果反馈
  • 遇到的挑战
  • 接下来的计划
    
• 结束语、新游戏预告
  

PS, 随时修改

---

我知道没有图你们是不会看的，先上JB：

*以上为游戏本地测试时的屏幕截图，本来想录视频，但是没成功。


*以上为现实中的实际效果，所有的NPC都在进行随机运动，FPS(60)；

---

下面进入正题~

（一）概述：本帖中主讲的思路的独特之处

        首先我需要提到的是，本贴思路的特殊性。RPG Maker系列的网络化早在08年就开始有人不断地探索并且开拓了，外国甚至已经有人制作出了成熟的网络模块。早在鄙人开始进行实践活动之前，已经在各方论坛（国内国外）搜索过RPG Maker MV的联机功能相关的讨论了。自从RPG Maker MV以来，制作方机智地采用前端最流行的HTML5 Javascript作为引擎，而Javascript作为前端开发最重要的语言、有着悠久的发展历史，前端开发的社区已经通过了原始的资本积累。这些资源、技术的积累不光促进了整个前端开发领域的繁荣，也同时成为 RPG Maker MV 社区自问世以来急速发展/拓展/转型的重要催化池。因此，国内外无数RPG Maker 开发者抓住这项资源优势，展开了对联机化的实践工作。今年各大RM论坛搜索“联机”的关键词比以往翻了好多倍。

        很好，现在进入正题。笔者早些已经翻阅了很多成品项目，看了源代码和其中的Documents。绝大多数RMMV网络化的作者采用的标准套件是：WebSocket + Node.js 这样的标配。个别实力派开发者使用的是自行开发的c++或者php服务端代码。关于服务端与客户端的选配问题，我会在下面细讲，不过在此之前，让我先讲一个更重要的因素为什么本帖的思路特殊。据观察，因为RM是作为角色扮演（RPG）游戏引擎的性质，决定了其对于即时性的需求低于一般HTML5网络游戏，更有开发者利用RPG Maker  这款引擎开发出SRPG，卡牌类网络游戏。这本无可厚非，开发任何游戏或者程序，最重要的是定制最合适自己的开发方针、设计思路。但是，鄙人却第一个不高兴了：笔者同时也是群战系统的作者，从小到大使用RPG Maker引擎只做动作游戏ARPG，特别是最近要开发的即时战斗游戏（骑马与砍杀、全面战争系列是最爱，也是一直以来的模仿对象）。动作游戏，特别是即时动作游戏、即时战略等游戏，在网络通讯中，对于即时性的需求是十分高的。 自从 RPG Maker 从XP 代的每秒20帧，开了平滑模式才40帧（感谢二楼纠正错误），再演变到如今ACE和MV的每秒钟更新60帧！网络动作游戏如何做到快速地、流畅地、准确地、可靠地，安全地传输服务端、客户端的数据，其中包括延迟、断线重连等问题，成为了首当其冲最重要的问题。 这里注意，HTML5游戏的发展史比RPG Maker MV等长，HTML5游戏在如何解决“快速地、流畅地、准确地、可靠地，安全地传输”的问题上早有解决方案，但此技术尚未被广泛应用到RPG Maker开发中。

*群战系统游戏截图

        因此，国内外有很大数量的RPG Maker网络化的开发者十分简略地利用了这些设计思路（我就列举出一些我看到的案例）：
        【问题一】 打包客户端用户生产的数据，发送到服务器，通过服务器群发给所有其他客户端，最后其他客户端再解压。
        这样的设计模式，管用倒是管用，但是这需要所有的客户端都是“守信用的”，要知道，前端的代码可都是开源的，要确保玩家守信用不擅自修改代码进行作弊这是十分困难的（作弊还算轻的了）。其次还有一个严重的问题就是：如果在服务器端和客户端同时运行游戏逻辑，由于机器之间的差异，导致游戏逻辑更新的不同步。这会使不少玩家（高配电脑运算快），本地以及更新到新的位置，可服务器却还在慢半拍的位置，反之亦然。 最后玩家会被不知道哪里打来的子弹打死，或者穿过本来不应该穿过的障碍物。
       
        【问题二】 每当服务端游戏中物体移动移动时，向客户端发送物体的移动向量（x，y 坐标的变化率），然后再有客户端根据向量在本地渲染图形的移动。
        这个问题被称为 弹跳球问题（bouncing ball problem）， 如下图所示，横轴表示的时间（毫秒），时间轴上每个点代表一次更新、接收向量数据包的时间（间隔一样）。蓝色曲线代表游戏物体实际的移动轨迹，红线代表服务器发送的游戏物体的向量移动数据。由图可见，如果我们只是单纯地把物体每次更新的瞬时速度传送给客户端渲染，那么，直到客户端接收下一次数据包之前，物体都会保持原有的移动方式，这很可能会导致错误的数据！同时，如果更新的频率低了，游戏本地的角色移动起来就会看着“卡巴拉基” “鬼畜” “抽搐” “一震一震”地，只能通过提高频率而解决。然而现实中由于网速、延迟等各种问题，服务器不可能每次都完好无缺地、精确地、高频地把数据发给所有客户端（除非他们都用OC-3）。

       
        *弹跳球问题实际情况描述

        以上是两种RPG Maker 网络游戏开发者最常用的套路，其中第二种的致命性不如第一种，那是因为在RPG Maker中，游戏多为标准的“走格子”移动方式，大多数情况下角色的移动方向是固定的，距离是固定的，上下左右，顶多来一个8方向脚本，这也完全没问题。因此，服务器想客户端发送坐标向量数据的思路完全可行！但，让我们重新看一下本帖的标题：“【笔记】关于RMMV制作高即时性联机游戏（一）: 实践报告”。 那么好，高即时性才是本帖的主题。不然的话，我也不会在此处费这么多口舌向大家讲一些已经实现了的功能。况且，鄙人接下来要开发的项目【群战OL】即将抛弃传统的走格子式的移动方式，改为全像素移动(6R有类似效果的脚本，感兴趣的可以搜一搜)。对于放弃了标准化移动模式的RM动作游戏，自然需要一套完美的解决 第二个问题的 方法。





正在写，还没写完

---

（二）基础知识

1) 服务端/客户端：
        码字中。。。       

1) Node.js：

       

什么是Node.js：
        Node.js是一个基于Chrome JavaScript运行时建立的平台， 用于方便地搭建响应速度快、易于扩展的网络应用。Node.js 使用事件驱动， 非阻塞I/O 模型而得以轻量和高效，非常适合在分布式设备上运行数据密集型的实时应用。其优点很多，譬如有很多实用的开发库、框架，请自行百度，这里不再复述了。

使用Node.js开发最重要的理由:
        本身Node.js就非常适合HTML5游戏的服务端开发，但一定要要记住我们帖子的正题：使用 RPG Maker MV 进行网络化开发。RMMV引擎十分完善，在画面方面采用了Pixi.js渲染，引擎的脚本语言使用了JavaScript；为了能让RM开发者 “最大程度地调用RPG Maker MV现成的代码，而不是重0开始写一款html5游戏”， 我们选择使用Node.js这款JavaScript运行平台作为服务器端。如前面所述，我见过实力派开发者使用C++/Php等语言些自己编写服务端。但他们遇到的挑战就是需要把客户端游戏逻辑重新用C++/Php编写一遍。经过实践得出，RPG Maker MV默认的代码和库稍加修改即可在Node的环境下运行。
               
       
       
1) 套接字（Socket）

什么是 套接字（Socket）：        
        源IP地址和目的IP地址以及源端口号和目的端口号的组合称为套接字。其用于标识客户端请求的服务器和服务。它是网络通信过程中端点的抽象表示，包含进行网络通信必需的五种信息：连接使用的协议，本地主机的IP地址，本地进程的协议端口，远地主机的IP地址，远地进程的协议端口。
        具体内容自行百度。

使用Socket.io/WebSocket的理由:
        WebSocket protocol 是HTML5一种新的协议。它实现了浏览器与服务器全双工通信(full-duple)。一开始的握手需要借助HTTP请求完成。
        “socket.io封装了websocket，同时包含了其它的连接方式，比如Ajax。原因在于不是所有的浏览器都支持websocket，通过socket.io的封装，你不用关心里面用了什么连接方式。你在任何浏览器里都可以使用socket.io来建立异步的连接。socket.io包含了服务端和客户端的库，如果在浏览器中使用了socket.io的js，服务端也必须同样适用。如果你很清楚你需要的就是websocket，那可以直接使用websocket” ——百度知道。
        具体内容自行百度。

---

（三）即时性网游开发思路

        那么重点来了： 在翻阅了两款优秀HTML5 优秀开源项目 BrowserQuest by Little Studio 和 RealtimeMultiplayerNodeJs by Mario Gonzalez。 其中，RealtimeMultiplayerNodeJs作为本贴的教材，我整理了一下 Mario Gonzalez 的设计思路，并且进行了实(mo)践(fang)活动。所以接下来讲给大家： 一个高即时性的联机HTML5游戏在 RPG Maker 中的应用。 由于这部分只是概述，让我先陈述一下 本联机的设计思路，具体的实现我会在下面详细地写。据说作者是从Quake这个游戏中得到的启发。
        Gonzalez大师所设计的思路整体如下：

客户端的职责	服务端的职责
记录/数据化用户的输入(Input)	处理用户的输入
渲染游戏画面(Render)	移动游戏对象
	更新游戏逻辑(update)
	创建一个描述游戏所有动态对象的数据包
	更新网络模块（包含了发送和接受）

*延迟模式逻辑图

        为了达到，“快速地、流畅地、准确地、可靠地，安全地传输数据”的目的。我们需要在游戏中有意地加入一个固定的微小的延迟(N)：让所有的客户端在服务端实际时间的N毫秒后，延迟渲染游戏画面。这个N要足够小，欺骗玩家的眼睛，但同时N要足够大，能够让若干条服务器的数据传送到客户端。在开源的范例里，游戏逻辑的更新是60帧每秒，作者使用了N=75毫秒的延迟，我实践后证明这个延迟不会对玩家造成任何影响。如下图所示，横轴是时间，时间轴上每一个点都是服务器创建一个“描述游戏所有对象的数据包”的时机。范例中，服务器每16毫秒（60帧）就会创建一个数据包，并加入到服务端的缓冲区，再以30帧每秒（33毫秒左右每帧）的频率发送到客户端，由于客户端画面的渲染和实际时间之间有75毫秒的预留的延迟，在游戏画面实际刷新之前，客户端可以缓冲3-5个数据包。然后根据这3-5个缓冲好的数据包重新进行客户端的渲染即可完美达成目的。

        细节会在接下来几块实践报告里面讲，我先说此设计模式的优点（此模式已被实践证实成功）：

• 一旦在传输过程中数据包丢失，设有延迟的缓冲的机制可以弥补缺失的位置：利用其它缓冲的数据推断出缺失的数据包位置信息等。
  
  
• “让客户端只负责渲染画面以及发送用户的输入信息，固定频率接收服务器信息” 首先解决了【问题一】客户端和服务端更新的不同步导致的一系列问题（致命问题），其次，防止了玩家很容易作弊的现象（也很致命）。
  
  
• 队友动作游戏来说，特别是群战的开发，士兵的运动轨迹是必须要做到精确的。不能容忍【问题二】中的“不稳定”“抽搐”“鬼畜”地移动方式， 通过固定频率创建描述所有物体位置信息的数据包，并发送给客户端可以有效提高画面的流畅度。
  
  

---

（四）实践报告

码字中

（刺夜之枪 2017）

shitake

mark一下
顺便贴个参考：https://github.com/NetEase/pomelo

RaidenInfinity

XP 开了平滑模式40帧，否则20帧
VA 60帧

guoxiaomi

围观~我也研究过这些……但是想到作弊的事情，就觉得更加的麻烦……

walf_man

写的非常好，苦于一直无法解决同屏的问题
等你的现成的成果吧

非洲的咸鱼

（第一帖就是挖坟的。。。看我洛阳铲）
楼主，现在进度咋样了？出成果了吗？