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

ExecuteIfBound()

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

ExecuteIfBound()

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