我应该将CCSprite,CCNode或NSObject子类化吗？

Question

我看到某些文本似乎总是将CCSprite子类化.我在某个地方读到这样做并不好,最好从基本的东西开始.我想知道专业游戏开发者在游戏结构方面做了些什么.这是CCSprite的子类或在NSObject类ETC中添加CCSprite.

我希望我的问题有道理.

Answer 1

我的偏好是几乎完全是CCNode的子类.

如果我需要精灵,标签或任何与基本实现略有不同的行为,我只会继承CCSprite,CCLabel和其他内部Cocos2D类的子类.如果类别不足,子类化将是最后的手段.大多数Cocos2D开发人员显然不明白的是CCSprite本身就是一个完整的类,不需要扩展(子类)来表示游戏对象.但是很容易陷入这种习惯,因为通过创建CCSprite子类,您可以获得视觉效果,并且您拥有游戏逻辑代码的容器.这样做不是很好.

如果你考虑一下,只要你向CCSprite添加某种游戏逻辑代码,它就不再只是一个CCSprite,或者是它？考虑它的一个好方法是:如果你继承一个类(将其命名为MyClass)并向其添加自定义代码,那么将MyClass子类化为其他目的是否有意义？如果没有,那么你不应该是子类.

使用广泛使用的"Car"类的OOP类比:你将"Car"子类化为更专业但仍然是通用的类,如"SportsCar","Truck","Van",但你不会将"Car"子类化为打造"保时捷911 V-Turbo Model 6".为什么不？因为"SportsCar"类具有创建SportsCar 实例的所有方面,然后成为"保时捷911 V-Turbo Model 6".

你需要考虑的另一件事是"保时捷911 V-Turbo Model 6"将是一个高度专业化的类别,除了定义非常具体的汽车之外没有任何其他目的.将"Porsche 911"类子类化是没有任何意义的,因为它基本上失去了它的通用属性,并用非常具体的实现细节替换它们.如果你有一个你无法合理地继承的类,那么你已经在类层次结构中创建了一个死胡同,并且本质上是编写功能代码,而不是面向对象的代码.尽管如此,对于简单的游戏来说还是可以的,但是如果你敢于做更多游戏,它会回来困扰你.

总结一下:只有当你的目的是制作一个更专业但仍然普遍可用的CCSprite时,你才会继承CCSprite.其中一个例子是CCLabelTTF,它是CCSprite的子类.它只增加了在运行时从字体和字符串创建CCSprite纹理的功能.子类化CCSprite的另一个例子是,如果您需要一个CCSprite,它将从谷歌地图更新其纹理,使其类似于基于经度和纬度坐标和缩放级别的地图图块.它仍然基本上是一个愚蠢的对象,其唯一目的是在某个位置显示矩形图像.那就是CCSprite.一个在某个位置显示纹理的哑对象.

真正的问题是这个问题:是("是"),你的游戏对象精灵呢,还是有("有"),其可视化表示雪碧？答案应该始终是后者.子类化的通用规则是"是一个"关系,如果"有一个"它是复合模式的时间.如果有疑问,两者似乎都适用,总是在"有一个"方面犯错,因为这总是有效的.

为什么我会说游戏对象不是精灵,而是有精灵？显然两者都适用.答案:游戏对象"只是一个"精灵,只要它可以由一个精灵表示而不是其他任何东西.但事实上,您的游戏对象可能必须由多个精灵,精灵,标签和一些粒子效果来表示.这意味着随着应用程序的开发,"是一种"关系更容易破裂,这意味着额外的重构工作.

通过使用CCNode作为游戏对象的基类,并将可视节点添加到该基本节点,您还可以使用基节点作为游戏对象视图的控制器对象.这意味着它将更好地符合模型 - 视图 - 控制器(MVC)模式.

最后,我不会将NSObject子类化为应该位于cocos2d视图层次结构中的任何内容,或者保留对cocos2d视图层次结构中某些内容的引用.原因很简单,NSObject子类不提供CCNode的任何标准功能(调度,添加子节点,子节点的相对定位),最重要的是,很难将NSObject子类与Cocos2D的自动内存管理一起使用.节点类.

没有详细说明,简单的规则是,如果一个子类具有一个Cocos2D节点的实例变量,它本身应该是一个Cocos2D节点,这样内存管理和所有其他方面都很容易和万无一失.就Cocos2D而言,CCNode类是视图层次结构的根类,因此它类似于UIResponder类,能够承担UIView和/或UIViewController类的角色(顺便说一下,这两个类都来自UIResponder)在场合.

简而言之:子类CCNode,然后使用组合/聚合模式来表示类的视觉方面.

Answer 2

你的问题肯定是有道理的.

这基本上是一个架构问题.如果你的游戏主要基于"动画",我会去CCSprite的子类化.如果您的游戏主要基于某些逻辑,可能是RPG或其他任何东西,那么屏幕表示实际上只是游戏状态的可能视图之一.因此,在我看来,它应该是表示游戏状态的对象树中的一个对象的一部分.

换句话说:如果你的游戏状态本质上是一个场景,那么子类CCSprite,因为Cocos2D在管理场景方面可能比你更好.如果你的游戏状态是"其他东西",你可能应该考虑建立你自己的状态表示,并使你的精灵成为游戏对象的一部分.如果您决定更改渲染,这还允许您"切换"图形引擎.例如,您可能正在使用Cocos2D中的2D表示进行RPG.过了一会儿,你向Ubisoft展示你的演示,他们爱上它并给你2000万美元来完成它,但他们要求3D渲染.如果你去CCSprite的子类,你必须重做所有的游戏.如果你想在一个NSObject派生类中集成CCSprite/CCNode,你就可以了.

当然,这个例子有点夸大了......例如:D

Answer 3

如果您在Cocos2D之旅中有这个问题,请继承CCSprite的子类并完成它.您现在不会创建任何需要微调类高级技术的东西.我说这不是对你的能力的侮辱,而是作为曾经有过这个问题的人.

当您开始怀疑是否需要重写CCNode的OpenGL方法调用时,那么您将需要仔细考虑子类化选项.子类化CCSprite可以为您提供更低级别的所有方法和属性,使您能够发现,学习和前进.

简而言之:子类CCSprite.