遊戲開發 協議設計

遊戲開發—協議設計

遊戲開發—協議-protobuf

遊戲開發-協議-protobuf原理詳解

通俗地說，協議就是通訊雙方能夠理解的一種資料格式。維基百科這麼定義網路協議：

網路協議為計算機網路中進行資料交換而建立的規則、標準或約定的集合。

協議設計包含三要素：

語法：語法是使用者資料與控制資訊的結構與格式，以及資料出現的順序。

語義：解釋控制資訊每個部分的意義。它規定了需要發出何種控制資訊，以及完成的動作與做出什麼樣的響應。

時序：時序是對事件發生順序的詳細說明

也就是說，語義表示要做什麼，語法表示要怎麼做，時序表示做的順序。我們要基於此來設計我的協議。

通常遊戲有一些特殊性，比如流量要盡量的少，安全性要求更高，以及對平台支援足夠多等等。這一切的需求就要求遊戲協議設計，盡量簡單、通用，以及**層上易擴充套件、解析效率足夠高等特點。

基於此，我需要從以下幾個層次來考慮遊戲協議的設計方案。

因為知識點比較多，建議先讀知識圖譜，對整體結構有乙個清晰的綜括。

應用層主要是常用是解析方式定義和解析，主要的選型，主要是看你基於什麼需求了，適用於實際需求就好。我們常用的協議型別，主要有這兩種：文字協議、二進位制協議

文字協議設計的目的就是方便人們理解，讀懂。如常見的http協議，一般的常見http協議如下：

username=test&password=1234複製**

這種格式非常貼近我們的文字描述，方便閱讀，而且目前http也是客戶端瀏覽器或其他程式與web伺服器之間的應用層通訊協議，適用非常廣泛。但你也看到，有時候基於乙個很簡單應答，就要帶上很多其他的頭資訊，這對於對流量有要求的遊戲應用來說，還是很浪費的。

優點：

1、通用，適用廣泛

2、方便理解，可讀性好

1、基於行讀，解析效率一般

2、攜帶附帶資訊過多，傳輸的效率低下

3、無狀態，伺服器不知道客戶端的狀態，必須基於客戶端的請求來回應，實時性低

4、很難嵌入其他資料，對二進位制支援差

二進位制協議就是一串位元組流，是乙個典型的ip協議，一般通常包括訊息頭(header)和變長的訊息體(body)，訊息頭的長度固定，訊息體長度不固定，包含主要的內容主體。一般訊息頭會包含訊息體的長度，這樣就能基於頭資訊從資料流中解析出乙個完整的二機制訊息了。

一般的格式如下：

我們看到head部分定義包含:

cmd:命令字

sign：驗證串

content-leg:訊息體長度

headercrc：頭驗證（不是必須）

sign是乙個驗證字串，對訊息體資料進行一定加密驗證，保證資料安全。

content-leg是本次訊息體的長度。

body部分，比如我們如下定義:

