Unity3D的两个坑

Unity3d虽然做东西便利，也因此带来两个很大的坑。 其一是因为编辑器很容易关联不同的脚本，如果开发者经验不足，会让脚本之间依赖混乱，最后组织结构如同蜘蛛网，修改起来极其麻烦。 再微博上经常遇到一个问题，很多人吐槽， C#脚本和UnityScript脚本之间不能混用，基本上就是这个问题引起，因为如果保持单向依赖，接口放置再Plugins目录，实现放在SCR目录就不会有任何问题。 解决这个潜在问题的办法是开发者要在心里搞清楚依赖关系，让代码保持单向依赖才行，这个编辑器肯定帮不了开发者。 第二个坑更惨，我本人也陷入。 基于组件的开发模式，很容易惯纵开发者把渲染合逻辑代码混合到一起。因为每个组件都是场景中的一个位置和物体，很容易让开发者用空间关系来划分游戏结构，比如我们之前的游戏设计分为上面显示，中间UI下面操作三分的显示结构。基于直觉代码结构也是分为这三块。感觉很好，但在需求变化时候，比如要去处中间UI部分，我才发现问题的严重性，这样做等于显示和逻辑强耦合近来，泥马，我五一用了一个礼拜去重构（可以说使重写）代码，影响整个游戏70%代码都要重写，甚至到现在还有很大一部分等待重构。这个教训极其惨重，泥马，本质上代码还是要MVC啊，组件只是工具，Unity3d也是工具，工具不能影响本质，只能为本质服务，游戏的逻辑和渲染分离这么最基础的问题我都忘掉，检讨。我建立了一个空的组件书，不带任何渲染只处理逻辑关系。然后渲染放在另外一个渲染树上面去做才好。（用一个有限状态机去做控制部分）。 胜负的关键不是剑而是剑客本身。我个人认为，Unity3D的开发比Cocox2D要简单，但是简单并不代表更容易，但是因为Unity3D的简单，反而让开发者很多时候放弃思考，者带来的问题可能更加严重。保持一个谨慎的心，工具不停在变，但是软件开发的本质，还是那些。莫忘初心，方能始终！