 日志正文
|
||
|
之前在「游戏引擎的层级架构」以及「商业或自制，引擎大不同！」两篇文章里，曾经讨论过游戏引擎的基本概念以及商业引擎与自制引擎的不同之处；而在这篇文章里，第三人称射击游戏《Fracture》的开发者 Kyle Wilson，对于游戏开发领域的 Middleware（中间件）提出了几项有力的观点，非常值得做为使用与选择游戏开发中间件的参考指南。
原文出处：Good Middleware 身为游戏软件的设计者与创造者，为什么我们需要仰赖别人制作出来的某些东西？为什么我们要花钱购买所谓的中间件？主要来说，中间件能够提供两大益处，同时也具有相对应的代价。 首先，相较于自己撰写的程序代码，中间件能够以更少的花费提供给使用者更多的程序代码。因为中间件的开发商能够将研发费用平均分摊在大量的授权客户上，所以比一般的游戏开发公司，更能够维持庞大且具深厚经验的团队，专注在特定领域的功能项目之中。然而此项利益的相对代价，在于没有任何中间件的功能，能够百分百符合游戏项目的所有需求；中间件是写来支持最常见的使用案例，因此如果开发者拥有不同于一般标准的特别需求，最好还是自行实作这些特殊的功能。 另一项使用中间件的益处，是能够为「你应该担心的事」与「你无须担心的事」画出一条清楚的界线。只要中间件具备良好的文件以及稳定的系统，你就不需要浪费心思忧虑那些隐藏在公开接口之下的东西。当游戏的复杂度增长到了某种程度以上时，如果中间件能够协助开发者划清各项功能系统的责任界线，将是一项相当具有价值的恩惠。而相对的代价，则是你不能够去改变界线另一端的东西；如果决定要使用中间件，就必须愿意接受某种程度上的缺乏灵活性，也必须愿意将原本所使用的技术调适到合于中间件的程度，否则花钱购买中间件将会演变成为一场灾难。 每个游戏都会具有某些独特的卖点，以与市面上的其他游戏做出区别；对于这些独家功能，游戏开发者应该在团队内部自行研发。同样地，每个游戏也会有许多与其他游戏相同的特征，对于这些寻常可见的功能，游戏开发者应当购买架上现成的技术，然后接受技术的不弹性之处，并且修改游戏的设计去适应它。总结以上论点，就是应该在游戏独特卖点以外的功能，尽可能地使用中间件；正如同 Joel Spolsky 所说的：「不要外包你的核心竞争能力！」(Don’t outsource your core competency.) 所以，当你搞清楚哪些游戏功能应该藉由中间件实现，同时也心悦诚服地领略了使用中间件的益处之后，在琳琅满目而且五花八门的 Middleware 领域里，要如何挑选出最合适于游戏项目的中间件？以下有几项必须谨记于心的内容： 好的中间件让你挂勾自己的内存配置器： 在日益复杂的游戏系统中，天真无邪的 malloc() 函式或者 operator new 内存配置程序，已经难以满足游戏程序设计者的需索无度：我们必须自行管理内存的配置行为。自行管理内存有许多优点存在，例如能够准确追踪游戏内存的使用量、可以轻易地找出内存漏洞的臭虫，以及平衡对象资源系统的负载量等等，因此对于中间件来说，必须要能够让使用者挂勾 (hook) 自定义的内存配置器。 好的中间件让你挂勾自己的输入输出函式： 现在多数的游戏，都会将原来数量庞大且分散在各档案目录中的游戏素材，压缩打包成几个大型的档案。如果中间件不能让使用者挂勾自定义的 I/O 操作程序，程序设计者就难以使用档案打包的方式将游戏素材包装起来。另外对于以光盘为储存媒介的游乐器平台来说，如果不能够控制中间件的 I/O 操作，就无法对档案的读取进行排序以减少光盘搜寻时间。 好的中间件拥有可扩充的功能性： 如前文所述，没有一个中间件能够达成游戏开发者所要求的每一项功能。所以好的中间件应该要提供可实现的抽象接口，以及可挂勾的 Callback 函式，让使用者能够在有需求之处进行特制化的行为，例如在一个动画套件中实作自定义的动画控制器，或者是在一个物理套件中撰写自定义的碰撞基底对象。 好的中间件会避免符号冲突： 为了避免程序代码中的符号冲突状况，每个中间件内的类别名称都应该以自定义的前缀起始，或者是包含在函式库的命名空间范围之内。另外，需要特别留意那些使用 STL 函式库的中间件；当转换到 STLPort 或是新的开发环境中时，开发者可能会突然发现程序代码里冒出许多定义的冲突。另外，程序设计者也应该尽量减少对于 #define 语法的依赖与滥用，才不会发生符号定义相互遮蔽的状况。 好的中间件对于线程安全具有明确定义： 在越来越朝向「多核多绪多乐趣」发展的游戏领域里，中间件对于多线程的支持已经是刻不容缓的需求。为了使游戏程序在多个线程上运行无误，中间件必须充分地告知程序设计者，哪些操作可以同时并进地执行，而哪些操作又必须依序地执行。理想上来说，中间件应该要能够让程序设计者执行异步化的资源创建程序，才能在其他线程中建立资源对象后再交由主线程处理。 好的中间件能够适应于你的数据处理管线： 对于中间件来说，游戏数据的处理管线同样是很重要的一环。中间件应该要能够将游戏数据导出成与平台无关 (platform-independent) 的格式。在理想状况下，这个格式仍应可以直接被游戏系统读取，然后在游戏释出版本的建置程序中，再使用命令行工具将这些游戏数据转换为高效能的特定平台 (platform-specific) 版本。 好的中间件是稳定的： 中间件最主要的优势之一，就是能够释放你的心思，让你能够专注在更关键的事物中。在这个层面上，中间件就像是程序编译程序一样，使程序设计者免于担心低阶的实作细节，但前提是你必须要能够信任编译程序！使用一个充满臭虫的中间件就像是身中「双重诅咒」一样，不仅无法减轻使用者的负担，还会迫使我们不得不花费心思在某个陌生人所写的程序代码之中。更糟的是，如果你自己修复了其中的臭虫，就必须在每次中间件改版之后，自行处理相关的程序代码更新程序。请记得，中间件的益处只有在 API 不被使用者侵犯时，才能充分地展现出来。 好的中间件给予你源码： 尽管在前一则要点中，声明了使用者不应该自行修改中间件，但是拥有存取源码的权利，仍然是使用中间件时不可或缺的必须品。有时候，你会需要检视程序代码的来龙去脉以追查游戏中的臭虫；而另外有些时候，则需要重新编译源码以连结相对应的建置设定值。在我使用过某款商业游戏引擎的经验里，也曾经深入源码追踪一些可疑的问题，最后找出了潜藏在引擎程序代码中的臭虫。如果没有获得存取源码的权利，游戏开发者就只能够以不精确的试误方式，猜测中间件里可能存在的问题根源，因此将会使得游戏开发流程更加地艰巨困难。
或许有些读者会认为给予使用者源码，不就等同于放弃了软件开发的心血结晶与知识产权？实际上，中间件真正的价值并不在于源码，而是在于开发商的品牌以及研发人才。购买中间件的游戏开发者，并不是期望能够买来即插即用，然后就可以不用再去理会，从此过着幸福美满的日子；反之，游戏开发者与中间件开发商之间，应该比较像是伙伴之间的合作关系，而不是银货两讫后就不再往来的交易行为。不论是后续的支持服务或者升级更新，都是选择中间件的环节里非常重要的考虑点之一，而这也是商业引擎与其他免费程序代码或者开源引擎最关键的不同之处。 如果在缺乏仔细评估并谨慎考虑的情形下，原本节省游戏开发经费的美意，最后反而可能会变成悔不当初的决定。虽然在网络上或者书籍里，可以找到许许多多各式各样免费与开源的程序代码、函式库或者游戏引擎，但是在开发预算动辄上看数千万甚至上亿台币的的游戏开发领域里，我们承担不起使用没有售后服务与保障的免费程序代码、函式库以及游戏引擎的风险。 除了上述几项要点以外，对于中间件的选择，还有许多其他的问题需要纳入考虑，例如：中间件花费了多少内存使用量？需要使用多少 CPU 资源？升级到新版本时会不会很麻烦困难？与其他中间件的互动状况如何？开发商的支持如何？或许是最重要的一点：要花费多少钱？以上种种问题都是必须依据个别产品需求进行考虑的关键要点，而不变的规则是：在不外包核心竞争能力的前提下，应该要尽可能购买现成的中间件以协助游戏的研发流程。 最后，作者列出了在《Fracture》开发流程中所使用的中间件：
文章出处：http://blog.monkeypotion.net/ 我的相关日志：
最后修改于 2008-11-22 22:17
阅读(?)评论(0)
|
||
评论
想第一时间抢沙发么？