游戏编程模式学习（编程质量提升之路）

前言

在稍微学习游戏编程常用的设计模式，用于到框架设计当中，再进一步替身编程质量
文档地址:https://gameprogrammingpatterns.com/
中文地址:https://gpp.tkchu.me/

一、命令模式（Command Pattern）

将一个请求（request）封装成一个对象，从而允许你使用不同的请求，队列或者日志将客户端参数化，同时支持请求操作的撤销和恢复。

命令就是一个对象化（实例化）的方法调用。

补充：
commands are an object-oriented replacement for acallbacks.
命令是面对对象化的回调。

注解:无论使用哪种方法阐述，命令相当于对函数（或者叫方法、回调、行为、DoSomeThing）的一种延伸和封装，试之具备良好的扩展性。

1.命令模式练习场景

I.需求场景

实例-输入响应。四个键对应角色的不同行为。
基础是实现代码如下：

void InputHanlder(){if(Input.GetKeyCode(KeyCode.X)) jump();else if(Input.GetKeyCode(KeyCode.Y)) fireGun();else if(Input.GetKeyCode(KeyCode.A)) swapWeapon();else if(Input.GetKeyCode(KeyCode.B)) lurchIneffecively();
}

上面代码是将所有检测按钮命令的代码写进到了InputHandler里面。而如果使用基础的命令模式来实现，如下创建一个Command类

class Command{ public virtual void execute(){};
}

创建各个子类

class JumpCommand : Command{ public override void execute(){jump();}
}class FireCommand : Command{ public override void execute(){swapWeapon();}
}class SwapWeaponCommand : Command{ public override void execute(){fireGun();}
}class LurchIneffecivelyCommand : Command{ public override void execute(){lurchIneffecively();}
}

这样通过各自Command的子类来实现对应的操作。

管理器中存储基类，实例化为不同的子类，输入通过实例进行处理

class InputHandler{private Command buttonX;private Command buttonY;private Command buttonA;private Command buttonB;public void handlerInput(){if(Input.GetKeyCode(KeyCode.X))   buttonX.execute();else if(Input.GetKeyCode(KeyCode.Y)) buttonY.execute();else if(Input.GetKeyCode(KeyCode.A))  buttonA.execute();else if(Input.GetKeyCode(KeyCode.B))  buttonB.execute();}
}

补充：使用空对象模式来处理null，可使用工厂模式来完成空对象的创建。

再创建一个简单的Factory类型来对InputHandler对象赋值

public static class CommandFactory{public static Command Create(KeyCode keycode){switch(keycode){case X: return new JumpCommand();case Y: return new FireCommand();case A: return new SwapWeaponCommand();case B: return new LurchIneffecivelyCommand();default:throw new InuptOutOfRangeException("error keycode!");}}
}

2.解耦命令与执行者

加入我们要具体实现jump方法的功能的时候，这里是跳跃的指令，所以把跳跃的执行者依赖到JumpCommand当中会有一个问题，因为Command父类里面没有获取JumpBehavior的方法，缺乏内聚性，也违反了开闭原则。

class JumpCommand : Command{ public JumpBehavior Behavor;public override void execute(){ Behavor.Jump();}
}

应该将命令和执行者进行解耦，当然执行者本身也需要进行一下抽象，代码如下:

class JumpCommand : Command{  public override void execute(IBehavior behavor){ behavor.Jump();}
}interface IBehavior{public void Jump();
}

通过传入参数的方式来减少类的依赖。进行execute时将对应要执行命令的执行者传入过来。

3.使用命令对玩家角色和AI的操作进行统一抽象

对AI角色使用同样命令操作，输入命令的实现交予AI【可使用状态机，行为树等】
通过命令流实现生产者端-消费者端解耦（人工智能->命令流->角色）

首先需要实现一个AIAtcor,而这个AIActor本身是执行者，所以继承IBehavior

public class AIActor : IBehavior{private ICommand[] Commaands;private float stayTime;private ICommand lastCommand;private Command JumpCommand;private Command FireCommand; protected void ICommand HandleInput(){if(stayTime > 0){stayTime -= Time.deltaTime;return lastCommand;}stayTime = Random.Range(0,2);if(Commands == null){Commands = new ICommand[]{JumpCommand,FireCommand};}int rand = Random.Range(0,2);lastCommand = Commands[rand];return lastCommand;}
} 

