boardgame.io用于Unity的工程实践方案【暂时半途而废】

前言

用Unity开发网络游戏时，Server端的实现有多种选择。由于unity官方自带的UNET多人联机模块停止维护，并且在将来的版本将弃用，新的联机模块尚未发布，所以目前unity上做多人联机一般用第三方方案，www.photonengine.com的photonEngine就是一个比较专业但收费的unity多人联机解决方案。

boardgame.io 是 Google 开源的一个游戏框架，免费、开源，所以看起来比较有前途。boardgame.io实现于node.js中，对于仅用到node.js的游戏开发是非常友好的，但对于Unity前端或其它什么前端，官方没有提供，似乎也没有先例。目前的boardgame.io可能就是一个小众的框架。boardgame.io如何用于Unity，应该是与node.js的其它各种库如何用于Unity一样的问题。

我们深受Windows的毒害，白白浪费了大量的精力去学习微软过时的技术。与Linux一起萌生的开源活动终于颠覆了封闭的软件行业，现如今诞生的技术已经实现了前人搭积木的思想，无论是node.js，python，还是C#，等等，都有大量软件构件供我们极其方便地重用，极大地提高了软件开发效率。感谢开源！有感于此，从今而后尽量把学习实践笔记放到网络上共享，既是分享，也可以用于自查，何乐而不为？但既然作为笔记，可能难免零碎。

boardgame.io-client用于Unity的工程实践方案

任务

核心任务是研究如何把应用boardgame.io实现的Server与Unity做的Client关联起来。为了达到这个目标，首要任务是研究学习boardgame.io的应用开发，对其有某种程度上的认识。为了达到这个目标，可能需要研究学习boardgame.io的源码，需要研究学习C#调用JavaScript的办法；可能需要改造boardgame.io，或者是在boardgame.io的基础之上另行实现C/S交互，或者，等等。

方案设想

boardgame.io同时实现browser端和server端的代码（这正是node.js开发的优点），用node.js实现游戏的browser端非常方便。但是现在要把browser端换成Unity做的Client，用什么样的技术方案好呢？

经过一周的初步学习，有了一些认识。初步了解到boardgame.io实现于node.js中，官方没有提供非node.js实现的软件与boardgame.io协同工作的方案/文档。

Unity前端内嵌web插件容纳boardgame.io的browser端代码可行吗？

这样不需要考虑C/S交互，仅需考虑C#调用web插件来控制JavaScript了。但是，游戏要发布到Android和IOS，web插件是否同时实现多个平台，web插件不一定稳定可靠，调用web插件来控制JavaScript几乎没有先例，并且实践经验表明存在各种潜在隐患；等等。

Unity中可内嵌的web插件：（1）Embedded Browser插件，不支持android、iOS、UWP平台，仅支持PC端（2）UniWebView插件，适用于Andriod、ios和Mac os，据说在移动端效果最好，不支持windows PC，收费约30$（3）UnityAndroidWebviewToTexture插件，似乎仅支持android（4）3D WebView插件，功能强大，各种平台都支持，但收费贵，且按支持平台收费。

排除这个之后，可行的方案似乎只能是在boardgame.io的基础之上用webSocket另行实现C/S交互了。但这样一来，C/S交互要考虑接口定义与实现，要考虑C/S接口调试，想想也就够麻烦的；boardgame.io被弱化成了一个游戏状态管理器，与服务器交互这个最重要的功能被丢弃了。

近两天又酝酿了两个方案。

其一，在Unity前端并不需要渲染网页，仅仅执行JavaScript就可以了，所以不必内嵌web插件，直接找一个可以执行JavaScript的通用.net库似乎就可以了。初步了解了一下，V8.net功能强大（有这个是不是就可以直接运行node.js开发的东西了？！），但体积比较大。体积比较小，用的也比较多的Jint似乎可以考虑。这个方案需要用最简单的方式验证一下。该方案符合短平快的方针，但可能因JavaScript引擎而存在一些不可靠的因素。

