【Unity插件 - Photon Bolt官方文檔翻譯】00 Bolt和Pun的對比

前言

首先,放出Bolt的Unity資源商店頁面地址:https://www.assetstore.unity3d.com/cn/#!/content/83233

然后,簡單的介紹一下Bolt吧!

Bolt是一款Unity非常強大的網絡解決方案的插件。

也就是用來開發聯機項目的。

用Bolt開發聯機游戲,可以不寫服務端、不用自己租服務器、代碼簡單、五分鐘完成設置!

聽起來是不是和Pun很像!

基本和Pun是一樣的,但是區別就在于,Pun使用的是Photon云作為服務器,Photon云基本都是在國外,而且500的最大玩家數需要95美元一個月,真的是延遲又高又貴呢!

而Bolt是把服務器建在房主的電腦上(建在玩家的電腦上),由房主進行數據傳輸、接收、處理。

這樣我們就不必考慮自己租用服務器了,房間和連接可以有無限個,而且延遲會低很多!

而且Bolt支持大部分主流的平臺:安卓、Ios、Win、Mac、Steam、PSN、XBox1等。

只不過一些有內購、賬號的游戲(比如棋牌游戲),應該不太適合使用Bolt,因為Bolt的邏輯是寫在客戶端里的,而且由客戶端進行處理。

因為自己的項目使用Photon的Pun(Photon Unity Networking Free)插件延遲太高了。

所以我就想著,能不能像《無主之地2》、《失落城堡》那樣,聯機的時候由房主作為服務端,這樣既可以保證延遲很低(至少不用傳輸數據到國外,再傳輸回來)。

而且這樣還可以省掉一大筆租用服務器的費用!

然后我們就發現Photon的Bolt插件,正好可以實現這樣的功能。

但是有一個很大的問題就是Bolt在國內根本就沒有任何資料可以參考……

本來Pun的資料和教程就很少了,Bolt真的幾乎就是沒有……

所以,索性翻譯下Bolt的官方文檔,因為國內用Pun的比較多,所以第一篇翻譯的是Bolt和Pun的區別。(之后的翻譯的文檔就按照Bolt官方文檔的順序進行~)

文檔是我和谷歌翻譯合力翻譯的QWQ,我自己也知道翻譯的挺差勁的,希望大家能夠在錯誤的部分向我指出哦~讓我們把這個它變得更好~

附上Bolt文檔的官方地址:https://doc.photonengine.com/zh-tw/bolt/current/setup/overview

官方文檔已經翻譯了70多頁了,但今天雙十一!轉賬轉不出!明天就買買買!

PDF文檔,請到這個鏈接進行下載:http://gad.qq.com/article/detail/35394

下載方法請參考:http://gad.qq.com/article/detail/35416



PUN vs. Bolt

Introduction 介紹

PUN和Photon Bolt是兩個強大的游戲網絡中間件。 兩者之間的選擇并非易事。 本文檔的目標是提供這兩種工具之間的可理解的總結比較,以幫助開發人員確定哪一個最適合他們的需求。

PUN

PUN(Photon Unity Networking)是原始Unity網絡API的一個克隆,由可靠的Photon基礎設施提供支持。 除了無所不在的配對之外,PUN的基本構建塊還包括:游戲對象狀態的序列化(支持轉換等); 和遠程過程調用(RPC)。

PUN給開發者直接和完全的控制發送/接收,而且,加上它的可擴展的多播式房間中繼通信模式,是一個強大的游戲聯連網主力。

Photon Bolt

Photon Bolt是一個更高級別的API,它允許開發者通過一組數據結構來定義可聯網的游戲狀態(稱為Bolt資產(called bolt assets):狀態,對象,事件和命令 states, objects, events and commands),并將這些資產與游戲對象預制件相關聯。

Bolt的網絡模型通過回調和觸發事件和命令而增強,以最小的開發人員的努力,為Unity提供最先進的壓縮,客戶端預測和延遲補償的廣播。

Quick Comparison 快速比較



https://doc.photonengine.com/en-us/bolt/current/reference/pun-vs-bolt


Features Comparison功能比較

Photon Bolt和PUN方法都有其優點和原因。

在這里,我們試圖通過比較影響類似游戲網絡領域的每個特征來解釋它們之間的重要區別。


Host Client (Bolt) vs. Dedicated Server (PUN) 主機客戶端vs專用服務器

使用PUN:

你已經有了一個真正的專用服務器,你可以連接到實際存在的房間。

創建一個房間的客戶是第一個加入它的客戶。 它將被標記為房間內每個人都知道的主客戶。 主客戶端不是主機,也不是服務器,只是一個特殊的客戶端,可以做額外的東西(偽權威)。

然而在Bolt中:

其中一個Bolt客戶端需要充當服務器,真正的專用服務器或真正的主機。

這可能有點令人困惑,所以讓我們來澄清一下:

通過PUN:如果主客戶端退出,另一個玩家(如果可用)將成為新的主客戶端。 以此類推,直到沒有更多的玩家。

另一方面,用Bolt:服務器是“靜態的(static)”; 啟動游戲并選擇成為服務器的這個“客戶端(client)”,將作為服務器停留。 如果主機客戶端(服務器)退出,其他客戶端都不會成為服務器(當然,所有客戶端都將斷開連接)

