游戏项目开发总结

    历时8个月的开发,一个基于体感摄像头的游戏终于完工了。游戏类型与WII里面的雷曼兔子洗衣服的游戏很像，依靠体感摄像头对玩家动作的识别来操作游戏。整个开发过程当然不是很顺利，现在正是回顾这个开发过程的好时机，因为很多与项目相关的感受和记忆还非常清晰，时间久了那些痛苦的感觉就会遗忘，而遭受痛苦的地方才是需要我们认真反省的地方，这样才能对以后的开发起到积极的促进作用。

 

项目组成员

    由于这个游戏项目是个单机休闲游戏，所以人员配备上非常有限。程序1人，美术3人，策划1人。其中UI美术1人，3D美术2人负责场景、模型和动作。当然只有程序是全职投入的，其他人员还同时兼顾其它项目的开发。成员都是拥有相当工作经验的同事来担任。

 

项目的计划

    从规模上来看确实不是一个复杂的项目，所以在项目初期我们曾天真地觉得这应该在三个月内就可以完成，但现在来看时间足足多花了好几倍。游戏项目的开发不像一般应用的开发，只要功能实现没有问题就算完成了，而游戏项目中其实没有真正意义上的“完成”这个概念，因为你可以无限制的完善，使游戏拥有更好的画面，更好的手感、更丰富的内容、更动听的音乐与音效等等。唯一限制你的就是预算。

    所以在最初核算工作量的时候我们就犯了一个错误，按照功能点来制作执行计划。比如：关卡管理系统、道具管理系统、人物管理系统等等，这些系统是从游戏策划案中抽象出来的。看起来好像这些东西都做完了游戏也就完成了，但实际上这里面有太多的东西没有包括在里面。而且有些看似简单的功能点最后为了达到好的效果花费了大量的时间。比如这个项目中人物从水里举起衣服和放下衣服产生的水花效果，最终我们花费了2个多星期的时间才调试出一个合适效果，比预先估计的时间多了好几倍。当然简单的水花效果还是好做的，但是这里的“合适”是指能完美配合游戏中人物的动作节奏和游戏风格就非常不容易了。

 

使用的技术

    技术方面我想在后面单开一篇文章来讲，这里只是简单的把用到的技术列一列。由于以前项目的积累，我们主要用的一套工具以开源的各种引擎和库为基础，并基于这些基础构建了我们自己的游戏引擎，所以在这个项目中我们也会采用这一套东西。主要包括Ogre渲染器、CEGUI界面库、Lua脚本库、Bullet物理库、ParticleUniverse粒子库、OpenNI体感库和OpenAL音效库等等。

    有人看到这里会说为什么不使用现在更流行的UDK、Unity3D等引擎呢，那些引擎不是更成熟、功能更强大吗。其实我之前也有这种想法，因为看了UDK那些引擎提供的例子之后觉得实在是太爽了。但我也问了很多用了这些引擎的朋友，很多人都说真正用深入了其实也没想象的那么好。效果好那是使用了各种先进的渲染技术，但最终是否体现出引擎本来的渲染能力，很大一方面要依赖美术的功力。功能方面也是一样，这么庞大的引擎要想精通需要很长的学习时间。像我们这样的小团队应该避免使用如此重量级的工具。就像前面提到的水花特效，如果你不能将想象中的水花效果拆解成需要什么美术资源，需要什么粒子发射器、影响器等等元素，就算用高端的工具也同样做不出来。另外我觉得人比工具重要的多，就算有再好的工具而没有能驾驭的人也是白搭。

 

项目开发中的失误

    令人非常难过的事情就是往往项目中做正确的事远远没有做错的事情多。这一节就想把错误提出来分析分析，尽量能在以后的开发中避免。

