我现在有了一个大致的思路，还是事先计算，在上方不能提供宝石时，从左右侧获交替取宝石。实时判断太麻烦而且不如事先计算节约cpu。
只是最近太忙，没时间具体写代码。。
现在的做法是不是实时计算，是事先计算每下落一格，全盘所有滑块的下落情况，然后加上时间戳，存进数组里缓存，一直循环这个检测过程，最后没有能下落的就停止检测，
以上检测是一个时间帧里完成
最后才开始播放每个滑块的下落运动
但是这样存在一些问题，最后出现带传送功能的就有时间差的问题，效果看起来不连贯！
我觉得和游戏的玩法有关。如果游戏在所有宝石下落未停止前玩家可以继续消除（操作），那么实时计算比较好。如果是必须所有下落和消除动作结束前玩家不能操作，那么先计算出所有的过程是比较简单的。所以每次玩家操作一次后，我是计算出全部下落路径，然后来播放。等所有下落完毕后，计算消除。当不能消除、不能下落，再允许玩家操作。
按每个格子进行计算的，每次前进一格，可以算是步进式吧。如果出现时间差（有快有慢的）的状况，是不是把动作尽量同时启动会好些？不是非常清楚你的算法。
我之前的算法里有棋盘和格子对象的设计。在格子对象里可以处理从左上和右上交替取宝石的逻辑。
还有种情况是 空穴的 上/左上/右上 都是阻挡，这样不知道是否需要往下退一格再去 左上/右上 取宝石
观察了 《开心消消乐》 和《 candy crush soda saga》 ，宝石的垂直下落都是走的重力加速的效果，不是匀速, 所以感觉是加入了实时计算
不需要下退一格，因为要遍历每个格子，所以如果不能从上、左上、右上取宝石，那么这个格子就跳过好了。
我认为实时计算比较靠谱 因为如果一次性计算好 宝石的目标位置 虽然保存了宝石掉落到目标位置的节点路径 这样就相当于是宝石吧位置都提前预定好了 这样就会出现一个问题 如果A宝石到达指定位置需要走5部 但是A宝石到达指定位置上方的宝石 只需要3步就可以到达 这样出现的效果就是 A宝石还没到达指定位置的时候 A宝石要到达指定位置的上方就已经存在一个宝石了 这样形成的动画效果就是上方先有了宝石 下方才有的 正确的效果应该是从下往上依次填充
如果是实时计算的话 就可以避免这样的情况发生 如果是一次计算好的话 在所有的宝石到达指定位置以前是无法再次进行更新位置的算法操作 限制比较多
实时计算和一次计算 他们的计算消耗应该是一样的 虽然一次计算是在一帧以内计算出来的 但是这一帧的计算量还是不小的 这样一帧执行的时间势必会比实时计算的时间要长
1赞
最近看了篇关于三消游戏开发的介绍。发现使用一个ColumnManager对象来对宝石进行按列管理是比较方便的思路。
而具体移动确实实时计算比较好，我认为可能在ColumnManager中为宝石按步移动比较好（每次移动到另外一格）
关于下落速度测试效果如何 我测试了重力加速度 感觉比candy慢很多
是不是调整一下数值就行了？另外我猜需要注意检查一下不同分辨率下速度能否匹配的问题。
最近看了篇关于三消游戏开发的介绍。发现使用一个ColumnManager对象来对宝石进行按列管理是比较方便的思路。
楼主看的这篇帖子能发下连接嘛！我也遇到同样问题！没有好思路！或者想和楼至交流下
已经忘记在哪看到的了，不过我记得Unity里的一个例子好像是用到了这种设计
其实难点还在于有斜向下落和纵向下落在下落过程中有重叠产生，可能在实时检测的时候要添加一些判断
楼主解决了吗，能不能说下做法啊，我现在也遇到这个问题！
我是这样想的 通关下落规则可以知道棋子从什么位置到上面位置 还有什么地方斜向掉落 这些写在while 里 每一步判断 是否到斜向掉落的位置了 到了后 x 和y 都偏移 完了后继续y轴掉落 当到达位置后判断棋子是否可消除 qq 1016121454 加我qq 我们可以后续交流交流
楼主。。。一样的问题。
只看到实时计算和一开始计算完两种方式。
不知道具体一点的算法。还是无从下手啊。。。
好心多指点一下啊！！！
嗯。感谢回复。我昨天又问了人做出来了。
就是每一轮只移动一格，斜的也认为是一步。在临时表里做移动，再找下一轮所有可移动一格的。
好快啊。你的处理思路
其实很简单的。。。你把 消除了的 数组 赋值 = 0那你就知道 你该从那里 落下来了。落下来后 把值 赋成 1