zoukankan      html  css  js  c++  java
  • 引擎设计与商业模式

            这篇文章摘自“免费打工仔”在www.gameres.com上的发言,虽然字数不多,但对几个引擎的评价却一语中的。

    引擎设计与商业模式

    包括我在内的很多朋友都喜欢看国外引擎的代码,并比较引擎之间的优劣。但是你会发现,每种引擎的设计都是于他开发者和用户及其相关,优秀的引擎不仅是设计上的优秀,更重要的是适应自身的商业(社区)模式。在这篇文章里我们着重讨论一下卡马克的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最重要的是从设计之初就目标开源社区,而不是商业或者技术。

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

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

    Ogre3D 只做图形引擎,不做其他部分。

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

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

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

    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只是一个东拼西凑的烂番茄。但是他们这些问题都是对他们所在领域的取舍。我认为,就如同人一样,如果排除环境而言,世界上并不存在绝对的完美。引擎也是如此,他们都是希望在各自的环境和条件下尽量完美。如果我们对这些客观的实时视而不见,那么对引擎的评价也是不公正的。

    虚幻引擎

    雷神之锤III

    Ogre3D图形引擎

    Orz游戏开发框架

  • 相关阅读:
    Entity SQL 初入
    ObjectQuery查询及方法
    Entity Framework 的事务 DbTransaction
    Construct Binary Tree from Preorder and Inorder Traversal
    Reverse Linked List
    Best Time to Buy and Sell Stock
    Remove Duplicates from Sorted Array II
    Reverse Integer
    Implement Stack using Queues
    C++中const限定符的应用
  • 原文地址:https://www.cnblogs.com/xiaop/p/1663419.html
Copyright © 2011-2022 走看看