隨手寫的，將近一萬字，懶得二次整理了

內(nèi)附工程源碼，見評論區(qū)！

一、教程筆記—————————————

由于我從26課開始才想著要記筆記，前面可能也有很多可以寫的地方，但是不想再看一遍了

而且由于我是開2倍速看的，30節(jié)后面幾乎是3倍速+跳進(jìn)看的，這份筆記肯定是不全面的，僅供參考

筆記這塊只是簡述，后面自己做的時(shí)候可能寫了詳細(xì)說明

第26節(jié)

多格式文本需要設(shè)置樣式，且每次修改配置后需要編譯才可預(yù)覽

需要注意UI綁定屬性是每幀執(zhí)行的，最好用事件驅(qū)動UI

第12節(jié)

敵人變色直接在材質(zhì)里做動畫就行

第11節(jié)

菜單說明，最好定義枚舉，根據(jù)按鈕的枚舉彈出說明，根據(jù)枚舉游標(biāo)計(jì)算偏移位置即可

第9節(jié)

過場動畫的圖片，20次復(fù)制粘貼的部分，可以嘗試用for循環(huán)寫，也可以嘗試在材質(zhì)實(shí)例里實(shí)現(xiàn)

第8節(jié)排序算法

考慮封裝函數(shù)庫，方便類似的情況使用

第7節(jié)

刪除再添加玩家實(shí)體，缺少這么做的意義，不如直接移動，因?yàn)橥婕覍?shí)體內(nèi)存了太多必要數(shù)據(jù)了

第29節(jié)

存檔頭像、先手列表頭像等，建議存入一個數(shù)組，然后遍歷設(shè)置

第30節(jié)

讀取后，創(chuàng)建只寫一套，根據(jù)是否讀取決定數(shù)據(jù)而已，善用branch等流程控制

第31節(jié)

怪物掉落數(shù)值可以放到怪物數(shù)據(jù)表格中，在結(jié)算時(shí)根據(jù)怪物ID去取

第33節(jié)

刪除生成玩家沒必要，可以記一下死掉的index即可

第35節(jié)

可以不用定時(shí)器觸發(fā)函數(shù)，這種0.01秒一個計(jì)時(shí)器，不知道會出什么問題，實(shí)際上等于一個tick函數(shù)

第36節(jié)

道具效果，同類封裝，改變屬性的上下限等處理應(yīng)在屬性內(nèi)部寫，而不是在效果內(nèi)寫，同理，死亡亦可寫在屬性內(nèi)，再傳出通知

這塊沒具體研究，UE的游戲?qū)傩灶?，官方文檔中提到自帶了響應(yīng)屬性變更的事件，可以在屬性變化時(shí)進(jìn)行上下限處理

第37節(jié)

道具選中敵我改用委托

第47節(jié)

直接設(shè)置game?input?mode

UI內(nèi)寫reset和init，沒必要移除控件再重新創(chuàng)建，移除后是需要等待進(jìn)行垃圾回收的，每次創(chuàng)建都是新生成一個對象

由于翻譯問題和查找方便問題，建議使用英文引腳和函數(shù)名，在編輯器設(shè)置的語言部分

循環(huán)，寫for和break、while更清晰

數(shù)據(jù)表格主鍵，類似數(shù)據(jù)庫主鍵和map的鍵值對概念，UE內(nèi)叫row?name

升級經(jīng)驗(yàn)動畫的簡化，可以直接tick，根據(jù)delta計(jì)算變化量，再設(shè)置給進(jìn)度值/數(shù)字顯示

大拇指沒必要復(fù)制粘貼多份藍(lán)圖，做成一個子控件，存入一個數(shù)組，再進(jìn)行顯示隱藏的操作

二、實(shí)際開始制作的筆記—————————————

最核心的是，用數(shù)據(jù)驅(qū)動表現(xiàn)

地圖關(guān)卡、戰(zhàn)斗場景actor、gamemode、playerController等，哪些邏輯放在哪個部分，是需要明確的規(guī)則來區(qū)分的

很多邏輯可以直接寫在戰(zhàn)斗場景里，而沒必要在幾個藍(lán)圖之間來回調(diào)來回傳，戰(zhàn)斗的邏輯強(qiáng)綁定在戰(zhàn)斗場景這個actor內(nèi)，需要復(fù)用時(shí)通常只會改變配置/數(shù)據(jù)，如生成角色位置、攝像機(jī)位置、場景大小等，可以放到數(shù)據(jù)表配置中，亦可創(chuàng)建新的不帶邏輯的戰(zhàn)斗場景2，再把2的數(shù)據(jù)傳給戰(zhàn)斗場景1進(jìn)行覆蓋

