[游戏] 网络游戏：为什么失败

来源：http://blog.csdn.net/Nightmare/archive/2005/06/29/407235.aspx

继互联网、电子商务、软件培训后，网络游戏是又一个被炒得过热的领域。随着钞票疯狂的砸下来，血拼的优胜劣汰进程也就开始了，如果不能走向成熟，就会走向失败。

开始的时候依靠的是概念和狂热，或者爆发或者默默消亡。第二批开始有竞争，但出于抢站市场的欲望，不论输赢都可以继续砸钱。第三批就是不理智的stampede，一拥而上，不想被踩死就要跑在最前面。

常见错误1：包罗万象的目标

有远大的目标是好事，但不是做事的方法。当问到“我们要做的游戏是什么”，如果回答如“我们的游戏将包含游戏A的所有功能，还有游戏B里的新花样，并且还改进了C系统，增加了独一无二的D系统，还有……”，那么这个项目就有这种危险了。如果一个东西什么都是，那么它就什么都不是。在设计如此庞大的体系前，最好先研究一下：

1. 项目的预算有多少
2. 能允许的最长开发时间是多少
3. 人员数量和经验，以及对复杂系统的控制能力
4. 目标用户群是什么样的人，他们喜欢玩哪些东西
5. 竞争对手有哪些，他们的产品的特点

尤其对资金有限的创业公司来说，预算和开发周期是主要制约因素，必须以尽量小的代价去获取尽量大的成果，盲目开始项目只会让后期进入进退两难的境地。

常见错误2：显示引擎就是用来显示场景

经常能看到有些客户端的招聘要求里只有对Direct3D和显示特效的强调。也就是说，很多人只看到了3D引擎、在3D引擎里又只看到了模型和特效。但它们只是一小部分，而且并不是最有技术含量的部分。因为3D技术已经发展了很多年，尤其是硬件发展速度快，硬件厂商巴不得软件开发人员用上他们提供的所有先进技术，所有的技术都是开放的，都有详细的文档和样例。到今天已经是几乎每个人都自己写一套3D引擎的地步，开源的引擎都已经一抓一大把了。

但这并不是说每个3D引擎都一样，相反它们有很大的差别，一个好的引擎是有很多重要而有技术含量的功能的，而一般个人做的引擎都很简单，功能甚少，但它仍然可以叫引擎，可以绘制模型和一些特效。需要什么样的引擎由游戏本身的需求决定，也可能很简单的就够了，也可能要功能相当完整的。这里给出个比较完整的显示引擎功能的单子：

1. 图元绘制
2. 模型绘制，最好支持多种模型格式
3. 模型预览工具
4. 给3DSMax、Maya等的模型导出插件
5. 半透明对象的排序
6. 动画（硬动画、顶点动画、骨骼动画）
7. 贴片功能
8. Billboard支持
9. Lightmap贴图
10. 至少一种绘制影子的技术，如Shadow Volume, Shadow Map或者简单的投影一个黑圈
11. 至少一种绘制天空的技术，如SphereMap、CubeMap
12. 资源滚动装载（在显示资源很多时很重要）
13. 粒子系统，最好是可由脚本编辑的，这样就不再需要程序员干预制作过程
14. 对Shader支持和足够的调试功能
15. Unicode的文字绘制
16. Scene Graph管理，QuadTree、OctTree或者BSP等
17. 大场景会用到LOD的功能
18. 图层支持
19. GUI系统
20. 资源文件打包支持，最好支持ZIP格式
21. 性能分析支持，至少包括FPS、每帧三角面数、每帧DrawPrimitive的数量
22. 室外游戏会需要Terrain系统的支持
23. 镜头特效，如光晕、震动等
24. 文档，包括针对使用引擎的程序员和使用相关工具的美工人员的

可以发现，一个比较完整的3D引擎是个庞大的系统，它的整体架构的好坏就变得很重要。细心的人会注意到这里没怎么提到特效，也就是很多人最关注的问题。事实上，大部分的特效制作源于美工，而程序提供一个基础的支持，如果等着程序员写出每个特效，那就只能指望延长工期了。

常见错误3：客户端就是显示引擎

显示引擎只是个基础层，它不是业务层，而业务层才是真正的客户端。好比你有了锤子和钉子，你只是有了工具，钉钉子才是你要做的事情。客户端要做的事情如：

1. 处理网络的数据
2. 声音引擎
3. 维护、预测游戏世界的一个窗口的状态，并聪明地进行图像声音上的表现
4. 输入处理
5. GUI系统的交互，想尽各种办法改进用户体验
6. 游戏编辑、调试工具
7. 安装、在线更新工具

这里很可能需要把一部分定制的工作交给制作人员，比如GUI界面，因为他们经常需要调整改善设计，因此，设计可定制的GUI系统会增加一些难度。如果3D引擎里已经支持则只需要再提供一些游戏逻辑的接口，否则就要费些心，在这里提供一套配置方案。

常见错误4：直接向最终目标努力

网络游戏是个大工程，不是几个月就能完成的。早期的设计不可能是完美的。如果直接向最终目标努力，那么可能到后期游戏才运行起来，才会发现问题，但这时已经太晚了，更不用说长时间的看不到效果的工作会让士气低落。正确的方法是尽量早的让游戏运转起来，哪怕只能发几条Hello消息，然后再向里面加入更多的功能。不要等半年之后底层系统完成之后才开始搭建游戏，这时很容易会因发现问题或者需求变化不得不修改底层，如此反复，拖累甚久。