# Unlight 從 TCP 到 WebSocket 的 HTML5 之路

2021 TGDF 台北遊戲開發者論壇

[共筆筆記索引](/ZA0Ckn94T0yN_JM36Z3KPw)

[官網連結](https://2021.tgdf.tw/speakers/4)

[簡報連結](https://speakerdeck.com/elct9620/2021-tgdf-unlight-cong-tcp-dao-websocket-de-html5-zhi-lu)

講者：邱政憲（蒼時弦也）

# background

- flash 停止支援，需要使用其他工具開發
- 本來決定使用 unity
- 版權方希望推 H5 版本
- unity 使用 WebAssembly，沒辦法支援 DLL

# 連線問題

- 原本暫時不處理的 TCP 連線問題要改成用 websocket
- 評估後改成以 golang 開發 proxy server
- 把 web socket 轉換成 TCP 連線再丟給 server

# 封包問題

- Unlight 使用的是自訂的資料結構，需要以二進位方式處理
- 然而 JS 處理這個很麻煩
- solution：跟 proxy 共用封包解析套件，用 WebAssembly 提供支援

# 目前架構


## server

不調整，相對穩定

## Proxy

- 單一 websocket 連接，背後 proxy 到不同伺服器
- TCP 連線狀態由 proxy 管理，斷線可以用相對少的修改方式解決

### why golang?

- 本身有不錯的 websocket / IO 處理支援，省時間

## Cmd lib

- 透過 Code Generator 產生能夠自動編碼與解碼封包的套件
- Proxy 可以針對玩家封包做紀錄，JS 端可以透過 Wasm 直接用於解析

## Bridge lib

- 透過 ProtoBuf 和 WebAssembly 溝通和解析指令
- 封裝成事件跟 Promise 物件，提供非同步操作

## State lib

- 問題：Unlight 本來的設計，狀態和事件是混合且嚴重耦合的
- 把互動抽象化，Client 只需要根據狀態變化更新
- 製作單獨的 debug console，避免 lib 開發被 client 開發卡到
- 使用 TS 加入型別檢查與封裝，避免協作時理解錯誤

# 總結

- 原本以為轉到 H5 應該很快
- 當東西複雜到一個程度，沒有型別檢查會很痛苦
- 原本以為重寫網路模組會不好處理，可是改用 Proxy 之後成本沒那麼高
- 選用 Unity 是因為 JS 太多必要套件沒辦法使用，但使用 WebAssembly 後雖然效果不好但仍然可以解決問題

###### tags: `2021TGDF` `台北遊戲開發者論壇` `共筆筆記`