回顧

在這三篇文章中，我與你一同實現了一個僅使用 SwiftUI 實現的「最小化可行性」遊戲《能否關個燈》，通過 SwiftUI 簡潔的 DSL 很好的把這個遊戲的核心體現出來了，並使用了簡單的「狀態機」雛形來完成了對遊戲核心邏輯的保障。

這個遊戲主要是想讓大家「強行」理解遊戲開發中最核心需要關注的問題——狀態。遊戲中每一個可以產生互動的「道具」，甚至 NPC 等其實也是「道具」，如果我們不給這些「道具」繫結「事件」，通過「狀態」去觸發「事件」。其實這換到 app 或 web 中也都是一樣的道理，甚至你可以認為手機本身也是一個龐大的狀態機，只不過有些狀態一直存在，不需要我們去修改。

在遊戲中，我們通過維護一個二維列表來「記錄」下當前所有燈的狀態，通過這些狀態的修改達到對燈的開關，這帶給了我們一個反思：通過狀態去修改 UI

但這些架構的演變最終你會發現都逃不出對狀態的管理。一個專案發展到後邊，各個狀態所要觸發的事件，狀態之間的聯動等問題，如果前期沒理解好業務，或者業務的發展速度快於架構的所能夠承載的最大值，慢慢這個專案就會變得十分難吃。

所以你也會發現，幾乎每隔兩三年就會出來一個要革掉前輩的命框架，比如最近非常火的 Flutter，因為就算用上 RN，Weex 等技術，還是不能很好解決一些問題，關於 Flutter 我不想在此談太多，畢竟在此我們關注的還是遊戲開發本身。

通過這三篇文章，我想你應該能夠對遊戲開發本身有了一個最直觀的理解。在《能否關個燈》這個遊戲中，我們只對燈的狀態進行了修改，就對各種介面元素進行了聯動。後續的涉及到 SpriteKit 框架的使用中，你會發現「被動」的狀態響應這類事情會更多，比如給兩個檢視新增上剛體屬性，把這兩個剛體放在一個物理世界中，我們只需要做一些配置，甚至都不需要去修改它們的狀態，這兩個檢視就可以在這個虛擬的物理世界中發生真實的物理互動。

下一步

接下來，我們 UIKit 將實現下一個遊戲——黎錦拼圖，看看這種「強視覺」的遊戲要怎麼去做好狀態的維護。同時，這也是我的 WWDC19 學生獎學金的接收參賽專案，一起來領略黎族神祕的風土人情吧！

注意：本系列第一個遊戲的講解到此結束，接下來的其他所有遊戲均通過小專欄進行釋出，一年後同步其他平臺。

GitHub 地址：github.com/windstormey…

來源：我的小專欄《 Swift 遊戲開發》：xiaozhuanlan.com/pjhubs-swif…