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


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

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

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


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

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

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

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

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

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

#.接着就是痛苦的调试了L，但是相信有了构造合理的系统，一切行为和变化都显得很清楚能够全盘控制，同时您还能够一边和多个mm聊天。: J

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