瞎折腾：用Unity撸纯HTML5移动游戏/应用

XU许

这两天灵机一动，概略折腾了个demo


效果上有点像Unity本身家的Project Tiny那样，Build之后得到的是一个纯HTML5的前端应用。




不外分歧于Tiny，我们这里设计的还是相对传统的GameObject+组件这种开发方式：场景->GameObject->组件，而非DOTS那套。
使用GameObject 挂在组件的方式编纂场景，编写C#代码，并在构建时导出HTML应用。
因为暂时没筹算把它做完，就压根没往GitHub上整，概略写点东西 算是记录一下：
<hr/>首先是概略思路：
这玩意其实相当于是一个独立的引擎或者说框架了，和Unity的Runtime基本上不妨。目前大体上可以分为两个部门：
一个是核心模块(core)，这部门是一个独立的、与Unity无关的独立工程，由C#和TypeScript编写。在核心模块中，有一套从头实现的GameObject和Compoment的机制。核心模块可以直接用来编写业务逻辑并构建HTML应用，不需要编纂器。



直接用core部门编写业务

另一个部门就是针对Unity的扩展，把core部门的东西和Unity关联起来。
在应用构建时，Unity的扩展部门会把在编纂器中编纂的场景、Prefabs等内容读取出来，存储成Json放进HTML应用的资源中，（我们暂时在HTML应用中把Scene、Prefabs什么的都统称为Stage），然后在浏览器中运行时，Core会把各种GameObject按照JSON加载出来并挂在Components，由Core来维护整个应用的生命周期，并把需要显示的内容绘制在Canvas上。
所以，虽然说是用Unity开发HTML应用，但基本上和Unity本身没啥关系了，只是借用到了Unity的编纂器。而在应用运行时，就是个纯挚的HTML应用了，就没Unity的事了（其实Tiny之前还是TypeScript的时候也是这么干的，此刻不清楚，还没细看过它的实现）
<hr/>也正是因为上述的道理，所以我们在实际写业务逻辑的时候，需要把我们的业务代码和Unity的内容（UnityEngine定名空间等）明确的分隔开。同理，在编纂场景的时候，我们也不能挂载Unity提供的组件（目前Unity的Canvas等几个组件除外，导出的时候会自动忽略）。
也就是说，MonoBehaviour也是不能用了。我们本身实现了一个Behaviour类，用宏定义符号做了分隔：在编纂器下，担任自MonoBehaviour，以便我们在编纂器下挂在组件和调试。而在构建HTML应用时，MonoBehaviour部门的东西就会被剥离，由Core来打点这些组件。



从头实现的Lable组件（demo阶段，所以功能贼少）

（在编纂器中调试这件事，目前的设计是用宏定义在编纂器下担任Unity的组件，比如目前的Lable在编纂器下会担任自UnityEngine.UI.Text，这样做的目前的借用Unity的Runtime来调试应用，另一方面可以直接用Unity直接的方式构建App。当然目前这个想法有没有什么坑还不知道，还没往下深入的做，没遇到坑暂时。）
<hr/>浏览器里运行C#的问题：
折腾这玩意，最底子的目的是我想用C#写HTML5应用玩。所以浏览器里跑C#的问题就必然得解决了。
常见的方式有两种，一个是WebAssembly，另一个是把C#翻译成JavaScript.
权衡了各种因素，目前的实现的demo中选择了后者，我们在构建应用时把C#翻译成了JavaScript. （但其实直到此刻对于两者的选择还是摇摆不定）
这里使用了开源项目http://Bridge.NET来实现这个功能。 把C#翻译成JavaScript在目前最大的好处是包体极小，兼容性较好，GC什么的问题也不大。
<hr/>待续（如果有继续往下折腾的话，待续）