《多元窗口》技术方案 - 本地热更新

《多元窗口》这样的多进程多窗口游戏在Unity中不仅实现复杂，调试复杂，就连预览也复杂。其他游戏只需要点击编辑器的播放键，就可以直接看到游戏的预览。而我每次修改哪怕一丁点内容，也要大费周章导出整个游戏才能知道结果，每次导出都起码要1分钟，对修bug与关卡设计都十分不友好，我就想在复杂关卡的设计前解决该问题。

不同于旧版本的场景切换，我在新的程序框架中把所有关卡都以预制体的形式保存，并且我还用了Addressable进行管理。而行业里确实有一种办法可以让一个已经导出的游戏可以动态更新部分内容，也就是“热更新”。保持游戏打开的情况下更新游戏的文件，并在加载时应用更新的文件，不仅可以快速更新游戏内容，还可以节省空间占用（需要的时候临时下载）。不过传统的热更新大多用在网游与手游中，在单机游戏中通常没什么热更新的必要。但《多元窗口》和手游一样具有需要导出且测试麻烦的特性，倒是恰好用得上这个技术。

Addressable是Unity自带的一个极其好用的资产管理插件，并且内置了本地和远程热更新的功能，甚至还包含了一个简单的服务器托管。不过我就用不到远程了，我选择在本地的一个新的文件夹设置了临时仓库，用于游戏关卡文件的构建与加载。加上这些，只要build addressble的资产就可以快速应用到已经导出的游戏中了，起码节省了大量时间。

不过，导出给玩家游玩的游戏可不能从这个临时仓库加载内容，毕竟玩家的电脑上是不存在对应路径的，所以还需要两种不同的模式。Addressable倒是好说，本身带有profile，也就是可以提前设置好模式，需要的时候切换即可。但是每次build的时候都要考虑当前是用于测试的还是给玩家玩的，并去修改addressable的模式。虽然也不复杂，但是未来难免出现哪天忘记切模式的情况。所以，我还研究了如何确保万无一失。

我一开始想到了配置构建文件，这应该是Unity 6新增加的内容，允许开发者设置很多种不同的导出方式，应对多种不同的平台。我新建了一个测试专用的配置文件，并在里面加上了Test的标签，只要导出的时候读取一下标签，动态切换模式即可。

这套方案还挺成功的，但是坑人的Unity可没说切换配置文件的时候比导出更久。只要点一下开关配置文件，就约等于重启一遍Unity引擎，起码三分钟过去了，而正常导出不过也就一分钟多。完全不理解为什么同一个平台之间切换会这么久，总之这个方案特别失败。

然后我就想起了《Cato》作者在机核分享的插件，里面有一个Build Manager，说不定能帮上我的忙。省略不知道多久的调试、看源码、改功能，很遗憾，这个完全不适应我的游戏情况，更多是为了多平台服务的。图上这个Scripting Defines完全是陷阱，比Unity自带的还难用。最终我还是返璞归真，自己造轮子去了。最终的方案就是利用BuildPipeline.BuildPlayer，为测试版本专门写一个不一样的导出按钮，然后在用这个按钮导出的时候顺带切换addressable的模式。

眼下《多元窗口》正在推翻之前的设计，制作更加独特的内容。希望能在不久的未来让各位能在试玩版中玩到完全不一样的内容。