Unity3D怎么添加人物？簡單文件導(dǎo)入人物控制器的模型預(yù)制體，在菜單欄能找到并直接點擊Assets，接著選擇importpackage-gtCharacters；隨后在project面板下再把fir

Unity3D怎么添加人物？

簡單文件導(dǎo)入人物控制器的模型預(yù)制體，在菜單欄能找到并直接點擊Assets，接著選擇importpackage-gtCharacters；隨后在project面板下再把firstpersonercontroler拖到場景中即可解決。

unity源代碼怎么導(dǎo)入？

引擎的源碼是不對外開放的,不能見到被裸芯片的類的源碼,詳細(xì)方法——在代碼編輯器中點擊某個類,接著按F12

在maya里導(dǎo)出fbx的文件放進(jìn)unity3D里，為什么貼圖都不見了，都只是一個白模而已？

fbx文件本身不帶貼圖，請通過看看方法來，是需要文件導(dǎo)出fbx文件，把所有貼圖放進(jìn)unityassets目錄下的一個子目錄中，然后將fbx拖到這個文件夾中，結(jié)束后即可看見了手動不兼容了貼圖，至于所有骨骼、部件、材質(zhì)、貼圖，一概不允許使用中文

去當(dāng)unity游戲開發(fā)實習(xí)生應(yīng)該具備哪些能力和知識？

0x01.項目前期規(guī)劃時的問題

這里指的也不是策劃推廣的需求或是游戲玩法的計劃，反而另外一個Unity項目我們要在一開始比較明確并如何制定好的規(guī)范和標(biāo)準(zhǔn)。以及一個Unity項目或軟件項目，這部分是很有用的，只不過項目早期的規(guī)劃緊接著項目的開發(fā)時間越久，就越?jīng)]法可以修改。

對意見的最少機型不比較明確

另外一個Unity項目，我們首先要必須明確我們所必須支持什么的不超過設(shè)備標(biāo)準(zhǔn)。而且項目組要有這樣的設(shè)備，以供開發(fā)和QA團隊使用。

不然的話，對項目的優(yōu)化將無從查起談起過。

資源標(biāo)準(zhǔn)不比較明確

變更土地性質(zhì)過Unity項目的同學(xué)可能會都有吧過類似于的經(jīng)歷，即開發(fā)完畢過程中的資源標(biāo)準(zhǔn)不比較明確。這常常覺得都是早期在項目規(guī)劃時沒有重視資源標(biāo)準(zhǔn)導(dǎo)致的。

因為在項目的早期階段，最好能夠內(nèi)容明確資源標(biāo)準(zhǔn)比如模型的vertex數(shù)量、紋理資源的尺寸格式等等。

也要對每幀開銷中，腳本和渲染所花費的時間有一個目標(biāo)和預(yù)期。

沒有比較合理的Asset流水線

這里指的是資源應(yīng)該要聽從一定會的流程和標(biāo)準(zhǔn)從美術(shù)那里導(dǎo)入到Unity項目中。

很多項目結(jié)果會出現(xiàn)性能問題，是因此沒有個合理的Asset流水線。使造成項目內(nèi)的資源標(biāo)準(zhǔn)根本無法管理，很多冗余數(shù)據(jù)或不要什么目標(biāo)設(shè)備水平的資源構(gòu)建進(jìn)了到最后的安裝包里。

所以，以及項目組，大家一定得更改一套及其自動化的Asset流水線。為Asset的規(guī)格和標(biāo)準(zhǔn)制定內(nèi)容明確的規(guī)范，在自動化腳本中參與系統(tǒng)設(shè)置。

的或texture是否需要自動打開read/write?texture的壓解格式？尺寸？非人形的model在導(dǎo)入時是否是關(guān)掉了rigs？動畫模型有無開啟了OptimizeGameObject選項？等等。

沒有合不合理的構(gòu)建和QA流程

