游戏中的设计模式与编码原则

一. 设计模式

设计模式(DesignMode)是前人开发经验积累总结的精华的设计方法，是被反复利用取得较好的效果的设计思路，设计模式有利于工程的清晰有序的组织，有利于开发者之间的交流，容易被其他开发者所理解和使用或者维护。

1.1单例模式（Singleton）

单例模式是游戏开发中最常用最简单的一种模式，用静态方法（类方法）实现让某个类只有一个实例，并且提供一个静态的公有全局函数来访问其私有对象使其为整个系统所共享。

游戏中单例模式基本上必不可少，比如：某个游戏场景中只能有一个实例化的场景，场景的私有成员要可以供其他成员或系统访问；某个游戏场景可能只能有一个控制器，或者只能有一个主角等等。

1.2观察者（Observer）

在观察者模式中，对象和对象之间建立了一对多的依赖关系，改变被观察的对象的状态后，关心此改变的观察者都会被通知，典型的例子是游戏中的UI事件机制，比如一个按钮点击后会通知相应的管理器接收事件进行处理，用户的操作会通知所有相关联的对象。

1.3工厂方法（Factory Method）

设计模式中的工厂方法指的是，通过定义一个接口实现将某个类的实例化推迟到子类，想要实例化哪一个类由子类来决定。例如：如果在一个机战游戏中使用工厂方法来创建实例化游戏中的主机、敌机、子弹、Boss等频繁重复创建的对象，工厂函数在真正创建某个对象之前并不知道要创建哪个类的对象，而直到具体到子类是才知道要创建的是主机、敌机还是子弹，实际上就是重复利用一个创建生产方法来重复性创建不同类的对象。

1.4迭代器（Iterator）

迭代器是一个用来访问一些聚合的统一管理资源的访问工具，利用迭代器的First、Next等方法可以依次访问像List、Vector、Dictionary等一些语言里的数据结构里的对象

元素，但不暴露对象的内部表示。

1.5访问者模式（Visitor）

游戏中访问者模式主要是针对一些结构中操作很多，元素繁多复杂，但类的变化不多的时候，就应该将操作独立出来并统一，从而避免污染这些对象。比如：Unity中的各种组件作为场景中的一个节点可能有一些共同的方法，但方法的具体实现不同，要想在外界统一调用，就要让他们继承同一个父类，父类的统一接口调用时他们返回自身不同的对象从而判断进行不同的具体操作。

1.6 MVC模式在游戏中的应用

MVC将程序分成三部分：模型（Model）、视图（View）和控制器（Controller），尤其是在网络游戏中除了用户界面交互和游戏逻辑处理，还要涉及到数据的大量传输，将这三部分分开各自处理各自负责的部分，从而使复杂的游戏系统变得更清晰和层次化。游戏中的MVC主要对应为数据层、表现层和逻辑层。

数据层主要是指游戏中的各种数据资源：声音、图片等等。资源在工程中开始是原始的数据，在程序中需要代码封装将原始资源变成代码可控的对象资源。比如Unity中的Texture材质类、AudioClip声音片段等等。

表现层在游戏中是以Scene场景来展示的，以及控制场景切换的控制器，比如Cocos2d中的Director导演控制器与Scene场景类，通过场景来展示一个承载大量UI组件图片精灵等可见事物对象。

逻辑层又要分成数据接口层、游戏AI层和操作控制层几部分。数据控制层主要是要从数据层提取数据并进行封装用于逻辑处理与存储。AI层是游戏控制的核心，负责控制游戏中对像的状态改变，以合理的方式去执行任务协助玩家或者与玩家共同进行游戏。操作层主要是指玩家操作事件的处理。

1.7游戏中的面向对象编程（OOP, Object Oriented Programming）

游戏尤其是角色游戏本身目的是尽可能模拟一个虚拟的世界，面向对象是非常重要的实现手段和理念，更符合现实世界对象的概念，不同对象有共同的属性共同的功能，也有自己独特的属性独特的功能，通过面向对象的思想可以完美的来表达描述和操作游戏中的角色事物。

角色游戏中的一个角色会有名字、性别、血量、攻击力等复杂的属性，同时又有走路、跑步、攻击等复杂的动作功能，通过面向对象用一个类便可以将一个角色封装起来从而清晰的表达一个角色的完整的生命周期与状态以及与其他对象的交流互动。

二. 编码原则(ProgrammingPrinciple)

2.1低耦合

耦合度的高低主要是指两个模块之间的依赖程度，游戏开发中为了防止逻辑混乱降低维护难度一般需要尽量降低类与类之间的耦合度。机战游戏中主机与敌机、子弹与敌机、主机与敌机子弹之间的碰撞检测都需要有一方对另一方进行引用计算，碰撞检测的处理如果分散放在不同的类内就会增加耦合度。因此为了降低耦合度应该将碰撞事件广播出来统一到一个碰撞事件控制器中进行独立集中处理。

2.2代码复用与完整性

高效游戏开发都需要借助于游戏引擎和框架，框架提供了丰富的可重复利用的基类，但有时候由于游戏功能需求需要扩展框架的类，这时候为了保证框架代码的完整性应该通过扩展或者继承的方式来为框架类添加需要的属性和方法。

2.3可扩展性

可扩展性指游戏中定义的类应该想框架那样容易扩展，尽量简化抽象化基类，然后子类继承通过多态性等实现基类的扩展，完成更丰富的功能适应功能更复杂的情况。

2.4开闭原则

指的是基类对于扩展是开放的，可通过继承等方式进行类的扩展，但对基类的修改是关闭的，不允许对基础类进行修改。