Cocos2D游戏循环澄清

Question

注意:我不是母语为英语的人.请原谅任何语法错误.

我开发了一个简单的游戏,左边有一个射手,右边有敌人......非常简单.

该项目几乎完成,它完美运行,但现在我对游戏循环管理有一些疑问.

我安排从右边出现的敌人给调度程序一个间隔,这没关系,但我通过一个简单的ccMoveTo动作从右到左管理敌人的移动,我再说一遍:它完美无缺.问题是我读了一些关于"在每一帧中渲染精灵"的内容,将此操作委托给每帧运行一次的调度方法.

更好:我读到不使用动作移动精灵,但是逐帧重新渲染它们模拟以1/60频率(fps频率)调用的预定方法中的移动,并且我读到此实现可以防止不同硬件系统的稳定性差异..

我问的是:

• 这是正确的方法吗？
• 这是一个旧的"设计模式",与Cocos2D已经过时了？(这意味着使用ccMoveTo动作是完全完美的)
• 或者两个实现在同一级别是否正确？

编辑:

- 同样的技术也应该用于动画吗？

Answer 1

首先,如果它"完美地运作"并且您的游戏几乎完成,请不要改变您的游戏.如果你现在改变了一些东西,你就冒着对你的游戏玩法进行微妙改变的风险,你的游戏将需要更长的时间才能完成,最后玩家可能甚至都不会注意到差异.您可以在下次尝试不同的方法,但对于您当前的游戏,只要一切顺利,请保持原样.

我相信你所读到的是我也会说的:不要使用CCMoveTo/CCMoveBy进行游戏对象的(复杂)移动.如果移动非常简单,或者从A到B一次性移动,CCMove动作就可以了.但即使这样,更新循环的更新循环也很容易实现.

CCMove操作的问题在于您想要更改方向和/或速度时的行为.在这种情况下,您必须创建一个新的移动操作.如果你经常这样做,你将在你的游戏中添加比必要更多的alloc/dealloc周期.其次,CCMove动作在它们产生任何影响之前会占用一帧不活动状态.这意味着如果你每帧都创建一个新的CCMove动作,那么该游戏对象将被卡住而根本不会移动.如果你不那么频繁地改变它,你每次物体改变速度或方向时都会发现短暂的停顿.两者都不可取.

替代方案并不像听起来那么复杂.是的,您需要在移动的游戏对象中安排更新,如下所示:

[self scheduleUpdate];

然后实现更新方法,您可以在其中更新节点的位置:

-(void) update:(ccTime)delta
{
    self.position = CGPointMake(self.position.x + 1, self.position.y);
}

更灵活的运动通常使用速度矢量(CGPoint,通常是实例变量)来确定运动的速度和方向:

-(void) update:(ccTime)delta
{
    self.position = ccpAdd(self.position, self.velocity);
}

现在,您可以通过如何将速度添加到位置以及如何更新速度本身来获得更多花花公子.例如,您可以调整速度以确保对象的移动速度不会超过每秒x像素.您还可以通过降低每个帧的速度来添加模拟重力.还有更多.基本原则保持不变.

唯一真正不同的替代方案是将更新之间的增量时间考虑在内.这确保了节点随时间传播相同的距离而不管帧速率如何.意味着如果帧速率从60到20 fps下降,节点仍然会移动相同的距离,但每帧会移动几个像素以弥补丢失的时间.如果不考虑增量时间,节点会随着帧速率下降而减慢速度.

积分增量时间是一个简单的乘法:

-(void) update:(ccTime)delta
{
    self.position = ccpAdd(self.position, ccpMult(self.velocity, delta));
}

但是,大多数游戏不应使用时间增量.它可能导致相当不可预测的结果,包括如果设备忙于十分之一秒或更长时间的游戏世界模拟中的巨大跳跃,例如,如果它接收电子邮件或SMS.

大多数游戏应该放慢速度然后试图弥补"迷失"的时间.问题在于,在此期间玩家不能更快地做出反应(相反),因此比正常情况更快地推进游戏世界模拟对玩家来说是不公平的,并且可能导致过早失去肢体或生命.