《游戏编程模式》一7.8 并发状态机

7.8 并发状态机

我们决定给我们的主角添加持枪功能。当她持枪的时候,她仍然可以:跑、跳和躲避等。但是,她也需要能够在这些状态过程中开火。

如果你执着于传统的有限状态机,那我们可能需要把之前的状态加倍。对于每一个已经存在的状态,我们需要定义另一个状态,它做的事情也差不多,不过就是多了持枪的操作。比如站立状态和站立开火状态,跳跃状态和跳跃开火状态等。

如果我们添加更多的武器种类,那么这个状态数量将会急剧增加。而且不仅仅是增加了大量的状态类实例,它还会增加大量的冗余,实际上带不带枪的状态仅有是否包含开火代码的区别而已。

这里的问题是,我们把两种状态杂合在一起了。我们把两种不同的状态硬塞到一个状态机里面去了。为所有可能出现的组合建模,我们可能需要为每一种状态准备一组状态。解决方法比较直观,就是分开成两个状态机。

如果我们需要为主角定义n种状态和m种它能够携带的武器状态,如果使用一个状态机来表示,那么我们需要n×m个状态。而如果使用两个状态机,那么状态组合仅是n+m。

首先我们可以保留原有的状态机的代码和功能不管它。接下来,我们定义一个单独的状态机,用来处理主角携带的武器。现在,我们的主角会有两个状态索引,其中一个看起来如下所示:

为了便于示例说明,我们这里使用了完整的状态模式来处理女主角的装备变化。事实上,由于装备目前只有两个状态,我们完全可以只使用一个布尔值变量来替代。

class Heroine
{
 // Other code...

private:
 HeroineState* state_;
 HeroineState* equipment_;
};

当主角派发输入事件给状态类时,需要给两种状态都派发一下。

void Heroine::handleInput(Input input)
{
 state_->handleInput(*this, input);
 equipment_->handleInput(*this, input);
}

这样每一个状态机都可以响应输入事件并以此切换状态而不用考虑其他状态机的实现细节。当两个状态没什么关系的时候,这种方法工作得很好。

功能更加完备的系统可能会让一个状态机来处理输入,以便另外一个状态机不会接收到输入。这样将能防止两个状态机对同一输入进行错误的响应。
在实际中,你可能会发现你需要对某些状态处理进行干预。比如,如果主角不能够在跳跃的过程中开火,或者她在装备武器的时候不能俯冲。为了处理这种情况,在代码里面,对于每一个状态,你可能需要做一些简单的if判断并做出特殊处理。虽然这可能不是最好的解决方案,但是至少它可以完成任务。

时间: 2024-10-22 20:03:55

《游戏编程模式》一7.8 并发状态机的相关文章

《游戏编程模式》一导读

前 言 游戏编程模式在五年级的时候,我和我的小伙伴们获准使用一个放置着几台非常破旧的TRS-80s[1]的闲置教室.为了激励我们,一位老师找到了一份印有一些简单BASIC程序的打印文档给我们. 当时,计算机上的音频磁带驱动器是坏掉的,所以每次我们想要运行一些代码的时候,都不得不仔细地从头开始键入代码.这使得我们更喜欢那些只有几行代码的程序: 如果计算机打印足够多的次数,或许它会神奇的变成现实哦[2]. 10 PRINT "BOBBY IS RADICAL!!!" 20 GOTO 10

《游戏编程模式》一第1章 架构,性能和游戏

第1章 架构,性能和游戏 游戏编程模式在我们一头扎进一堆模式之前,我想为你介绍一些关于我如何看待软件架构以及它是如何应用到游戏的一些背景,这可能会帮助你更好地理解这本书的其余部分.至少,当你陷入关于设计模式和软件架构是多么糟糕(或者很棒)的一场争论中时,它会给你一些论据来使用. 请注意,我没有假设你站在争论中的哪一方.就像任何军火商一样,我为所有战斗方提供武器.

《游戏编程模式》一7.9 层次状态机