例如移動角色進(jìn)行攻擊，移動和播放攻擊動畫、顯示傷害數(shù)字，均為客戶端表現(xiàn)，不需要用gamemode寫，gamemode只在服務(wù)器上運(yùn)行，服務(wù)器實(shí)際上只需要知道誰打了誰，打了多少傷害即可（即走一遍傷害/技能/道具效果計(jì)算流程），然后再通知場景進(jìn)行表現(xiàn)。

戰(zhàn)斗場景可以視為一個統(tǒng)管所有進(jìn)入戰(zhàn)斗后的邏輯表現(xiàn)的actor，所以也可以在觸發(fā)進(jìn)入戰(zhàn)斗時(shí)動態(tài)生成該actor，一樣能復(fù)用的

UE5中一些同類節(jié)點(diǎn)被折疊到一個節(jié)點(diǎn)中了，例如multiply，拉出該節(jié)點(diǎn)后可把節(jié)點(diǎn)引腳轉(zhuǎn)化為任意數(shù)據(jù)類型，比如vector，默認(rèn)拉出為vector*vector，可改變引腳為vector*float（第一節(jié)移動玩家到敵人的方向*100來保持玩家移動后離目標(biāo)的距離），另外AI Move To?節(jié)點(diǎn)的acceptance radius參數(shù)就是這個作用，沒必要自己再寫一遍

各種位置和旋轉(zhuǎn)，直接初始化的時(shí)候賦值arrow數(shù)組變量，再從這個數(shù)組里取就行，不需要來回設(shè)置再取值

動畫藍(lán)圖里傳傷害值也太秀了

死亡動畫直接在動畫藍(lán)圖內(nèi)的狀態(tài)機(jī)管理即可，根據(jù)動畫所綁定角色的是否死亡布爾值來決定是否從正常idle+run狀態(tài)轉(zhuǎn)到dead狀態(tài)

UE5的蒙太奇可以直接設(shè)置一個動作的自切割片段和片段間順序，一個動作也可以實(shí)現(xiàn)死亡后一直躺地上的，見Death_Montage

生成角色時(shí)存入數(shù)組并標(biāo)識編號，出手順序可以直接根據(jù)編號取到速度，再按高低把編號存入新的int數(shù)組作為出手順序

嚴(yán)格定義戰(zhàn)斗開始、回合開始、角色行動開始、角色行動結(jié)束等戰(zhàn)斗流程節(jié)點(diǎn)

繼承自怪物base和玩家base的玩家1類、玩家2類沒有意義，如果只有變量的變化，完全可以放入配置表內(nèi)，生成式讀表包括mesh等。一些配置可以放入繼承自object的空類內(nèi)，作為純數(shù)據(jù)對象，在gamemode初始化時(shí)實(shí)例化（單例）

UI動畫結(jié)束、蒙太奇動畫等不要用delay硬寫來控制時(shí)間，用綁定委托、事件通知等，UI動畫有bind藍(lán)圖節(jié)點(diǎn)，蒙太奇可在內(nèi)部設(shè)定通知，在播放蒙太奇的藍(lán)圖節(jié)點(diǎn)引腳會觸發(fā)對應(yīng)通知時(shí)間

Actor的widget組件，draw指的是繪制的大小，居中可以設(shè)置pivot，這個決定相對位置百分比

可以把血條的細(xì)節(jié)下的UI的space屬性設(shè)為screen，即可在UI層渲染而非場景層，位置可通過在mesh組件掛一個點(diǎn)，在該點(diǎn)掛血條，來控制血條位置，或是直接掛在mesh下

血條的信息更新可以通過事件驅(qū)動，見官方文檔https://docs.unrealengine.com/4.27/zh-CN/InteractiveExperiences/UMG/HowTo/EventBasedUI/

藍(lán)圖接口是規(guī)定函數(shù)名和輸入輸出的，具體實(shí)現(xiàn)由繼承接口的藍(lán)圖內(nèi)寫，即不同藍(lán)圖需要不同實(shí)現(xiàn)，但作用和輸入輸出相同時(shí)使用，例如動物餓了要吃食物補(bǔ)充能量，輸入為食物，輸出為能量，有的動物是前胃發(fā)酵來消化，有的是后腸發(fā)酵，UP主這樣用倒是實(shí)現(xiàn)了一種事件多播的效果，這塊沒具體研究藍(lán)圖部分，但是按理說可以通過bind自定義事件做到類似的效果，不知道是我理解錯了還是教程用錯了

攝像機(jī)位置，不用寫死位置，可以通過攝像機(jī)組件的transform屬性拿到相對位置Relative Location，因?yàn)檫@個屬性在transform的結(jié)構(gòu)體內(nèi)，所以直接輸入location找不到對應(yīng)節(jié)點(diǎn)，需要先取到transform

