開始之前先說一下網游中服務器與客戶端的大致關系：

網絡游戲中各段關系圖

客戶端職責：

1）接收玩家的輸入翻譯得到【玩家指令】上傳服務器；
2）接收服務器下發的【游戲指令】并將其實現

服務器職責：

1）接收客戶端的指令并處理；
2）廣播當前幀所需的游戲數據與游戲狀態；

強聯網中的高帶寬與游戲中的卡頓解釋：

服務器壓力：

我們打團戰的時候會出現輸入沒有響應，正式因為讓你的輸入產生結果的模塊不在客戶端而是在服務器；此時服務器要處理大量用戶指令計算時間過長外加網絡限制，客戶端得不到及時的數據更新；
【有預處理機制部分還是能動的，例如部分網游在延遲是時也能正常速率移動，但是在得到最新數據后，玩家將被糾到正確坐標；這正是一種降低小幅延遲的策略，所帶來的現象。想繼續了解如何解決網絡延遲策略的可以傳送門https://www.zhihu.com/question/36258781/answer/80841137】

高帶寬：

多名玩家同屏時，為了能看到其他玩家的樣子和屬性值，所以每次更新都需要所有需要繪制的玩家數據，所以高帶寬是強聯網的前提；

我們再來看局域網中的主機與客戶端的關系

主機與客戶端的關系

因為主機與客戶端本身都是同一套應用程序，所以都包含完整功能；然而局域網游戲中，作為主機的一端除了運行完整的客戶端（玩家操作接收處理和圖像圖形顯示）職能外，還需要具有網絡結構中的服務器端職能，對整個局域我那個游戲的數據進行計算與存儲，邏輯處理與發送；而其他客戶端進需要運行客戶端部分功能即可參與局域網游戲；（故局域網中主機壓力巨大，既要做邏輯與數據運算，還要完成圖像顯示處理）

--------------------開啟本章內容（官方案例講解）-----------------------------

書接上回在上一篇尾巴上留了RPC介紹，也就是虛幻的函數復制原理，本章我帶著大家過一遍官方關于networke的案例，了解一下變量復制與函數復制以便后面使用節點時不會懵逼；

下載官方案例"內容示例"

在這里下載
下載完當然是打開了
打開后我們點擊根目錄Content，然后使用篩選功能，找出所有場景
然后找到【Network_Features】

這里推薦點擊官方的幫助文檔“食用”效果更佳：

找到綠色的幫助對象，點擊打開幫助文檔
英語不好的同學可以切換到中文

案例1.1對象的復制

該場景的查看方式均使用多窗口瀏覽；

不要忘了上一章講的多窗口瀏覽方式和設置方法

本案例將在兩個【Target Point】的位置生成幽靈對象；由于對象的藍圖類的Replicates屬性的不同，所以表現出不參與復制對象在主機端存在而客戶端不存在的效果；

運行結果

1）我們打開場景藍圖與兩個幽靈的藍圖類；

兩個生成對象所使用的藍圖類是不一樣的
雖然是繼承關系但是在復制選項上有所區別

可以看到由于兩個不同的對象類在復制選項上有所區別，故客戶端與服務器的顯示結果是不同的，

需要注意的（一定將核心處理限制在主機端）：

確認服務器執行

這是聯機藍圖的關鍵所在，邏輯也好數據處理也好，一定要交給服務器來操作，客戶端只要做顯示與用戶操作采集相關的編輯即可；

案例1.2 Switch Has Authority節點學習

該實例通過對服務器和客戶端執行不同實現來加深對Switch Has Authority 節點的了解；

顯示結果
該幽靈的藍圖

案例1.3值復制（僅更新變量值）

該實例主要使用值復制的方法來實現客戶端與主機的數據同步；

運行結果，客戶端觀察到左側幽靈的健康值一直為0而右側的則與服務器同步
右側的幽靈中關于Health這個int值進做了復制設置

知識點分析：

當變量被標記為Replicated后，在服務器修改該變量數值，系統會及時將其更新到客戶端，此時對該變量進行調用則可以拿到更新后的值；【使用在角色屬性或是繪制相關數據的同步情景，】

案例1.4值復制（更新變量值時觸發一次函數調用）

本實例使用定時修改一個標記為RepNotify的浮點值得方式變更交通燈的狀態;我們主要學習RepNotify標記所帶來的一次事件調用；

1，創建一個變量
2，標記為Replicated
3，你會發現蹦出來一個與該變量關聯的函數
4，桶蓋這個函數來對變量賦值即可
標記提供的一次函數調用，此處用來變更材質顏色屬性值
為什么燈有變化？有興趣的同學看看材質藍圖

知識點：

使用該標記后得到的函數調用，可以用來編輯一些諸如生命歸零的死亡判斷，或是與跟該變量有關的函數賦值操作就像本示例中的材質屬性變更都可以寫在該函數中；

案例1.5 事件廣播Multicast的使用

本實例通過對自定義事添加Multicast標簽使其成為服務器在調用時，所有客戶端都會觸發的事件，達到廣播的目的；

觸發事件的廣播設置

案例2.1 不添加復制標記的藍圖效果

本實例應當是作為參照示例使用，并沒有特殊之處

我們可以看到永遠是服務器端觸發金閃閃實現，
畢竟事件沒有加復制標記客戶端未接收任何事件調用

案例2.2 依舊是事件廣播Multicast的使用

本實例中關于事件廣播就不贅述了，我們可以發現一個有趣的事情就是有個圈，在圈外的客戶端是無法接收到廣播消息的，并且在進入環形范圍內也不會再看到觸發效果【廣播事件是不會被保存的】（當然你站上去也是沒用的，以為有DoOne節點，只可能發生一次）

Paste_Image.png

看一下圈是怎么縮放設置的

縮放環形模型大小

該值是每個參與復制的對象，都需要設置的值，該值標示這個對象接收服務器消息數據更新的范圍（這個值不能直接用，為了距離比較時削減運算開銷所以是個平方值，這里注意一下）

注意該對象的Replicates屬性

案例2.3關于如何對進入復制檢測范圍的對象進行狀態更新

本實例中使用了一個bool值來記錄狀態，當有客戶端進入該范圍內時更新這個客戶端用戶的變量值，這個時候會觸發Replicated標記創建來的函數，也就實現了開箱和閃光效果

此處將特效顯示與箱子翻起的顯示部分都放在這個函數內了

知識點：

我們可以模仿此方法，來實現對走入檢測范圍內的新對象的狀態更新；

案例2.4 僅保留開箱后的結果更新，不顯示閃光特效

我們可以看到這個版本的藍圖中開箱與閃光特效被分開觸發了，這樣在觸發范圍內的客戶端可以接收到觸發閃光特效也可通過變更bool值變量來完成開箱動畫，但是后進入的客戶端僅能觸發開箱動畫，即完成了新版組合方案；

變更后的藍圖 創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的UE4 HTC VIVE - 番外篇 - 局域网联机（二）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。