分享：使用 TypeScript 編寫的遊戲代碼

《上篇博客》我寫出了我一直指望的 JavaScript 大型程序的開發模式，以及 TS(TypeScript) 的一些優點。博客完成以後，我又花了一天時間試用 TS，用它來重構以前編寫的一個 JS 遊戲：《Javascript 坦克遊戲》。

 

源碼下載

---

源碼我已經上傳到 CSDN 了，無需資源分，下載地址：http://download.csdn.net/detail/zgynhqf/8565873。

源碼使用 VS 2013 +TypeScript 1.4 進行開發。打開後，顯示以下圖：

JsTankGame 1.0：老的使用 JS 編寫的坦克遊戲。

JsTankGame 2.0：新的使用 TS 直接翻譯過來的遊戲。

JsTankGame：在 2.0 的基礎上，對類型進行了重構後的新遊戲。

 

重構步驟

---

因爲老的 JS 遊戲是採用 MS Ajax Client Library 構建，而且採用了 OOD 的方式來進行設計，再加之 TypeScript 能夠兼容 JS 的所有代碼。因此使用 TypeScript 來移植的工做也比較簡單，主要是替換類型設計的代碼：類、繼承、接口等。

完成以上工做後，也就獲得了使用 TS 編寫的 2.0 版本。過程當中體會到了強類型語言的諸多好處，固然也有一些 TS 目前並不完善的地方（後面會說）。

獲得了強類型的 2.0 版本後，並無結束。爲了體驗強類型對於重構的好處，我決定在這個版本之上作代碼結構上的重構。

有了強類型編寫的代碼，我能夠很方便地分析出每個類型、每個方法，具體在哪些地方被使用。這樣，我就能很快地知道類型之間的依賴關係。不看不知道，一看嚇一跳。以前一點一點隨心寫的代碼，本覺得類型設計得還不錯，之間耦合性應該不是很高。可是圖畫完以後，才發現與想象中差點很遠，這就是沒有畫圖直接編寫代碼的結果，見下面兩張圖：

能夠看出各精靈類型之間的關係是比較亂的，雙向依賴隨處可見。（其實圖中由於把 SpriteManager 畫到了另一張圖，因此沒有顯示出更復雜、更亂的關係。）

 

據此，我繪製了新的關係圖，而後按照此關係來重構了全部的代碼。這樣就獲得了最新的 3.0 版本。

新版本的類型關係圖以下：

分層：

精靈：

管理器：

代碼層面，主要是把各精靈之間耦合的代碼，都移植到了上層的管理器中。同時，爲精靈定義事件來解除精靈與管理器的直接耦合。

 

TS 首次體驗中感覺的優缺點

---

• 優勢：
• Lambda 很是好地解決了 this 指針的問題。
• Chrome、IE 都能直接調試 TypeScript！
• 過程當中還發現了弱類型沒法發現的錯誤。由於重命名，尚未修改原來的代碼。（SpriteManager.js 98 行）

 

• 缺點：
• 開發環境-尚未集成代碼註釋功能，只能手動拷貝。
• 開發環境-不支持代碼區域的定義（Region，很是重要，便於分區域管理較多代碼的類型。沒有這個功能，一樣致使代碼沒法寫得更多，畢竟每一個類的代碼量也很多。）。
• 開發環境-目前還不支持 Code Snippets。
• 開發環境-不支持關鍵字代碼生成：if、while、swith、括號匹配等。
• 語法-不支持事件的定義。
• 語法-暫時還不支持爲類定義重載方法。見 SpriteBase.IsCollided 方法。

其它：

• 編譯出的 JS 代碼有必定的冗餘。命名空間處顯得特別明顯。
• 重寫基類方法，沒有提示。
• 基類的屬性獲取器/設置器沒法重寫。
• 沒法分辨哪些方法是虛方法。
• 接口中不能定義只讀的屬性。
• 還存在 BUG。（SpriteManager.ts line 93）。
• 簡單定義一個數字類型的字段的話，默認值並非 0，而是 NaN。

 

總結 

---

整體說來，通過試用，我感受 TS 到目前的 1.4 版本，已經能夠用於正式的大型 JS 項目開發。可是還有不少地方須要改進！

 

附 Chrome、IE 調試 TS 截圖：