然后再根據(jù)取到的location做計(jì)算進(jìn)行移動來實(shí)現(xiàn)進(jìn)入的效果。結(jié)果發(fā)現(xiàn)這不就是個動畫嗎？UE一定有自己的功能可以K攝像機(jī)動畫

進(jìn)入戰(zhàn)斗的攝像機(jī)效果，應(yīng)該通過動畫來實(shí)現(xiàn)，查了下UE5內(nèi)置了ActorSequence，在攝像機(jī)所在actor內(nèi)添加該組件即可使用，使用原理同關(guān)卡序列（sequence）UE4需要下載該插件

選中敵人的變色，也不需要用定時(shí)器做，做一個0.01秒的定時(shí)器其實(shí)就相當(dāng)于一個tick（unity的update，每幀執(zhí)行），在角色材質(zhì)/組件寫一個tick判斷IsSelecting變量，為真則設(shè)置顯示，之后設(shè)置該bool值為假，然后在寫了選中邏輯的地方tick，選到角色時(shí)則給這個角色設(shè)置IsSelecting為真（幾個節(jié)點(diǎn)搞定的東西我調(diào)了一小時(shí)，被自己蠢哭）

視頻背景材質(zhì)那里，UE5報(bào)錯提示LoglmfMedia: Error: Tracks 000009D6AE400F10: Format is not supported in D3D12.

根據(jù)關(guān)鍵字百度后，在b站視頻BV1uq4y1A7M6評論區(qū)找到解決提示

UE默認(rèn)不支持DX12下的MP4格式解碼，裝個插件改下解碼器就行

打開工程后左上角，編輯->插件，找到electra player，勾上后重啟項(xiàng)目啟用插件，然后再打開media player，解碼器選electra player，就可以播放了

另外建議UMG做的各個UI最好按照功能模塊制作成分別的控件，梳理好層級，最后再一起放到整個戰(zhàn)斗內(nèi)的大UI下，直接在這里完成所有的UI操作，GameMode和戰(zhàn)斗場景等就可以只操控這一個UI對象即可

例如我把單個玩家信息板做成一個控件，在戰(zhàn)斗大UI下放一個垂直框，進(jìn)入戰(zhàn)斗時(shí)玩家數(shù)組傳給大UI，for?each來遍歷生成每個玩家的信息板，把各個玩家傳給單個信息版并調(diào)用信息板的初始化函數(shù)

其他模塊UI同理

大坑點(diǎn)，教程都是先生成玩家控制的所有角色的pawn，再在這個pawn內(nèi)處理該角色的各種數(shù)據(jù)，而pawn實(shí)際上是一個必須在場景內(nèi)存在實(shí)體的actor

這就導(dǎo)致這種寫法在處理角色的非場景信息時(shí)，還必須存在場景的實(shí)體，例如角色的等級、經(jīng)驗(yàn)等，所以教程里各種來回傳角色信息，，角色屬性數(shù)據(jù)和實(shí)體之間的界限非常模糊，寫的很亂

當(dāng)角色本身做復(fù)雜時(shí)，不得不給每一個相關(guān)的object，例如game?mode、game instance、map、game?controller、battle?scene，來回設(shè)置這些變量并傳遞信息

外加屬性寫的也非常臨時(shí)，如果再加上裝備和天賦加點(diǎn)等設(shè)定，根本沒法維護(hù)

例如做個玩家所有的角色的信息面板界面試試，在戰(zhàn)斗外打開能打開該面板的那種，很難寫

暫時(shí)想到的更好的做法是，先把角色視為一個數(shù)據(jù)集，單純繼承自Uobject，其內(nèi)包含角色需要的所有數(shù)據(jù)，例如一級戰(zhàn)斗屬性通過角色類型ID讀取角色表獲得，二級戰(zhàn)斗屬性通過函數(shù)庫在一級屬性變化時(shí)同步更新

其他包括移速、升級屬性等，都在該object初始化時(shí)，通過角色I(xiàn)D生成，可以設(shè)為init函數(shù)，生成對象時(shí)調(diào)，或者弄成構(gòu)造函數(shù)

然后進(jìn)入戰(zhàn)斗則根據(jù)該object屬性，生成對應(yīng)的pawn，而這個pawn實(shí)際上只是用來處理表現(xiàn)的，模型的移動攻擊啥的，不存在任何數(shù)據(jù)， 只負(fù)責(zé)在場景內(nèi)的實(shí)體表現(xiàn)

離開戰(zhàn)斗刪除pawn即可

