|
Unity 的缺点很多, 比如 Bug 多, API 设计不优雅, 脚本系统性能差又不好用, 奇葩的组件设计, 蹩脚的输入管理......(详见吐槽) 好在其中大部分官方都表示正在或将要改进.
但是我们还是选择 Unity, 因为开发者对引擎的了解程度比起这个引擎是否完美对项目来说更加重要. 之前有考虑过 Unreal, 但谁能保证用 Unreal 就比用 Unity 开发效率更高, 质量更好呢?
如果说要选择其他引擎, 那么原因肯定是 Unity 存在对项目来说难以克服的问题. 好在目前还没遇到, 而且也有其他成功的游戏验证了 Unity (这些开发者被坑的飞起了吧).
吐槽1: Unity bug 多有目共睹, 它们一般 20 天就发个大版本, 如此快速的迭代后果就是不稳定, 经常还发生设计变更, 实在是......
吐槽2: 那个 sharedMesh 和 sharedMaterial 真是够了, 而且还有 sharedMaterials 这样的返回堆对象副本的 API......
吐槽3: 所有的事件回调都塞进 MonoBehavior, 既不好看也不好用. 官方说正在设计新的事件解决方案, 坐等.
吐槽4: 内置组件, 该序列化的数据不序列化, 比如 Rigidbody, 默认质心和惯性张量自动计算, 即使脚本访问修改了数据, 复制这个物体后, 质心和惯性张量还是自动计算的.
吐槽5: ......
再补充几个 Unity 的编辑器的坑吧:
编辑器 API 里各种裸 delegate 访问, 加个 event 不好吗, 某个程序员直接对 delegate 赋值其他人代码就全挂了;
编辑器里很多返回引用的 API, 上次看到一个插件, 那个作者直接修改编辑器风格, 自己的插件看起来正常了, Unity 的界面坏掉了;
写编辑器看起来不是很难, 难的是处理 Undo/Redo, 默认的 Undo 解决方案是针对序列化数据的, Undo/Redo 触发时 Unity 仅对序列化数据执行修改, 其他非序列化数据一概不管. 做个稍微复杂的的插件, Undo/Redo 就能烦死人了;
Editor 设计为特殊目录, 里面放 Editor 代码. 看起来很美好, 实际上很傻. 编辑器少不了要访问私有成员, 而且 Editor 代码不能被 Runtime 代码访问, 最后还是用 UNITY_EDITOR 包起来写到一起算了(有个小技巧, 使用 C# 的 partial 关键字来分离编辑器代码是个不错的选择);
谁能告诉我 Gizmos 和 OnSceneGUI 的本质区别? Gizmos 类不能在 OnSceneGUI 里使用, 但是它们明明看起来是一种东西; 而当你折叠一个组件后, 所有同类组件的 Gizmos 就看不见了......这个设计我始终不能理解......
再补充个: new GameObject 时, 这个 GO 属于哪个 Scene ? 新的 SceneManager 也没有解决这个问题.
成功游戏案例:
The Forest on Steam
Republique on Steam
Cities: Skylines on Steam
Ori and the Blind Forest on Steam |
|