4. 命令模式的撤销实现

原理是如果一个命令对象能做一件事情，那么这件事情是可以撤销的。

实现方法，提取命令：
1.注意保存具体的信息，而不是统一的行为。
2.此时的命令不是重复执行的对象，而是根据实际情况，在所需的时机不断创建的实力。

定义并实现Undo

//假设操作是一个简单的移动操作
void Undo(){MoveTo(Vector3 before){//执行前保存下before的}
}

class MoveCommand : Command{private Vector3 currectState;private Vector3 before;private Vector3 nextState;public MoveCommand(Vector3 state,Vector3 nextState){currectState = state;nextState = nextState;}public void Excute(IBehavior behavor){before = currectState;behavor.MoveTo(nextState);}public void Undo(IBehavior behavor){currectState = before;behavor.moveTo(before);}
}

这里是保存before状态，回退的核心。多条撤销与重做的情况下，需要用数据结构List保存命令
Undo=>回退上一条，并前往移动前保存的位置before
Redo=>执行当前标志位的下一位，并且在把标志位指向下一位
这里编写一下代码

补充，实现记录的方法有两种
1.备忘录模式，即记录快照（常用设计方式，数据在命令中）
2.持久化数据，即保存新的实体对象（每次创建新的命令，都创建一个新的命令执行对象的主体。数据都在执行者身上）

二、享元模式

1.应用场景

I.大量相同相似的对象
II.可按内容状态分组，并将不同的部分外部化
III.享元实例足够多的情况下才有必要

2.目的

I.减少大量内存使用
II.降低程序需要处理的数据量
III.创造需要共享信息的大量实例更加方便

3.实现方式

设计数据结构，使之包含共享部分。对象非共享部分额外存储，对象实例引用共享部分，不对其进行修改。

这里使用Unity的ScriptableObject举例子，简单创建下结构

[Serializable]
public struct ObjectFlyweightData{public Mesh mesh;public Material[] materials;
}[Serializable]
public struct SceneObject{public ObjectFlyweightData flyWeightData;public string name;public Matrix4x4 localToWrold;
}public class SceneObjectGroup : ScriptableObject{public SceneObject[] SceneObject;
}

上面比如说，我们在场景中有很多对象，而场景中的使用相同的网格和材质的东西可以作为享元部分。

三、原型模式

1.运用场景

当对象有一些比较通用的状态时，可以考虑从原型模式开始构建新的对象，从而避免从零开始构建新的对象。

从零开始构建的缺点：
几乎没有进行复用，造成浪费
结构相似，内部状态接近，仅有部分不同的物件，构建逻辑重复度高

2.实现方式

步骤一、对原型的全部状态进行克隆（根据情况进行深度克隆还是浅度克隆）
步骤二、后续对与原型不同的状态进行修改，重新赋值

实现途径有多种
1.原型类上面实现clone方法
2.使用构建者Spawner来实现

这里实现一个原型生成器

public class PrototypeSpawner : MonoBehaviour{public GameObject Spawn(GameObject prototypeObject,PrototypeSpawnAdditionalDataGroup additionalData){var target = Insrantiate(prototypeObject);if(additionalData!=null){additionalData.AttachTo(target);}return target;}
}public class PrototypeSpawnAdditionalDataGroup : ScriptableObject{public PositionAdditionData Postion;public MainMaterialReplaceAddition MainMaterial;public ArmScaleAddition ArmScale;public void AttachTo(GameObject target){Postion?.AttachTo(target);MainMaterial?.AttachTo(target);ArmScale?.AttachTo(target);}
}

上面代码是把prototypeObject作为原型，PrototypeSpawnAdditionalDataGroup里面是作为不同原型的修改的数据。

四、状态模式

假设我们在完成一个卷轴平台游戏。 现在的工作是实现玩家在游戏世界中操作的女英雄。 这就意味着她需要对玩家的输入做出响应。按B键她应该跳跃。简单实现如下：

public class Heroine : MonoBehavior{void Update(){if(Inuput.GetKey(KeyCode.B)){Jump();}}
}

看到漏洞了吗？
没有东西阻止“空中跳跃”——当角色在空中时狂按B，她就会浮空。 简单的修复方法是给Heroine增加isJumping_布尔字段，追踪它跳跃的状态。然后这样做：

public class Heroine : MonoBehavior{bool isJumping = false;void Update(){if(Inuput.GetKey(KeyCode.B)){if(!isJumping){Jump();}}}
}

接下来，当玩家按下下方向键时，如果角色在地上，我们想要她卧倒，而松开按键时站起来：

public class Heroine : MonoBehavior{bool isJumping = false;void Update(){if(Inuput.GetKey(KeyCode.B)){if(!isJumping && !isDucking){Jump();}}else if(Input.GetKey(KeyCode.Down)){if(isDucking){Duck();}}}
}

这样进行开发，我们会发现，每次添加新的功能都要添加多一个bool值来进行判断和约束，当功能越来越多就会bool的数量就指数增加，那么代码的复杂程度会指数级别增加。

这个时候是应该使用状态机的形式来进行开发。

祝贺，你刚刚建好了一个有限状态机。 它来自计算机科学的分支自动理论，那里有很多著名的数据结构，包括著名的图灵机。 FSMs是其中最简单的成员。

要点是：
你拥有状态机所有可能状态的集合。 在我们的例子中，是站立，跳跃，俯卧和速降。
状态机同时只能在一个状态。 英雄不可能同时处于跳跃和站立状态。事实上，防止这点是使用FSM的理由之一。
一连串的输入或事件被发送给状态机。 在我们的例子中，就是按键按下和松开。
每个状态都有一系列的转移，每个转移与输入和另一状态相关。 当输入进来，如果它与当前状态的某个转移相匹配，机器转换为所指的状态。

举个例子，在站立状态时，按下下方向键转换为俯卧状态。 在跳跃时按下下方向键转换为速降。 如果输入在当前状态没有定义转移，输入就被忽视。

1.实现轻量级的状态机

首先先对状态机进行抽象化

public interface IFsm{int CurrentState {get;}//添加对应的状态码，设置进入、退出、更新状态的时候调用的回调。bool AddState(int state,Action<int> onEnter,Action<int> onExit,Action<float> onUpdate);//删除掉这个状态bool RemoveState(int state);//更新函数bool Update(float time);//添加从状态from到to使用什么触发码bool AddTransiton(int from,int to,int triggerCode);//触发一下对应时间bool TriggerEvent(int eventCode);//状态切换bool SwitchToState(int stateId,bool forceSwitch);
}public class LightFsm : IFsm{private readonly Dictnary<int,Tuple<Action<int>,Action<int>,Action><float>> actions = new ();public int CurrentState{get;private set;}private Action<float> beforeUpdateCallBack;private Action<float> afterUpdateCallBack;private List<ValueTple<int,int,int>> transitions = new ();public LightFsm(int defaultState = -1,Action<float> beforeUpdate,Action<float> afterUpdate){CurrentState = defaultState ;beforeUpdateCallBack = beforeUpdate;afterUpdateCallBack = afterUpdate;}public bool AddState(int state,Action<int> onEnter,Action<int> onExit,Action<float> onUpdate){if(actions.containKey(state)){throw new Exception($"不能重复添加状态{state}行为");}actions.Add(state,new Tuple<Action<int>,Action<int>,Action><float>>(onEnter,onExit,onUpdate));return true;}public bool AddTransition(int from,int to,triggerCode){if(!actions.containKey(from) || !actions.containKey(to)){return false;}transitions.Add((from,to,triggerCode));return true;}public bool TriggerEvent(int eventCode){foreach(var transition in transitions){if(transition.Item1 == CurrentState && transition.Item3 == eventCode){SwitchToState(transition.Item2);return true;}}return false;}public bool AddState(int state){if(actions.ContainKey(state)){ actions.Remove(state);return true;} return false;}public bool SwicthToState(int stateId,bool forceSwitch = false){bool hasState = action.ContainKey(stateId);if(!hasState) return false;bool stateChanged = stateId != CurrectState;if(!stateChnaged && !forceSwitch) return false;if(stateChanged){if(actions.TryGetValue(CurrentState,out var oldActions)){oldActions.Item2?.Invoke(stateId);}}var oldStateId = CurrentState;var newActions = action[stateId];CurrentState = stateId;newActions.Item1?Invoke(oldStateId);return true;}public void Update(float time){if(actions.TryGetValue(CurrentState,out var actions)){beforeUpdateCallBack?Invoke(time);actions.Item3?.Invoke(time);afterUpdateCallBack?Invoke(time);}}
}

五、双缓冲模式

电脑具有强大的序列化处理能力。 它的力量来自于将大的任务分解为小的步骤，这样可以一步接一步的完成。 但是，通常用户需要看到事情发生在瞬间或者让多个任务同时进行。

使用线程和多核架构让这种说法不那么正确了，但哪怕使用多核，也只有一些操作可以同步运行。

一个典型的例子，也是每个游戏引擎都得掌控的问题，渲染。 当游戏渲染玩家所见的世界时，它同时需要处理一堆东西——远处的山，起伏的丘陵，树木，每个都在各自的循环中处理。 如果在用户观察时增量做这些，连续世界的幻觉就会被打破。 场景必须快速流畅地更新，显示一系列完整的帧，每帧都是立即出现的。

双缓冲解决了这个问题，但是为了理解其原理，让我们首先的复习下计算机是如何显示图形的。

计算机图形系统是如何工作的（概述）
在电脑屏幕上显示图像是一次绘制一个像素点。 它从左到右扫描每行像素点，然后移动至下一行。 当抵达了右下角，它退回左上角重新开始。 它做得飞快——每秒六十次——因此我们的眼睛无法察觉。 对我们来说，这是一整张静态的彩色像素——一张图像。

这个解释是“简化过的”。 如果你是底层软件开发人员，跳过下一节吧。 你对这章的其余部分已经了解得够多了。 如果你不是，这部分的目标是给你足够的背景知识，理解等下要讨论的设计模式。

你可以将整个过程想象为软管向屏幕喷洒像素。 独特的像素从软管的后面流入，然后在屏幕上喷洒，每次对一个像素涂一点颜色。 所以软管怎么知道哪种颜色要喷到哪里？

在大多数电脑上，答案是从帧缓冲中获知这些信息。 帧缓冲是内存中的色素数组，RAM中每两个字节代表表示一个像素点的颜色。 当软管向屏幕喷洒时，它从这个数组中读取颜色值，每次一个字节。

在字节值和颜色之间的映射通常由系统的像素格式和色深来指定。 在今日多数游戏主机上，每个像素都有32位，红绿蓝三个各占八位，剩下的八位保留作其他用途。

最终，为了让游戏显示在屏幕中，我们需要做的就是写入这个数组。 我们疯狂摆弄的图形算法最终都到了这里：设置帧缓冲中的字节值。 但这里有个小问题。

早先，我说过计算机是顺序处理的。 如果机器在运行一块渲染代码，我们不指望它同时还能做些别的什么事。 这通常是没啥问题，但是有些事确实在程序运行时发生。 其中一件是，当游戏运行时，视频输出正在不断从帧缓冲中读取数据。 这可能会为我们带来问题。

假设我们要在屏幕上显示一张笑脸。 程序在帧缓冲上开始循环，为像素点涂色。 我们没有意识到的是，在写入的同时，视频驱动正在读取它。 当它扫描过已写的像素时，笑脸开始浮现，但是之后它进入了未写的部分，就将没有写的像素绘制到了屏幕上。结果就是撕裂，你在屏幕上看到了绘制到一半的图像，这是可怕的视觉漏洞。

这就是我们需要这个设计模式的原因。 程序一次渲染一个像素，但是显示需要一次全部看到——在这帧中啥也没有，下一帧笑脸全部出现。 双缓冲解决了这个问题。我会用类比来解释。

表演1，场景1
想象玩家正在观看我们的表演。 在场景一结束而场景二开始时，我们需要改变舞台设置。 如果让场务在场景结束后进去拖动东西，场景的连贯性就被打破了。 我们可以减弱灯光（这是剧院实际上的做法），但是观众还是知道有什么在进行，而我们想在场景间毫无跳跃地转换。

通过消耗一些地皮，我们想到了一个聪明的解决方案：建两个舞台，观众两个都能看到。 每个有它自己的一组灯光。我们称这些舞台为舞台A和舞台B。 场景一在舞台A上。同时场务在处于黑暗之中的舞台B布置场景二。 当场景一完成后，将切断场景A的灯光，打开场景B的灯光。观众看向新舞台，场景二立即开始。

同时，场务到了黑咕隆咚的舞台A，收拾了场景一然后布置场景三。 一旦场景二结束，将灯光转回舞台A。 我们在整场表演中进行这样的活动，使用黑暗的舞台作为布置下一场景的工作区域。 每一次场景转换，只是在两个舞台间切换灯光。 观众获得了连续的体验，场景转换时没有感到任何中断。他们从来没有见到场务。

使用单面镜以及其他的巧妙布置，你可以真正地在同一位置布置两个舞台。 随着灯光切换，观众看到了不同的舞台，无需看向不同的地方。 如何这样布置舞台就留给读者做练习吧。

重新回到图形
这就是双缓冲的工作原理， 这就是你看到的几乎每个游戏背后的渲染系统。 不只用一个帧缓冲，我们用两个。其中一个代表现在的帧，即类比中的舞台A，也就是说是显卡读取的那一个。 GPU可以想什么时候扫就什么时候扫。

但不是所有的游戏主机都是这么做的。 更老的简单主机中，内存有限，需要小心地同步绘制和渲染。那很需要技巧。

同时，我们的渲染代码正在写入另一个帧缓冲。 即黑暗中的舞台B。当渲染代码完成了场景的绘制，它将通过交换缓存来切换灯光。 这告诉图形硬件开始从第二块缓存中读取而不是第一块。 只要在刷新之前交换，就不会有任何撕裂出现，整个场景都会一下子出现。

这时可以使用以前的帧缓冲了。我们可以将下一帧渲染在它上面了。超棒！

模式
定义缓冲类封装了缓冲：一段可改变的状态。 这个缓冲被增量地修改，但我们想要外部的代码将修改视为单一的原子操作。 为了实现这点，类保存了两个缓冲的实例：下一缓冲和当前缓冲。

当信息从缓冲区中读取，它总是读取当前的缓冲区。 当信息需要写到缓存，它总是在下一缓冲区上操作。 当改变完成后，一个交换操作会立刻将当前缓冲区和下一缓冲区交换， 这样新缓冲区就是公共可见的了。旧的缓冲区成为下一个重用的缓冲区。

1.使用场景

这是那种你需要它时自然会想起的模式。 如果你有一个系统需要双缓冲，它可能有可见的错误（撕裂之类的）或者行为不正确。 但是，“当你需要时自然会想起”没提提供太多有效信息。 更加特殊地，以下情况都满足时，使用这个模式就很恰当：

我们需要维护一些被增量修改的状态。
在修改到一半的时候，状态可能会被外部请求。
我们想要防止请求状态的外部代码知道内部的工作方式。
我们想要读取状态，而且不想等着修改完成。

记住
不像其他较大的架构模式，双缓冲模式位于底层。 正因如此，它对代码库的其他部分影响较小——大多数游戏甚至不会感到有区别。 尽管这里还是有几个警告。

交换本身需要时间
在状态被修改后，双缓冲需要一个swap步骤。 这个操作必须是原子的——在交换时，没有代码可以接触到任何一个状态。 通常，这就是修改一个指针那么快，但是如果交换消耗的时间长于修改状态的时间，那可是毫无助益。
我们得保存两个缓冲区
这个模式的另一个结果是增加了内存的使用。 正如其名，这个模式需要你在内存中一直保留两个状态的拷贝。 在内存受限的设备上，你可能要付出惨痛的代价。 如果你不能接受使用两份内存，你需要使用别的方法保证状态在修改时不会被请求。