角色信息等，都可以根據(jù)角色object來生成，存取存檔數(shù)據(jù)也存該object就行了，根本不需要每次進(jìn)入戰(zhàn)斗時(shí)根據(jù)角色類的類型再處理各種生成

坑點(diǎn)， possess之后立馬設(shè)置攝像機(jī)，會出現(xiàn)視野轉(zhuǎn)到目標(biāo)位置了，但沒綁定到攝像機(jī)、視角不跟著攝像機(jī)移動的情況，延遲一幀也不行，延遲兩幀再set?view?target又對了

原本是玩家操控pawn的，然后操控單位遇敵后，進(jìn)入戰(zhàn)斗場景，有個離開原場景攝像機(jī)動畫，和進(jìn)入新場景的攝像機(jī)動畫

由于進(jìn)入戰(zhàn)斗后的操作是交給ai控制pawn的，玩家負(fù)責(zé)下達(dá)指令

所以我在完成離開原場景后，進(jìn)入的瞬間possess這個玩家的角色給ai?controller，并設(shè)置視角到戰(zhàn)斗場景，隨后立即播場景內(nèi)的攝像機(jī)組件動畫

動畫是正常播的，但是視角顯示沒有變化

推測為possess執(zhí)行時(shí)，不光把pawn和controller進(jìn)行綁定，同時(shí)還會設(shè)置攝像機(jī)到視角，而其執(zhí)行順序和周期本身是不能保證在之后自己加的的set?view?target，這個節(jié)點(diǎn)的后面的什么時(shí)候執(zhí)行

完成possess的所有操作的花費(fèi)時(shí)間不一定是固定的，且藍(lán)圖內(nèi)沒有完成的回調(diào)節(jié)點(diǎn)，只有改變controller的事件綁定

該坑點(diǎn)還導(dǎo)致不好寫存檔系統(tǒng)，比如你敢寫個返回游戲開始界面嗎

因?yàn)閟avegame類，在藍(lán)圖內(nèi)沒有提供保存實(shí)例化對象的節(jié)點(diǎn)，只能保存基本類型和基本類型組成的結(jié)構(gòu)體類型的變量

所以必須把玩家信息的每一個變量都在savegame里寫一遍再存取一遍，非常麻煩

當(dāng)然并不清楚一個單純繼承自uobject的、用于存儲玩家數(shù)據(jù)信息的對象，savegame在藍(lán)圖內(nèi)能不能存取，這個沒有去試驗(yàn)

升級經(jīng)驗(yàn)效果那里，完全可以直接把升級前后的各種數(shù)據(jù)給UI，即當(dāng)前EXP、等級，獲得的EXP、EXP經(jīng)驗(yàn)表，UI自己做表現(xiàn)，不可能把這種動畫的timeline弄到角色類里然后設(shè)置一大堆變量的

UI對象的銷毀，據(jù)程序朋友說，為UE的GC自動進(jìn)行對無插槽的widget的銷毀回收

所以雖然remove?from?parent，執(zhí)行后依然能在調(diào)試對象中看到該widget，但是之后UE會自動進(jìn)行回收

第28節(jié)

控件接口那里，可以把所有能esc關(guān)閉的控件都實(shí)現(xiàn)該接口，然后在這些控件的構(gòu)造函數(shù)內(nèi)將自身存入player?controller的widget數(shù)組內(nèi)，回到場景則清空數(shù)組，每打開一級窗口，則add數(shù)組，按esc則移除數(shù)組內(nèi)最后一個控件并移出數(shù)組

由于event?anydamage?只能放在受到傷害的actor內(nèi)，為了模塊統(tǒng)一，考慮把傷害事件寫在rolebase內(nèi)，或者額外寫一個object用來處理這些東西，再掛給role

教程中的道具和技能做的實(shí)在是糟糕，根本沒法維護(hù)，我這邊做的時(shí)候，嚴(yán)格

特效等資源，直接復(fù)制粘貼的話，需要保證目錄的一致，教程資源均需粘貼到content根目錄下，導(dǎo)入成功后可再進(jìn)行遷移位置

如果發(fā)現(xiàn)有錯誤，最好先看看輸出日志，比如我這個特效因?yàn)檎迟N的目錄不對，進(jìn)去之后會播不出來，丟了材質(zhì)，因?yàn)椴馁|(zhì)的引用路徑不正確，也報(bào)錯了找不到文件

游戲的數(shù)據(jù)，最好按照層層關(guān)系進(jìn)行處理，例如所有的圖片ID引用，用專門的表做，在用到的地方填I(lǐng)D來這張表查

效果也歸類到一起，例如道具和技能，本質(zhì)上都是執(zhí)行一段戰(zhàn)斗內(nèi)的效果，這個效果的屬性可能包括目標(biāo)、效果、效果數(shù)值等

