snake_knife-优快云博客

原创《游戏编程模式》读书笔记事件队列

其他情况下使用这样的异步很可能是不如同步的，尤其是在复杂逻辑中，想象一下，A函数的调用是因为B事件，B事件是C函数扔进队列的，C函数的调用是因为D事件，D事件又是E函数扔进队列的...没有调用栈的帮助，每一次确认事件的来源都是一次折磨。事件队列基本上可以看作一个“异步”的观察者模式：小王发出请求，小李关心并且对请求进行处理，唯一的不同是，在观察者模式中，所谓的“发出请求”就是小王直接去调用小李注册在他这里的函数，敦促小李立刻执行这一事情。使用这一设计模式，就是为了解决处理请求自由度的问题。

2025-04-09 23:18:51 23

原创《游戏编程模式》读书笔记组件模式

因此最好不要允许一个物体携带两个相同的组件，比如我说“我会写字”“我会说话”，这是两个组件，那我说“我会写字”“我会写字”，其实完全没有意义。”，这意味着要尽量减少组件携带者的属性和逻辑而尽可能把这些东西移到组件内部（如Unity的GameObject，作为组件携带者就非常的“空白”），如果不慎把一个组件携带类的逻辑写得很死，就会导致耦合并且让组件模式的优势完全失效，举个例子，如果在组件携带类里写了一段函数，同时引用了运动物理组件、音频播放组件和角色属性组件，那实际上就完全没有实现这几个功能的解耦。

2025-02-09 20:23:29 343

原创《游戏编程模式》读书笔记类型对象

类型对象几乎可以用于任何想让策划灵活编辑的类中，而且可以与继承结构一起用，因此哪些部分写在硬编码的继承中，哪些部分写在灵活的类型对象中就很有讲究了。另外一些不动程序就修改不了的东西，就应该写在类的继承里，比如“效果种类”，如果本来只有“伤害效果”，现在要加一个“治疗效果”，这个治疗效果的功能实现肯定是要加新的代码的，那么“伤害效果”和“治疗效果”就应该都是“效果”类的子类，不过有时，很希望让“效果的种类”这个属性乱变，那就又得塞进类型对象了，具体要不要用还是要看设计。

2025-01-16 21:49:01 183

原创《游戏编程模式》读书笔记子类沙盒

这种时候就不是“子类沙盒”了，而有点像“数据沙盒”，buff没有任何子类，而是直接在运行的过程中根据策划的配置数据决定自己的效果（这通常伴随着大量if判断），还是这个例子，改为buff上有两个bool值，分别代表“该buff会不会使携带者受伤增加/造成伤害减少”，还有两个float代表效果数值，在buff产生效果时，根据bool值来决定效果，这样策划只要把两个bool值都配置为true，就能实现“混合buff”。如果UI系统显示图标的方法发生了变化，也只需要修改父类中的一处方法，而不用到处找。

2025-01-12 06:48:35 175

原创《游戏编程模式》读书笔记字节码

首先，在执行字节码这一步，如果采用中缀表达式的方式来存储字节码就会遇到括号的问题，处理起来比较麻烦，所以字节码使用后缀表达式的形式，这样运算直接用一个数值栈就搞定了，不需要多一个栈来存储符号，也不需要处理括号。字节码说白了就是一个符合自定义语法的字符串，为了说明这一模式，假设我们在制作一款卡牌游戏，那一张牌的效果就好比一串字节码，游戏运行过程中，程序只需要不断获取玩家所打出的牌的字节码，并且交给我们编写的字节码执行器去执行就可以了。字节码可以说是最高级、最麻烦的办法。字节码的思想其实已经讲完了，就是。

2025-01-08 22:20:32 260

原创《游戏编程模式》读书笔记序列型模式

而对于销毁来说，你在更新一个实体时是不能确定“在这帧后面的更新中这个实体会不会被销毁”的，所以统一来说，你应当让这帧被销毁的实体参与这帧的更新，所以也不能立刻把这帧被销毁的实体扔出这个更新列表，而是要先存在一个“即将销毁”列表中，等待更新完了后再把这些实体移除。还是以unity为例（因为我只用过unity，乐），unity的GameObject是没有Update的说法的，所有的Update都是在组件上的，说明unity的更新是基于组件的更新。刚刚讲到双缓冲，实际上双缓冲是这三章中最小最简单的部分。

2025-01-04 17:21:27 342

原创《游戏编程模式》读书笔记状态模式

