[转载]游戏研发和引擎研发 From: Sina

sea_bug

ryan_w_cn 原作

游戏研发与引擎研发


1. 目的

早期并没有专门的游戏引擎一说, 但随着游戏产品的迅速繁荣,
开发技术和工具逐渐被整理成具有良好可重用性的模块, 同时也为了满足开发商快速开发同类，同性质游戏的
需求, 游戏引擎开始大量出现，并被彻底的商业化, 成为了国际化的商品.

对于开发商来说, 拥有一套功能强大, 结构良好的引擎，好处是显而易见的
首先降低了后续产品的开发成本和开发难度, 在引擎的基础上开发游戏产品,
对开发人员的要求也会降低, 生产力会提高, 这主要体现在两个方面:

1. 引擎就是一种开发工具, 使用它之后游戏开发人员不必要懂太多的底层技术,
不必要每个人都是图形专家, 例如图形渲染，资源管理, 音乐音效, 界面控件等都是引擎现成的部分,
开发人员只需要去熟悉它们的接口和调用方式. 正确的用好它们就可以了.

2. 引擎的使用迫使开发人员在引擎的技术框架内去解决问题,
从某种程度上讲, 避免了开发过程中的'胡思乱想', 而把精力集中在游戏产品的开发上.

另外引擎本身也是一种商业化的产品, 是可以用来卖给其他的开发商, 直接获得收益, 而且这种商品具有长期
的盈利能力, 通常使用引擎的游戏开发商和引擎的开发商需要保持长期的合作关系, 卖引擎同样也是卖服务.
在国内，目前还没有出现一款真正商业化的引擎, 这是由国内这种大量的小作坊开发的模式决定的, 开发商要么
有心无力, 要么就是有力无心, 缺的不是优秀的开发人员, 而是对待引擎开发的正确意识和有能力推动引擎开发
的管理者.


2. 方法

引擎的新功能开发流程 : 1. [游戏组]提出功能特性的需求
2. [引擎组,游戏组]特性分析与筛选
3. [引擎组,游戏组]功能描述与接口描述初步归档
4. [引擎组]开发, [游戏组]反馈, 文档形成

游戏开发与引擎开发之间应该把握一定的距离, 两者脱离太远, 会导致引擎的开发跟不上游戏开发的脚步,
不能快速，有效的满足需求, 两者过于接近, 又会造成引擎的开发容易被具体游戏特例化, 不利于引擎的
结构拓展和商业化. 正确把握两者之间的尺度正是引擎开发管理者能力的体现.

昱泉信息技术(上海), 早先用名为'Lizard'的3D引擎, 开发了多款还算成功的单机游戏, 但这个引擎
后来用在网络游戏开发的时候, 开始出现很多不合用的地方, 比如切景频繁, 读入速度太慢, 同屏人数
过多但缺乏LOD支持, 物件的Show/Hide判断技术已经过时, 对大场景的显示效率缺乏优化措施等等,
但这个引擎的维护开发工作完全在台湾进行, 并且没有专门对特性需求进行审查的流程, 导致大陆这边的
开发人员提出的需求很难快速得到反馈. 这就是一个游戏开发与引擎开发脱离太远的例子.

至于游戏开发与引擎开发距离太近的例子就数不胜数了, 很多游戏产品的开发把开发游戏与开发引擎
划上等号, 等产品完成后, 想整理代码来重用开发新的游戏, 发现游戏层与引擎层浑然一体, 结构混乱,
代码复用的可能性极低, 想做新的开发已经举步维艰. 不得不做新的引擎底层. 造成这种结果, 项目时间
太赶固然是一个重要原因, 但开发管理者缺乏此类意识才是要害.

开发技术人员往往谈起新功能，新特性, 满口新名词, 劲头十足, 但对自己的代码提供给别人使用的
接口方式上却不愿意花心思, 要知道接口的制定可不是那么容易的事, 不需要完美但要完满, 很少有人愿意
研究这其中的讲究之处. 好的引擎除了功能强大, 往往从功能调用的接口上就能感受到作者的匠心独用,
而差的引擎看起来好像功能一大堆, 但乱糟糟的有很多重复的功能接口, 或者使用起来要人命, 只有作者一个人能懂. 在这个方面, 有个很好的正面例子, 微软有专门的函数小组, 为它庞大的产品线提供公用函数库, 要知道微软的很多产品的功能都是重复使用的, 若没有好的底层接口规划, 何来今天的微软帝国.

综上所述, 一个有一定规模的游戏开发公司, 如果不打算从别人那买引擎来使用, 那么就需要规划一个专门的引擎组, 引擎开发围绕着游戏产品进行, 但从项目上一定要分开, 迫使引擎开发人员从他人使用的角度来对待代码, 而游戏开发人员把自己当作用户来对引擎组提要求. 引擎开发的管理人员来负责双方的沟通,并且制定功能特性的提出, 筛选, 开发, 满足的规范流程, 文档随时随地都在更新和维护, 而不是等到最后一刻来整理. 引擎组也可以安排自己的研发计划, 使引擎向国际先进水平靠拢, 提高竞争力.

BTW: 韩国的网络游戏不是很多么, 没关系, 我们的口号是'把引擎卖到韩国去!' ;-)

hWnd

网络游戏？？
真的是黔驴技穷，没办法了，用网络这个卖点来维持生计……