目標(biāo)為，作用目標(biāo)范圍（敵我）、作用數(shù)量、選擇類型（主動還是隨機(jī)）

效果為，效果類型、傷害、治療、復(fù)活、加buff等

數(shù)值為，參考基數(shù)（最大生命50%？力量*10？）、系數(shù)、來源等級系數(shù)（1級力量*10,2級力量*15）等

而且盡量有限的屬性都寫成枚舉值，這樣不容易出錯，后期也好修改（改ID、插ID啥的）

這里只是淺淺的舉個例子，游戲的實(shí)際開發(fā)的數(shù)據(jù)復(fù)雜量要大得多，而這一部分主要為數(shù)值策劃的工作（配表工具人就是我了）

道具的使用特效，簡單點(diǎn)也可以直接放表里，用的時(shí)候再取，復(fù)雜點(diǎn)可以專門把經(jīng)常需要變的特效參數(shù)，如持續(xù)時(shí)間、變色等，提到特效表再從道具表讀

數(shù)據(jù)相關(guān)根據(jù)自己需求來即可

很多數(shù)據(jù)實(shí)際上在整個游戲過程中也只存在一份，且不隨關(guān)卡地圖的變更而銷毀，完全可以把這些數(shù)據(jù)放到GameInstance里，游戲?qū)嵗?/span>

道具這塊做好UMG的控件分層，基于自己的習(xí)慣，比如道具，在背包、戰(zhàn)斗內(nèi)、商店，這幾個應(yīng)用場景內(nèi)的界面樣式可能有不同，但又有很多復(fù)用的邏輯

可以把邏輯相同的部分放到一個控件內(nèi)，再基于這個控件做針對需求的三份控件，也可以都做在一個控件里設(shè)變量進(jìn)行不同的init操作

玩家的輸入，默認(rèn)只有player?controller會接收，可以在actor的屬性面板內(nèi)打開選項(xiàng)來讓該actor接收用戶輸入——auto receive inout

做到后面真的是沒耐心繼續(xù)做了，這份筆記也寫不下去了，記不得自己和教程里哪些點(diǎn)不一樣，優(yōu)化了哪些，哪些做的不如教程

總有個思想就是，覺得這個項(xiàng)目只是自己拿來練習(xí)用的項(xiàng)目，而做到后面，教程也沒有教出什么新東西，用到的知識點(diǎn)幾乎在前面都用過了

所以你教程看完的話，會發(fā)現(xiàn)UP主后面也做的很水，教程完全是草草了事。一開始我還覺得很不爽，結(jié)果自己也是這個心態(tài)

而且既然是學(xué)習(xí)用，學(xué)到了這項(xiàng)目也就廢了，做出來的完全沒有可玩性和可維護(hù)性，也不好擴(kuò)展，不如下個項(xiàng)目見，于是更不想繼續(xù)做了

三、總結(jié)——————————————————————————————————————

花費(fèi)時(shí)間較長的部分

1、整理美術(shù)資源——這部分因?yàn)橛媒坛痰馁Y源，實(shí)際上是節(jié)約了大量的時(shí)間的

2、UI拼接——這塊重復(fù)勞動感很強(qiáng)，總感覺在做體力活，花的時(shí)間也長

3、同一個引用在多處重復(fù)設(shè)置變量——他們都應(yīng)當(dāng)指向同一份數(shù)據(jù)，而如果不是引用類型的話，實(shí)際上每個對象內(nèi)都是分別的副本，需要來回進(jìn)行數(shù)據(jù)的傳遞進(jìn)行更新，很容易出錯還花時(shí)間

4、debug——都是些經(jīng)常犯的小錯誤居多，最好注意下哪些地方經(jīng)常犯錯，有意識的去多注意這些地方

個人經(jīng)常犯的小錯誤

1、for循環(huán)后把只執(zhí)行一次的東西放到了循環(huán)體內(nèi)

2、數(shù)據(jù)用完后、重置狀態(tài)時(shí)，沒有清除臟數(shù)據(jù)，以防萬一可以用完后clear一下，初始化時(shí)clear一下，養(yǎng)成習(xí)慣，費(fèi)性能的話大不了最后再優(yōu)化

3、index是從0開始的，length是最后的index+1

4、線連的太長，以至于超出預(yù)想的執(zhí)行效果，藍(lán)圖執(zhí)行該節(jié)點(diǎn)時(shí)，對象屬性均為該藍(lán)圖內(nèi)的引用，比如我在節(jié)點(diǎn)1設(shè)置了a的值，之后過了n個節(jié)點(diǎn)直接在節(jié)點(diǎn)5處取節(jié)點(diǎn)1的a值引腳，而中間又在節(jié)點(diǎn)3對a進(jìn)行了++之類的操作，此時(shí)在節(jié)點(diǎn)5的a值是++后的值