包装成类的话，就可以这么写：当前状态.HandleInput（），当前状态是一个状态类的实例，不同的状态都继承自一个状态父类，实现了自己的HandleInput方法。比如一个角色本来可以按shift奔跑，但是当他瞄准时不能奔跑，那么“是否在瞄准”就是这个标记，本来可以奔跑，现在在瞄准就不能奔跑了，这就是影响的处理逻辑的方式。一般来说只是这种程度的需求的话，一个bool变量，一个if判断就搞定了，但是如果这样的变量越来越多，那你就不得不在代码里塞很多的if，这种时候，就要状态模式出场了。

2024-12-28 21:04:57 322

原创《游戏编程模式》读书笔记单例模式

打个比方：假设有一个信号总线管理类，那你所有能发出信号的类都应该持有这么一个类的一个实例的引用，这个引用从哪里来？但是这带来的是，任何类都有了发送信号的能力，很快你就会发现在代码的各处都充斥着发送信号的操作，你完全无法控制哪个类能发送信号，哪个类不能，比如ABC三个类彼此相关，你想把发送信号的操作都集中到A中，但是做不到，因为口头约定的编程规范相当脆弱，很快就有新入职的程序图方便在B里，在C里发送这一信号，而你阻止不了他们。总之，书中所说的“全局静态变量有害”这一点，我是再赞同不过了。

2024-12-24 20:19:15 311

原创《游戏编程模式》读书笔记原型模式

原型模式的模板是一个实例的好处就在于更加自由，你不能（或者说最好不要）在运行时动态地进行类的声明，或是改变类的某个方法的实现，而实例完全是可以的，你只需要偷偷改变模板实例的某个函数指针，或者干脆把整个模板实例都替换掉。原型模式是一个很有趣的小系统，但是正如之前所说，随着这个系统越来越大，你的头也越来越大，完全用这种方式完成一个项目的话，最后你还是会追求一个相对稳定的“类”的定义。书中关于原型模式的引入问题是“怪物生成器”，同时书中也提出了不是原型模式的解决方案，例如c++的模板。

2024-12-20 18:15:35 171

原创《游戏编程模式》读书笔记观察者模式

总线型，就是有一个管理者负责管理所有的消息，监听者在它这儿注册，发送消息的被监听者也把消息发给它，由这个管理者把消息广播给监听者。而观察者模式中，消息的生产者压根儿就不知道它这个消息会导致什么操作，它也不关心，它只负责广播这样一个消息，剩下的就交给监听它消息的人自由发挥了。如果监听者对消息的消费需要有一个优先级，那么维护这个优先级将会非常麻烦，并且需要大量的约定去描述这个优先级分级（什么监听者的优先级为1，什么监听者的优先级为2，诸如此类），这时应当考虑观察者模式之外的方法去实现这一功能。

2024-12-17 20:46:53 318

原创《游戏编程模式》读书笔记享元模式

同样是上面的例子，有临时buff修改了怪物的弱点，如果你想当然地去操作怪物的弱点list，那就会导致所有怪物的弱点list都跟着一起被修改。例如每个种类的怪物都有一个巨长的记录它的弱点的List，那么并没有必要每个怪物的实例都保留一份这个List的复制，而更应该在怪物初始化时直接list = config.list（由于c#的对象都是浅拷贝，所以这个语句实际上只是赋值了一个指针），这样相当于配置文件config中的那个弱点列表就是所有怪物都在共享。

2024-12-16 20:23:53 210

原创《游戏编程模式》读书笔记命令模式

命令模式下的代码则是这样：if (玩家按下空格) jumpCommand.excute(),其中jumpCommand是一个Command类的实例，Command类都有excute方法，并且不同的子类分别有自己的实现。这一例中，jumpCommand可能就是一个JumpCommand类的实例，而JumpCommand类是Command类的一个子类，在它的excute方法中，调用了jump()这一方法，从而让命令模式下这段代码最终也调用到了jump()方法。例如，在玩家按下空格时，让玩家操作的角色跳跃。

2024-12-15 20:12:22 189

原创（自记）关于Unity的FixedUpdate和Update

如果你想在Update中正确处理这些buff的逻辑，会相当棘手，在这1次Update的调用中，你知道中毒buff造成了5次伤害，也知道现在“天命强化”buff在这次更新应当失效，但是哪些伤害被改为了治疗？你应该记录下来这次Update的deltaTime，比如是0.017s，然后看看这个中毒buff的掉血间隔，比如是0.5s，把这次Update的deltaTime累加到之前你计算的累计时间中去，然后判断这个累计时间有没有到达0.5s，如果到达了0.5s，则造成伤害并让累计时间减少0.5s。

2024-12-12 18:42:52 490

snake_knife的博客