《原神》大家肯定都很熟悉了，自去年年末上线以来就引得无数话题，首当其冲的当然还是动画风格的“救公主”游戏，哦不对，应该是《原神》的二次元画面吸引眼球啊，对对对，就是因为画风和元素机制吸引眼球，果然当时上线之后霸占了8国下载榜首，时至今日，《原神》已经是在国内外的二次元游戏市场站稳了脚跟，除非…除非出现下一个超级二次元游戏才给能《原神》来个“千年杀”！
那么要给《原神》一个“千年杀”，首先要做出和《原神》差不多的游戏吧，咋就没人做出类似的《原神》的竞品呢？
“那是因为我只会打字”
其实之前有很多大咖对“做一款《原神》难不难”这一话题有过争议，一派说“《原神》呦，那可难死了，地狱级难度，别想了别想了”，另一派说“不就是抄个代码嘛，难个der”，所以到现在咱也还是一头雾水，咱不懂，咱也不敢说。
诶那我们今天就从技术层面来聊一聊，要做出一款和原神一样的游戏，到底难不难！
Round 1：元素反应机制
玩过《原神》的小伙伴应该都知道，游戏中有7种元素相互反应（草元素暂未实现），不同的元素相互会有各自的元素反应，这就属于Gameplay游戏逻辑层面，采用状态机模型，可以在AbstractEntity（Fabric/Yarn命名方式）类里实现。
有人说这不就是游戏里常见的Buff嘛？程序员表示：“我可谢谢你！”
这东西像Buff，实际上又有很大区别，大多Buff是数值上的加成变化，而元素反应可以对人、物、地表、海水等等，相比而言比Buff的要求会细致很多，我们举个栗子！
游戏中风属性会扩散，这时有三个史莱姆分别附带水、雷、冰属性，想要过来啃死你这个小萌新，这时候温蒂一个大，你猜猜这个大会扩散哪一种元素？
哎呦这个复杂，这不是概率问题嘛？难道你想套路我！
其实也没啥毛病，当游戏机制复杂到一定程度，就可以像这样来霍霍你了，当两个属性冲突时，你猜电脑会不会死机？
这就是所谓的“机制冲突”了，那想要解决机制冲突，当然是要把我们的秃（资）头（深）程序员搬出来，搞一套非常严格的代码参数来控制这个元素反应，设定触发的优先级和条件，附着量、消耗量、阈值和CD等等等等…光这个就比开发Buff带感多了，要是每个游戏都这样做，那程序员的头发可是一把一把一把一把掉啊。
Round 2：动作ACT
在这个游戏里，动作ACT其实就是美工+程序的结合，在玩家操作时，我们要给指令加上优先级，设定高级指令可以覆盖低级指令，比如你在做出一个攻击指令时，我们在画面中看到的是一个流畅的攻击动作，实则已经完成了4个分解动作，分别为：动作开始的起始时间、动作执行时间、动作完成时间、下一个动作的衔接时间，如果超过了衔接时间，那人物动作就会被重制，也就是我们看到的普通站立状态。
技能层面中，设定技能释放不能在动作执行时间内，但可以在动作开始前和完成时间内释放，大招的释放则不会受到这个设定的限制。《原神》中的重击也属于技能范畴内，因为在重击时不能释放技能，这样看来的话，技能层面的优先级就是重击>战技>爆发，但技能层内部也是会有优先分层的哦，关于这技能设计这方面，我想育碧和卡普空应该很懂吧！
加在最高指令下面的还有强位移指令，比如躲避、跳跃等等，用户会根据实时状况做出应对的技能，当然，这个指令的优先级肯定是在技能指令之上的，玩家也不会遇到一个打不过的怪还要硬打吧，当然是先跑为上啊！
那最最最最高级的，就是挨打！游戏里难免会有小丘丘跑来偷袭嘛，那难免就会受到攻击，抛开无敌帧，挨打会终止一切动作，管你在释放技能还是干嘛，通通没有用！
要小编说，其实受到攻击也不是最高级指令，毕竟ESC才是永远的神！
你感觉看了这些之后也能做出一款动作游戏了？
那我问你，发动一个大招要多少秒啊？分配到每个层级是多少秒啊？普通攻击和大招攻击的时间差距怎么安排呐？指令覆盖多少时间最为合理？
数值&战斗策划+美工：“来人，给我拖出去斩了！”
Round 3：卡通渲染
我们都知道《原神》是基于Unity 制作的，Unity本身是有一套通用的渲染管线，但你仔细看《原神》这个渲染效果，是单单普通通用渲染管线能做出来的嘛？（没有贬低本身渲染管线的意思！！！！！大佬求放过）
其实是米忽悠花重金！哦不是，花重功夫，对Unity引擎之下的渲染进行了魔改，定制了一套渲染管线，让它多线程作业，整合成一套完整的，适合自己项目的开发工具就很难了，这里不得不膜拜一下引擎程序员，他们不但懂代码、数据模型，还有图形API、Shader，更更更重要的是，他们在数学这方面那也是一顶一的强，这里特别指高数，大佬，收下小编的膝盖吧！
一款游戏如果涉及到渲染管线，那么制作这款游戏本身的难度就已经提高了，如果一个普通程序员说渲染不难？那小编只能弱弱的说一句：是的，你最厉害！
Round 4：性能优化
程序员们都知道，游戏人物模型其实在一开始做的是很精细的，但是至于为啥我们在手游上看的到人物仿佛卸了妆嘞？
之所以这样就是因为两大原因，一个是Unity本身卡资源，另一个是因为手机真的带不起来啊，这让程序员可头疼死了，诶？你问小编为啥知道？别问！问就是小编去当卧底了！（bushi）
于是乎就涉及到了性能优化这一点，江湖上有这么一个传言，在最初版本里故意写延迟，然后在后续版本中优化，把原有的延迟降低，哦吼，这样一来就觉得“诶可以了！”，程序员在这里含着馒头落泪，不容易啊，为了一口馒头不容易啊！
这怎么仿佛看到即将到来的双十一大促（其实还早），先把商品价格提上去，然后和你说打折，这路子，早就被我们程序员玩烂啦！
比如在《原神》中的一个优化小编觉得很有意思，凝光旗袍的裙角会随着走动而做出飘扬的感觉，你以为这是物理作用嘛？并不是！其实这是用布料解算预先做出来的效果，让你视觉上认为是根据动作或者环境问题影响的。
在设定的情况下播放效果，这样不仅可以避免穿模Bug，也能节约资源，平时在游戏中也看不出什么破绽。!
你不知道的是，手机电脑壁纸上的鹿鸣小姐姐，也是通过这一点实现的哦！
但米哈游在《原神》的优化，并不是靠着衣服，毕竟Unity这座大山就不能让你轻易翻过，能有这样的优化效果，其实还是得益于那套定制的渲染管线，资源的损耗就变成了可控可改的，这是Unity本身不具备的，所以才能让《原神》在开放世界中的深景和内存管理得到很好的提升，或许你没有注意到，从高空中看脚底的树可能是贴图效果哦，这就是对加载资源剔除效果最直接的体现。
听起来好像只是像加载和存储一样的操作，但是实际操作起来难度是非常大的，《原神》能做到目前这种流畅度确实是很不容易，而且在Unity定制底层之后，就要和一键移植多平台功能说拜拜了，就想知道，米忽悠《原神》组的程序员们，当时是不是含泪加班？
以上四个回合直接给各大有想法的制作人KO到体无完肤，毕竟人才+金钱缺一不可嘛，也期待各大厂商或者独立游戏人早日开发出《原神》之上的优秀游戏哦，溜了溜了~
后续我们还会以专业的游戏开发角度去剖析热门游戏，有想要学习专业游戏开发的小伙伴可以私聊我领取游戏开发学习大礼包一份哦（包含2021 新版C#入门课程、U3D攻城狮面试题大全，热门小游戏原素材等），欢迎大家一起来学习！