如果用unity製作乙個高效能的類工廠遊戲, 我應該選擇用C rust替換底層的運算來加速嗎

1樓：

確實有一些效能敏感的遊戲會用C++/Rust編寫核心庫，然後以dll的方式導進Unity用，不過說實話這種方案操作起來過於麻煩，實際可操作性不強。

而且如其他回答所說，C#已經很快了，C++對於C#的效能提公升遠不足以解決架構和演算法帶來的效能瓶頸。

題主主要擔心的應該還是工廠遊戲裡大量單位的行為和狀態更新吧，DOTS確實是很好的選擇，不過它還沒有定型，寫起來可能還是挺麻煩。在傳統的架構下，通過減少骨骼動畫、優化Update以及做好各方面的剔除工作（LOD和不可見物體不執行邏輯這樣），就可以獲得很大的效能提公升了。

2樓：

換個語言基本沒什麼卵用，這種效能差距是體現在數量級上的。

要從架構上解決問題

一種選擇是並行化，對於大規模相似簡單GameObject的更新改成放在GPU上做，充分利用ComputeShader的平行計算能力，戴森球計畫選擇的就是這個方向。

如果更新邏輯比較複雜，非要在CPU上做，可以考慮ECS，它可以充分利用區域性性原理，做成批處理，然後批處理就有向量化的可能，CPU都有向量指令集，應該可以幫不少忙。

3樓：ggffss

語言帶來的這點收益遠遠不如ECS帶來的收益。並且il2cpp就已經是C++了，所以你這是純屬瞎折騰。

不要過早優化

當然你要說，什麼物理引擎什麼的，可以用C++/rust做成單獨的模組。

4樓：林玉偉

unity現在不是有brust嗎，先推薦DOTS裡的jobs和brust，可以用於生產了

如果是ecs的話可以考慮下面這個框架，有多語言版本的，Entitas:

sschmid/Entitas-CSharp

或者像戴森球那樣在computeshader上做文章，c#現在很快的，按題主自己的思路可能是想未來移植到ue吧，不過demo都沒得，我覺得沒必要

5樓：

這一類遊戲的效能優化的主要思路是，充分利用場景當中可變物件的相似性。

對於這類遊戲，在遊戲的任何乙個幀迴圈當中，需要更新狀態的物件的數量都可能遠遠大於狀態本身和更新方法的種類。

也就是類似軍隊當中「整齊劃一」的要求，要努力消滅單個物件的個性，強調群體的共性，將方法作用於群體物件上，而不是遍歷各個物件呼叫其方法。

在GPU端也是類似，要充分採用instance和indirect draw，將同乙個型別的物件的繪製過程合併在乙個或者數個DrawCall當中，將不同個體的單獨資料以某種資料結構組織在buffer當中，在一次DrawCall當中讀取這些引數繪製大量物件。

動畫系統也是類似，相同的物件參照同乙份動畫序列資料，各自保留乙個指標，指向當前所處的幀。也就是動畫資料只有乙份，動畫更新邏輯也只跑一遍，但是更新N個指標。

物理系統也要盡量選擇一些群體性的判定演算法，避免對於個體的迭代。

最為重要的其實是這種設計模式，而不是具體的實現語言。關鍵是需要摒棄商業引擎原本以單個object/actor為中心的AoS架構，改為以行為和過程為中心，單個過程處理所有適用物件的某個部分的，SoA的架構。將個體盡量表達為一組表明其狀態的資料，而不是包括方法的「物件」。

6樓：夜葵

unity的所有關於物件的操作都是在乙個主線程操作的，你要怎麼實現多執行緒的管理GameObject呢？除非你去修改Unity引擎底層。