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