文章

顯示從 8月, 2021 起發佈的文章

【Unity編輯器拓展 】拓展編輯器菜單

圖片
在日常開發中我們會經常用到Unity的右鍵菜單,這些菜單都是支持自定義的,我們可以透過編寫自己的 Editor腳本 來向其中添加一些自己的選項。 Unity版本:2020.3.12f1 Project視圖右鍵菜單 Hierarchy視圖右鍵菜單 1. 通過Editor腳本拓展Project視圖右鍵菜單 準備工作: 在Project視圖中創建一個名爲 “Editor” 的文件夾作爲Editor腳本的存放點,還可創建一個名爲 “Scripts” 的文件夾並將“Editor”文件夾移入其中以方便整理。 創建腳本: 在Editor文件夾中創建一個腳本,名稱自定,然後打開。 移除類名後的MonoBehaviour繼承,命名空間引用加入using UnityEngine; 和using UnityEditor; 腳本準備工作 添加如下內容。 創建菜單項 其中的static void的名稱可自定爲其他名稱,[MenuItem]方法用於將這個 static void MenuTool1() 方法添加到右鍵菜單中,第一個參數寫入菜單項的路徑“Assets/Expand Tools/Tool1”,第二個參數( isValidateFunction )填入false如果不需要的話,第三個參數爲該菜單項在菜單中的優先級,數值越小越靠前。 菜單項示例 當我們點擊圖中的 "Tool1" 選項便會調用 static void MenuTool1()  方法 還可以使用相同方法拓展Create菜單 拓展Create菜單 效果預覽 2. 通過Editor腳本拓展Hierarchy視圖右鍵菜單 方法與Project視圖相同,將路徑中的“Assets”改爲“GameObject”即可 拓展Hierarchy視圖右鍵菜單 效果預覽 點擊後會在場景中創建一個球體 參考資料 【Unity官方 文檔 】MenuItem

使用OnGUI實時調試遊戲

圖片
在遊戲開發過程中需要對遊戲進行數值上的調試,可以使用Unity的OnGUI方法來將要調試的數值實時顯示在屏幕上。 不多說,上代碼,這裏以遊戲內實時顯示FPS爲例。 Unity版本:2020.3.12f1 示例代碼 效果示例圖:FPS顯示在左上角 參考資料 【Unity官方文檔】OnGUI 【Unity官方文檔】GUI 【Unity官方文檔】UnityEngine.IMGUIModule

C# 隱式轉換

圖片
有些時候我們需要將兩個不同的類相互進行轉換,就像Object類可以轉換爲Bool一樣(如圖1),不論是使用 if(Object) 還是 if(Object != null) 效果完全一致,這實際上是因爲Unity在Object類中已經爲我們定義了Object到Bool的隱式轉換(Implicit Conversion,如圖2),同樣的,我 們也可以使用相同的方式讓一組自己的自定類之間可以相互轉換。 Unity版本:2020.3.12f1 圖1:Object隱式轉換爲Bool 圖2:UnityEngine.Object類中的隱式轉換 首先,我们分別定義兩個名爲"Class1""Class2"的類(如圖3)。 圖3:定義類 定義Class1到Class2以及Class2到Class1的隱式操作符 (如圖4) 。 圖4:定義兩個類之間的隱式轉換關係 經過一系列的操作,現在可以發現Class1和Class2之間可以相互轉換了(如圖5) 圖5:class1和class2相互轉換 注意: implicit operator只能在要轉換的Class中的其中一個中定義,不可在除這些類之外的任何一個類中定義(包括父類)。 錯誤示例 正確示例 同時,同一個 implicit operator在兩個類中只能存在一個

盤點Unity中比較容易踩得坑(1)

圖片
作爲一名剛剛入門Unity C#的新手,在編程過程中也踩了不少坑(有些不算是坑),這裏面有不少會對遊戲運行產生少量或甚至大幅的影響,我在這裡列舉一下Unity C#中比較容易踩坑的地方以及建議。 1. 刪除不必要的空Update()方法 在我們新建腳本之後,Unity會提前爲我們創建好兩個空的內置方法:Start() 以及 Update() 新建腳本 但有些腳本並不需要這些方法,因此我們需要將它們刪除掉而不是留空,因爲無論這些內置方法是否爲空,Unity始終會通過C#的反射來調用這些方法,從而造成不必要的性能開銷。 2. Invoke() 內的方法名使用nameof代替string 在使用諸如Invoke(), InvokeRepeating()來調用方法時,盡可能使用nameof(圖2.1)來代替string(圖2.2) 圖2.1:推薦方法 圖2.2:不推薦方法 雖然不論使用哪種方法都不會出現性能上的差距,但未來一旦需要使用“Ctrl+R, Ctrl+R”快捷鍵來 重命名“SampleMethod”方法時,Visual Studio會自動檢測並修改nameof (SampleMethod) (圖2.1)中的方法名,但不會自動重命名string中的常值"SampleMethod"(圖2.2),因此使用nameof增加了代碼的可維護性,降低了在未來因代碼維護而產生BUG的可能性。 3. 使用 gameObject.CompareTag() 代替 gameObject.Tag == "Tag" 在很多情況下(例如:碰撞體事件),我們需要對遊戲物體的Tag進行比較,常見的比較方法是 gameObject.tag  == "Tag"  或  gameObject.CompareTag("Tag"),這裏比較推薦第二種也就是 CompareTag("Tag")來比較物體的Tag。 下面列出了在分別使用兩種方式比較三次所花費的時間的測試結果 方法一:gameObject.tag  == " Player " 方法二: gameObject.CompareTag("Player") 用於測試兩種方法的代碼 測試結果: 經過以上測試表明,方法二

Blog留言板

沒甚麼好說的,用來作爲第一次創建Blog的紀念吧。 同時也作爲一個網站建議收集帖,如果你有任何的網站佈局、內容等建議。歡迎在下方留言。