杂谈之游戏开发中的控制器类

作者:i_dovelemon

日期:2016 / 02 / 27

来源:CSDN

主题:游戏开发，设计

引言

        我们知道，游戏开发中的实体对象具有很多的属性，如Position(位置)，Scale(缩放)，Rotation(旋转)，Color(颜色)。我们进行游戏开发逻辑层面上的设计也主要就是和这些东西打交道。通过对这四种基本参数的操作，我们能够实现很多非常复杂的效果出来。笔者在实际的开发项目当中，也主要和这些内容打交道，并且经过一段时间的开发，慢慢有了疑问。在开发的过程中，策划提出的需求，我们往往都是直接的将这些操作绑定在某个实体对象上面。比如说有一个游戏，敌人能够一边向玩家冲刺过来，一边又在不停的旋转，想要撞击玩家。对于这样的需求，我们往往就直接的在这个敌人的Enemy类里面编写好这种“边冲刺，边旋转”的功能。功能编写完毕之后，似乎能够很好的工作。可是过了几天，策划们觉得这样不够智能化，他们希望能够让敌人先跳跃到玩家的身边，然后在进行“边冲刺，边旋转”的操作。那么，在这个时候，我们往往都需要修改代码，来适应这样的功能。类似的事件在游戏开发中频繁的发生。如果我们采用上面的策略进行对这四种参数的硬编码设计，那么当策划需求发生改变的时候，我们往往需要花费很大的精力去应对它。所以，我常常思考有没有什么好的方法能够进行这样的操作。我们回归到最初的状态，我们所有的设计都是围绕着Postiion，Scale，Rotation，和Color来进行。而对这些基本属性的操作实际上都是一样的。所以，我们为什么不预先编写好一些类似的控制类，如Jump，Fly，WalkBySpline，ScaleIn，ScaleOut，FadeIn，FadeOut这样的操作了？这样的操作能够重复的在游戏中进行使用，如果我们抽象的够好，那么对于所有基于Position，Scale，Rotation，Color的操作，都能够通过一个或者多个这样的控制器进行组合来完成我们需要的功能。想到了这里，我就想到了曾经学习cocos2d-x的时候，它里面提供了一套名为Action的操作类。这些操作类就很好的实现了我们上面所讨论的内容。

控制器实现的两种方式

        熟悉cocos2d-x的同学就知道它的Action机制的实现是基于引擎的统一编码，也就是说所有的Action能够施加的控制都是继承与CCNode的类型。这样的设计能够让我们在控制器里面直接控制实体(cocos2d-x中的CCNode)。这种设计方式，对于一个统一的代码库能够很好很优雅的进行工作。

        但是在现实世界的开发中，往往没有那么的顺利。很多的库设计的都不是那么统一和优雅，他们往往没有统一的接口来让控制器进行操作。那么对于这样的库，我们又该如何去设计这样的功能了？很简单，那就让控制器放弃对实体的直接操作，而是通过返回描述信息的方式，让实体自己去操作自己。比如说，对于上面提到的FadeIn和FadeOut这两个控制器，我们就可以返回Alpha值，然后让那个实体在适当的时候自己去设置自己的Alpha值。

        这是我所想到的实现控制器的两种不同的方式：

• 基于代码库的统一接口，让控制器直接控制实体对象
• 对于不是统一接口的代码库，让控制器成为纯逻辑上的运算器，然后让实体自己在适当的时候去设置他们自己

两种实现方式的优缺点比较

基于代码库的统一接口

        优点：

• 省事儿，一旦组合好了控制器之后，就将控制交给了控制器，完全不用考虑自己的情况
• 代码风格统一，容易阅读，对后期的维护人员来说是一种福音

        缺点：

• 控制移交给控制器，那么实体就不能够灵活的控制控制器施加控制的时间，不能够根据自身的情况，随时中断控制的执行

纯逻辑运算器的控制器

        优点：

• 实体对象能够灵活的控制控制器施加的时间，能够根据自身的情况，动态的调整控制器的组合形式，是否忽略控制器的控制等等

        缺点：

• 需要实体对象选择合适的时机来进行设置，也就将这种选择丢给了开发人员，给开发人员带来了一定的麻烦

总结

        关于这方面的设计，仅仅就想到了这点皮毛！各位网友如果有什么更好的想法，欢迎大家交流！！