当前位置:Linux教程 - Linux - 开放源码下的游戏开发

开放源码下的游戏开发



        
    作者 Shawn Hargreaves
    译者 彭青松
    原稿来源:http://linuxtoday.com/stories/7398.html


    引言

    大家都认为Linux下应该有更多的游戏。最近当Loki尝试着移植Windows下的游戏时,我们看到了希望。但同时他也遇到了一些困难。首先,Loki是出于商业动机,这并非广大自由软件爱好者所希望的。其次,关键在于广大Linux爱好者希望自己创造,而不是仅仅移植。
    通常高级程序员们喜欢做很\"酷\"的事。他们会不厌其烦的做一件事,但只有当所有有兴趣的结束了才会停止(一个典型的例子是,考虑Linux GUI环境下复选框是和文件是如何一样的重要)。游戏是很\"酷\"的,并且大多数程序员喜欢编写游戏程序。并且在这方面Linux还大大落后基于Windows平台的大量应用软件。可能会天真的认为,这根本不是什么大不了的事。
    在这篇文章中,笔者将向大家解释为什么游戏从根本上不同于很多其他软件。同时给出一些原因为什么开放源码能和商业源戏相抗衡,并且也会让大家知道让广大程序员写商业游戏的弊端。

     

    为什么游戏是独特的

    在文章\"The Magic Cauldron\"中,Eric Raymond认为软件业在很大程度上是一种持续但前景不定的制造业上的一种服务业。然而,游戏只是这里\"很大程度\"上的一个小的分支,不具有支持的价值。互相合作和可靠性是互不相关关的。当从商业游戏中的税收来源几乎占了游戏发布后头一月的全部收入后,可以认为,从持续的发展中可能什么也得不到,普通用户希望他的软件可靠、灵活,并且最重要的是有预见性。如果你设计出的游戏情节不是依照通常思路的话,玩家会很高兴,他们可能会成年的玩此游戏。玩家们需要在新游戏的基础上的不断创新,新奇和原创是最受欢迎的。但如果你什么原创也没有的话,所作出的游戏可能也会被玩家抛在一边,没有人会对似曾相识的游戏感兴趣。
    这里的\"不同\"和\"更好\"在商业游戏发展中也显然是一样重要的,并且这也是为什么我们到现在还未发现任何基于因特网的令人挥奋的游戏。一个较好的例子如下,最近我玩了游戏Grim Fandango,这个非常华丽和大胆的游戏是Lucasarts写的。仅有的缺点是游戏中间的一小段,游戏停顿到几乎不能玩的程度。这可能是某种内存或缓存管理错误而导致不断从光盘中读取相同数据。如果我有源码,我确信能够也愿意在几小时内把这个问题解决。
    但我认为即使有源码我也不会去干的,因为我修改的那段时间如果用来玩这个游戏的话,这个游戏已经玩结束了。为了一个以后再也不会用的程序而去花时间,这不会有任何动力的,并且即使我把这个游戏的补丁发给Lucasarts,其他的玩家在找到并且安装完这个补丁之前,可能也已经结束了这个游戏了。这个行业的步伐非常快,即使某个开发者的前一个作品进入了排行榜,他也必须很快努力作好下个游戏。去修改成为过去的东西是一点意义也没有的。
    在The Magic Cauldron中,Eric Raymond提出了一系列可能为自由软件产品赚钱的建议。其中一些可能跟游戏有点关系,但大部分是一点关系都没有。从某种意义上说,利用免费游戏来提供有偿在线多人游戏服务是有可能的,但这只适用于某些类型的游戏(如Ultima Online),并且潜在收入还会包括开发成本,除非你也向免费软件的用户收费。并且你也不能利用免费软件来销售硬件,Nintendo,Sega和Sony实际上已经停止了他们为促销硬件而卖游戏的计划了。你还可以自己注册商标,但即使成为媒体的一个热门话题,这也不会因为你的游戏中包含版权而给你带来收入,而不象其他在免费游戏基础上出售的其他产品。
    这看起来有些不尽人情。合作和持续的发展对于这样的一锤子买卖能产生大的效益。并且商业公司在源码开放后因不再有发展而不再有经济利益。基于这种考虑,我想信只有当人们意识到不可缺少的技术不同于游戏本身之后,开放源码上的游戏才会发展起来。

     

    游戏是写出来的,不是编出来的

    以前的程序员写诸如Space Invaders之类的游戏时都是在家里完成的。没有艺术细胞并不会影响他们的创作,因为没有人能够在8X8点阵的单显上做出什么稍好一点的图形。
    后来硬件得到了改进。在32X32点阵、16色下做出一个好看的孙悟空来也很不容易。于是游戏公司请来了艺术家们,因此程序员不必为了图形而困惑了。游戏开始有了很大进展。
    之后硬件又得到了进一步的发展。一些人别出心裁地想出了在屏幕上模拟三维模型的主意。一旦三维模型在PC上运行达到了一定的速度,这些人的腰包也就立即鼓了起来。很多人参与到在屏幕上虚拟三维模型中来,他们不断想出了一种又一种办法来使三维模型运行得更快,更自然。其中一些人富了,另一些人却没有。竞争是很激烈的。因为这些三维模型很依赖于这些天才程序员,采用特殊的编程方法导致了这种差别。艺术家们现在只能努力把程序员们分配给他们的任务作好。
    现在,即使是刚接触计算机的人都能建个三维模型。所用的工具就是3d API,其他的技巧就全部由硬件自动来完成了。因此如果现在运行比较慢的话,等第二年由于硬件的改进,速度就会变快了。当然现在仍然需要高级程序员,并且一个较好的建模工具的速度可能比简单的快上几倍,但最终这几倍并不很重要。所以即使有更好的算法未被发现又怎么样呢?因为最终,劳动只归结为用你的艺术天赋来表达。优秀的游戏艺术家可以用一些多边形和文字图形做出奇迹来,而其他人可能只会作出普通的图像来。不管技术如何先进,不管你用什么优秀的建模工具。现在程序员的角色包含写出好的工具并且尽这种工具对于艺术家和普通用户足够的好用,而不是让他们也懂得技术前沿的知识。
    如果你不想信的话,看一下Valve从ID软件公司取得Quake授权之后是怎么做的就知道了。Half Life是一个了不起的胜利,这不是因为其开发工具优秀,而是因为其设计的水平。他们为了做好开发,大概花了好大功夫来改进各种工具的功能。但最后同用户见面的是游戏本身,而不是改进过的各种开发工具。
    值得关注的是没有人意识到艺术家和程序员现在的巨大作用。从他们的薪水不难找到一些工作在一起的程度相当的程序员和艺术家,但实际上程序员创造的价值要大得多。要问起这个问题,游戏开发公司的老板们可能会给出这样的解释,真正有水平的程序员实际上很难找。但实际上真正有水平的艺术家也同样很难找。这两种人都对项目的成功起到重要的作用。真正的区别是当一个不会编程的人反而能够给出一个主观的判断谁是优秀艺术家。
    我认为大多数游戏艺术家工资都较低,并且大多数程序员收入过高。如果我是一个游戏开发商的话,我将想办法降低程序员的工资。其中一个办法是让程序员公开他的代码,让其他人来改进你的工作。
    制作自由软件时同样存在着轻视艺术家的问题。造成这个问题的部分原因是因为高级程序员的身边缺少大量的艺术家,所以大多数人已经习惯于脱离艺术家而工作。但真正的原因可能是高级程序员们太高傲了,陶醉于他们能用纯文本就能做出全部的事情。但实际上游戏是为娱乐而作的,而不是为显示编程技巧的。作为玩家的孩子们一定更喜欢漂亮的界面。

     

    商业游戏向自由软件转化

    为了从游戏中赚到钱,你应该有一个拿得出手的作品。我相信在大多数场合下,开放源码之路对于改进模块中的源程序是一个比较好的办法。你可能不情愿你设计的一个精彩游戏被人玩过后就扔在角落里了。但如果你做法得当的话,你可能会同其他开发者合作,从而改进你的源程序库。
    注:在极少数情况下,最成功的游戏可能得益于用户把它移植到一个新的平台上并加以改进,增加新的内容。这种情况即使在源码不开放的情况下也有可能成功(如Doom与Quake)。但事实表明,这种可能在成功的例子中的可能性只占不到万分之一。一些其他开发者也曾试着鼓励用户进行这种移植工作,但现在都没有消息了。
    我认为两种办法会走向不同的极端。你把并不成熟的游戏卖给用户们,同时把你的源码给同样是在开发游戏的你的同行们。这显然和通常的Linux模式下的所有用户都是合作者的方式不同。但如果你把开发步骤分成两个不同的部分则会有更好的结果。一部分给艺术家,一部分给程序员。开放源码的想法对于商业终端开发者可能并不能很好的适用,但对于可再开发的游戏则会有惊人的效果,此是艺术家们也同时是终端用户。
    虽然现在很少有游戏开发商采用了这种办法,但大趋势是不可阻挡的。现在唯一的困难是还没有足够的开发工具,而这正是基于互联网上的开放源码的优势所在。
    大多数游戏公司已经开发出了一些室内工具、编辑器、文件转换器和一些实际上是代码库的模块。这些通常都很粗糙或很专业化,但对于开放源码来说却是好素材。如果你能够大致写出这些工具的基本模块,那对于其他人来说就不需要为你花费太大的精力为你去维护这个程序。同样的对于游戏本身的源码也一样,如源程序维护,物体动作等需要一遍又一遍的重复劳动。因为已经开发出来的游戏随着时间的改变而必须不断更新。如果一次性劳动就能达到最佳效果的话,将省却大量的人力物力。一些公司在尝试把内部模块标准化,但还不适用于整个程序本身。
    这种方法固然好,但你得首先保证其他开发者能够在你的模块基础上开发,从而你能够把他人的成果搜集起来供自己用。你要在既能从外界获取更多有用的程序又能保证自己有足够的让其他开发者感兴趣的产品去出售这二者之间找到最佳结合点。如果你只是简单的发布一些源程序,而没有经过自己的组织和调试的话,大概不会有人会感兴趣的。
    其中一条路是公布源码的同时公布一些初期数据。在开放源码准则下,你还可以把进一步的数据留作出售。对其他开发才来说,这是一种容易被他人接受的开放源码系统。对于用户来说,把初期数据作为免费的演示版下载同当前的惯例也没有什么不一样。
    另外可行的办法是,把游戏中较专业化的部分保密,同时以库的形式开放其他部分的代码。这对于一些有保护意识的人来说可能会安全些,但实际上这并不是个好主意。这些库还得需要很多文档、例程和至少还得需要的一些使用环境,这个工作恐怕大家都不愿意做。如果你把全部可编译执行的游戏代码公开的话,从某种意义上来说,这能避免写太多的说明文档,这就大大减轻了劳动。
    不管你采取哪种方式,都要尽量使用模块。这便于你收集所有程序中的改进,以方便你将来使用。但如果模块分得不好的话,这不会对你的工作有帮助。如果你知道谁都能改变游戏的主要模块,你要确信这些模块之间是互相独立的。我建议分成多个模块分别编译,然后链接成整个游戏。让用户认为这些模块都是可利用的,即使在程序员们对游戏升级后仍有保存价值。
    在Magic Cauldron中,Eric Raymond提出了第三种可能的建议。他提到Doom开始时是作为有价值的经过智能加工的产品出现的,但后来其源码也开放了。我认为他在这里犯了个错误,因为他并未认识到游戏业的发展速度已变得多么快。ID开放Doom的源代码时,这些代码很难懂,但大家都在为这二代而工作,后来也未出来过更高版本。开放源码确实是他们的明智的举动,并且人们觉得剖析这样一个经典的游戏很有兴趣。但ID却不得不一直等到所有人的工作都已结束时为止。关于Doom几个增强的版本终于出现,但以当时的改进速度,根本无法用于今天的开发游戏中来。
    我也反对如下言论:如果你想开放全部代码,那就直接开放不去管它了。如果是这样的话,即使你等上整整一年,你的代码只会对比你的技术落后一年的人有用,这些人可能会对你一年前做的工作加以改进。这种工作没有任何实际意义,只是一种良好的愿望而已,你不会从中得到什么益处。

     

    对编程高手的一点建议

    以下是写给因特网上的游戏程序员的:传统的开发工作可以抛弃了。如果商业游戏开发者们能够开放他们的源码,并且集中精力到他们自己所真正感兴趣的程序上。但目前我在网上所发现的和加入的和游戏相关的开发,现在还不能完全照我设想的那样发展下去。
    就通常的游戏基本结构来说,Linux尚有两点不足:其一是一个比较成熟的3d API,其二是一个较好的3d编辑器。API是一个急需解决的问题。感谢一些高手们在MESA和Xfree86上所做的工作。但由于没有一个好的软件包,游戏开发者们也离不开价格昂贵的商业软件。因此,若能开发出象相当于为Photoshop而设计的3D Max之类的软件现在很重要。这个工作可能要经过几年艰苦的努力,并且你的成果也不会因此而进入排行榜。但这个工作可能恰恰是推进Linux下的游戏发展的最关键的一步。
    在网上开发出好游戏的难度是在于能否保证整个游戏有个相同的风格。他们需要能够细致的不断解决一个个问题,并且也应该有个标准决定某个工作到什么时候就可以结束了。换句话说,他们是在一个集体环境里工作,而不是在一个市场上。如果光是把些有着不同想法的人人拉到一起,同时他们各自也都只朝着自己所想的去做的话,这是不会有什么结果的。大多数程序由于集成了一些天才的智慧而优秀,但对于游戏来说,让各种不同的思想在一个游戏中不互相冲突则会更好些。
    显然,如果单靠一个人的力量,做出能够获取巨大利润的商业软件是不可能的。所以遇到困难时同其他人讨论和组织一个讨论组是很必要的。但据我的经验,这种做法并不可取。原因有二:第一,虽然在这样的讨论组中就某个问题你会得到一些答复,但你却很难找到两个意见相同的人。这会导致你把精力浪费到没有价值的讨论上去。第二,为了引起其他开发者对你的项目的注意,你还得绞尽脑汁描绘你的游戏会成为什么样子。同时你可能也不希望把光会一时冲动的人拉到你的项目中来。
    我认为的一个较好的办法是考察网上软件业的发展史,从中总结出一些东西来。Unix是在一个标准协议的基础上建立的,具有非常稳定的结构的,同时包含有很多小块的操作系统。经验表明,高级程序员们擅长于做这样的东西,并且很多成功的例子在刚开始时规模都是很小的,后来才逐渐发展起来的。游戏产业在游戏结构和模块化应用方面做得很不好,但我们可以把我们擅长的地方来较好的实现模块化,而不是象其他程序员那样常在不情愿做的情况下开发。
    我们的提议决不是为了进行编程风格的培养,而是不断寻找游戏所需要的新特点,单从themes.org站点就可以学到很多有用的东西。一点也看不出通常游戏的味道,我认为在开放源码方面取得最大成功的游戏莫过于象这样的一个游戏。聪明的程序员们会写出游戏的框架,在此之上可能再由其他更多的程序员们写出其他的程序,而最后的游戏可能是在一些考虑如何画图的艺术家们手里出来的。各个最小组也最多由两三人组成,他们在一起共同探讨某一个问题,但最关键的工作往往就是初期所做的工作。
    如果你认为在Linux 上所做的开发就属于自由软件的范畴,那么我想你可能不赞成在游戏开发中也公开源码。当你花了几年的时间做了一个大型游戏的框架最后发现你的名字只能在长长的readme文件的某个地方找到,所有荣誉都被做最后发布工作的人占去了。但从好的方面看,如果你的框架做得足够好的话,其生存周期还是远比现在的游戏其存在的时间长的。不可能是你所开发的游戏框架和游戏开发商所想的一模一样。如果能想法做出能把游戏在Linux和Windows平台下转换的工具,那对整个游戏产业的贡献将是不可估量的。
    任何在Atari ST和Amiga时期成长起来的人可能认为很象老的游戏包,并能想到这些游戏包是多么的无用。但从那时起,很多东西已经变了。随着硬件的改进,任何细节的升级都会使你的程序的可再用性有所提高。作为开放源码,开发工具只是一个开始的地方,而不是一个让人捉摸不透的黑匣子。最重要的是,我们有很多可以利用的非常优秀的脚本语言。商业游戏开发商们本应知道好的脚本语言会让开发工作变得简单些,但他们却一再犯类似的错误。要么是他们用自己的脚本语言而导致开发工作受到种种限制,要么他们由于前期工作用的全部是C而导致开发人员也不得不抱住C不放。
    有个现象让我感到欣慰:一些人在开发几乎相同的游戏。最近我访问了linuxgames.com站点,发现大多数新闻都是关于Doom,Quake和Loki的。这些新闻是关于这三个游戏的原始方式和一些讨论方式。我个人不发表哪个游戏更好的评论,但我仍怀疑这样做的价值。完全复制决不会让我觉得Linux下的游戏会比Windows下的更好。我我们需要做的是人们最近几年所没有玩过的游戏。从一个好的游戏获取其中的思想并不是不可以,但为什么不加入一些新的观点进去呢?这样就不会导致相同的拷贝了。请千万把\"克隆\"的思想从你的工作中抛弃。
    归根到底,我相信Linux下游戏的发展还依赖于广大Linux爱好者自己。游戏编程人员通常错误的依赖他人能够写出更好的语句,但开放源码只有当我们都能够充分发挥我们自己的能力之后才会起到巨大的作用。在这个时代,光写几个循环语句可能并不会对在我们所喜受的操作系统上运行的游戏作出多大贡献,但有着大量的工作尚等待我们去做。大家赶快行动吧!

     

    鸣谢

    本文是在Eric S. Raymond(esr@snark.thyrsus.com)的指导下完成的,在此表示感谢。
    同时我也要感谢Arron Shutt(version8@ashutt.demon.co.uk)的关于游戏问题的讨论。
    发布人:netbull 来自:Linux公报