message:login{

string username;

int64 passwoard;

優點：

1、沒有冗餘字段，傳輸高效，耗費流量小

2、解析速度快，基於基礎資料型別操作

1、可讀性差，不利於除錯

2、擴充套件性差，對複雜資料結構支援不夠

以上我們看到了兩種協議型別，但對於訊息體的解析介紹很少，訊息體的格式決定了的他的語義和時序，格式不同資料的序列化和反序列化也是不同。比如message:login，你可以基於json來定義，也可以基於xml來定義，定義不同解析方式也各不相同。

一般的訊息體格式主要有以下幾種:json、protocolbuff、xml、自定義

json

json是一種輕量級的資料交換格式,網際網路應用的很廣泛了。常用的框架也很多，推薦fastjson,解析速度還是不錯的。json的好處是，開源，格式統一，解析速度也還可以。缺點就是會有一些冗餘字元，不夠簡潔。

protocolbuff是是google提供的乙個開源序列化框架，類似於xml，json這樣的資料表示語言。但是比這些占用空間都小，沒有冗餘字段。而且好處是靈活，解析速度快，易於開發（基於配置自動生成**），可支援語言也比較多。一條訊息資料，用protobuf序列化後的大小是json的10分之一，xml格式的20分之一，是二進位制序列化的10分之一

不多解釋了，大家都用有過，強烈不建議使用這種，除了無效字元過多（標籤），而且解析效率比上面兩種都是很低的。

自己定義就是自己定**析方式，比如通過文件定義好乙個訊息的結構，第乙個欄位是什麼型別，第二個字段什麼型別...等等，基於此自己寫工具解析。好處是對外協議不透明，解析效率和傳送效率都還不錯，缺點就是開發難度高，不容易維護。

遊戲通訊，安全也很重要，不然協議被破解，使用者刷資源，整個遊戲的平衡性就被破壞了，輕者影響其他玩家體驗，重則遊戲直接被廢。

一般的安全處理就是對協議進行加密。一般有以下幾種:

採用對稱加密或者hash加密來對訊息內容進行加密，兩端採用同一種加密演算法，基於同乙個金鑰對訊息體進行加密換算，以此來檢視資料是否一致。

金鑰可以使用者登陸的時候獲取一次。還有一種是基於每個使用者金鑰不同，以此防止金鑰洩露大範圍影響全服玩家。

動態加密，可以提前設定乙個私有金鑰庫，裡面包含一定數量的金鑰，每次客戶端請求的時候，基於協議號來設計乙個演算法獲取其中乙個金鑰。每個協議的金鑰都是在協議到達的時候時時獲取的，這樣即便某乙個協議的金鑰被破解，對其他協議依然無效。

採用非對稱加密，或者加鹽處理。非對稱加密速度太慢了，不建議。

考慮服務端的承載成本，以及手機遊戲上網路環境差，原則上udp是比tcp更適合的方式。但是由於遊戲對於資料完整性、安全性要求比較高，採用tcp的又可靠與安全。

目前採用netty作為推送伺服器的也有支援上百萬連線的應用了，tcp這塊效能對於一般遊戲支援足夠了。長鏈結遊戲多採用分區分服來應對高併發壓力，短鏈結多採用分布式來應對。

二進位制協議中，位元組序需要注意，跨語言、平台通訊的時候會出現亂碼問題。目前的位元組序主要有，little endian和big endian之分，也就是常說的大頭和小頭之分。

具體是大頭在前還是小頭在前，這個和主機的cpu有關係powerpc系列採用big endian方式儲存資料，而x86系列則採用little endian方式儲存資料。這個在手機主機上也會出現。

應對方案是：

客戶端和服務端強制採用一種位元組序，一般採用網路位元組序（big endian）

協議**現浮點型別要特別注意，浮點型別的傳送上面位元組序處理ok了，還得注意浮點數的多平台運算不一致問題。

比如遊戲中要對尋路、戰鬥等公式計算，牽扯到浮點數了，有可能前後端算出的不一致，以arm為例，arm的浮點數就有軟模擬、硬體ieee-754相容、simd下ieee-754不相容三種情況。

此時解決方案，

1、統一一種格式，比如前後端都採用軟模擬，或者強制採用硬體ieee-754（軟模擬速度慢）

2、轉換為定點數，也就是浮點轉換為整數（速度快）

Erlang遊戲開發 協議

erlang 百科 協議包含通訊協議和資料格式.通訊協議目前常用的是 http和tcp.其有各自的特點根據遊戲的特點而進行選擇.http比較成熟,使用極其廣泛.具有豐富的基礎軟體和工具.對於簡單的social game可以使用http作為通訊協議.這類遊戲對實時性要求不是很高,使用http也很容易做...

Erlang遊戲開發 協議

協議包含通訊協議和資料格式.通訊協議目前常用的是 http 和tcp 其有各自的特點根據遊戲的特點而進行選擇.http比較成熟,使用極其廣泛.具有豐富的基礎軟體和工具.對於簡單的social game可以使用http作為通訊協議.這類遊戲對實時性要求不是很高,使用http也很容易做到效能擴充套件,可...

Android遊戲開發設計步驟

如今搭載android作業系統的手機數量比iphone多得多。據悉，android裝置平均每天啟用40萬台。但ios對開發商來說依舊是個更加有利可圖 更受歡迎的平台。原因是 android無需花錢買應用 眾多裝置和應用商店使得android市場呈分散狀態。1 手機遊戲開發簡介 遊戲的本質就是在螢幕上...