状态机驱动的游戏开发

在之前的需求-开发流程中，由pm同学在PRD中进行描述，并制作​“游戏时间轴​“来阐述游戏的逻辑，之后开始写代码来实现。这一流程无法很好地表达游戏逻辑，协作的时候也需要反复向别的同学去解释，以及后续改动时不知道改了哪里，开发起来也容易出错

为了之前的痛点，优化工作流程，提出状态机驱动的游戏开发法。围绕游戏状态机的设计与实现来进行：

• 全程可视化，方便演示、沟通

• 状态机的逻辑（脚本）可以进行版本管理

• 游戏端、服务端可以复用（一定程度上）

• 思路确定，battle起来有理有据（逃

具体步骤：

1. PM提出需求稿，向大家展示说明

2. 游戏开发根据稿写出状态机并可视化（产出状态图），由PM确认

3. 拿着状态图可以开始进行UI/动效设计评审、技术评审

4. 开发阶段直接复用之前确定好的状态机逻辑，进行程序开发

5. 提测后将状态图与程序包一并提交给QA，由测试同学进行比对测试，目标程序行为与状态图一致

• 多人联机时：游戏状态 在游戏端维护一份、在服务端维护一份，游戏端等待服务端的消息，来受控地推进状态。

• 单机游戏：只在游戏内维护状态机即可，由游戏端的事件驱动。

使用状态机进行UI开发：http://slides.com/davidkhourshid/finite-state-machines

创建状态机借助XState，声明式创建状态机，并且可以方便地可视化、模拟运行：观看演示

https://github.com/davidkpiano/xstate

https://statecharts.github.io/

https://xstate.js.org/docs/

https://xstate.js.org/viz/

另一个js状态机lib：https://github.com/jakesgordon/javascript-state-machine

还有：https://github.com/ccqgithub/StateMachine

变量-状态表

	选择角色	进场	答题中	答题结算	淘汰	etc
题板显示 isBoardShow	false	true	true	false	false
选项可点击isButtonActive	false	true	true	false	false
角色可选择isSelectRole	true	false	false	false	false
答题倒计时answerTimer	-	-	setInterval	-	-
etc

将状态封装好后，切换状态的同时切换对应状态下维护的所有变量：统一管理某个状态下所有变量的值：​var[state] = value​免去手动维护无数个boolean变量的痛苦。优点同一时刻，一个状态机一定处在一个状态上：

• 便于debug，只需要把当前状态、当前状态下的所有变量打印出来即可

• 便于处理游戏逻辑的全局暂停/恢复，只需保存状态上下文即可

• 便于处理“中途加入”的情况，直接将状态置为对应状态即可

• 时间旅行会很容易实现，便于支持游戏回放，甚至seek（跳播）、倍速播放等

• 减少游戏出错的可能

• 配合dino框架进行双向绑定，减少开发的心智负担

具体实践

todo