所以總結一下,在Bolt,如果主機斷開連接,游戲結束。 ping和延遲也取決于與主機播放器的連接。(Pun類似于GTA5戰局,Blot類似于無主之地2的那種聯機)

Events (Bolt) vs. RPCs (PUN) 事件vsRPC

PUN(和許多Unity的網絡解決方案)和Bolt之間的顯著區別是Bolt沒有RPC或“遠程過程調用”的概念。 在PUN中,RPC是

一種告訴所有或選定的客戶端“請立即運行此方法”的方法。

另一方面,Bolt使用“事件Events”來實現相同的功能。

Automatic State Replication (Bolt) vs. Flexibility (PUN)? 自動狀態復制vs靈活性

使用Bolt,您不必編寫序列化代碼。

一切都是由Bolt的編譯器根據您創建的資產來表示游戲狀態而生成的。 這能很好的節省時間,也意味著你受益于其他功能,如壓縮。 但是,這也意味著您無法完全控制網絡的運行方式以及操作方式。

使用PUN,您可以編寫自己的序列化例程,決定要發送的內容以及要接收的內容。

這樣,您可以編寫自定義的推算函數(dead-reckoning functions),并決定哪些客戶端使用自己的代碼來接收每條信息。

Bit Compression (Bolt) vs. Message E?ciency (PUN) 位壓縮vs消息效率

由于Bolt代碼生成關注對象的狀態序列化,因此可以從最先進的壓縮技術中受益,這大大減少了游戲的網絡交通復雜性。 然而,即使是通過中繼運行游戲,而不使用授權服務器上的邏輯,Bolt的消息也必須始終通過主機。 這給基于Bolt的游戲增加了延遲。

PUN不會遭受這樣的警告,因為它的序列化代碼默認通過中繼,從一個客戶端向所有其他對等點發送數據。? 這里PUN的問題在于,由于開發人員編寫自己的序列化代碼,因此現有的壓縮技術無法實現(程序員可能不得不自己實現)。

Client-Side Prediction & Lag Compensation (Bolt) vs.?

Lite Authoritative-Server Possibilities (PUN)

客戶端預測和延遲補償(Bolt)vs Lite權威服務器可能性(PUN)

通常為了避免作弊,編寫權威的服務器代碼是每個游戲網絡開發者不時要面對的問題。

這意味著您可以讓您的服務器控制來自客戶端的輸入,并在必要時更正您發送回客戶端的數據。

Bolt通過其內置的客戶端預測體系結構(命令+響應)和滯后補償的shooter first raycasts (基于服務器時間近似hitbox緩沖區)大大簡化了權威服務器游戲的實現。 這意味著開發人員可以從FPS和動作游戲的多年行業經驗中自動獲得一個非常易于理解的API。

這種完全權威的(通常是專用的)服務器方法的問題是成本。 托管處理高CPU負載的服務器可能使得游戲在經濟上不切實際。

使用PUN,可以編寫與客戶端的每個自定義序列化消息相匹配的服務器端插件server-side plugins,這些消息在傳遞給其他客戶端之前可以被攔截或修改。 這是一個非常靈活的API來實現Photon服務器本身所需的最小邏輯,從而使服務器成本得到更平滑的擴展。

Bolt信息(Bolt's message)的打包和壓縮(本身就是一個好處)使這種做法不切實際。

總之,使用PUN而不使用服務器插件并基于主客戶端可以實現偽授權功能。 這要求主客戶(也可能是所有的主客戶候選人)保

持每個客戶100%的真實狀態,這是棘手的。

Bolt解決了這一點,通過引入:客戶端狀態(client states)。

在FPS游戲中,一個典型的“玩家狀態”將包含關于每個玩家的位置,速度,相機間距等的信息。通過Bolt,這些狀態是在Bolt自己的Unity編輯器擴展中定義的,這使得一切用戶友好、 安全地工作。 Bolt負責通過網絡為您同步狀態,服務器(玩家主機)負責每個客戶的實際狀態,從而阻止作弊。

絮醬翻譯


看的有點暈,說下自己的理解吧,可能不對,希望指出。

Pun(我自己之前的項目都是使用的Pun),需要使用Photon云作為服務器。

Photon云好像是:有20個免費 的最大同時在線連接數。

收費是:95美元/月,最大同時在線連接數:500。

所以,如果選用Pun的話,首先,延遲高(Photon在國內有服務器,但是好像需要申請),第二就是成本高。

Bolt的服務器是"架設"在玩家的電腦上的,所以相當于支持最大同時在線連接數:無限。

而且因為是架設在玩家的電腦上的,如果玩家都是同一個城市之類的,延遲會相當低。

(總比連到國外再連回來低!)

然后Bolt有100個免費的最大連接數,用來做玩家配對。

但是Pun和Bolt都有一個問題就是:邏輯是寫在客戶端里的。

所以,最好做一下代碼混淆。

然后就是一些付費類游戲(棋牌、卡牌、Moba等),就最好使用Photon Server之類的吧。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 228,197評論 6 531
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,415評論 3 415
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 176,104評論 0 373
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,884評論 1 309
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,647評論 6 408
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,130評論 1 323
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,208評論 3 441
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,366評論 0 288
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,887評論 1 334
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,737評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,939評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,478評論 5 358
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,174評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,586評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,827評論 1 283
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,608評論 3 390
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,914評論 2 372

推薦閱讀更多精彩內容