Swift 游戏开发阶段总结（〇）

回顾

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

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

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

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

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

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

下一步

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

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

GitHub 地址：github.com/windstormey…

来源：个人小专栏《 Swift 游戏开发》：xiaozhuanlan.com/pjhubs-swif…