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…