游戏与其他软件最大的不同 就是游戏有Update逻辑 一般的软件是由"事件"驱动 因为它不会突然跑出来一只"兔子" 因此,只有游戏才有"帧"的概念 (没秒多少帧,就是没秒Update执行多少次) Unity有自己的生命周期 Awake,Start,Update- 只要继承MonoBehaviour就可以启用此生命周期 完整的生命周期请参看我以前写的博客http://www.cnblogs.com/fws94/p/6372557.html 虽然继承…
GoF中定义: "在一个操作方法中定义算法的流程,其中某些步骤由子类完成. 模板方法模式让子类在不变更原有算法流程的情况下,还能够重新定义其中的步骤" 每一次武器攻击目标时,都要按逻辑执行: 1.开火.枪口特效 2.子弹特效 3.武器特效 4.通知敌方被击中 而每一种武器(如:枪,炮)都要执行一遍相同顺序的逻辑 模板方法模式就是着手解决这个问题的 1.定义一个算法的流程,即是很明确地定义算法的每一个步骤,并写在父类的方法中,而每一个步骤都可以是一个方法的调用 2.某些步骤由子类完成,不…
前段时间在忙一个新项目 博客好久没有更新了 GoF中定义: "将对象以树状结构组合,用以表现部分-全体的层次关系.组合模式让客户端在操作各个对象或组合时是一致的." 是一致的意思就是:能够对根节点调用的操作,同样能够在叶节点上使用 "分层式管理结构"一般也称为"树状结构" Unity中对于游戏对象的管理,也应用了树形结构的概念 让游戏对象之间可以被当成子对象或设置为父对象的方式来连接两个对象 public abstract class IComp…
GoF中定义: "使用共享的方式,让一大群小规模对象能更有效地运行" 享元模式一般应用在游戏角色属性设置上 游戏策划需要通过"公式计算"或者"实际测试"等方式找出最佳的游戏属性 因此,在游戏系统中建立一个管理方式来建立和存储属性信息就显得尤为重要 对象中那些只能读取不能写入的共享部分被称为"内在状态" 如:最大生命(MaxHP).移动速度(MoveSpeed)等属性 还有不能被共享的部分,被称为"外部状态"…
GoF中定义: "将一个复杂的构建流程与它的对象表现分离出来,让相同的构建流程可以产生不同的对象行为表现." 建造者模式可以分为两个步骤来实施: 1.将复杂的构建流程独立出来,并将整个流程分成几个步骤,其中的每一个步骤可以是一个功能组件的设置,也可以是参数的指定,并且在一个构建方法中,将这些步骤串接起来. 2.定义一个专门实现这些步骤的实现者,这些实现者知道每一个部分该如何完成,并且能接受参数来决定要产出的功能,但不知道整个组装流程是什么. 把握两个原则:"流程分析安排&qu…
GoF中定义: "定义一个可以产生对象的接口,但是让子类决定要产生哪一个类的对象.工厂方法模式让类的实例化程序延迟到子类中实施" 当类的对象产生时,若出现下列情况: 1.需要复杂的流程 2.需要加载外部资源,如从网络.存储设备.数据库 3.有对象上限 4.可重复利用 建议使用工厂方法模式来实现一个工厂类. public abstract class Product { } public class ConcreteProductA : Product { public Concrete…
GoF中定义: "定义一组算法,并封装每个算法,让它们之间可以彼此交换使用. 策略模式让这些算法在客户端使用它们时能更加独立." 游戏开发过程中 不同的角色会有不同的属性计算方法 初级解决方法便是:if else,不够再来几个if else 高级点儿的就用switch case配合enum 对于小型项目或者快速开发验证用的项目而言,这么做是没问题的 但是开发规模或产品化项目时,最好还是选择策略模式 在策略模式中, 算法中的每一个都应该独立出来 将计算细节加以封装 客户端只要根据情况来选…
GoF定义: "将抽象与实现分离,使二者可以独立的变化" 游戏中,经常有这么一种情况 基类角色类(ICharacter),下面有子类士兵类(ISoldier).敌军类(IEnemy) 基类武器类(IWeapon),下面有子类枪类(IGun).炮类(ICannon) 当然,有用枪的士兵,有用炮的士兵 这么一组合,就是2*2 = 4个类 游戏后期,当角色类添加一个角色类时,变成了2*3 = 6个类 若再添加一个武器类,3*3 = 9个类 类成倍数增长 维护起来也就越来越困难 这种两个类群组…
GoF中定义: 定义一个接口来封装一群对象的互动行为 中介者通过移除对象之间的引用 以减少他们之间的耦合度 并且能改变它们之间的互动独立性 游戏做的越大,系统划分的也就越多 如事件系统,关卡系统,信息系统,界面系统等. 系统切分越细,就意味着系统之间的沟通越复杂 单一系统引入太多其他系统的功能,不利于单一系统的转换和维护 单一系统被过多的系统所依赖,不利于接口的更改,容易牵一发而动全身 由于需要提供给其他系统操作,系统的接口可能会过于庞大,不容易维护 using UnityEngine; pub…
GoF中定义: "为子系统定义一组统一的接口,这个高级的接口会让子系统更容易被使用" 其实这个模式虽然很少听过 但我们在敲代码的时候却是经常使用 比如: 在游戏初始化时 要初始化很多东西 如果把这些需要初始化的一步一步列出 确实简单直接 但缺点也很明显:不容易移植.代码臃肿 而如果把这些所有需要初始化的东西放到一个函数里面 初始化的时候只调用这一个函数 便可以把原来的缺点掩盖 而且初始化时只需要调用初始化函数,并不需要关心到底初始化了那些内容 其实,这也是我们通常口头上说的"…