其他經(jīng)驗(yàn)分享

1、剛學(xué)的時(shí)候，不要想的太遙遠(yuǎn)，容易炸，盡可能先找自己能理解的教程去照著做，實(shí)在理解不了就硬著頭皮多看幾遍

2、第一個項(xiàng)目會因?yàn)樽约赫J(rèn)知和熟悉程度不夠，而有大量的渣寫法，所以確實(shí)是最好當(dāng)練手，以學(xué)習(xí)為目的去做

但不要因此就做個半成品，起碼流程得完全做通，才能保證自己真的掌握了，下次做的時(shí)候才能寫的更好

3、避免重復(fù)造輪子，當(dāng)你想實(shí)現(xiàn)一個東西的時(shí)候，最好默認(rèn)UE有這個功能，如果實(shí)在找不到再考慮自己實(shí)現(xiàn)

例如場景組件的動畫，在actor?sequence插件內(nèi)可以直接設(shè)置播放時(shí)的玩家禁用移動輸入等操作

4、盡量用數(shù)據(jù)驅(qū)動，數(shù)據(jù)層和邏輯層和表現(xiàn)層嚴(yán)格分離，界面表現(xiàn)用拿到的數(shù)據(jù)僅做展示，邏輯控制這些數(shù)據(jù)的關(guān)系，區(qū)分好輸入數(shù)據(jù)

例如玩家的所有信息都可以先弄成一個數(shù)據(jù)集合型的object，然后再在進(jìn)入戰(zhàn)斗、進(jìn)入場景時(shí)，用這些數(shù)據(jù)生成場景內(nèi)的actor，這個actor只負(fù)責(zé)移動攻擊、模型和動畫，以及接受這些事件的通知

5、數(shù)據(jù)表可以通過excel進(jìn)行大批量配置，再導(dǎo)出成csv生成UE內(nèi)的數(shù)據(jù)表

這塊教程網(wǎng)上也很多，在UE內(nèi)編輯數(shù)據(jù)表很不方便的，例如1-100級的升級所需經(jīng)驗(yàn)，總不能手敲100次吧？

————————————

6、如果你想做獨(dú)立游戲，動手前先解決素材問題，再解決可玩性驗(yàn)證，再初步完成數(shù)值設(shè)計(jì)，最后再動手做

因?yàn)榍皫撞蕉紩绊憣?shí)際的程序開發(fā)，最好是先想清楚再做，不然做著做著就只能成練手作品了

7、盡量獨(dú)立制作，不要想著靠別人幫忙做，大多數(shù)人三分鐘熱度，而別人退出合作，即會打擊你的熱情，也很可能導(dǎo)致項(xiàng)目荒廢（意見不和、技術(shù)領(lǐng)域不同等）找新的人又得重新磨合

當(dāng)然，找人幫忙解決一些小問題是可行的，越小越細(xì)的事情越有可行性

8、多總結(jié)，總結(jié)雖然花時(shí)間，但總結(jié)的過程可以幫助理清思路

DONE——我完成的部分

創(chuàng)建人物、人物移動控制

進(jìn)入離開戰(zhàn)斗，回合開始結(jié)束、人物行動開始結(jié)束

移動、攻擊、被攻擊、死亡動畫的控制

人物戰(zhàn)斗信息UI

戰(zhàn)斗菜單

出手順序排序

血條UI、傷害跳字

攝像機(jī)過場動畫、搖晃效果

選中敵人時(shí)特效

戰(zhàn)斗勝利結(jié)算UI

戰(zhàn)斗失敗

游戲開始界面

存檔讀檔

經(jīng)驗(yàn)系統(tǒng)和升級表現(xiàn)

角色詳情面板

左上角掛操作介紹

道具和貨幣系統(tǒng)

背包

商店

道具效果

設(shè)置

NOT DONE——沒做的部分

技能——放棄

復(fù)活效果——放棄

設(shè)置聲音、攻擊時(shí)移動到場景中心——放棄，無意義

幾個沒做的點(diǎn)，我覺得教程中的做法也很臨時(shí)，基本和道具類似，沒什么參考價(jià)值，就沒去花時(shí)間做了，感覺照著做只是純體力活

還可以優(yōu)化的點(diǎn)：

比如地圖內(nèi)放置的怪物碰撞點(diǎn)，可以通過數(shù)據(jù)表生成，定義每一行為一個怪物數(shù)據(jù)，配置包括?1id?2碰撞點(diǎn)location?3怪物ID數(shù)組?

