我们从unity4.0开始用，一个30人左右的团队做关卡式MMOARPG，做第一个项目的时候就遇到无比多坑，资源管理、寻路、动画都很不好用，所以当我们有机会推倒重来做个新项目的时候就选择尽量少用unity功能的思路来走，当时还是4.x，所以刚才说的系统还是不好用，所以我们抛弃引擎自带的资源依赖，自己管理依赖（将资源引用拆了自己记录和加载卸载），不用NavMesh，自己写寻路生成、加载和逻辑，动画系统基本抛弃状态机设定，自主控制动作逻辑（仅保留动作融合功能），每一个抛弃都意味着1个高级程序或者主程级别程序一个月以上的开发周期，投入是挺大，但回报也很好，整体基本做到业内比较先进的运行性能与表现性。
但这套东西迭代到5.x的时候就遇到障碍，主要是资源管理系统，5.x开始的资源打包得到了改进，依赖没那么恶心（虽然还不是很好），但因为引入了pbr，光照烘焙加了高光烘焙机制，这套机制会产生一些与场景深度依赖的光照数据，不能动态加载，使得之前的剥离机制在某些地方不能工作，其他还有诸如网格打包时会根据依赖情况来做剔除，也不能纯粹地只打网格等等。
再往后到现在，Addressables出来了，资源管理部分已经比较完善，AnimationClipPlayable也解决了Animator各项短板，引擎都在不断完善，自己写的方案有些还能使用，有些会显得鸡肋。
铺垫完我的经历，总结一下我的经验和建议，自己做的东西容易存在时代局限性，过个三五年后，可能自己的东西会改不动（这几年来我们的框架重构了3次，有些模块已经改不动了，但依然有局部先进性），适应不了时代的变化，当然一般来说也不用考虑这么长远。而用不用unity提供的东西取决于你是否了解它，并自己能否有能力（时间、开发水平和人力）来替代它，想知道未来unity会不会做出你想要的效果，就关注他们的roadmap，或者在Forum问一下他们的技术人员，了解他们的开发计划，如果未来他们会做，你就考虑要不要等他们。
以上建议基于我一开始讲到的人员和游戏类型背景（中小型团队做MMO类型游戏），更大型的团队或者更复杂的游戏类型一般更倾向自己做，反之就倾向依赖引擎功能或者第三方插件等。
