基于虛幻引擎的ACT 游戲設(shè)計與開發(fā)

游戲體系架構(gòu)設(shè)計（MVC架構(gòu)）淺談MVC架構(gòu)在游戲中的應(yīng)用MVC模式（Model-view-controller）是軟件工程中的一種軟件架構(gòu)模式，把軟件系統(tǒng)分為三個基本部分：模型（Model）、視圖（View）和控制器（Controller）。 模型：有一種思想叫做“所有的開發(fā)都是以數(shù)據(jù)為中心”，在MVC中模型就是我們的數(shù)據(jù)中心，它的工作主要是保存數(shù)據(jù)并且處理數(shù)據(jù)組織的相關(guān)邏輯。以好友系統(tǒng)為例，好友模型需要保存從服務(wù)器請求過來的數(shù)據(jù)，然后提供接口返回排序后的好友列表。 視圖：視圖負責(zé)與用戶的交互，而交互又分兩種，分別為輸入和輸出。輸入就是收集玩家的操作，例如點擊一個按鈕或者輸入某些文字。而輸出就是將游戲中的各種數(shù)據(jù)展示出來。 控制器：控制器則相當(dāng)于一個控制中心，它關(guān)聯(lián)著模型與視圖。當(dāng)模型改變時控制器會將改變更新到視圖上顯示出來。而視圖接收到玩家的交互時，控制器會對數(shù)據(jù)做出相應(yīng)的處理。UI與表現(xiàn)層UI系統(tǒng)我將每個UI頁面劃分一個個小的控件構(gòu)成，且每個小的控件可復(fù)用。對于一個按鈕，它一般包括鼠標(biāo)移入動畫、鼠標(biāo)移出動畫、鼠標(biāo)點擊動畫、按鈕外觀以及鼠標(biāo)點擊后的響應(yīng)函數(shù)。對同種類型的按鈕來說，一般只有按鈕背景及鼠標(biāo)點擊后的響應(yīng)函數(shù)不同，例如技能。外觀可將背景圖片用一個變量保存，這樣改變一個按鈕背景只需改變一個變量即可；而按鈕點擊后的響應(yīng)函數(shù)可只調(diào)用一個Dispatcher，當(dāng)我們使用一個按鈕的時候只需定義對應(yīng)按鈕對象的Dispatcher即可（若未定義則為空函數(shù)）。這樣可以大大減少不必要的重復(fù)開發(fā)，以減少開發(fā)時長。游戲表現(xiàn)層設(shè)計把表現(xiàn)層和邏輯層分開是一件必須要做的事情，這么做有幾個顯而易見的好處：表現(xiàn)層出錯不會影響邏輯；不依賴表現(xiàn)層的邏輯便于在不同設(shè)備、不同平臺復(fù)用；可以快速模擬一個邏輯較長時間運行的結(jié)果，特別適合用嘗試的方法尋找最佳選擇的AI等。理論上，一個游戲，只要玩家的輸入能夠獲得反饋，并且反饋是符合游戲規(guī)則的就可以。至于輸出設(shè)備是顯示器還是蜂鳴器并不重要。一個好的游戲表現(xiàn)層設(shè)計的目標(biāo)是——去掉表現(xiàn)層也不影響邏輯邏輯層的運行。表現(xiàn)層可以獲得邏輯層的信息，但絕對不能操作邏輯層。但把表現(xiàn)層設(shè)計的完全與邏輯層無關(guān)是意義不大的，因為：表現(xiàn)層本身就是為了表現(xiàn)邏輯層，認為它們完全無關(guān)、強行將它們完全分割開是一種設(shè)計過度和本末倒置；表現(xiàn)層為了更好的效果可能需要實時獲得一些邏輯層的信息，這些信息全都靠事件和指令傳遞毫無效率?；叵胂挛覀兊哪繕?biāo)其實是：去掉表現(xiàn)層也不影響邏輯邏輯層的運行。我們只要確保表現(xiàn)層不會影響到邏輯層就可以了?！氨憩F(xiàn)層可以獲得邏輯層的信息”的例子：“當(dāng)收到一個消息‘某個對象從A點移動到B點’時，表現(xiàn)層去找邏輯層獲得這個對象的HP信息，從而決定在其身上播放怎樣的特效，這是比較自然的。反過來如果邏輯層拋出的‘移動’消息中包含HP簡直不可理喻；而把將要播放什么樣的特效放在拋出的消息里也不對，因為這不是邏輯層應(yīng)該關(guān)心的——事實上睿智的策劃可能經(jīng)常做出這樣的畫面改動，這種改動本來就不應(yīng)該影響到邏輯代碼?！薄氨憩F(xiàn)層絕對不能操作邏輯層”的例子：“一個氣泡在水中上浮，升到某一高度會分裂為兩個氣泡。表現(xiàn)層很可能比邏輯層更清楚地知道氣泡的高度（因為邏輯層有時候只關(guān)心軌跡、路線而不是具體某時刻的坐標(biāo)），所以這時候一定要忍住不要在表現(xiàn)層判斷高度然后生成分裂的氣泡對象——通知邏輯層這么做也不行，因為這違背了‘去掉表現(xiàn)層也不影響邏輯邏輯層的運行’的原則。正確的做法一定是在邏輯層做判斷。邏輯層知道的信息永遠比表現(xiàn)層要多，盡管可能是一些raw信息。在這個例子中，即便邏輯層只關(guān)心氣泡從一個點走到另一個點的路徑，也一定有辦法預(yù)先計算出到達分裂高度的時間。最后一定是邏輯層來決定何時創(chuàng)建新對象?！边壿嫎I(yè)務(wù)層戰(zhàn)斗系統(tǒng)戰(zhàn)斗系統(tǒng)由幾個部分組成：人物移動、普攻、技能、防御、受擊打和死亡組成。（人物狀態(tài)機）好友對戰(zhàn)系統(tǒng)局域網(wǎng)好友對戰(zhàn)分為主機（創(chuàng)建房間的玩家同時作為服務(wù)器與客戶端）與非主機（作為客戶端）。為保證游戲的公平性大部分邏輯的執(zhí)行都在服務(wù)器，玩家的操作會傳遞至服務(wù)器執(zhí)行，然后將執(zhí)行結(jié)果傳遞回客戶端。例如玩家釋放技能時會告知服務(wù)器此時釋放技能，并通過表現(xiàn)層釋放技能動畫，但傷害判定會由服務(wù)器完成。網(wǎng)絡(luò)層UE4多人游戲基于客戶端-服務(wù)器模式。也就是說，會有一個服務(wù)器擔(dān)當(dāng)游戲狀態(tài)的主控者，而連接的客戶端將保持近似復(fù)本。服務(wù)器設(shè)計服務(wù)器是UE4多人游戲的一個重要部分。服務(wù)器的作用包括：做出所有重要決定，包含所有的主控狀態(tài)，處理客戶端連接，轉(zhuǎn)移到新的地圖以及處理比賽開始/結(jié)束時的總體游戲流程等。服務(wù)器負責(zé)驅(qū)動游戲流程，在游戲開始/結(jié)束或切換地圖時傳遞所需信息給所有客戶端，在游戲進行時會傳遞每一個Actor中我們設(shè)定好需要傳遞的信息給所有客戶端。游戲狀態(tài)和流程一般是通過GameMode這一Actor來驅(qū)動。只有服務(wù)器才包含此Actor的有效復(fù)本（客戶端不包含復(fù)本）。要向客戶端傳達該狀態(tài)，可以使用GameStateActor顯示GameModeActor的重要狀態(tài)。GameStateActor被標(biāo)記為復(fù)制到每個客戶端?？蛻舳藢薌ameStateActor的一個近似復(fù)本，而且能使用這個Actor作為引用，用于了解游戲的一般狀態(tài)。該游戲中大多數(shù)的邏輯層代碼都只在服務(wù)器中運行，然后由服務(wù)器傳遞特定結(jié)果給客戶端?？蛻舳嗽O(shè)計客戶端主要是完成各類表現(xiàn)層的功能以及少量邏輯層功能（例如人物移動是客戶端先行進行移動然后再根據(jù)服務(wù)器所傳遞的位置信息進行校驗與調(diào)整）?？蛻舳伺c服務(wù)器的通信當(dāng)新的客戶端初次連接時，會發(fā)生一些事情。首先，客戶端要向即將連接的服務(wù)器發(fā)送一個請求。服務(wù)器將處理這條請求。如果它不拒絕連接，服務(wù)器會向客戶端發(fā)回一個包含了繼續(xù)運行所需信息的響應(yīng)。主要步驟如下：客戶端發(fā)送連接請求。如果服務(wù)器接受連接，則發(fā)送當(dāng)前地圖。服務(wù)器等待客戶端加載此地圖。加載之后，服務(wù)器將在本地調(diào)用AGameModeBase::PreLogin。這樣可以使GameMode有機會拒絕連接如果接受連接，服務(wù)器將調(diào)用AGameModeBase::Login該函數(shù)的作用是創(chuàng)建一個PlayerController，可用于在今后復(fù)制到新連接的客戶端。成功接收后，這個PlayerController將替代客戶端的臨時PlayerController（之前被用作連接過程中的占位符）。此時將調(diào)用APlayerController::BeginPlay。應(yīng)當(dāng)注意的是，在此actor上調(diào)用RPC函數(shù)尚存在安全風(fēng)險。您應(yīng)當(dāng)?shù)却鼳GameModeBase::PostLogin被調(diào)用完成。如果一切順利，AGameModeBase::PostLogin將被調(diào)用。這時，可以放心的讓服務(wù)器在此PlayerController上開始調(diào)用RPC函數(shù)。當(dāng)連接建立后，客戶端與服務(wù)器之間的通信主要為Actor的復(fù)制。Actor的復(fù)制包括：組件復(fù)制：服務(wù)器向客戶端同步組件。屬性復(fù)制：服務(wù)器向客戶端同步變量（當(dāng)變量發(fā)生改變時）。RPC（遠程過程調(diào)用）：RPC允許客戶端或服務(wù)器通過網(wǎng)絡(luò)連接相互發(fā)送消息。默認情況下，RPC并不可靠。要確保在遠程機器上執(zhí)行RPC調(diào)用，需添加Reliable關(guān)鍵字。RPC的具體調(diào)用如下表所示。Actor所有權(quán)未復(fù)制NetMulticastServerClientClient-ownedactor在服務(wù)器上運行在服務(wù)器和所有客戶端上運行在服務(wù)器上運行在actor的所屬客戶端上運行Server-ownedactor在服務(wù)器上運行在服務(wù)器和所有客戶端上運行在服務(wù)器上運行在服務(wù)器上運行Unownedactor在服務(wù)器上運行在服務(wù)器和所有客戶端上運行在服務(wù)器上運行在服務(wù)器上運行（從服務(wù)器調(diào)用的RPC）Actor所有權(quán)未復(fù)制NetMulticastServerClientOwnedbyinvokingclient在執(zhí)行調(diào)用的客戶端上運行在執(zhí)行調(diào)用的客戶端上運行在服務(wù)器上運行在執(zhí)行調(diào)用的客戶端上運行Ownedbyadifferentclient在執(zhí)行調(diào)用的客戶端上運行在執(zhí)行調(diào)用的客戶端上運行丟棄在執(zhí)行調(diào)用的客戶端上運行Server-ownedactor在執(zhí)行調(diào)用的客戶端上運行在執(zhí)行調(diào)用的客戶端上運行丟棄在執(zhí)行調(diào)用的客戶端上運行Unownedactor在執(zhí)行調(diào)用的客戶端上運行在執(zhí)行調(diào)用的客戶端上運行丟棄在執(zhí)行調(diào)用的客戶端上運行（客戶端調(diào)用的RPC）（數(shù)據(jù)發(fā)送流程） （數(shù)據(jù)接收流程）本章小結(jié) 我的設(shè)計思路來自于守望先鋒，將每一個功能盡可能的劃分為一個個可以復(fù)用的子功能，避免重復(fù)開發(fā)，提高效率。游戲架構(gòu)可以說是一個游戲中最重要的部分，好的架構(gòu)可以做到事倍功半的作用，對于一款應(yīng)用來說（尤其是當(dāng)這款應(yīng)用成為了大型應(yīng)用），重構(gòu)的代價是十分之高的。架構(gòu)只有更好沒有最好，作為一個虛幻引擎剛?cè)腴T的初學(xué)者，在架構(gòu)的設(shè)計上還亟待提高。第四章ACT游戲的開發(fā)與制作ACT游戲的開發(fā)與制作游戲背景介紹游戲采用第三人稱游戲模式，以格斗游戲與動作冒險為游戲類型，同時融入了RPG元素。游戲背景設(shè)立為公元286年，古羅馬帝國被一分為二分裂成東羅馬帝國與西羅馬帝國的時代。單機模式下，玩家將扮演一位東羅馬帝國的騎士，被派往營救被敵國俘虜?shù)幕首?，并完成?fù)仇；聯(lián)機模式下，兩位玩家會分別扮演東羅馬帝國和西羅馬帝國的兩位戰(zhàn)士，為了己方帝國的榮譽進行1V1決斗。游戲玩法玩家扮演的主角，左手持盾、右手持劍，玩家可以通過有技巧的移動躲避、防御、普攻和技能來與敵方戰(zhàn)斗，并可通過隨機產(chǎn)生的急救藥品進行少量血量回復(fù)。開發(fā)意圖與游戲特色開發(fā)意圖旨在實現(xiàn)一個冷兵器時代的競技對戰(zhàn)類游戲。游戲特色為該游戲體量小，只保留了競技游戲所需的內(nèi)容，除去了許多無用的內(nèi)容，且戰(zhàn)斗方式完全參考冷兵器時代，讓玩家能在各種玄幻、魔法類戰(zhàn)斗游戲橫行的年代體會到冷兵器時代的戰(zhàn)斗方式與新奇的快感。游戲開發(fā)環(huán)境游戲引擎選用游戲引擎我選用的是UnrealEngine4.21.2，因為虛幻引擎4的場景渲染效果更偏向中世紀風(fēng)格，且封裝了網(wǎng)絡(luò)功能，便于開發(fā)。編程語言優(yōu)勢編程語言選用的是C++語言，因為虛幻引擎4的客戶端開發(fā)基本由C++語言完成。因為C++語言不但擁有極高的性能（虛幻引擎4需要較高的性能），而且C/C++可以被嵌入任何現(xiàn)代處理器中，幾乎所有操作系統(tǒng)都支持C/C++，跨平臺性非常好。游戲模塊開發(fā)表現(xiàn)層角色模型與動畫角色模型主要由Materials（材質(zhì)）、Skeleton（骨架）、Textures（貼圖）構(gòu)成，其中骨架與材質(zhì)構(gòu)成SkeletonMesh（骨架網(wǎng)格體）。動畫主要由AnimationSequences（動畫序列）構(gòu)成，然后由動畫序列構(gòu)成BlendSpace（混合空間）和Montage（動畫蒙太奇），最終由三者共同構(gòu)成AnimationBlueprint（動畫藍圖）。由骨骼網(wǎng)格體與動畫藍圖構(gòu)成最終的人物（也稱人物藍圖）。動畫播放與Blend動畫播放主要由AnimationBlueprint（動畫藍圖）實現(xiàn)，動畫藍圖決定著角色不同時刻應(yīng)該播放何種動畫。動畫藍圖分為EventGraph（事件圖表）和AnimGraph（動畫圖表），事件圖表負責(zé)從游戲中獲取各種數(shù)據(jù)（移動速度、人物當(dāng)前狀態(tài)等），動畫圖表則是使用狀態(tài)機的形式播放AnimationSequences（動畫序列）或BlendSpace（混合空間）來控制人物的動畫播放。EventGraph（事件圖表） AnimGraph（動畫圖表）場景模型與加載優(yōu)化場景模型構(gòu)建本游戲場景模型是由多個StaticMesh（靜態(tài)網(wǎng)格體）構(gòu)成，場景的搭建是由一個個小的靜態(tài)網(wǎng)格體組件拼撘而成。LOD與mipmap優(yōu)化LOD（LevelOFDetial），多細節(jié)層次（多層次細節(jié)），其作用是在Mesh優(yōu)化的時候為了減少渲染三角面片數(shù)量而產(chǎn)生的一種技術(shù)。LOD產(chǎn)生原因：對于普通沒有運用LOD的Mesh渲染時，無論Mesh距離攝像機的距離是多少，都渲染出相同的效果，相同的頂點數(shù)和面數(shù)。為了實現(xiàn)渲染的頂點數(shù)和面數(shù)隨距離相機的遠近而減少、增加，提高渲染效率，產(chǎn)生LOD。LOD原理：事先存儲不同頂點數(shù)、面數(shù)的同一種Mesh，設(shè)置與攝像機不同距離先顯示何種模型，解決問題，實現(xiàn)優(yōu)化。Mipmap（多級漸進紋理），Mipmap產(chǎn)生的原因：對于紋理根據(jù)距離相機遠近而采用不同分辨率去渲染。Mipmap原理：多級漸進紋理是由一組分辨率逐漸降低的紋理序列組成的，每級紋理寬度、高度都是上一級紋理寬高的一半，根據(jù)距相機遠近采用不同紋理渲染。特效與后處理粒子特效實現(xiàn)與控制UE4中存在一套完整的粒子系統(tǒng)實現(xiàn)系統(tǒng)，它將粒子特效實現(xiàn)了模塊化。每個模塊代表了粒子行為的一個特定方面，并只對行為的該方面提供屬性參數(shù)，比如顏色、生成的位置、移動行為、縮放行為，及其他等。用戶可以在需要的時候添加或者刪除一個模塊，來進一步定義粒子的整體行為。由于這里的結(jié)果中只有必要的模塊才會被添加進來，因此并沒有額外的計算，也沒有不需要的屬性變量的參與，且模塊可以很容易的被添加、刪除、拷貝。（默認模塊）Required-包含一些粒子系統(tǒng)絕對需要用到的屬性，比如粒子使用的材質(zhì)，發(fā)射器發(fā)射粒子的時間等。Spawn-控制粒子從發(fā)射器生成的速度，它們是否以Burst生成，以及其他和粒子發(fā)生時機有關(guān)的屬性。Lifetime-定義了每個粒子在生成后存在的時間，如果沒有這個模塊，粒子則會一直持續(xù)下去。InitialSize-這里對粒子生成時的縮放比例進行控制。InitialVelocity-這里對粒子生成時的移動進行控制。ColorOverLife-用于控制每個粒子的顏色的改變。屏幕后處理實現(xiàn)虛幻引擎4提供了后處理特效的功能，可以實現(xiàn)景深、光溢出、色調(diào)調(diào)整、飽和度等。虛幻引擎4的后處理是由PostProcessVolumn實現(xiàn)的，它一種特殊的體積，可以放置在場景中的任何位置。例如我們可以在Misc里面添加不同的材質(zhì)，來調(diào)節(jié)全局對比度，飽和度以及色溫的效果，也可以做一些鏡頭的特效，比如模糊，景深等。另外，我們也可以利用他實現(xiàn)描邊的效果，這需要一個菲涅爾效果的材質(zhì)，同時要把他添加到當(dāng)前的渲染層里面。虛幻引擎4為了方便開發(fā)者，特意在Mesh組件里面提供了一個這樣的接口bRenderCustomDepth來允許在游戲線程里面單獨渲染自定義的效果材質(zhì)。畫面渲染與優(yōu)化模型材質(zhì)選取與實現(xiàn)本次項目中，我采用了PBR材質(zhì)作為角色模型的貼圖材質(zhì)。角色鎧甲的質(zhì)感采用了較高金屬度的材質(zhì)，同時漫反射會使得鎧甲比較粗糙，符合角色特征；角色皮膚采用低金屬度、高粗糙度的材質(zhì)，皮膚的細節(jié)在紋理中體現(xiàn)；角色的衣服材質(zhì)與皮膚類似，但是由于有物理骨骼的作用，會顯得更為生動。光源排布與選取在空間環(huán)境光照亮場景與人物的同時，為了強調(diào)人物的細節(jié)與重點，在人物重心跟隨一個點光源，保證玩家能夠在陰影區(qū)域依然可以看清楚角色細節(jié)。實時軟陰影由于計算量過大，計算效率低，我采取了烘焙光照貼圖的方法。在場景需要照亮的地方，擺放足夠多的光源進行照亮，進行全局光的離線渲染，在烘焙出光照貼圖后，在加載場景的時候一同加載。雖然犧牲了少部分全局光帶來的、精致逼真的鏡面反射跟隨效果，但是在大大提升光照效果的同時，還有效提升了光照效率。真實感渲染場景和角色的真實性一直是畫面渲染追求的目標(biāo)。在場景和角色模型中，很多細節(jié)部位無法通過建模來實現(xiàn)，因為過高的面數(shù)會導(dǎo)致模型加載卡頓。那么這些細節(jié)我采用了法向紋理貼圖的方式來實現(xiàn)。法向貼圖是一張記錄了模型頂點法向量的貼圖，其像素點的rgb值分別代表了法向的3D矢量分量。這樣簡單的一張貼圖可以做到修改模型局部法向的效果，在光照計算中，會采用法向貼圖提供的法向信息，而非模型本身的法向量。這樣會對畫面的真實感有很大的提升。除此以外，畫面的后期處理也為真實感提供了很多選擇。雖然全局軟陰影有了很好的效果，但是局部依然有所欠缺或計算錯誤。在畫面后處理中，我選擇了SSAO，對模型交界處的陰影效果有了很大的改善。同時blur效果自發(fā)光材質(zhì)提供了光暈效果，使得光效更為真實。業(yè)務(wù)邏輯層戰(zhàn)斗邏輯模塊技能系統(tǒng)技能系統(tǒng)分為技能管理器、技能與技能動畫。技能與普攻都包含在技能系統(tǒng)中，人物在短時間內(nèi)普攻可接下一段普攻，技能可以打斷普攻。技能在結(jié)束是分兩步結(jié)束，分別為結(jié)束動畫（普攻在動畫結(jié)束后可接下一段普攻）與結(jié)束技能，兩者有短暫的時間差（無多段技能的則沒有時間差），具體流程如下圖所示：（技能施放流程）Buff系統(tǒng)Buff系統(tǒng)分為Buff管理器、Buff與Effect（Buff包含的效果）。若人物可以添加Buff，只需為其添加Buff管理器組件，Buff管理器包括AddBuff與RemoveBuff的接口。Buff管理器會逐幀遍歷所有存在的Buff并更新Buff持續(xù)時間，若持續(xù)時間已到變終止Buff。當(dāng)添加、移除、更新Buff時會啟動、結(jié)束、刷新其所有效果（每個效果為獨立計時執(zhí)行）。在該系統(tǒng)中每個Buff與Effect都為單例，但必要數(shù)據(jù)（例如每個Buff的剩余持續(xù)時間、當(dāng)前Buff層數(shù)、每個Effect的定時器對象等）是存放于Buff管理器中。因為游戲生成實例是比較損耗的操作，尤其是當(dāng)游戲為大型ACT游戲時可能會同時存在幾百上千個Buff實例，這樣可以降低系統(tǒng)的負載。具體流程如下圖所示：（Buff大致流程） 數(shù)據(jù)存放代碼： voidAddDataMemory(UBuff*Ptr,int32MemorySize){ BuffOffsetMap.Add(Ptr,BuffInstanceMemory.Num()); BuffInstanceMemory.AddZeroed(MemorySize);}VoidRemoveDataMemory(UBuff*Ptr,int32MemorySize){ BuffInstanceMemory.RemoveAt(BuffOffsetMap.FindRef(Ptr),MemorySize); boolbBeginChange=false; for(autoIter=BuffOffsetMap.CreateIterator();Iter;++Iter) { if(bBeginChange==false&&Iter.Key()==Ptr) { bBeginChange=true; continue; } if(bBeginChange) Iter.Value()-=MemorySize; } BuffOffsetMap.Remove(Ptr);}戰(zhàn)斗開始與結(jié)束在單機模式下，敵方NPC具有一個觀察視野，當(dāng)主角進入觀察視野后雙方會開始戰(zhàn)斗，直至其中一方死亡戰(zhàn)斗便會結(jié)束。技能與連招在該游戲中存在普攻與若干個技能。普攻分為三段，當(dāng)一段普攻結(jié)束后短時間內(nèi)按出普攻可接下一段普攻。普攻施放前搖階段受傷，施放技能或死亡可打斷普攻施放。技能施放前搖階段與死亡可打斷技能施放。打擊判定打擊判定根據(jù)施放不同的招式（不同段普攻或不同技能）可將打擊判定分為矩形判定、扇形判定以及范圍判定。UI模塊UI模塊分為游戲前，游戲中與菜單模塊。游戲前包括主界面（可選擇單機模式與局域網(wǎng)模式，或退出游戲）和局域網(wǎng)組隊界面（包括創(chuàng)建房間與當(dāng)前房間列表界面）；游戲中包括人物血量顯示，技能及冷卻顯示；菜單模塊為游戲中呼出菜單界面，其中包含重新開始、返回主菜單、退出游戲和返回功能。網(wǎng)絡(luò)層服務(wù)器搭建虛幻引擎4自帶一套網(wǎng)絡(luò)聯(lián)機機制，服務(wù)器與客戶端使用的是一套代碼，局域網(wǎng)游戲中創(chuàng)建游戲房間的玩家既是客戶端也是服務(wù)器。網(wǎng)絡(luò)協(xié)議虛幻引擎4使用的網(wǎng)絡(luò)協(xié)議為UDP協(xié)議，并基于UDP實現(xiàn)了傳輸?shù)目煽啃浴Ｍㄓ梅?wù)層事件派發(fā)與監(jiān)聽系統(tǒng)虛幻引擎4的事件派發(fā)與監(jiān)聽主要是一種Delegate的機制（Delegate是一種常見的設(shè)計模式），虛幻引擎4中的代理類型分為三種：多播代理、動態(tài)單播代理和動態(tài)多播代理。其作用廣泛，諸如碰撞、UI、藍圖、輸入等功能都會使用。函數(shù)描述Bind()綁定到一個現(xiàn)有的代理對象上。BindRaw()綁定到一個原始的C++指針全局函數(shù)代理上。原始指針不使用任何引用，所以如果從代理的底層刪除了該對象，那么調(diào)用它可能是不安全的，因此當(dāng)調(diào)用Execute()時要謹慎。BindSP()綁定一個基于共享指針的成員函數(shù)代理。共享指針代理保持到對象的弱引用，可以使用

