A0dd4d112c81e08d47c1822a7a9888d0
Swift 游戏开发阶段总结(〇)

回顾

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

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

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

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

top Created with Sketch.