就这样.
Sent to you by 柠檬杀手 via Google Reader:
最近的一两年，我一直思考游戏程序开发中的一些问题，可以归纳为"游戏，3D引擎，开发规模，复杂度"以及他们的关系和对游戏开发其他部门，策划，美术等的影响。
目前的趋势是，游戏开发规模越来越大，复杂度越来越高，这就成为了一个急待解决的问题。如何协调各个部门，团队中的每个人，让研发成本降低变得非常重要。下面谈谈其中一个很重要的部分：3D引擎。
3D游戏现已成为主流，3D引擎这个时候突显重要地位。各大3D引擎纷纷跳出来叫嚣。有一定研发实力的团队，有的自行研发3D引擎，有的使用开源引擎；大点的公司从公司发展层面考虑，有的可能会自己研发，有的可能花钱购买国外的3D引擎（为什么不是国内？很显然，从我周围的人来看，在引擎这事上，似乎大家都不太相信国人）。
请相信我，排除掉已经有一套完整3D游戏开发方案的公司，团队，那些还没跨过这条河的，要想顺利跨过去，绝非易事。看看上面简单列出的几条路，单单做决定走那条，就够费心的了。这几个方案也不会有哪一个会是在半年之内有个结果的。现实总是很残酷，但是我们还得要做出选择。
根据各个团队，公司实力，项目实际情况，几个方案的代价（时间，金钱）也各不相同。
（哦！差点忘了，还有一类非盈利性组织和个人（比如：我），这类人群可能也想开发一个3D游戏）
下面把这几条路分别说一下，首先说说自行研发：
去年的差不多这个时候，我有一个想法，针对一个特定的游戏类型，游戏需求，是否能在短时间之内开发出一个3D引擎呢？我为了验证我的一个想法，我开始完全重新开始设计，实现一个3D引擎。到现在一年时间里，我利用我的空余时间，完成了计划表里大约50%的内容。开发时间真的不多，如果把时间累加成正常上班时间，那么大概2个月。在评价这个结果的时候需要考虑几个因素：
1）我是一个人开发，如果多人，会是怎么样，效率会降低吗？
2）各个子系统，我尽量采用很中庸的方案，没有太多创新，或者说就采用了我脑子里本来就有的方案，而这些方案往往是以前经过验证了的。
3）由于开发时间分散，留给思考的时间相对较多，通常我们把这叫设计，这也是需要时间的，而这些时间我很难估计。
这里，我不对此下结论。只是分别说说，在几种情况下，如果自己研发引擎可能需要关注的问题：
1）如果是个人研发（比如我），动机太多了：学习，没钱买高级货，不写代码全身不舒服，时间太多没处打发......不管是什么，要想有个结果，那么必须做计划，而且严格按照计划执行，切忌再细节上折腾太久。
2）如果是公司或者团队，打算用来做项目的。那么，首先必须确保自身有这个实力。这个实力绝对不是仅仅掌握一些3D技术就可以了的，引擎是一个浩大的工程，对程序架构的要求远远多于3D技术本身，3D技术本身和程序架构能力缺一不可。第二点就是管理了。公司或者团队能确保核心引擎研发人员的稳定吗？管理人员能掌握引擎开发进度和质量吗？
然后说说开源引擎：
现在最火暴的开源3D引擎就是OGRE了，不得不承认，这是一个设计良好，成熟稳定，社区活跃的家伙。我周围但凡刚接触3D的程序，几乎都给我宣称研究过这东西。我每次都会想，OGRE就有那么容易吗？
开源3D引擎有个地球人都自己的问题，就是没有完整的一套内容开发工具。使用开源3D引擎的人，一般都会为此开发一大堆工具。而做过相关工作的人都知道，工具研发是最让人头疼的，也是最耗时的一部分了。这道理再简单不过了，网上有一堆开源3D引擎，而且很多都是那么几个人甚至一个人开发出来的，而有完整配套内容开发工具的都是要$的，还没几个。要是工具是个容易事，我相信，凭借开源社区老外一向的作风，早就放出来了。
还有一个不得不提一下的就是Irrlicht，成都雅美达工作室就是用的这个引擎。跟OGRE相比，我更喜欢Irrlicht。原因很简单，从学习的角度来讲，Irrlicht更容易学。Irrlicht有明确的接口概念，让人很容易就知道哪些是给用户使用的，哪些是引擎内部使用的。而OGRE这方面就让人有点恼火了，个人感觉不是研究过相当长一段时间的话，要在那一大堆C++类里搞清方向，还真不那么容易。但是，公正的说Irrlicht的很多设计真的不如OGRE，可能跟发展时间不长有关系吧。
可能存在这么一个误区，很多人仿佛觉得，使用引擎我就可以不怎么关心引擎相关的具体技术了。还能说什么呢？基本的还是应该知道吧。否则要是DP多了，发现性能上不去，还不知道原因的话，就有点麻烦了。
最后，就是商业引擎了：
我周围朋友，同事，用商业引擎还是比较多，Torque，Unreal2, Unity3D, Bigworld, GameBryo。公司采用商业引擎很多是为了规避引擎的技术风险和研发风险。但是，事实上，能完全规避吗？我个人觉得不一定。能把引擎用好的人，对技术的掌握也会十分到位，那么对于公司来讲，3D技术储备就是必不可少的。
据说Unreal2是学习难度最大的一个。我个人对商业引擎的了解也就仅限于GameBryo，这还是两个月前才开始的。做出采用GameBryo这个引擎的决定也是不容易的，细节太复杂，这里就不说了。只是从公司发展角度考虑，这未尝不是一个好的选择。毕竟痛苦一次，后面就容易多了，而且不需要为各种技术升级而操心，比如，要是Windows7流行了，DX11得支持吧。
我接触和学习GameBryo的这两个月，说实在的，时间很有限，但是也有一些感想。既然是使用引擎，我自然不会去关心引擎的技术细节，而且是刚开始，所以我把重心完全放在了使用学习上面。
GameBryo真是个好家伙，把我多年以来的一个想法给实现了。我一直坚信，美术非常喜欢在Max,Maya之类的软件内做东西，而不是我们自己做的编辑器。所以，最好美术能在Max里完成他要想完成的一切。GameBryo做到了这点，它几乎可以把Max所有的东西给导出来。想想给Max写插件，再看看那文档，那可真是个噩梦啊。但是很悲剧的是，我们的美术还是不会怎么做，他们还是习惯性的想要个场景编辑器。我觉得主要的问题出现在地形编辑上，Max里做地表，仿佛不那么容易。
从目前我了解到的情况来看，GameBryo还真算得上是设计良好（这可是它官网上说的）。说到这里，根据那个什么辨证的观点看，事物都有两面性，所以GameBryo也有些问题值得我们去思考。作为一个商业引擎，直白的说，就是要卖钱的东西。所以，必然设计之初就需要考虑跨平台（PC, PS3, XBOX360, Wii），游戏类型尽量通用等等。这样的一个结果就是设计必然复杂。这么一来我们学习的代价就加大了。而且，很恼火的是，往往这些跨平台和通用的需求最后都还是或多或少的成为了理想状态下的东西。跨平台还好，通用游戏类型这个需求实在就太难了。就拿GameBryo来说吧，我们是要做MMORPG，做个SplattingTexture的地型总还是正常吧。结果GameBryo在这方面的支持甚少，一个地图只支持４张贴图。想想原因吧，从我们的角度看，觉得这很不可思议，但是如果从GameBryo的角度来看，问题似乎就容易理解了。地形这样的需求应该还是比较高层的需求，跟游戏具体设计细节有很大关系。比如WarCraft3, WOW和Infinity的地形就是完全两个概念。对于GameBryo来说，到底实现哪种喃？的确是个问题。或许以后GameBryo都能实现吧。万一有游戏需要另外一种特殊类型的也说不好，需求总是无穷的。所以，我感觉GameBryo在一开始更愿意提供一个比较健壮的框架，让使用者自己来定义自己的需求。又绕回去了，基于GameBryo来做的话，得花不少时间了解它吧。
然后一个让我无法理解的东西是，GameBryo提供的示例实在是太少了。大致分几类，Tutorial, GraphTechDemo, GameDemo。从绝对数量上来说也不少了，大大小小几十个。那我为什么还说少？想想Direct3D SDK提供了多少示例吧，也是几十个。可Direct3D的API才几个啊？比GameBryo那可以是少多了。
综合来看，各种方案有优势，也有劣势，在不同的情况下，优势劣势比例不同。我个人觉得，如果是从项目的角度考虑，那么，在掌握各种3D技术的基础上，熟悉使用一个商业引擎才是正道。这年头，规模太大了，自行研发的风险也就很大，这一点是必须考虑的。当然了，自行研发引擎在某些时候也是可行的。这就好比为什么在有了Unreal3这样的超级引擎以后，还会出现CryENGINE这样的怪物。目标不一样，自然选择不一样。
最后，就是对于写代码有种特殊感觉的人，想要感受开发引擎带来的诡异快感，或借开发引擎满足自己某些私欲的人，那就还是继续做吧。毕竟目的不同。
Things you can do from here:
- Subscribe to Zeb的博客 using Google Reader
- Get started using Google Reader to easily keep up with all your favourite sites
没有评论:
发表评论