迷你小猴子村庄

随便画画

设计模式，不同的输入的自定义，接口

using System.Collections;using System.Collections.Generic;using UnityEditor;using UnityEngine;public class terraintest : MonoBehaviour{ // Start is called before the first frame update void Start() { } // Update is cal.

LinePush(box,box,box……)1. 检查box是否隶属于什么组groupA、groupB……。2. 如果属于组，则返回outcomeGroupPush()。3. 如果不属于组，则返回outcome BoxPush()。4. 2和3为递归，如果返回outcome都为true，则提取outcome后面的内容进行现实效果推移。outcomes记录为多条outcome链，每个链的形式如下，只有全部的链都返回true时，才开始往后执行。根据最近的记录开始处理现实效果。记录.

这个奇异推格子和普通的推格子游戏的区别在于2点：1. 有些格子是连在一起的家具块。这些家具块如果连在一起（没有裂缝），则被推一个会整个被推。2. 格子有可能破裂。如果它的形变承受力较弱的话。这很好理解，就是指我们推一个塑料到一个墙上，塑料有可能就扁了。事先声明：想过很多自然界的模型，但与推格子的抽象程序不符合。1,2两点是模拟了我们推箱子中的两个自然情况：一是黏着的东西整体被推。二是东西也有可能被推碎了。只需要实现这两种情况即可，其他元素仍然是非常抽象的推箱子。算法示意

花了一点时间完成了语法分析器。现在它应该可以实现自定义的语法。我一直都在想，如果要做这方面的一个设计模式，应该怎么处理我的游戏架构的接口呢？现在我觉得有趣的是现在觉得有趣的是，语法树处理一个战斗，结果在语法中是得到一个新的东西，还是返回一个已经改变的旧的？这件事一直在困扰我。新的和旧的有很多的含义，首先它们是区分，何时触发你想要触发的那个功能？其次可以这样想，它们只是将这个过程包裹起来而已，比如用一个action来包裹（a和b），然后把这个action返回出去。这个action是哪个类别？无所

更新方法模式涉及到我们平日设计模式时用的最多的一种东西，类似unity3d里面的update函数，在超级玛丽里，它可以模拟小乌龟小蘑菇在出现后的行为。哪怕是像象棋一样的游戏，我们不用随时更新它的行为（因为是由玩家触发的），但我们也需要更新它的动画。所以非常常见。这里的默认设定是由一个数组储存着这些需要update的对象。问题在于：为了让多个对象同时独立的运转，我们也许也要使用多线程。（需要参考11章 字节码模式）独立过程中的顺序问题，一个已经在A更新中死去的动物，不应该去读它的更新。这怎么办？标记

说到命令模式，本书中记录了它如何实现倒退，以及实现用流的方式将命令用在任何怪物，以及任何AI触发的情景上。在2.5参考中，作者提到了子类沙盒这个概念。听上去非常有趣。忍不住预先看看第12章。第12章看完了，这个子类沙盒似乎是一种思考方式（做游戏的平日里会经常思考的那种，书中说它很像是外观模式），里面最后有几个点很有帮助，问题：当基类的内容很多，难以调试时怎么办？回答：新建一个总结了某一块内容的类，比如音乐类，让基类去获得。这样可以在音乐类中维护一些音乐接口。问题：要外部调用时，每一个子类都需要初

装饰模式：动态地给一个对象添加一些额外的职责，就扩展功能而言，该模式比生成子类方式更为灵活。如果我按照继承树的方式来处理，那我生成一个实体【石榴树】，类与类之间的结构会帮我把所有内容处理好。但我如果要更改其中一个步骤，比如创造一种石榴树，保留其他特性，但不能存在！（好吧，非常抽象，大概理解为，这个石榴树是非存在物，是一种灵体），那我就要重新做一个这样的区别。如果我用装饰器的方法，我可以一层一层去包裹这个石榴树，最后建成它。比如【石榴树！【树【植物【生物【物体【存在】】】】】】这两个之间有什么区别

模板方法模式，可变性在于算法中的某些步骤。力量在于确定多样的顺序。它的解释如下：定义一个操作中算法的骨架，而将一些步骤延迟到子类中，使得子类可以不改变算法的结构即可重新定义该算法。这说实话，哪里都能用。子类中的写好的具体方法终究会以一些固定的顺序被调用（而父类规定了这个顺序）。我想到一个地方可以用——框架挑战*序中的7。试试看可不可以。首先是最基础的继承链条。【存在】-【物体】-【生物】-【植物】-【树】-石榴树其他链条有 -【花】-玫瑰【存在】-【物品】-【果实】-苹果它们分

为了设计一个比较妥善的框架来支持我底层的一个游戏公式。我想借用一下设计模式的威力。现在来分析一下我的需求：基本实现：玩家&砍&石榴树 =（-1精力的）玩家&砍&（木块+木块+木块）初步构架：【砍】继承一个【动作】类。砍的结果与砍的对象的类、实例数值有关【策略模式】，且有随机性。【模板方法模式】【砍】支持多种参数，如（玩家、石榴树、翻倍石）或（玩家、石榴树），使用多态完成。动作的多样性支持【装饰模式】，方便对简单的行为进行扩展。比如高级【砍

工厂方法模式属于很简单的模式。就是把建造对象包在一个盒子里。造一个盒子，然后告诉它你要创建一个a或者b对象……在这里，其实就是Factory。即把角色Icharacter的对象产生的地点，都整合在一个characterfactory下面。没了。为了方便各种制作，游戏有很多Factory【武器、角色、属性】。这些类都只有一个实例，所以作为静态方法被放在一个巨大Factory里。...

建造者模式（Builder）！耳濡目染，久闻大名。一个有个性的builder类，规定了某些固定流程我要怎么build。就像是一个写好了需求的订单~【规定了流程噢！】订单里面存的是过程。所以我们可以有一个父类，规定了过程。然后一些子类，规定了如何实现其中的过程。这其实就是所有信息啦！~订单~给产品do1（实打实的do）给产品do2（实打实的do）给产品do3（实打实的do）我们创建一个订单。然后把订单扔给机器。机器表示：收到！机器：已生产产品模型new product.机器：执行订单

享元模式！几乎任何时候都需要思考的，一个实例是可以复用的嘛！还是每一个调用者都需要有一份新的？在游戏属性管理时，我们可以看到属性可以被切割两次：共享or不共享变化or不会变化这部分是大家都有的属性。而且固定的。我出生时就是这样的数据。基本不会变化。它成为了一种配置。比如超级士兵最高public class BaseAttr{private int m_MaxHp;private string m_AttrName;private float m_speed;public Ba

这个模式很好理解。就是发挥继承的一个功能。一个父类，做一些方法。一些子类，实现这个方法。结束。理论上为了抽象，可以一层一层包。一般是把方法按照顺序包好。这样子类就无需处理顺序的事情了，只需要处理内容。复用 顺序。...

策略模式看到这里，觉得策略模式是我见过最有用的啦。我们遇到很多很复杂的东西，就用策略模式来处理。有哪些复杂的东西呢！比如公式计算。不同的职业的魔法抗性不同，有些技能扣血的方式也不一样。要如何做到简单的分离各种不同的计算方法，让玩家去挑选一个组的。就像游戏中的例子是考虑到了人物 和 怪物，虽然同为character，但计算时候有如下分别：敌人会有机会暴击增加额外攻击力。玩家可以通过兵营来升高自己的生命力。策略模式就是，建立敌人和玩家各自的策略。策略继承策略类。策略父类有着一些会被调用的计

书作者表示，桥接模式是他认为最好应用也是最难理解的。看完本章后，无疑感叹桥接模式的伟大。确实是非常好用的一种模式~一般来说用在抽象与实现分离的情况比如有许多形状，需要支持draw。有几种引擎，可以实现render，但代码不同。为了方便扩展，那么让各个形状继承于抽象形状类。并各自在自己的draw_real中调用父类draw。而父类draw也早就获得了引擎子类，子类重写父类的render方法->引用到自己带的代码中。两个群组因为功能上的需求需要合作但又想各自发展无关对方就是书里的情况【人物

单例模式就是只创建一个 且 方便引用只创建一个是通过static完成，类中有一个private static 的自己实现方便引用是通过get_set方法如果没有创建便直接创建一个private构造函数不允许外部访问。OK。书本中为了避免使用单例模式，提供了【只创建一个——计数器】和【方便引用——构造时直接传入单例等】等方法。中介者模式gameController 创建【Mediator】UI总类获得gameController 【ConcreteColleague1】LOGIC总

这个模式比较简单，没有什么要说的。外观类提供给调用者访问内部系统的方法。

（恶棍版本的笔记——即不好好说话的笔记）状态模式是一种内部状态的转换。神奇。我一开始以为 状态模式就是藏着switch的情况。但是关键是它如何隐藏自己的外壳被调用。就是调用者调用各种状态的情况。要达成这一点，需要各种状态需要知道调用者各种状态需要知道其他状态（可以建立它们）存在一个抽象状态，【⚪】它表示所有状态的当前选择。它的信用有：所有未来、过去、现在状态能够满足它的规格。流程调用者直接对【⚪】进行各种消息的处理。这些消息会直接进入调用者绑定的state中，被state调用。sta