2021 - TGDF - Unlight 從 TCP 到 WebSocket 的 HTML5 之路

Unlight 是一款超過十年的遊戲，在 Flash 已經無法使用的這個時代，我們該如何快速將原本使用 Flash + TCP 的架構轉換為 HTML5 + WebSocket 的設計呢？

Transcript

1. Unlight 從 TCP
   
   
   到 WebSocket 的 HTML5 之路
   Photo by Nastya Dulhiier on Unsplash
   

   View Slide

2. THE PROGRAMMER
   
   
   OF CREATIVE
   ૵
   ࣌
   ݭ໵
   @elct9620
   

   View Slide

3. View Slide

4. @2020
   

   View Slide

5. 評估後預計以 Unity 開發，並以⼿機平台為主
   原始計畫
   

   View Slide

6. Unity 可以使⽤ TCP 連線不⽤調整過多伺服器設計
   原始計畫
   

   View Slide

7. 合作夥伴在其他國家希望以 HTML5 版本發⾏
   意外發⽣
   

   View Slide

8. Unity 的 WebAssembly 無法使⽤ DLL 套件
   意外發⽣
   

   View Slide

9. @2021
   

   View Slide

10. 從第三⽅獲取建議可以使⽤ Cocos Creator 開發
    新計畫啟動
    

    View Slide

11. Cocos Creator 有類似 Unity 的介⾯，
    
    
    但是有很多限制存在
    新計畫啟動
    

    View Slide

12. 原本暫時不處理的 TCP 連線問題需要⽀援 WebSocket
    連線問題
    

    View Slide

13. 評估後以團隊成員熟悉的 Golang 進⾏開發 Proxy Server
    連線問題
    

    View Slide

14. Unlight 使⽤的是⾃訂的資料結構，需要⽤⼆進位⽅式處理
    封包問題
    

    View Slide

15. JavaScript 在處理⼆進位資料上非常不好實作
    封包問題
    

    View Slide

16. 跟 Proxy 共⽤封包解析套件，⽤ WebAssembly 提供⽀援
    封包問題
    

    View Slide

17. ⽬前設計
    

    View Slide

18. Server (Ruby) Proxy (Go)
    Cmd Lib (Go)
    Bridge Lib (JS)
    State Lib (TS)
    Client (JS)
    

    View Slide

19. Server (Ruby) Proxy (Go)
    Cmd Lib (Go)
    Bridge Lib (JS)
    State Lib (TS)
    Client (JS)
    

    View Slide

20. 伺服器部分維持現況不調整，是⽬前相對穩定的部分
    Server
    

    View Slide

21. Proxy 提供單⼀ WebSocket 連接，
    
    
    再由 Proxy 連到不同伺服器
    Proxy
    

    View Slide

22. TCP 連線狀態由 Proxy 管理，
    
    
    斷線可以⽤相對少修改⽅式解決
    Proxy
    

    View Slide

23. Golang 本⾝有不錯的 WebSocket / IO 處理⽀援，
    
    
    因此省下不少時間
    理由
    

    View Slide

24. 透過 Code Generate 產⽣能⾃動編碼和解碼封包的套件
    Cmd Lib
    

    View Slide

25. View Slide

26. View Slide

27. Proxy 可以針對玩家封包做紀錄，
    
    
    JS 端可以透過 Wasm 直接⽤於解析
    理由
    

    View Slide

28. 透過 ProtoBuf 和 WebAssembly 跟 Proxy 溝通和解析指令
    Bridge Lib
    

    View Slide

29. View Slide

30. View Slide

31. View Slide

32. View Slide

33. gRPC 其實是把 Protobuf 封裝
    
    
    加入了 Lookup 資訊找到對應的⽅法
    概念
    

    View Slide

34. 因為 gRPC 還需要其他處理，
    
    
    因此我們⽤⾃⼰的⽅式做 Lookup
    概念
    

    View Slide

35. View Slide

36. View Slide

37. 在將 Golang 綁定到 JavaScript 上時，我們遇到⼀些問題
    困難
    

    View Slide

38. View Slide

39. 除此之外我們因為 Code Generate 讓 WebAssembly 非常⼤
    困難
    

    View Slide

40. View Slide

41. 封裝成事件跟 Promise 物件，提供非同步的操作
    Bridge Lib
    

    View Slide

42. View Slide

43. View Slide

44. View Slide

45. 基本上是為了能有⼀個
    
    
    可以重複利⽤的連線模組並解決指令問題
    理由
    

    View Slide

46. 發現 Client 端開發無法很好使⽤ Bridge Lib
    
    
    且對狀態管理沒有概念
    State Lib
    

    View Slide

47. Unlight 原有設計的狀態和事件是混合且嚴重耦合
    State Lib
    

    View Slide

48. 把互動完全抽象化，
    
    
    Client 端只需要知道狀態有變化並更新即可
    State Lib
    

    View Slide

49. View Slide

50. View Slide

51. View Slide

52. 使⽤ TypeScript 加入型別檢查跟封裝避免協作時理解錯誤
    State Lib
    

    View Slide

53. View Slide

54. 在設計上就盡可能減少耦合，同時降低我們在協作時需要掌握的資訊
    理由
    

    View Slide

55. 總結
    

    View Slide

56. 原本認為重寫網路模組會很不好處理，
    
    
    不過改⽤ Proxy 後協助後修改成本並沒有想像中⾼
    TCP
    

    View Slide

57. 原本選⽤ Unity 主要是 JavaScript ⼤多必要套件無法使⽤，
    
    
    不過使⽤ WebAssembly 後效果雖不好但仍能解決問題
    WASM
    

    View Slide

58. 過程中調整次數最多的是 JavaScript 的部分，
    
    
    連線模組的設計到複雜結構的管理才讓我們從
    
    
    JavaScript 開始轉到 TypeScript 上，
    
    
    並且想辦法解耦來改善協作
    JS Lib
    

    View Slide

59. THANKS
    

    View Slide