先上预告片
https://youtu.be/Z7-V0FyylOQ
游戏内容介绍等就不细说了影片下方有Steam等其他更多资讯，下面就来随便闲聊开发过
程的一些想法
这个专案从四月中开始到现在，今天在Steam上以Early Access的方式释出了。
自己一人做独立真的是各种包办，自己要建模，各种收集素材（音效，UI等），还要码
程式码，Rigging, Animation，人力不足下真的是越做发现越多东西要做XD
此游戏采用Unity2019.3引擎，只能说HDRP真的坑蛮多的很多出乎意料的结果，像是loa
d场景后(additive)，场上本来有一个enabled Camera1 ，load好等几秒关掉1，再enab
le另一个Camera 2，结果两个看到的画面会不一样...，2会变成有问题desaturated的感
觉，怀疑是场景load好时Unity的自动绑Camera 1去做了啥。还没时间确定是不是PP的问
题就是。VFX Graph也是各种神奇异常，Editor看到和Build版还会出现大差异，只能说
Unity现在就算不是Preview的Package都要当成Preview来看XD
多人网络解决方案，嗯UNET死后，当然不是使用Unity那个从2018遥遥无期的ECS不明网
路深坑，而是采用开源免费的Mirror 当作HLAPI （RPC, SyncVar等)配上 Steamworks当
作他的Transport layer，Mirror的底层Transport LAPI只是抽象的Interface，所以可
以自己实现或是套用各种现成Transport像是Telepathy.
Mirror这方面相比以前用过的Photon Pun 相对好很多，不用被绑在Photon公司上面，然
后Steamworks又可以免费白嫖帮你relay XD 再来是他有非常强的Server Authority架构
，不像Pun可以让你的Client互相Rpc来Rpc去。这方面想说一下做独立小游戏真的别想太
多，快速做出东西来才是重要，一开始想说FPS游戏要啥网络防Hack，搞成Server几乎拥
有所有的Authority，像是移动是由Client发Commands给Server，而Server去验证更新移
动Client，缺点是，做到一半很快就发现这样会超级LAG，就算Steamworks transport底
层走UDP channel也是一样没改善，最后只好巴不得去做Client prediction和Server r
econciliation。但这样不如一开始好好给Client移动的全部Authority就好，还不用搞
得这样灰头土脸花费大量时间，玩家Client端也开心不会有Lag操作感，而且只是个小独
立游戏也没人想Hack你吧，所以真的别想太多，快速做出来好用的东西才是真的，不要
在那自嗨啥Server Authority架构，玩家架构才是真的。（而且Server Authority还是
可以骇啊）
预告片都是用Unity Cinemahine 去做的，这个Package很棒，终于不是Preview级别。
再来说到建模，游戏中的NMSL建筑，NMSL树，爆炸特效，地形等都是用Houdini(以下简
称H)去做的，效果方面不外乎是Vertex Animation或是在模型的UV2, Vertex color乱塞
我需要的资讯。
而关卡设计也是H去产生的，这方面是在H建模建筑后，直接利用建筑的几何资讯，顺便
在H里面定义所有怪物出生点，道路指示路径，道具掉落位置和挖大楼的楼梯位置，摆放
楼梯。而在H18里已经可以直接将任意H定义的资讯导入Unity，所以只要写个Script导入
Unity后用ScriptableObject保存即可。
但这样产生的Level缺点很明显，这种自动化生成的Level缺乏人为刻意的设计，就像自
动产生的故事一样，终究还是要一个Level Designer来好好设计游戏才会好玩，（没人
力啊没人力QQ），所以未来Level Design还是倾向于人工设计，自动化程序生成只是人
手辅助，最好是，用H做一些方便人手设计方便的工具就可以，像是人手指定位置，而自
动挖大楼地板放楼梯更新模型。但还是需要人力啊.
神智有点不清所以中文可能不是非常顺，先打到这里累了要睡觉
Leonard H.