ExecuteIfBound()

來調(diào)用它們。BindUObject()綁定一個基于UObject的成員函數(shù)代理。UObject代理保持到對象的弱引用，可以使用

ExecuteIfBound()

來調(diào)用它們。UnBind()解除綁定該代理。（綁定代理）執(zhí)行函數(shù)主要有三個，分別是Execute()、ExecuteIfBound()、IsBound()。本章小結(jié)在這款游戲中我覺得最需要提高的是人物戰(zhàn)斗方面。一款游戲永遠不是一個人能做的完美的，在缺少各種素材資源（例如擊飛、擊退等各類需要美術(shù)完成的打擊動畫）的情況下我無法將人物戰(zhàn)斗做的更加逼真，這也是我最遺憾的地方。第五章游戲設(shè)計與開發(fā)成果游戲設(shè)計與開發(fā)成果戰(zhàn)斗展示畫面細節(jié)展示性能分析在開發(fā)者模式下運行游戲幀率基本穩(wěn)定在60幀，偶爾會出現(xiàn)跳幀的情況，預(yù)計在Release情況下進行游戲會更好。網(wǎng)絡(luò)穩(wěn)定性分析在局域網(wǎng)情況下進行游戲網(wǎng)絡(luò)基本穩(wěn)定。游戲體驗綜述游戲流暢度較高，極少出現(xiàn)卡頓的情況，戰(zhàn)斗中打擊感有待提高。致謝結(jié)論論文工作總結(jié)ACT游戲已成為現(xiàn)如今最主流的游戲類型，每年有數(shù)不盡的新游戲上線，而游戲引擎作為其最主要的開發(fā)工具，尤為重要。在這段時間的設(shè)計與開發(fā)里，我總體完成了以下的幾項工作：1、研究了虛幻引擎4，學(xué)習(xí)了引擎許多功能的使用方式，并通過查閱相關(guān)的文獻資料對ACT游戲的開發(fā)有了一定了解。2、設(shè)計了游戲中UI、人物狀態(tài)機、技能系統(tǒng)、Buff系統(tǒng)、道具系統(tǒng)以及戰(zhàn)斗方式等。3、在研究設(shè)計的基礎(chǔ)上對游戲進行開發(fā)，并在開發(fā)時將一個個大