[业界新闻] 拷问Unity:开发U3D游戏要思考的问题

昨日gamelook曾就某投资人把移动团队失败原因之一归于选择Unity引擎进行了一番评论，工具本身无罪，但如何理解工具、正确使用Unity引擎确实需要讨论，在选择Unity之前你或许需要了解下这个引擎实际开发过程中的技术特点、以及适应的游戏产品类型，gamelook热心读者Fxcarl昨天就这个问题专门撰文一篇，来帮助大家了解Unity游戏开发、分享心得，推荐阅读。

如果有技术大牛看到不妨也发表下观点，帮助大家更好的理解Unity，欢迎投稿( news@gamelook.com )

文/FXCarl

代码驱动带来的技术题

游戏碎片化。U3D 引擎有个很有力的特色，就是实时编译运行。这意味着无论在任何时候，只要按下运行图标，当前的场景就会进入可执行状态。这导致了游戏在开发的过程中经常陷入一种不应当的自信状态。同时也导致了游戏内容长期处在碎片状态下，并低估游戏功能整合时可能遇到的困难。

资源管理是 U3D 引擎的一个难点。U3D 的资源管理系统因为跨平台的缘故和操作系统的文件系统是脱钩的，需要熟练的掌握 Resources 目录和 Assetbundle 的技术才能灵活的控制游戏中的资源使用情况。但这一工作时常会被简单的理解为将资源放置在游戏工程目录下，剩下的交给引擎自己搞定 ……

需要自己做数据系统。我们如今国内研发的作品，绝大多数是数据密集型（策略、经营、卡牌、KRPG），这和 Temple Run 这样的游戏类型有些不同。数据密集型的游戏需要采用数据驱动的形式来进行游戏的设计和开发，但是 U3D 提供的框架是一个代码驱动型的结构（对于原型开发来说极为有力）很多时候会让研发团队陷入泥潭 —— 看起来功能开发出来了（只要在U3D的对象检查器里调调参数就能工作），却迟迟无法进入大规模制作阶段（策划拿着数据表格却无法应用到游戏里）。U3D 引擎本身也没有提供任何在数据方面的支持，数据表要么需要自行处理，要么需要自己寻找嵌入式的数据库解决方案。

网络连接部分其实也是类似。U3D 本身集成的网络模块并不是为大规模 C/S 结构的游戏所设计，常需要自行开发一套客户端和服务器结构。当然也可以求助中间件来解决 …… 但是容易让人迷惑的地方在于，U3D 既可以使用 .net 的网络机制像端游一样工作，也退一步可以用加密的 www 机制，当一个简单的页游来处理。如何抉择是个难题，贸然贪多求全往往换来遥遥无期。

测试 U3D 开发的游戏亦一个很麻烦的过程。原因也是那个几乎不会崩溃，随时可运行的场景/逻辑混成编辑器 —— 它会让开发团队误算自己当前的游戏完成度，以及需要什么样的测试。

尖端技术带来的麻烦事

高精尖的动态光照和复杂材质系统。U3D 比起其他的移动平台或者网页游戏开发工具而言，往往最打动人的就是其无与伦比的画面渲染效果。但是在光鲜的官方演示背后，仿佛总有看不到的壁垒阻碍着其他开发者的步伐。实际上驾驭 U3D 所需要的能力是超乎一般想像的。U3D 的渲染架构的确够强大，完成 Unreal 甚至 CryEngine 级别的画面渲染质量都是可能的，但是它并没有包装这些系统而是将灵活性交给了开发者。我们的程序员是否已经控制住了渲染管线的复杂度？我们的技术美术是否可以指导我们的美术完成充分发挥 U3D 能力？美术制作人员是否有具有胜任所谓“次世代”精度要求的游戏内容制作？这些东西属于小团队吗？

全局光照烘培。这是一个非常非常非常实用的 U3D 功能。理应所有的 U3D 团队都灵活使用。但是想要用好就有了另外一番难度 —— 美术和场景制作人员的配合，而谁来负责就比较难说了。另外美术必须用非常精准的尺寸来制作场景中的物件，否则 U3D 将无法正确的处理全局 UV。

工具链带来的纷纷扰扰

GUI 系统的各种理论。所有人都在吐槽 U3D 自带的 GUI 系统太慢 —— 问题是真的有证据吗？一方面很多人说我做测试的时候做了一大堆的控件，的确很慢。另外一方面大家也会发觉 GUI 系统会带来一些不必要的渲染请求（Draw Call）。于是大家都在拼了命的做两件事情，一个是减少渲染请求，一个是想尽一切办法的避开 GUI。但其实情况没那么严重，无论是挑选替代中间件如 NGUI 还是直接使用 U3D 的 UI 系统都不会巨大的影响 —— 除了不当使用之外极少见到 GUI 成为性能焦点的时候。不过无论是 NGUI 还是 U3D 内置 UI 都没有很好的 UI 工具 —— 要么过于程序员导向，要么过于偏向布局而不方便增加代码功能。内部开发一些扩展工具或者工作流程都很有必要。

版本控制的难题。Asset Server 还是 SVN 其实多多稍稍都有不适应 U3D 的情况。但是更关键的地方在于整理好文件的内部结构以及经常备份。恰当的使用 U3D 的命令行模式可以实现 U3D 工程的自动编译发布。

扩展 U3D 本身功能的能力。因为 U3D 较为完整的功能而忽视对 U3D 本身的功能拓展是一种常见状态，随时保持专人不断的优化 U3D 本身的功能是非常重要的，譬如各种各样的批量化操作等等。但是这有个前提，扩展工具需要充分理解工具，U3D 相对来说功能过于强大，以至于很多团队中的成员会害怕学习，而将 U3D 作为少数团队成员或专属于程序员的工具 —— 这就很成问题了。

需要前瞻性的判断能力

每一个，每一个国内开发 U3D 游戏的团队都在抱怨 U3D 的中文字体支持问题等等。可是实际上真正用前瞻性的角度在使用 U3D 引擎的团队并不多 —— 以今天此时此刻为例，U3D 4.0 已经可以在任何平台上使用动态的字体，支持 Unicode 编码 —— 中文不在话下。从 U3D 3.5 迁移到 4.0 几乎不用对项目做任何的修改，而如果说之前并不知道 4.0 会支持动态字体的话，那么为什么不多去官方论坛关注一下每个版本的开发进度情况呢？每一个在 2013 才会发布的游戏都不应该担心字体问题才对嘛 ……

保持对每个版本 U3D 更新内容和未来 U3D 功能的关注可以大量减少重新发明轮子的问题，也能在遇到一些困境时保持更好的心态。直接邮件开发者也会是个很好的选择，请一定要多骚扰他们！一般提前3个月到6个月就能获知将来版本可能更新的内容的。

1  “Code-Driven”
State Management
Assets Management
Data Management
Networking
Testing

2 CuttingEdge Techs
Dynamic Lighting & Complex Materials (Textures)
Lightmapping
Nav mesh
Mecanim
DX11

3 Toolchain
GUI
VersionContorl

4 Vision