Unity —— 从UE4到Unity的转变和思考

这篇博客记录了我接触并使用Unity后，就使用过程中遇到的一些问题所产生的思考和想法

---

背景

到动笔的日子（2017/04/19），也刚好跳槽满半个月了。新公司的项目所使用的游戏引擎是Unity —— 这也就意味着我需要抛弃使用两年半的UE4，进而投入Unity的怀抱。经历了磕磕绊绊的探索之后，我个人认为自己对Unity已经基本上手，这篇博客也就用来记录一下一个Unity初心者产生的想法吧……

开发流程的转变

开发流程的转变对我的工作内容影响不能算大 —— 以前相对来讲团队更小的时候，作为主程我必须要时时关心整体的开发流程，而现在我需要的是沉淀，因此开发流程对我的影响并不太大。但我还是想聊一聊这一块的东西：

UE4的开发流程（自认为合理的开发流程）

就UE4来讲，由于Blueprint的横空出世，因此开发业务逻辑的难度空前降低，低到只要有正常人的智商都能够快速实现各种基本的业务逻辑开发。

但是由于Blueprint一来速度较慢（官方曾经承认至少慢10倍，不知道这个数值现在是否有优化……），二来不好维护，三来Debug操作极为繁琐，因此Blueprint更加适合于设计的验证、原型Demo的开发。当设计想法验证完成后，往往由程序来进行功能的拆解和重构，将其转化为C++代码（有些团队会使用Lua绑定，也是很赞的方向……），也方便日后进行优化。

因此我个人认为比较合理的团队开发流程如下：