观点：关于游戏系统的规划、设计与实现。

 

观点：关于游戏系统的规划、设计与实现。

1.游戏软件的画面形式大都是直接写屏的。它的最大好处就是平台无关性，而不用考虑纷繁复杂的window界面规范，不用考虑很多与界面相关的api或者mfc。瞥开这些无谓的平台特性，设计者可以非常自由的架构游戏界面系统以及表现形式。如果用目前主流的OOD设计的话，体验后的设计者的设计水平可以有非常大的提高。因此游戏系统设计非常合适做学习软件设计的案例。

2.如果想找一系列模式来概括游戏系统设计体系来形成独特的工程规律，其实是不必要的。从软件系统的角度去观察，游戏软件系统和普通的应用软件一样，它的内核就是数据，这个数据描述了一个状态，这就是整个软件系统的当前状态。游戏在运行发展，应用软件也在被控制，这些现象的实质就是系统状态的发展与更新----数据在变化与更新。是什么触发了状态(数据)的变化呢，是独特的软件规律，也就是说每个软件都有不同的系统状态更新规律(例如用户输入，事件触发，系统行为或是状态发展)，而这就是所谓的系统规律。每个应用软件都有自己的系统规律，而每个游戏软件也都有自己的系统规律，而这就是软件系统设计的依据，它需要被抽象、被规划、被封装。因此完全可以把游戏软件系统与别的其他的软件系统同等看待，他们是一样简单的、或是复杂的。 ^_^
补充一点：其实游戏系统很多之处都可以归纳出统一原理，例如精灵管理，地图管理等等。我认为这些都是局部设计与算法，还未到系统规律的高度。

3.关于架构软件系统，特别是以面向对象的方式。

我就简单说说我的一些心得吧：

#.事先尽量将软件需求做得详细、完备。

#.先从全局上规划整个系统。特别要考虑需求的变数以及系统的重用性、扩展性。

#.接着构造系统的模块，划分模块的功能及分布。注意将相对稳定的系统状态与系统 规律及系统变化分离，抽象出变化与联系将以封装，使得系统某个方面的变化可以独立与其他方面。MVC(model/view/control)方式是一个简单而典型的例子，3者能独立发展且重用。再针对你上边的例子，怪物的外观动作和怪物间的行为，前者描述了对象的外观，后者可能描述了对象间的交互—这里可能会存在变数。如果将怪物间的交互动作(例如“咬”)分离出来(可以构造一个识别Pacman类的PacmanAction类)，让其与怪物本身外观行为得以独立发展，相信系统的变化就会灵活许多，譬如你可以填加各种行为例如Talk，Kiss或是FakeDead ^_^ 等等而不必再大肆修改Pacman类或类层次，让这些动作与怪物自身的外观行为进行自由组合，相信其乐无穷。抽象变化将其封装就是这个意思。

#.有了模块图后，再将其细化为类图，这时类的继承系统以及类之间的通信关系一定非常明晰，经过一番精巧的局部构造后，相信当前的系统就会非常合理、优雅且充满能量。

#.接着……大概就是快乐或痛苦地编码了吧，反正是体力活儿~~ 好处是同时你还可以一边和mm聊天。*_*

#.接着就是痛苦的调试了L，不过相信有了构造合理的系统，一切行为与变化都显得非常清晰可以全盘控制，同时你还可以一边和多个mm聊天。: J

篇幅所限，有些观点说的比较抽象，希望大家得以指正。%_#