我們從unity4.0開始用，一個30人左右的團隊做關卡式MMOARPG，做第一個專案的時候就遇到無比多坑，資源管理、尋路、動畫都很不好用，所以當我們有機會推倒重來做個新專案的時候就選擇盡量少用unity功能的思路來走，當時還是4.x，所以剛才說的系統還是不好用，所以我們拋棄引擎內建的資源依賴，自己管理依賴（將資源參照拆了自己記錄和載入解除安裝），不用NavMesh，自己寫尋路生成、載入和邏輯，動畫系統基本拋棄狀態機設定，自主控制動作邏輯（僅保留動作融合功能），每一個拋棄都意味著1個高級程式或者主程級別程式一個月以上的開發周期，投入是挺大，但回報也很好，整體基本做到業內比較先進的執行效能與表現性。
但這套東西叠代到5.x的時候就遇到障礙，主要是資源管理系統，5.x開始的資源打包得到了改進，依賴沒那麽惡心（雖然還不是很好），但因為引入了pbr，光照烘焙加了高光烘焙機制，這套機制會產生一些與場景深度依賴的光照數據，不能動態載入，使得之前的剝離機制在某些地方不能工作，其他還有諸如網格打包時會根據依賴情況來做剔除，也不能純粹地只打網格等等。
再往後到現在，Addressables出來了，資源管理部份已經比較完善，AnimationClipPlayable也解決了Animator各項短板，引擎都在不斷完善，自己寫的方案有些還能使用，有些會顯得雞肋。
鋪墊完我的經歷，總結一下我的經驗和建議，自己做的東西容易存在時代局限性，過個三五年後，可能自己的東西會改不動（這幾年來我們的框架重構了3次，有些模組已經改不動了，但依然有局部先進性），適應不了時代的變化，當然一般來說也不用考慮這麽長遠。而用不用unity提供的東西取決於你是否了解它，並自己能否有能力（時間、開發水平糊人力）來替代它，想知道未來unity會不會做出你想要的效果，就關註他們的roadmap，或者在Forum問一下他們的技術人員，了解他們的開發計劃，如果未來他們會做，你就考慮要不要等他們。
以上建議基於我一開始講到的人員和遊戲類別背景（中小型團隊做MMO類別遊戲），更大型的團隊或者更復雜的遊戲類別一般更傾向自己做，反之就傾向依賴引擎功能或者第三方外掛程式等。
