去當unity游戲開發實習生應該具備哪些能力和知識？

0x01。項目前期規劃中的問題

這里我們指的不是策劃的需求，也不是游戲性的計劃，而是作為一個Unity項目，我們需要在一開始就定義和制定好規范和標準。作為一個Unity項目或者軟件項目，這部分非常重要，因為項目的前期規劃隨著項目的開發時間越長越難修改。

不清楚支持的最低型號。

作為Unity項目，首先要明確需要支持的最低設備標準。項目團隊應該有這樣的設備供開發和QA團隊使用。

否則，項目的優化將是不可能的。

資源標準不明確

開發過Unity項目的同學可能都有過類似的經歷，就是開發過程中的資源標準不明確。這通常是由于在早期項目規劃中沒有注意資源標準造成的。

所以在項目前期，最好明確模型中頂點數量、紋理資源大小格式等資源標準。

您還應該對每個幀開銷中花費在腳本和渲染上的時間有一個目標和預期。

沒有合理的資產裝配線

這里的意思是資源要按照一定的流程和標準從art導入到Unity項目中。

許多項目以性能問題告終，因為沒有合理的資產管道。因此，項目中的資源標準無法管理，許多冗余或不兼容的資源被內置到最終的安裝包中。

所以作為項目團隊，每個人都必須指定一個自動化的資產流水線。為資產的規格和標準制定明確的規格，并在自動化腳本中進行設置。

比如，texture是否開啟讀/寫？紋理的壓縮格式？尺寸？非人類模型在導入時會關閉裝備嗎？動畫模型是否啟用了優化游戲對象選項？等一下。

沒有合理的建設和QA流程。

也有很多項目建設不順利，建成的版本很難管理。規劃或者QA往往是為某個功能的開發找一個包。

所以項目組可以思考以下問題:

有專門的打捆機嗎？

一個新特性是如何發布到最終發布版本的？

是否有自動化可持續集成設施(CI)？

QA應該如何反饋bug，如何有效管理？

正式項目直接在演示原型上開發。

這也是常見的情況。在一些項目團隊中，少數人會在前期開發一些試玩游戲。演示通過后，他們將開始開發正式的項目。

這時候就會出現一個問題，就是在Demo的基礎上直接開發正式項目。因為很多Demo只是為了演示游戲性，所以代碼中有很多具體的Hack來盡快實現需求。

如果正式項目以此為基礎，到后期維護會比較麻煩。

除了上面提到的問題，還有一些其他需要注意的內容，比如制定統一的編碼標準，確定光照模式(RealTime？混合？烤的？)等等。

0x02。項目開發過程中的問題

經過項目的前期策劃階段，到了項目的開發階段，項目團隊可能會犯哪些錯誤？一些不好的做法可能會減緩項目的開發進度，增加項目團隊成員的焦慮。

不重視版本管理

許多團隊不不重視版本管理，或者他們對git等版本管理不熟練。

當然，有很多關于git最佳實踐的信息。建議項目組進行內部培訓和普及，讓每個人(編程美工策劃等)都能操作符合規范的版本管理。

對于Unity項目，序列化的格式建議設置為文本序列化。

設置提交掛鉤:

靜態數據存儲在Json或XML文件中。

很多團隊喜歡或者習慣用Json文件或者XML文件來保存一些靜態數據，在游戲運行的時候加載。但是使用Json或者XML文件保存數據會有以下問題:

裝載速度慢。解析時會有內存開銷。所以最好使用二進制來保存數據，Unity內部也提供了scriptableObject來幫助保存數據。

項目包含未使用的資源、插件或冗余庫。

這也是很多團隊的通病。一些廢棄的資源沒有及時處理，留在項目中甚至內置到最終發布版本中，造成了不必要的開支。

另一個問題是冗余或具有相同功能的多個庫。比如項目中使用的很多插件都是使用Json解析庫，會造成冗余。

僅在編輯器中測試性能。

這是一個非常不好的發展習慣。因為編輯器的性能成本是在編輯器中測試的，而不是在真正的目標平臺上。因此，在創建概要文件時，必須在目標平臺的設備上完成。否則只能得到誤導性的數據。例如，在Editor中，APIGetCompon

unity3d對美術資源的加密方式有哪些？

C#代碼混亂。深入來說，你可以嘗試修改mono加載dll的。官方有一個開源的monogit。

樓上說assetbundle是加密的。如果在這里添加資源文件名，也可以使用md5哈希。

如果使用其他腳本來加密參考腳本語言本身，lua可以使用luajit，