u3d的github工程怎么使用

推荐回答

可以的。　　1.游戏碎片化。U3D引擎有个很有力的特色，就是实时编译运行。这意味着无论在任何时候，只要按下运行图标，当前的场景就会进入可执行状态。这导致了游戏在开发的过程中经常陷入一种不应当的自信状态。同时也导致了游戏内容长期处在碎片状态下，并低估游戏功能整合时可能遇到的困难。　　2.资源管理是U3D引擎的一个难点。U3D的资源管理系统因为跨平台的缘故和操作系统的文件系统是脱钩的，需要熟练的掌握Resources目录和Assetbundle的技术才能灵活的控制游戏中的资源使用情况。但这一工作时常会被简单的理解为将资源放置在游戏工程目录下，剩下的交给引擎自己搞定……　　3.需要自己做数据系统。我们如今国内研发的作品，绝大多数是数据密集型（策略、经营、卡牌、KRPG），这和TempleRun这样的游戏类型有些不同。数据密集型的游戏需要采用数据驱动的形式来进行游戏的设计和开发，但是U3D提供的框架是一个代码驱动型的结构（对于原型开发来说极为有力）很多时候会让研发团队陷入泥潭——看起来功能开发出来了（只要在U3D的对象检查器里调调参数就能工作），却迟迟无法进入大规模制作阶段（策划拿着数据表格却无法应用到游戏里）。U3D引擎本身也没有提供任何在数据方面的支持，数据表要么需要自行处理，要么需要自己寻找嵌入式的数据库解决方案。　　4.网络连接部分其实也是类似。U3D本身集成的网络模块并不是为大规模C/S结构的游戏所设计，常需要自行开发一套客户端和服务器结构。当然也可以求助中间件来解决……但是容易让人迷惑的地方在于，U3D既可以使用.net的网络机制像端游一样工作，也退一步可以用加密的www机制，当一个简单的页游来处理。如何抉择是个难题，贸然贪多求全往往换来遥遥无期。　　5.测试U3D开发的游戏亦一个很麻烦的过程。原因也是那个几乎不会崩溃，随时可运行的场景/逻辑混成编辑器——它会让开发团队误算自己当前的游戏完成度，以及需要什么样的测试。