Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

888339de9e7a88688b6acb30d33e66cd?s=128

蒼時弦や

July 10, 2021
Tweet

More Decks by 蒼時弦や

Other Decks in Programming

Transcript

  1. Unlight 從 TCP 到 WebSocket 的 HTML5 之路 Photo by

    Nastya Dulhiier on Unsplash
  2. THE PROGRAMMER OF CREATIVE ૵ ࣌ ݭ໵ @elct9620

  3. None
  4. @2020

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

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

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

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

  9. @2021

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

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

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

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

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

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

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

  17. ⽬前設計

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

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

    State Lib (TS) Client (JS)
  20. 伺服器部分維持現況不調整,是⽬前相對穩定的部分 Server

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  55. 總結

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

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

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

    Lib
  59. THANKS