![U3D游戏开发商思考-LMLPHP]( "U3D游戏开发商思考-LMLPHP")
代码驱动带来的技术题
游戏碎片化。U3D 引擎有个非常有力的特色，就是实时编译执行。这意味着不管在不论什么时候，仅仅要按下执行图标，当前的场景就会进入可执行状态。
这导致了游戏在开发的过程中常常陷入一种不应当的自信状态。
同一时候也导致了游戏内容长期处在碎片状态下，并低估游戏功能整合时可能遇到的困难。
资源管理是 U3D 引擎的一个难点。
U3D 的资源管理系统由于跨平台的缘故和操作系统的文件系统是脱钩的。须要熟练的掌握 Resources 文件夹和 Assetbundle 的技术才干灵活的控制游戏中的资源使用情况。但这一工作时常会被简单的理解为将资源放置在游戏project文件夹下。剩下的交给引擎自己搞定 ……
须要自己做数据系统。我们现在国内研发的作品，绝大多数是数据密集型（策略、经营、卡牌、KRPG），这和 Temple Run 这种游戏类型有些不同。
数据密集型的游戏须要採用数据驱动的形式来进行游戏的设计和开发，可是 U3D 提供的框架是一个代码驱动型的结构（对于原型开发来说极为有力）非常多时候会让研发团队陷入泥潭 —— 看起来功能开发出来了（仅仅要在U3D的对象检查器里调调參数就能工作）。却迟迟无法进入大规模制作阶段（策划拿着数据表格却无法应用到游戏里）。U3D 引擎本身也没有提供不论什么在数据方面的支持，数据表要么须要自行处理，要么须要自己寻找嵌入式的数据库解决方式。
网络连接部分事实上也是类似。U3D 本身集成的网络模块并非为大规模 C/S 结构的游戏所设计，常须要自行开发一套client和server结构。当然也能够求助中间件来解决 …… 可是easy让人迷惑的地方在于，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 project的自己主动编译公布。
扩展 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
代码驱动带来的技术题
游戏碎片化。U3D 引擎有个非常有力的特色，就是实时编译执行。这意味着不管在不论什么时候，仅仅要按下执行图标，当前的场景就会进入可执行状态。
这导致了游戏在开发的过程中常常陷入一种不应当的自信状态。
同一时候也导致了游戏内容长期处在碎片状态下，并低估游戏功能整合时可能遇到的困难。
资源管理是 U3D 引擎的一个难点。
U3D 的资源管理系统由于跨平台的缘故和操作系统的文件系统是脱钩的。须要熟练的掌握 Resources 文件夹和 Assetbundle 的技术才干灵活的控制游戏中的资源使用情况。但这一工作时常会被简单的理解为将资源放置在游戏project文件夹下。剩下的交给引擎自己搞定 ……
须要自己做数据系统。我们现在国内研发的作品，绝大多数是数据密集型（策略、经营、卡牌、KRPG），这和 Temple Run 这种游戏类型有些不同。
数据密集型的游戏须要採用数据驱动的形式来进行游戏的设计和开发，可是 U3D 提供的框架是一个代码驱动型的结构（对于原型开发来说极为有力）非常多时候会让研发团队陷入泥潭 —— 看起来功能开发出来了（仅仅要在U3D的对象检查器里调调參数就能工作）。却迟迟无法进入大规模制作阶段（策划拿着数据表格却无法应用到游戏里）。U3D 引擎本身也没有提供不论什么在数据方面的支持，数据表要么须要自行处理，要么须要自己寻找嵌入式的数据库解决方式。
网络连接部分事实上也是类似。U3D 本身集成的网络模块并非为大规模 C/S 结构的游戏所设计，常须要自行开发一套client和server结构。当然也能够求助中间件来解决 …… 可是easy让人迷惑的地方在于，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 project的自己主动编译公布。
扩展 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
版权声明：本文博客原创文章。博客，未经同意，不得转载。