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

網(wǎng)絡游戲中各段關系圖

客戶端職責：

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

服務器職責：

1）接收客戶端的指令并處理；
2）廣播當前幀所需的游戲數(shù)據(jù)與游戲狀態(tài)；

強聯(lián)網(wǎng)中的高帶寬與游戲中的卡頓解釋：

服務器壓力：

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

高帶寬：

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

我們再來看局域網(wǎng)中的主機與客戶端的關系

主機與客戶端的關系

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

--------------------開啟本章內(nèi)容（官方案例講解）-----------------------------

書接上回在上一篇尾巴上留了RPC介紹，也就是虛幻的函數(shù)復制原理，本章我?guī)е蠹疫^一遍官方關于networke的案例，了解一下變量復制與函數(shù)復制以便后面使用節(jié)點時不會懵逼；

下載官方案例"內(nèi)容示例"

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

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

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

案例1.1對象的復制

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

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

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

運行結(jié)果

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

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

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

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

確認服務器執(zhí)行

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

案例1.2 Switch Has Authority節(jié)點學習

該實例通過對服務器和客戶端執(zhí)行不同實現(xiàn)來加深對Switch Has Authority 節(jié)點的了解；

顯示結(jié)果
該幽靈的藍圖

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

該實例主要使用值復制的方法來實現(xiàn)客戶端與主機的數(shù)據(jù)同步；

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

知識點分析：

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

案例1.4值復制（更新變量值時觸發(fā)一次函數(shù)調(diào)用）

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

1，創(chuàng)建一個變量
2，標記為Replicated
3，你會發(fā)現(xiàn)蹦出來一個與該變量關聯(lián)的函數(shù)
4，桶蓋這個函數(shù)來對變量賦值即可
標記提供的一次函數(shù)調(diào)用，此處用來變更材質(zhì)顏色屬性值
為什么燈有變化？有興趣的同學看看材質(zhì)藍圖

知識點：

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

案例1.5 事件廣播Multicast的使用

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

觸發(fā)事件的廣播設置

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

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

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

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

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

Paste_Image.png

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

縮放環(huán)形模型大小

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

注意該對象的Replicates屬性

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

本實例中使用了一個bool值來記錄狀態(tài)，當有客戶端進入該范圍內(nèi)時更新這個客戶端用戶的變量值，這個時候會觸發(fā)Replicated標記創(chuàng)建來的函數(shù)，也就實現(xiàn)了開箱和閃光效果

此處將特效顯示與箱子翻起的顯示部分都放在這個函數(shù)內(nèi)了

知識點：

我們可以模仿此方法，來實現(xiàn)對走入檢測范圍內(nèi)的新對象的狀態(tài)更新；

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

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

變更后的藍圖 創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。