yekdniw的UE4學習筆記

主旨 筆者過去被指派多次改善CPU效能的項目，累積了一些心得可以分享 因此本系列將以UE4為範例，預計提供一些觀念， 標準流程 ， 技巧給大家參考 讓大家都可以更快的入門，避免走一些曾經走過的冤枉路。 本篇不會提到太多UE4相關的技巧，會以效能分析與改善的觀念為主。 隨時審視自己的行為 在作效能改善的過程中， 一定要隨時知道自己在改善什麼， 做了這個項目在最佳情況可以改善多少。 不要一股腦兒的投入某個細項， 結果其實改善微乎其微。 CPU bound? GPU bound? 本系列要提的是CPU效能的改進，不會提GPU 改進的相關部份。 不過先了解自己的遊戲到底是CPU bound還是GPU bound 絕對是首先最重要的事情。 如何知道遊戲是不是CPU Bound? 在UE4要知道這件事很容易，將你的遊戲放到目標平台上 使用console command stat unit 並觀察CPU與GPU佔用的時間 CPU過高就是CPU bound，GPU過高就是GPU bound。 都很高的話，就挑嚴重的先處理吧。 謹記80/20原則 80/20原則是個概念，可以套用在很多的事情上(可以無限上綱的意思) 在這邊提的意思是，大多數程式執行的總時間只在執行少部分的程式碼。 所以我們在做效能改善的時候，只處理少部分的程式碼就可以改善最多的效能。 不要用猜的來改善效能 改善效能的流程請 務必 從量測效能開始， 偷懶跳過這個步驟，用"直覺"來改善效能的話 下場就是很容易成為80/20原則的反向教材， 花了80%的時間只改善效能的20%。 這是經驗談，就算是有經驗的老手也會中招。 畢竟一個遊戲系統很大，每個人都會知道自己經手的系統哪裡效能不佳。 如果直接分配一段時間(例如一週)，讓每個人改善自己的系統效能。 這種作法是最浪費，最沒有效率的，因為效率瓶頸可能根本就不在某人上。 又例如說某個系統有一段寫法很暴力或是用了很多層迴圈， 花了大把時間去改善，結果這段程式碼只執行一次，也不會影響畫面卡頓。 那麼這個時間應該要省下來去作別的項目。 藉由量測效能估算極限 先從量測效能開始的另一個好處是可以很快知道極限在哪裏。 拿到效能數據，有經

[前言]  這篇文章主要是關於UE4 GameplayAbilitySystem中GameplayEffect的細項介紹 在專案內我們大量使用GameplayEffect的各種用法來達成不同的Gameplay 而GameplayEffect有一大堆的參數, 讓我們在使用上遇到不少問題 寫這篇文章就是希望其他開發者不用走一次我們走過的冤枉路 [簡介]  先列出GameplayEffect可設定參數中的分類, 每個分類內在本文會有更詳細的介紹 GameplayEffect Tags - Tag的新增與移除 Modifiers - 修改AttributeSet內的Value Duration Policy - 不同的時間執行規則, 很多功能只有特定duration policy才會生效 Conditional Gameplay Effects - 額外apply的effect, 可以設定apply條件 Application - 這個效果能否套用的條件 Period - 週期執行 Display - 演出 Expiration - 結束後追加效果 Immunity - 這個效果套用時, 對其他效果免疫的設定 Stack - 同樣Effect的堆疊處理 Overflow - 堆疊溢出時追加效果 Grant Ability - "Give" Ability, 不會自動Activate GameplayCue GameplayCue Tag - GameplayEffect跟GameplayCue是透過GameplayTag關聯 [本文] Tags GameplayEffectAssetTag 這個effect的tag, 在做一些remove, immunity之類的檢查欄位 GrantedTag 當Effect apply後, 會同時賦予角色的tags OngoingTag Requirements 這個tag的玩法很像是遙控炸彈的概念, 先把炸彈的effect裝在某個對象上 滿足OngoingTag的時候effect就會active( tag有