$30 off During Our Annual Pro Sale. View Details »

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

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

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

蒼時弦や

July 10, 2021
Tweet

More Decks by 蒼時弦や

Other Decks in Programming

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