笑看风云

记录生活中的启迪与感动
  博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

引擎设计与商业模式

Posted on 2010-02-05 14:28  清晨的风  阅读(250)  评论(0编辑  收藏  举报

转自ogre中文论坛  http://bbs.ogre3d.cn

包括我在内的很多朋友都喜欢看国外引擎的代码,并比较引擎之间的优劣。但是你会发现,每种引擎的设计都是于他开发者和用户及其相关,优秀的引擎不仅是设计上的优秀,更重要的是适应自身的商业(社区)模式。在这篇文章里我们着重讨论一下卡马克的Quake 3引擎,Epic的Unreal 3,开源界的Ogre3D图形引擎以及相应的Orz扩展框架。

一、Quake3=天才模式

在很早以前,我们只能接触这款游戏引擎的代码。可以说卡马克是中国游戏图形界的导师。我的很多前辈都是从这款引擎开始学起,并立志开发一款中国人自己的图形引擎。后面介绍的虚幻引擎和Ogre3D引擎都或多或少的被这款引擎所影响。

提起Quake3引擎就不能不了解id公司和他的天才程序员卡马克大神。约翰·卡马克被称为3D游戏之父,因为其开创性的把3D渲染运用到了实时技术中来。他是图形学界的牛顿,所有开发游戏的人的偶像之一(另外一个是宫本茂)。有一本书《Doom启示录》就是讲卡马克和他的id公司的故事。在这本书中,你会发现卡马克对于程序技术的痴迷胜过一切(甚至超过成 人录像带)。

所以Quake3以及其他id公司的图形引擎产品,(曾经)唯一的目的是开发出最棒最新的图形技术,把卡马克的天才发挥到极致。id是卡马克的公司,Quake3也是卡马克的引擎。如同乔布斯和苹果一样,任何人也无法漠视卡马克和Quake3之间的联系。

1 Quake3 极其重视效率,这样可以便于在硬件支持前实现未来的图形效果。

2 Quake3 代码短小精湛,卡马克对其不断优化。

3 Quake3 不如其他引擎注重模块化,卡马克一个人就能搞定。

4 Quake3 不需要重构,卡马克擅长在最短的时间内重写整个引擎。

5 Quake3 对使用者极其简单,但扩展很难。如果需要扩展,卡马克会重写一个引擎。

Quake3以及同系列的引擎,在游戏历史上的价值是无可厚非的。但是你会发现,如果要修改这个引擎,基本上要了解所有的代码。这些东西很紧密,如果你希望换一个图形场景管理算法,你会发现基本上要修改整个引擎。你可以很容易做出和《雷神之锤3》一样的游戏,但是很难把它修改成其他类型游戏。(你会理解当年要卡马克做RPG的时候甚至用辞职来威胁id管理层。)

国内有很多朋友企图模仿Quake3的结构来实现一款图形引擎或者游戏引擎,但大部分都失败了,另外的一部分也没有获得成功(挣扎中)。不是说Quake3引擎不好,是因为中国很难有类似的环境。Quake3的商业环境是,你需要一个靠技术来赚钱而不是靠产品的公司,另外还需要一个天才如卡马克一样的程序大师来驱动。基于这两点,可以说Quake3的成功是无法复制的。

二、Epic的Unreal 3引擎 = 商业模式

很多朋友都有Unreal 3引擎的代码,但我没有读过。我只是从一些看过Unreal 3的朋友的口中了解一些相关的信息。这些信息包括,

1 Unreal 3开发游戏,如果不是极其复杂,只需要脚本和编辑器就好了。它有极其强大的脚本和编辑器系统。(上海育碧的一些朋友说的)。

2 Unreal 3代码中有很多违反常规知识的地方,比如充斥着菱形继承(C++虚拟继承)。(一个看过代码的朋友说的)

3 Unreal 3代码写的很难看(一个开发类似Quake国产引擎的朋友说的)。

4 Unreal支持大量平台,图形效果非常好。

上面有很多条款我是没办法证实的,但是我们姑且就认为都是对的。

在《游戏人》中有一段描写Unreal诞生的故事,老板并不看好为《虚幻竞技场》重新开发一款引擎,因为已经有了一款卡马克的了。要超越卡马克的图形技术太困难了。但是他们发现自己在编辑器的功能上可以领先id公司很多。基本上从那往后的10年里,Unreal依靠这一点成为了最成功的商业引擎,在商业领域上击败了卡马克。

1 Unreal 3 具有强大的脚本和编辑器,这是为了给购买引擎的公司节约开发成本。

2 Unreal 3 有一些菱形继承和紧凑的代码。这是为了商业上的紧凑型,就算开放一部分源代码,你也需要得到另外的授权,你无法单独使用。(上面提及的朋友告诉我的)

3 Unreal 3目标是当前的,漂亮的图形效果,更多的平台支持,是最重要的。

这些因素代表了Unreal 3的成功,一些其他的商业引擎,比如GameBro也很注重编辑器,而不是更优秀代码质量。与其提供良好的结构,不如实现更多的效果。他们也都在各自的定位上获得了相应的成功。

三、Ogre3D图形引擎 = 开源模式

Ogre3D图形引擎(http://ogre3d.cn)是开源界最出名的图形引擎(没有之一),包括国内的《天龙八区》、《成吉思汗》等,以及国外的《火炬之光》商业作品都是使用这款图形引擎作为开发基础。和Ogre3D同期的开源游戏引擎,包括IrrLight等,都不如Ogre3D这般成功。

Ogre3D最重要的是从设计之初就目标开源社区,而不是商业或者技术。

1 Ogre3D 好的结构带来更多的功能,而反之则不能。 开源社区需要好的结构让更多的人来参与,而不需要商业引擎的工期,所以有充足的时间发展(十年甚至更多),而不争朝夕。

2 Ogre3D 采用插件化结构,这样做的好处是让一些社区开发者,不用了解和改变整个引擎,就能扩充其功能,同样开源的Quake3就很难达到这一点。

3 Ogre3D 只做图形引擎,不做其他部分。 这样做首先是利用了开源社区其他的成果,比如OIS或者CEGUI等良好的开源产品。更重要一点是因为不涉任何游戏逻辑部分,核心模块只有5M左右大小,功能性引擎之间可以组合使用,这样做可以让Ogre3D适应不同领域,不仅是游戏可以使用,在各种仿真领域都可以大展拳脚。同时期的IrrLight反而因为提供太多游戏相关的东西,虽然学期曲线较缓,但是应用领域反而被闲置了。

4 Ogre3D在技术细节上 实现了场景图中节点和内容分离,场景管理器因此可以作为插件使用,这是Ogre3D设计的初衷。

5 Ogre3D 因为运用了大量软件工程知识,导致在计算机运算比较差的环境下和其他引擎效率有一些差距。但因为开源引擎的持续性,随着硬件性能的提高,十年后的今天,这些问题已经不再存在。

6 Ogre3D 和其他开源产品一样,对开发者要求较高(和一些商业领域的产品比较而言),不过Ogre3D也因此吸引了众多开源开发者(黑客)的参与。

基于以上几点,Ogre3D在开源界得到了前所未有的成功,这种引擎开发模式,在商业领域反而不能成功。

四、Orz游戏开发框架 = 分布模式

Orz游戏开发框架(http://bbs.ogre3d.cn)是国内Ogre3D社区开发的游戏框架,他利用了Ogre3D拒绝开发图形之外代码的基础。提供了一系列开发工具以及对各种功能型引擎的粘合。不得不说Orz在游戏引擎中采用了一种极端取巧的办法。他把底层功能性引擎的开发交给了其他开源界的产品,专注于逻辑和接口的实现。相对于其他部分而言,这部分的代码很少会受到硬件升级的影响。所以可以用较少的精力,不断优化已有的代码。但Ogre3D社区内也同时存在诸多开发框架,包括比较出名的yake和Goof等。Orz凭什么能在这些框架中脱颖而出呢?

传统上软件开发的组织结构的基本问题是布洛克法则:“在延期的项目添加程序员只会延期更久”。普遍来讲,布洛克法则认为,随着开发人员数目的增加,项目的复杂程度和通讯成本按平方增加,而业绩仅以直线增加。在传统开发合作模式中的这个结构,因为每个程序员必须了解其他人员开发的模块接口,导致问题随开发者之间通讯路径的数目增加,而后者与开发者数目是平方关系(更准确地说,遵从公式N*(N – 1)/2,这里N是开发者的数目)。依照开源软件的经验,如果你有一个足够大的项目,需要足够多的人合作,你唯一的办法是尽量降低程序员之间的依赖性。

Orz提出一个理想的分布式开发模型。在这个模型中,我们定义了一个公共的知识库,里面定义了交互的规则(消息等信息),所有的程序员按照这里提供的约定完成自己的代码,完全没有和其他程序员的直接交互。在这种情况下,增加程序员的数量并不会导致过度增加开发者之间通讯的成本。

在一些需要确定性结果的程序中,比如科学计算程序,很难达到理想的分布式开发模型,这是因为程序员之间要紧密的配合才能得到一个肯定的结果。然而对于游戏程序而言,它的目的是带来娱乐性和未知现实的模拟,就如同生活一样,你根本不需要(也不可能)知道别人想了什么和做了什么。只要大家遵守相同的规则,那么就是一个不错的体系,甚至越不可预测的结果给人带来的惊喜和愉悦感越大。而这正是我们分布式开发所具有的,比如你写了一只狗,他写了一只猫,我们按照宠物的知识来通信,你根本不用确定它们是成为朋友还是进行战争。就算加入一个宠物猪进来,我们也能正确的和它沟通——只要他遵守规矩。

Orz的目的就是基于这种分布式开发模型而设计,这和它的梦想相一致。顶尖的黑客定义游戏规则,大家来遵守,成千上万的程序员和他们的代码来组成一个真正的虚拟世界。

Orz通过一系列工具和手段来接近这个目的,基于插件来组合程序员们的代码,提供消息系统和ID管理器来确定公共知识库。

Orz框架是一个可以完成商业产品的游戏开发框架,但却走的更远。它在保证足够运行效率的前提下,尽可能的增加结构的离散性质。所有的游戏内容都可以被定义成不同种类的实体,这些实体可以通过插件系统在运行期动态载入,它们通过“及其强大”的消息系统相互沟通协作。任何一个开发游戏实体的程序员,都不需要了解其他实体的逻辑。只要他们共同遵守一个消息体系,就可以在这个基础上进行协作。

但不得不说,这是一个没有经过证实的理想而已。是否能达到这个目标还让我们拭目以待。

综上所述,所有游戏引擎都需要放置在具体的商业环境中来评价其是否成功。你可以说Quake3写得太僵化,Unreal代码难看,Ogre3D运行速度不快,Orz只是一个东拼西凑的烂番茄。但是他们这些问题都是对他们所在领域的取舍。我认为,就如同人一样,如果排除环境而言,世界上并不存在绝对的完美。引擎也是如此,他们都是希望在各自的环境和条件下尽量完美。如果我们对这些客观的实时视而不见,那么对引擎的评价也是不公正的。