然后可以在map里遍歷該數(shù)據(jù)表生成對應(yīng)的actor在場景內(nèi)

四、編輯器和項(xiàng)目相關(guān)——————————————————————————————————————

UE5和UE4相比變化并不大，主要區(qū)別在一些入門的人用不到的技術(shù)美術(shù)、渲染相關(guān)的地方，基本上UE4的教程都是可以直接用UE5復(fù)刻的

我一開始用的是UE5.0.1源碼編譯版本，因?yàn)橛昧薞S2022，最新的編譯器有些問題，改了UE5默認(rèn)使用的編譯器版本配置，版本為14.31.31103

https://forums.unrealengine.com/t/unhandled-exception-when-building-blank-project-version-1-2-is-not-supported-version/510668/7

需要安裝VS才能進(jìn)行打包

UE?最新版 5.0.2，已經(jīng)解決了和VS2022的編譯兼容問題?

項(xiàng)目設(shè)置相關(guān)：

這個地圖資源挺吃資源的，運(yùn)行的時(shí)候幀率跑不滿，項(xiàng)目設(shè)置使用固定幀率的話，如果GPU性能不夠跑的，幀率達(dá)不到設(shè)定的固定幀率，會對一些tick下的計(jì)算早成一定影響

打包出來我的1080+4K顯示器，只能跑到十幾幀，而GPU并沒有吃滿，好像GPU擺爛沒工作一樣

調(diào)了半天之后，在項(xiàng)目設(shè)置里開了前向渲染，意外的解決了，但我的電腦跑滿GPU也只有60幀上下

Shader學(xué)習(xí) （20）延遲渲染和前向渲染 - 九貓的文章 - 知乎 https://zhuanlan.zhihu.com/p/386420933

另外UE5不知道打包的哪些設(shè)置不對，初始的 空場景，只有一張圖和幾個按鈕，我的華碩猛禽1080跑滿100%，在4K分辨率下只有100幀，調(diào)成720P則有600幀，1080P300幀，2K為200幀

顯然一張圖就把4K的顯卡吃滿了是不太能接受的

另外分辨率、窗口模式之類的設(shè)置，打開發(fā)包出來，是保存在——項(xiàng)目導(dǎo)出文件夾\WindowsNoEditor\項(xiàng)目名稱\Saved\Config\WindowsNoEditor\GameUserSettings.ini

開發(fā)包默認(rèn)無該文件，可以參考 https://answers.unrealengine.com/questions/206504/how-to-default-fullscreen-in-shipping-package.html

項(xiàng)目設(shè)置中有GameUserSettings類，可以創(chuàng)建藍(lán)圖類，在項(xiàng)目設(shè)置中選用該類，來處理這些設(shè)置的保存

教程提供的資源，本身占用空間就達(dá)到了2.9G之大，開發(fā)包，內(nèi)容全進(jìn)包，打出來的PC開發(fā)包大小為3.08G，發(fā)行包1.37G，感覺算可以接受的了

主要是地圖和玩家模型占空間大，刪掉所有未使用資產(chǎn)將近700個后，資產(chǎn)占用也有2.6G，打出來發(fā)行包為1.26G

另外開啟?排除編輯器內(nèi)容 打出來的發(fā)行包只減小了不到1M

烘焙所有項(xiàng)、只烘焙地圖 ，打出來的包小了100M

而在刪除掉所有未使用的資產(chǎn)之后，項(xiàng)目壓縮包小了400M

但打出來的包，和只烘焙地圖，一模一樣大，一個字節(jié)都不差——1.26 GB (1,361,464,156 字節(jié))

這一塊整得我很迷，怎么可能出現(xiàn)一個字節(jié)都不差的情況呢？

推測可能是發(fā)行包本身打出來的時(shí)候，未使用資產(chǎn)也是不進(jìn)包的，而烘焙是直接用工程目錄下的cook進(jìn)行二次壓縮進(jìn)包的，這部分烘焙沒有排除未使用資產(chǎn)

官方文檔有這一段話

——嘗試確定項(xiàng)目的最終大小時(shí)須注意，項(xiàng)目的開發(fā)版本將略大于發(fā)布版本。

——在Medieval Match游戲范例中，開發(fā)版本與發(fā)布版本之間的容量差異約為14%。但各個項(xiàng)目的要求有所相同，因此兩個不同項(xiàng)目版本之間的容量差異可能大于14%，也可能小于此值。

而我這個開發(fā)和發(fā)行包差異這么大，不是很理解，未引用的資產(chǎn)也只占到400M

有關(guān)包體減小部分，建議直接看官方文檔，基本上很全

https://docs.unrealengine.com/4.27/en-US/SharingAndReleasing/Mobile/Android/ReducingAPKSize/

