開發者對於Unity Inspector的需求

用Inspector給值的方式進行開發是Unity中非常便利的方式，現在的元件式的開發理念下，給予在Inspector中可調的值讓元件的重覆利用性大幅的提高，也不用事事都必需經過程式端的調整。這算是某種資料導向（Data Oriented）的設計方式。

但當開發者開始對Inspector有更多的要求時，會發現它其它並沒有想像中的好用，如果真的要放入多元的資料，則自行改寫Inspector的擴充是無法避免的。但對於原先Unity就無法進行序列化（Serialize）／反序列化（Deserialize）的型別，光是改變Inspector的呈現資訊仍是無法做到的。

也就是說要真正擴充Inspector，除了賦予呈現上的擴充，也要兼顧到De/Serialize的部份。光是想到不同的型別的呈現方式和怎麼被存取等問題，就知道它的複雜度是無可比擬的，若是真的想要讓Inspector多元到可以在任何型別上，這包含了Interface、Delegate、Generic Type等，工程是異常的浩大。可能在進行遊戲專案時，光是完成Inspector的擴充就沒有餘力去開發遊戲本身的規則了。

不過，目前看起來陽春的Inspector其實在多數的情況下也還是可以滿足一般的開發需求，或許資料的呈現不直覺，以致於不好編輯，但都是小毛病，還在尚可接受的範圍。但碰到了也還是很常用的資料型別-Dictionary時，則會有點缺陷的遺憾。

從Unity Forum進行相關話題的搜尋，可以看到在標題為-Finally, a serializable dictionary for Unity! (extracted from System.Collections.Generic)的文章中有不少在Inspector可使用Dictionary的想法、討論甚至是可直接使用的程式碼，而文章雖是斷斷續續長達幾年的時間，但最後一篇文章是在前幾個月貼出的，也就是說此需求一直都是開發者關注的。而對於沒有時間自行撰寫此功能的開發者，也可以直接將此篇所付的程式碼引用到專案中，享受在Inspector裡可用、可存取Dictionary型別的快速方案。

一個使用上的問題解決了，嘗試到Inspector的強大便利好，很快就會有無法使用Generic Type和Delegate的不滿足，有心專研的開開發者，會在自尊心和好奇心的驅使下，開始花費時間探索怎麼將這些第二、第三常用的型別置入到Inspector，享受著和Dictionary一樣的便利性。

這是個無底洞，而且會違背原先開發上的宗旨。

不需要事事親恭，難到沒有現成的方案可以解決？在現有的Unity Asset Store（UAS）上查詢，不難看到解決此問題的外掛。其中最完善功能最齊全的非Full Inspector和Odin Inspector莫屬。

做個簡單的比較，Full Inspector現有的功能仍多過Odin Inspector，但Full Inspector已很久沒有進行更新，不清楚此外掛是否能無痛的和Unity 2017之後的版本做銜接，但在目前beta上跑，並沒有任何的問題。而Odin Inspector則是才剛起步沒多久的專案，功能陸續加上去，若是開發團隊按著自定的行程開發，應該會於短時間內囊括Full Inspector現行的功能。

現在的Odin Inspector有一個比較不同於Full Inspector的想法。它提出的Inspector客製化框架，不但可讓前述常用的型別可以良好在Inspector以特有的方式呈現，這樣框架制定後更是方便了開發者往後在撰寫自己的Editor擴充時，可以快速引用已有的框架-或是是搭配現有的Drawer或許是重新擺設UI去顯示某特定的型別。從這個觀點來說目前Odin Inspector對於型別的呈現，可說是客製化框架的副產物。

從Odin Inspector的官網上看它提供的功能，五花八門，常用的List、Dictionary當然是少不了的，另外它將色盤、貼圖／模型預覽等都做進來了，再加上對於原先已顯示的型別，增設了Drawer，讓各型別的呈現更加的適合專案中的設定。若開發者仍是不滿意已提供的呈現，可以依照自行的需求做客製化的撰寫，或是在直接在官網的Support那提出自己的需求，有可能會被排入到製作的行程中，若沒有辧法排入行程，他們的技術支援也可能會有簡易的方案進行協助。

說到底客製化Inspector的呈現不是絕對需要的，但不可否認的是在開發任何專案時，仍是會有某些型別做某方式呈現的需求。並不是不鼓勵開發者了解箇中技術後自行解決，而是利用現有的外掛、工具，讓自己的開發更順暢。