也有很多項目的構(gòu)建不是他沉思一番順意，構(gòu)建的版本也沒法管理的管理。策劃或則QA常常是找負(fù)責(zé)某個功能的開發(fā)戰(zhàn)火紛紛的打一個包出來。

因為項目組這個可以琢磨看看下面的幾個問題：

是否有拿來的打包機？

兩個新的功能是該如何查找到到了最后的發(fā)布版本的？

是否是有機電一體化的可ci/cd設(shè)施（CI）？

QA要如何反饋Bug，Bug怎么有效的管理？

臨時項目就在Demo原型上參與開發(fā)

這個也是一個較常見的情況，有些項目組早期會有少數(shù)幾個人變更土地性質(zhì)一些玩法演示Demo，Demo被同意之后結(jié)束變更土地性質(zhì)正式地的項目。

此時會有一個問題，即在Demo的基礎(chǔ)上直接開發(fā)完畢宣布項目。因此很多Demo僅僅就是為了演示玩法，所以才代碼中有很多是為以最快的速度實現(xiàn)方法需求的特定Hack。

如果沒有正式項目若要為基礎(chǔ)，到后續(xù)維護會也很請。

以外上面所提及的問題之外，另外一些別的不需要重視的內(nèi)容，.例如制定統(tǒng)一的編碼規(guī)范、可以確定區(qū)分的光照模式（RealTime？Mixed？Baked？）等等。

0x02.項目開發(fā)過程中的問題

經(jīng)過了項目早期的規(guī)劃階段，來到項目的開發(fā)階段時項目組有可能會犯哪些出現(xiàn)了錯誤呢？一些不好的實踐有可能會拖慢項目的開發(fā)進(jìn)度包括讓項目組成員的焦躁感向上升。

不如此重視版本管理

很多團隊對版本管理不重視，或者團隊內(nèi)部對版本管理.例如git的操作不熟練。

其實，關(guān)于git的最佳實踐的資料有很多，我建議你項目組在內(nèi)部接受培訓(xùn)班和廣泛普及，讓大家（程序美術(shù)策劃設(shè)計etc）對版本管理的操作符合規(guī)范。

是對Unity項目，serialization的格式見意設(shè)置里為textserialization。

系統(tǒng)設(shè)置commithook：

支持靜態(tài)數(shù)據(jù)存儲在Json或XML文件保存到

不少團隊很喜歡或習(xí)慣于使用Json文件或XML文件來保存一些靜態(tài)數(shù)據(jù)，在游戲啟動的時候程序加載在用。但是可以使用Json或XML文件需要保存數(shù)據(jù)會有以下的問題：

加載速度慢。Parse的時候會才能產(chǎn)生內(nèi)存開銷。所以才數(shù)據(jù)好是不使用二進(jìn)制來保存，在Unity內(nèi)部也能提供了ScriptableObject來幫助能保存數(shù)據(jù)。

項目中包涵了還沒有會用到的資源、插件或系統(tǒng)冗余的庫

這又是很多團隊中最常見的一個問題。一些銹跡斑駁的資源沒有及時處理，始終送回項目中哪怕被構(gòu)建體系進(jìn)入了到最后的發(fā)布版本，從而會造成不必要的開銷。

另一個問題是冗余或多份同樣功能的庫，比如項目中使用的插件中有多款插件都建議使用到了Json解析庫，這樣的話都會導(dǎo)致冗余。

只在Editor中測試性能

這是一個很都不好的開發(fā)習(xí)慣。因為在Editor中測量的是Editor的性能開銷，而不是在能夠的目標(biāo)平臺上的性能開銷。所以我在做Profile的時候，必須得在目標(biāo)平臺的設(shè)備上通過。否則只有得到讓人誤會的數(shù)據(jù)，比如在Editor中，GetComponent這個API會再產(chǎn)生堆內(nèi)存的分配，但在真機上并不會產(chǎn)生堆內(nèi)存的開銷。