這個講的也不錯https://chowdera.com/2022/01/202201240934569241.html

五、工程源碼分享————————————

鏈接：https://pan.baidu.com/s/16P949_e4xG_9Lnq_1RJ2Pw

提取碼：ws1s

一個是項(xiàng)目壓縮包，一個是打包出來的開發(fā)版本包（development），一個是發(fā)行版本包（shipping），一個是刪去未使用資產(chǎn)的發(fā)行包

我這份是UE 5.0.2源碼引擎，但項(xiàng)目是純藍(lán)圖項(xiàng)目

然后我用Epic Game Launch?另外下了一個UE5.0.2?打包不需要編譯shipping版UE5，非?？?/span>

而源碼版本，只要項(xiàng)目目錄變更，就會重新編譯一些打包工具鏈 而且非常慢，我的9900K超頻4.4G，需要編譯將近1小時(shí)

兩個版本打出來的發(fā)行包包體大小相差不到0.2%，而引擎的占用空間，源碼版本大約270G，二進(jìn)制版包括c++調(diào)試，也只需要100G以內(nèi)

可以說除非你需要改源碼，不然完全沒有用源碼編譯版本的必要，強(qiáng)烈建議去launch下載二進(jìn)制版

制作的時(shí)候，實(shí)際上只有前兩節(jié)參考教程的比較多，后面就完全是看個開頭看看教程準(zhǔn)備做啥，然后直接自己豐衣足食了，所以本項(xiàng)目和教程的實(shí)現(xiàn)出入較大

且未經(jīng)優(yōu)化，做到后面做煩了，大量的臨時(shí)寫法

發(fā)行包打出來才發(fā)現(xiàn)分辨率設(shè)置沒生效，因?yàn)槠洳话脩粼O(shè)置配置文件，類似的坑踩了很多

我這個項(xiàng)目總共花費(fèi)了8天時(shí)間制作，其中打包、MP4解碼、幀率低、研究UE5項(xiàng)目設(shè)置、攝像機(jī)+UI動畫，這幾個部分起碼花了2天

外加開始不熟悉各種節(jié)點(diǎn)和藍(lán)圖的數(shù)據(jù)傳遞，前幾天做的不僅慢，弄出的bug也多

六、雜談————————————

入行兩年半了，入行就是大廠數(shù)值，雖然項(xiàng)目沒成，但相比很多人我已經(jīng)很幸運(yùn)了

外加現(xiàn)在明顯感覺進(jìn)步變慢了，漸漸地日常工作學(xué)不到東西了，索性直接回家擺大爛，打打游戲找找初心

這次開始學(xué)UE，主要是自己除了工作經(jīng)驗(yàn)之外，沒有任何拿得出手的東西證明自己的價(jià)值，找工作非常頭疼

外加多學(xué)點(diǎn)東西總是有好處的，既然數(shù)值層面很難有長進(jìn)，那就擴(kuò)寬知識面，實(shí)在找不到理想的工作就自己在家憋獨(dú)立游戲

之前第二個項(xiàng)目3個多月就解散了，當(dāng)時(shí)用的就是UE4+c++，因?yàn)轫?xiàng)目干的不舒服還自己偷偷學(xué)了下怎么實(shí)現(xiàn)的，然后自己動手做了項(xiàng)目的一個劇情部分的答題小游戲

而第一個項(xiàng)目干了2年，用的是Unity+C#+LUA，服務(wù)器是c++。大量的技能配置很難搞，最后是程序?qū)崿F(xiàn)接口，策劃用lua寫技能腳本進(jìn)行二次拼接

畢設(shè)用的是unity做的游戲，這次又自己做了UE5回合游戲DEMO

總的體驗(yàn)下來，重要的還是人，引擎這東西很多思路和用法都很接近，對策劃來說要想做好游戲，接觸的肯定得多，也得會用

當(dāng)然你入行后可能會發(fā)現(xiàn)大量的人不會用引擎，因?yàn)樗麄兌荚诓邉澅韭毠ぷ魃媳怀绦蛎?、制作人或者老板整的很難頂，外加沒有編程基礎(chǔ)也很難理解引擎

但是你會引擎，你不容易被程序忽悠，好把握其他人的工作量，也能節(jié)約和程序美術(shù)的溝通成本，在做功能的邏輯梳理和數(shù)據(jù)表結(jié)構(gòu)制定時(shí)，也能更優(yōu)雅

另外想靠這個教程入行程序，估計(jì)是不太靠譜的，藍(lán)圖程序員作用太小了，能實(shí)現(xiàn)的東西有限，好一點(diǎn)的游戲公司都不太會考慮你的