回顾

在这三篇文章中,我与你一同实现了一个仅使用 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