回顾

在这三篇文章中，我与你一同实现了一个仅使用 SwiftUI 实现的「最小化可行性」游戏《能否关个灯》，通过 SwiftUI 简洁的 DSL 很好的把这个游戏的核心体现出来了，并使用了简单的「状态机」雏形来完成了对游戏核心逻辑的保障。

这个游戏主要是想让大家「强行」理解游戏开发中最核心需要关注的问题——状态。游戏中每一个可以产生交互的「道具」，甚至 NPC 等其实也是「道具」，如果我们不给这些「道具」绑定「事件」，通过「状态」去触发「事件」。其实这换到 app 或 web 中也都是一样的道理，甚至你可以认为手机本身也是一个庞大的状态机，只不过有些状态一直存在，不需要我们去修改。

在游戏中，我们通过维护一个二维列表来「记录」下当前所有灯的状态，通过这些状态的修改达到对灯的开关，这带给了我们一个反思：通过状态去修改 UI，这个问题一直困扰着目前客户端开发中。客户端开发架构从 MVC 至今演变出了非常多的变种，但这些变种在我看来都是 MVC 的衍生物，有些架构能够做到只修改状态就完成了 UI 的修改，比如 Redux，Flux 等，有些架构把一个组件的各个模块拆得非常细，比如 VIPER，通过使用 VIPER，你可以非常容易的测试各层边界处的交互。

但这些架构的演变最终你会发现都逃不出对状态的管理。一个项目发展到后边，各个状态所要触发的事件，状态之间的联动等问题，如果前期没理解好业务，或者业务的发展速度快于架构的所能够承载的最大值，慢慢这个项目就会变得十分难吃。

所以你也会发现，几乎每隔两三年就会出来一个要革掉前辈的命框架，比如最近非常火的 Flutter，因为就算用上 RN，Weex 等技术，还是不能很好解决一些问题，关于 Flutter 我不想在此谈太多，毕竟在此我们关注的还是游戏开发本身。

通过这三篇文章，我想你应该能够对游戏开发本身有了一个最直观的理解。在《能否关个灯》这个游戏中，我们只对灯的状态进行了修改，就对各种界面元素进行了联动。后续的涉及到 SpriteKit 框架的使用中，你会发现「被动」的状态响应这类事情会更多，比如给两个视图添加上刚体属性，把这两个刚体放在一个物理世界中，我们只需要做一些配置，甚至都不需要去修改它们的状态，这两个视图就可以在这个虚拟的物理世界中发生真实的物理交互。

下一步

接下来，我们 UIKit 将实现下一个游戏——黎锦拼图，看看这种「强视觉」的游戏要怎么去做好状态的维护。同时，这也是我的 WWDC19 学生奖学金的接收参赛项目，一起来领略黎族神秘的风土人情吧！

注意：本系列第一个游戏的讲解到此结束，接下来的其他所有游戏均通过小专栏进行发布，一年后同步其他平台。

GitHub 地址：https://github.com/windstormeye/SwiftGame

来源：我的小专栏《 Swift 游戏开发》：https://xiaozhuanlan.com/pjhubs-swift-game