其二，研究学习boardgame.io源码，将其Client代码移植为C#代码。这个方案也不需要另外考虑C/S通信问题，移植即实现，且C#端直接实现的boardgame.io客户端库可以作为可复用构件被反复使用。这样做的话，我就打算建boardgame.io的C#客户端开源项目了。嗯，不但可用于Unity，还可用于一切.net环境，似乎是个很好的想法。

总之，现在可以考虑的方案有：

1）在boardgame.io的基础之上用webSocket另行实现C/S交互，把boardgame.io弱化成游戏状态管理器。

2）C#调用跨平台的JavaScript引擎执行boardgame.io的代码，把boardgame.io当作黑箱让其自己去同步C/S状态。

3）将boardgame.io的Client代码移植为C#代码，形成构件，一劳永逸，开源共享。

方案整理

从上图看，要想从Unity做的客户端中获取Node.js中的boardgame.io Game状态，按照对boardgame.io的弃用力度从低到高，有以下几种方案：

1）不对boardgame.io的功能做任何改变，在客户端建立一个JavaScript运行环境运行boardgame.io的client部分，通过JavaScript引擎与boardgame.io交互来取得game状态，响应game状态更新事件。这个JavaScript运行环境可以是浏览器或者Chrome V8引擎，也可能可以是纯正的JavaScript引擎（无UI渲染）（包括Node）。这种情况下相当于对上图中的Game状态接口层又封装了一下，或者说作了一个JavaScript到C#的接口转换。

2）不要boardgame.io的client部分，直接用C#重新实现Game状态接口层和通信同步层。这个方案难度大，但一劳永逸，可以形成boardgame.io.client.net这个可重用构件。

3）不要boardgame.io的client部分，也不要Server端的通信同步层，通信同步另外用websocket实现。坏处是开发工作量应该是更大，C/S通信同步的调试难度大，且不标准不通用，对于其它项目也无法拿过去直接用。好处是上手快，随心所欲，C#端要做成什么样就做成什么样。这个方案仅仅利于boardgame.io来管理游戏状态，要处理繁琐的各方状态同步问题。

4）不要boardgame.io，这样想怎么做就怎么做。但是工作量最大，相当于自造轮子。

所以我的倾向是先尝试第一种方案。不行再尝试第二种方案。

对于第一种方案，又有多种思路：

1）利用浏览器插件。有for C#的，也有直接for Unity的（例如Embedded Browser、UniWebView、UnityAndroidWebviewToTexture、3D WebView，可在Unity Asset Store搜到）。有免费的，但不好用；有功能强大的，但收费贵。本项目既然不用，就不进一步研究了。

2）利于移动端Node.JS库。这个有可能是最好的方案了，应该是只要能在node中正常执行就可以通过这个库来执行。坏处可能是体积大了点，效率低了点。参考在你的ios、android应用中嵌入官方版nodejs是什么感觉？ - 知乎。

3）利用JavaScript引擎。例如ChakraCore, Jint, Jurassic, MSIE JavaScript Engine for .NET, NiL.JS, Jering.Javascript.NodeJS, Microsoft ClearScript.V8, VroomJs and YantraJS。既然用.NET，那么我首推Microsoft.JSInterop，但它只能用于.NET 8，这条路对于未来的Unity可能是最好的。

时间精力问题，我仅尝试方案1.3（可能踩坑失败），不打算尝试方案1.2（尽管它看起来可行性更好）

尝试用JavaScript引擎执行boardgame.io-client

步步推进过程：

1）学会用vsCode调试JavaScript，包括node中运行的CJS和ESM代码、Chrome浏览器中运行的的代码、TypeScript代码。成功。

2）尝试在node中而非浏览器中运行boardgame.io教程Client。成功。

3）找到一个JavaScript.net引擎，在Unity APP中运行简单的JavaScript脚本。用Jint实现了，并且在手机上测试了，成功。

4）用Jint尝试运行boardgame.io教程Client。经过先期试验，首先发现必须支持XMLHttpRequest和WebSocket，进一步发现boardgame.io这两个包用到了很多node.js核心模块，所以只能考虑在Jint中支持socket.io。目前还在试验中，看起来难度比较大。

尝试暂停到此中止。