自从 Cocos Creator 3.0 之后, 我们更新了 Cocos Store, 这是一个可以让开发者对外发布免费或者收费资源, 比如音乐, 图片, 代码之类的地方.
Cocos Store 及其资源在全世界范围内人气持续攀升. 精妙的工具不断涌现, 其背后的开发商功不可没. 其中具有代表性的就是由 Lucid Sight 团队开发的开源后端网络系统 Colyseus.
如果你缺乏后台开发经验或者在开发多人在线游戏时遇到麻烦, 那么开源服务器 Colyseus 及其技术团队将成为你的救星. Colyseus 是一款易用, 好用的多人在线游戏服务器, 这一点已被诸多 HTML5 和手机游戏证明.
现在它来到了 Cocos Store, 我们通力合作确保其在 Cocos Creator 上完美运行, 并且筹划了未来的合作规划.
这里我们有请 Colyseus 的创作者 Endel Dreyer, 与 Lucid Sight 的首席技术官, Colyseus 的拥有者 Farzi Zubair 接受采访.
Cocos: 很高兴采访二位. 对于没听说过 Colyseus 的开发者, 你们会如何介绍自己?
Colyseus 团队: 直截了当, 我们的目的是将多人在线服务大众化, 所以我们开发了 Colyseus, 一款基于 Node.js 的高级多人在线后台服务平台.
我们的初心是简化多人在线游戏的实现, 以便开发者更专注于自己的游戏体验而不必承受后台开发的种种困难. 而且, Colyseus 提供服务端与客户端全套的解决方案就是为了方便开发者使用.
C: 为什么基于 Node.js?
CT: Node.js 通过各种方式致力于打造完美开发体验的生态系统. 其 JIT 编译器能提供比某些 C 语言程序高出许多倍的性能. Node.js 程序运行比 Java 需要的内存更少. 而且 Colyseus 得益于 Node.js 提供的各种模块. 各种问题都可以通过搜索 (和制作) 模块找到解决方法, 比如寻路, 导航, 连接数据库等等.
C: 听起来很有吸引力. 那么 Colyseus 作为一款联网工具相对于开发者已有的网络工具有什么优势呢?
CT: 市面上有许多多人在线服务框架. 但是以我们的经验, 我们能提供开发者需求的绝大多数功能. 作为独立开发者, 通常无力负担大额的游戏服务软件费用, 无法直接做到服务器扩张, 或者服务器代码难以修改以适应自己的游戏.
我们的软件是开源的, 这就为开发者提供了免费的服务器程序及其修改权 (MIT协议). 这也使得 Colyseus 能运行于各种容器, 并且缩放自如 (无论是自建还是订阅 Colyseus Arena 服务都能实现快速缩放), 高级 API 使得服务器与客户端沟通更加流畅.
C: 我看到你们为很多游戏引擎开发了客户端, 但是作为西方最大支持者之一, 为什么看中 Cocos Creator 和 Cocos2d-x 了呢?
CT: Cocos 产品名声在外. Cocos 社区也招人爱. 我们想为其游戏开发者提供最好的多人在线解决方案. 另外, 我们是开源社区的大fan, 专门支持像 Cocos 这样的开源项目.
C: 我们注意到你们的产品是用 TypeScript 写的, 就像 Cocos Creator 一样. 为什么做出使用 TS 这个决定, 这对于 Cocos Creator 意味着什么?
CT: TypeScript 意味着更好的可维护性. 对于程序员来说比 JavaScript 更好. JavaScript 程序员总是犯下拼写错误这类能直接导致服务器崩溃的失误. 但是一旦使用 TypeScript, 编译器就会阻止这种事情发生. Colyseus SDK 包含全部类型定义 - 你甚至可以从 Cocos Creator 里直接获取服务端状态变量.
C: 让项目接入 Colyseus 服务有多容易?
CT: 首先打开商店页面找到 Colyseus 插件. 下载安装.之后就可以在你的 Typescript 组件里使用了. 实现把客户端连接到一个 (或多个) 房间, 房间里的客户端互相传递信息, 监听服务器状态变化这样各种的功能.
Endel Dreyer
C: 换个话题. 我们观察到多人在线游戏从以前的不到十人到如今的50, 100 甚至上千人于一个副本中同时在线. Colyseus 对于这种需求是如何满足的呢?
CT: 好问题. Colyseus 非常灵活，它可以为任何游戏类型或使用要求提供解决方案，因为它是开箱即用的基于房间的后台服务系统. 根据游戏复杂程度, 每个房间可以轻松支持 1500 个并发玩家 (CCU). 要是你想制作大型多人在线游戏 (MMO), 我们建议你把 "游戏世界" 分成若干个房间, 再用多线程同步房间逻辑.
我们在自己的 MMO 游戏 CSC 中使用了这种 "分割游戏世界" 的方案. 具体来说就是把宇宙根据坐标分割为多个房间. 通过设置房间参数就能实现这个功能, 然后再让客户端根据房间参数加入各个房间即可.
举个例子, 当一个玩家进入游戏时, 他的坐标是太阳系 (我们设计的) 0, 0 点即太阳的位置. 当他移动的时候, 我们根据区域定义他的新坐标. 比如一个区域是 10,000 平方公里. 当他远离太阳时, 他的坐标可能是九宫格区域之一 (0,1 1,0 1,1 -1,0 以此类推.. – 房间命名比如 “sol_0_1 = 0,1” 这样). 为了移动平滑, 我们在一开始就让玩家进入了这 9 个房间. 即初始房间和九宫格的另外 8 个房间. 玩家移动时不断地离开房间和加入新房间, 使得他始终能收到当前坐标房间和移动方向目标房间的信息. 加入多个房间的另一用途就是为玩家提供全局消息 / 聊天消息 (比如 “sol_chat, sol_global” 房间). 全 3D 世界的话也可以使用类似机制, 不同的就是把二维坐标改成三维的.
对于服务缩放, 有许多解决方法, 主要取决于你的游戏类型和游戏设计. 每个服务器上每个房间应该容纳多少人上限要合理. 这个数值很大程度上取决于游戏类型, 每秒信息数量以及游戏逻辑复杂程度. 这就是我们为 Colyseus 提供的 SaaS 托管解决方案的魅力所在. 作为程序员, 你大可不必担心服务器容量, 比如新开房间, 游戏世界随玩家数量增长而变大之类的压力. 我们的 Colyseus Arena 系统能根据你的游戏服务压力情况自动部署新服务器以保持平衡, 确保每个房间都能高效运作.
C: Colyseus 为开发者提供了什么样的功能?
CT: 除了刚才提到的 "房间" 机制, Colyseus 还有独创的同步机制以取代平常的收发消息功能. 改变服务器状态时客户端都会收到回调反馈.
我们的房间状态同步算法能确保网路上只有必要的部分信息在传播. 当服务器端结构变化时, 客户端会在下个 "补间时段" 与服务器同步.
C: 我们很多开发人员都是这个行业的新手，所以我们很想知道网络技术在过去几年里是如何进化到今天的?
CT: 最近几年间最显著的进化是容器的引入以及系统的灵活和伸缩性. 使用容器能让开发者更有效地创建和卸载服务程序. 配置得当的话, 游戏就可以轻易支持更多玩家同时不需要维护和为多余的服务器买单. Colyseus 是基于 Node.js 的轻型框架, 天生就是完美的容器应用服务系统.
过去的游戏后台要么使用最高端昂贵的机器, 要么就是使用许多的虚拟机. 容器有点像虚拟机但是部署上比虚拟机快得多. 也就是说不管新开还是卸载都能很快完成, 省去了大量因为服务缩放而产生的费用.
Farzi Zubair
C: 感觉不错啊. 要是开发者开始使用 Colyseus 开发游戏, 你能给出一些对提升游戏有帮助的建议吗?
CT: 任何第一次制作多人在线游戏的开发者都应该牢记以下事情.
-
开发游戏时就要考虑到作弊者，并使服务器尽可能具有权威性——因为作弊会导致游戏的完全失败. 一旦您的游戏上线，您的团队会忙不迭地工作并且急于修补漏洞，而作弊部分可能会成为最为高昂的资源消耗。这就是为什么我总是建议开发人员从一开始就尝试使服务器尽可能具有权威性, 将可能影响游戏结果的逻辑和功能限制在服务器代码中, 杜绝玩家找到作弊或破解游戏的方法.
-
专注于游戏体验, 把服务器端交给值得信赖的 SaaS 服务 -- 自托管非常适合开发调试, 但是一旦开始就要尽快找到你的 DevOps 解决方案或者 SaaS 服务. 我们见到许多开发商到离游戏上线还剩最后几周, 都还没有考虑服务器或 SaaS 的事.
有一个叫做 Agones 的开源服务器就做得很好. 它运行在基于 Kubernetes 上的大量 docker 容器中. 但是, 要是独立开发者或者从未与托管服务打过交道, 你会发现忽略了服务器环境这个大问题. 这通常会导致服务器匹配和 SDK 整合的失败. 所以做游戏除了开发工作还不够, 还需要聘请 DevOps 工程师然后找到合适的服务器. 对于小型游戏工作室来说, 这无疑是一笔巨大的前期成本, 并且早晚都要支付.
所以 SaaS 服务可能是更好的选择. 使用合适的 SaaS 解决方案, 您只需按使用量或 CCU 付费, 在游戏上线初期费用很低, 而当游戏越来越受欢迎的时候轻松扩张. Colyseus Arena 就是这样的解决方案, 专门设计用来运行游戏的 Colyseus 代码.
- 保持简单 -- 这可能是我们为 MMO 游戏开发者给出的最重要建议. 开发多人游戏的新手很多都着眼于消息发送和游戏的复杂度上面. 我总是建议他们尽快制作游戏原型或 MVP. 然后进行游戏测试, 确保游戏体验, 然后将其作为模板, 以更有效率的方式重新创建游戏服务器/客户端. 这种二次开发中往往更有效率.
Colyseus 未来的目标是什么?
我们的目标一直是做你想要的 “那个” 服务器. 我们从社区获得的请求大多是支持 WebSockets 以外的其他协议, 比如 rUDP 或 WebRTC. 另一个对我们很有意义的请求是提供一个实体-组件模式. 我们一直在倾听社区和客户的更多建议.