7.9 层次状态机 在我们把主角的行为更加具象化以后,她可能会包含大量相似的状态.比如,她可能有站立.走路.跑步和滑动状态.在这些状态中的任何一个状态时按下B键,我们的主角要跳跃:按下下方向键,我们的主角要躲避. 如果只是使用一个简单的状态机实现,我们可能会在这些状态中重复不少代码.更好的解决方案是,我们只需要实现一次然后它便可以在所有的状态下都复用. 这可能同时带来好坏两种影响.继承是一种强大的代码重用方式,但是,它也会使得子类与基类之间的代码变得紧耦合.它是一个很大的"锤子",需小

《游戏编程模式》一第7章 状态模式

第7章 状态模式 "允许一个对象在其内部状态改变时改变自身的行为.对象看起来好像是在修改自身类." 交代一下:我写的有些过头了,我在本章里面添加了太多东西.表面上这一章是介绍状态模式[1]的,但是我不能抛开游戏里面的有限状态机(finite state machines,FSM)而单独只谈"状态模式".不过,当我讲到FSM的时候,我发觉我还有必要再介绍一下层次状态机(hierarchical state machine)和下推自动机(pushdown automat

《游戏编程模式》一7.2 救星:有限状态机

7.2 救星:有限状态机 为了消除你心中的疑惑,你可以准备一张纸和一支笔,让我们一起来画一张流程图.对于女主角能够进行的动作画一个"矩形":站立.跳跃.躲避和俯冲.当你可以按下一个键让主角从一个状态切换到另一个状态的时候,我们画一个箭头,让它从一个矩形指向另一个矩形.同时在箭头上面添加文本,表示我们按下的按钮. 恭喜,你刚刚已经成功创建了一个有限状态机.有限状态机借鉴了计算机科学里的自动机理论(automata theory)中的一种数据结构(图灵机)思想.有限状态机(FSMs)可以看

《游戏编程模式》一7.5 状态对象应该放在哪里呢

7.5 状态对象应该放在哪里呢 我这里忽略了一些细节.为了修改一个状态,我们需要给state_指针赋值为一个新的状态,但是这个新的状态对象要从哪里来呢?我们之前的枚举方法是定义一些数字.但是,现在我们的状态是类,我们需要获取这些类的实例.通常来说,有两种实现方法. 7.5.1 静态状态 如果一个状态对象没有任何数据成员,那么它的唯一数据成员便是虚表指针了.那样的话,我们就没有必要创建此状态的多个实例了,因为它们的每一个实例都是相同的. 在那种情况下,我们可以定义一个静态实例.即使你有一系列的FS

《游戏编程模式》一1.1 什么是软件架构

1.1 什么是软件架构 如果你从头到尾阅读了这本书,那么你并不会了解到3D图形背后的线性代数或者游戏物理背后的演算.这本书也不会告诉你如何一步步改进你的AI搜索树或者模拟音频播放中的房间混响. 哇,此段简直为这本书打了一个糟糕的广告. 相反,这本书是关于上面这一切要使用的代码的组织方式.这里少谈代码,多谈代码组织.每个程序都具有一定的组织性,即使它只是"把所有东西扔到main()函数里然后看看会发生什么",所以我认为讨论如何形成好的组织性会更有趣些.我们如何分辨一个架构的好坏呢? 我大

《游戏编程模式》一1.3 性能和速度

1.3 性能和速度 你有时候会听到关于软件架构和相关概念的批评声,尤其在游戏开发中:它会影响到游戏的性能.许多模式让你的代码更加灵活,但是它依赖于虚函数派发.接口.指针.消息以及其他至少有一些运行成本的机制. 一个有趣的范例是C++模板.模板元编程有时可以让你获得抽象接口而没有任何运行时开销. 对灵活的定义,不同人有不同的看法,当你在某些类中调用一个具体方法时,你相当于将这个类固定(很难做出改变).当你使用一个虚方法或者接口时,被调用的类将直到真正运行起来才能被追踪到,这样的程序更具灵活性但是会

《游戏编程模式》一7.3 枚举和分支

7.3 枚举和分支 一个问题是,Heroine类有一些布尔类型的成员变量:isJumping_和isDucking_,但是这两个变量不应该同时为true.当你有一系列的标记成员变量,而它们只能有且仅有一个为true时,这表明我们需要把它们定义成枚举(enum). 在这个例子当中,我们的有限状态机的每一个状态可以用一个枚举来表示,所以,让我们定义以下枚举: enum State { STATE_STANDING, STATE_JUMPING, STATE_DUCKING, STATE_DIVING