设计失误

    这是在项目开发中最具杀伤力的失误之一了。说白了就是策划设想的玩法在游戏原型做出来以后发现不好玩，于是对玩法进行修改。这就等于之前已经完成的很多工作都白做了。不幸的是在整个项目周期中我们经历了一次玩法的修改,造成相当一部分逻辑代码和美术资源一起作废了。

    其实玩法在最初设计阶段应该都还可以，否则就没有开始的必要了，但是为什么做到最后确会觉得不好玩，这是个很难讲清楚的问题。修改玩法的问题在以往的开发经历中我遇到了好几次，而且有时候会在一个点上推翻好几轮。经过思考之后我觉得这可能还不能单纯怪玩法，很多游戏的玩法单看都是很简单的，但之所以好玩还依靠了画面的衬托、良好的手感和音乐音效等其它因素的辅助。

    所以我觉得有一些被推翻的玩法真的可能是被误杀的。因为在游戏没有完工之前是粗糙的，缺乏良好的画面、手感、音乐、音效和特效的衬托，没有办法让我们完整的评价这个玩法。比如你控制几个由方块组成的小人去打很多其它的方块小人，可能会觉得非常无聊，但把人物换成张飞或关羽，再配上宏大的场景，优美的音乐，良好的音效和炫目的特效，你会觉得非常过瘾。因为这就是三国无双。而光有效果没有玩法也一定是不行的，其实这些因素完美的结合在一起才能造就好玩的游戏，缺一不可。就像一部缺少优秀故事情节，而仅拥有豪华演员阵容和完美特效的电影一样，它终究不能算是一部好电影。

    不过这只是我的一点心得，毕竟我不是专职策划，不能从理论层面来分析玩法这个问题。但不管怎样以后开发的时候在玩法的选择和调整一定要慎重，最好能快速搭建一个原型系统来验证玩法。

技术失误

    这个问题大多由程序自身造成的。因为程序员终究不是安于现状的人，所以总是想与时俱进，改造现有的架构，引入新的技术等等。但这些对项目来说都是风险，而且是很大的风险。在这个项目中就在这个地方吃了一点亏，好在最后没有出很大的问题。

    这次出问题的地方就是脚本了，之前我们在项目中也引入了Lua脚本，但用的不是很深入。不过现在在游戏中使用脚本是很普遍的事情了，所以我们也觉得是不是应该把脚本整到我们的项目中。这时候程序员的那种精神来了，咱不能比别人差呀，于是决定在项目中引入脚本，而且还是在项目进度执行到一半的时候做出了这个决定。于是对程序架构做了重大改变，把相当一部分c++写的代码改用脚本实现。最后的结果就是大幅增加了工作量，因为原先很多功能c++已经实现，改为脚本就是重新翻译和整理一遍。

    另外开发语言从最擅长的c++换为Lua也注定会出现问题。一门陌生的语言想要精通必须要深入实践才行，而且越用才能越有心得，所以这个代价就是项目后期把早期写的脚本全部重构了一遍。当然客观来说最后还是发挥了脚本的好处，当然这些技术细节就不在这里详述了，以后有机会可以单独再写一篇关于脚本实践的文章。是那句话，人比工具重要的多，就算有再好的工具而没有能驾驭的人也是白搭。无论多先进的工具，在引入项目时如果没有熟悉的人，都将存在极大的风险。

    PS：我们还有一个更大型的项目，在开发过程中引入脚本，由于原先程序过于复杂，中途终止了脚本的引入，最终只有少部分模块引入了脚本，对项目的后期开发和维护产生了很不好的影响。

 

总结

    从项目来看实现了最初的想法,达到了预期的目标。但从游戏角度来看这不一定是个好游戏，无论从画面上和玩法上都还有很多的不足，当然这些不足有一部分是受预算影响的，所以留下了一些遗憾。但对团队来说是一次真枪实弹的历练，让每一个人又经历了一次完整而独特的游戏开发流程，这对以后的开发来说又积累了宝贵的经验。

转载于:https://www.cnblogs.com/cppguru/archive/2011/12/20/2294319.html