方块的补充是博主考虑时间最久的一个环节，纠结于是否需要扩大数据列表，把删除掉的积木在列表尾部补齐，又担心如果一列消除掉太多，Scratch角色超出边界后坐标移位。反复尝试过程中发现即便相同编号的克隆体堆叠在一起，但只要加一个限制条件，就可以让他们有序的下落。于是就有了本篇博文-《Scratch版本开心消消乐游戏中方块的消除与补充逻辑》，有意思的是，思考最久的方块补充环节，最终却是占代码量最少的一步。
如同小鸟数据的其他案例的极简风格，程序本身仍旧仅包含两个对象，程序的数据处理基本交给了小齿轮角色，彩色方块角色主要负责屏幕展示，但在这个实例中，它们也参与了数据列表的修改。
先来看一下消除检测这块自定义积木的最终形态，上一片博文提到由2进入消除检测，或由0进入消除检测总共有4种情况：
流程2没有消除
流程0没有消除
流程2有消除
流程0有消除实际上发现有消除后的情况基本一致，无论部分数据有没有被改动，我们统一初始化一下就好。没有消除的时候需要分两种情况，流程0没有消除的情况直接进入流程1，流程2但没有消除的情况，是用户拖拽了错误的方块，没有达成消除条件，我们需要先复位拖动方块，再进入流程1。
因为涉及到对两个彩色方块的私有变量的读取与修改，积木的消除与补充逻辑我们都写在彩色方块这个角色里，先来看一下消除的逻辑，虽然名为消除，实际上我们只是把符合条件的方块变小后隐藏，然后直接挪到了顶端，这样做有什么好处呢，不需要去担心一共需要补充多少块积木，也不用去考虑补充进去的积木的具体坐标，消除就是向上挪，补充就向下挪就好。
被消除（上移）的方块都被赋予一个新的编号值，比如当前数据列表总共64项，我们移上一排，从左到右依次把上移的方块编号修改为“65~72”，如果第一列中同时消去了6块积木，那么我们就空出了6个空格，以及多出了6个编号为65的上移积木。现有的展示在屏幕上的积木编号不能变动，但被修改为随机造型之后，编号的准确性就失去了意义。之所以都设置为“65~72”，是为了在补充积木时，能够与未被消除但需要下落的积木采用同一个逻辑。注意这里的头部有一块将私有变量方块状态置0的积木，如果缺少这一积木，未及时将被拖动的方块状态置0，在后续的拖动中积木的交换会产生“BUG”。
下落的逻辑是这样的，检查克隆体下方是否是空格，如果是则下落一格，把数据表中的原位置修改为0（图中55号），把数据表中的新位置修改为造型编号（图中47号），同时把下落单元格的私有变量—克隆编号，也从55修改为47。
尽管编号为71的积木一共有六块，但因为克隆体还是有运行的先后顺序，当第一个71号发现下方是0，并迅速把下落单元格修改为自己的造型编号之后，运行排名靠后的并列几名就暂时失去了下落的机会，下方的0就像一个漏斗，不管有几个人排队，但每次只能通行一个，当第一个71号下落变成了63，继续下落变成了55之后，原来63的位置又被设置成了0，又有一个幸运儿即将获得下落的机会。
补充积木的程序如下，如同文章开头所说，确实是很小的一段代码吧，正应了一句老话：“事儿越大，话越少”。在这段程序中，我们判断数据列表中的0是否都被造型编号所填满，如果没有，继续去搜寻等待下落的克隆体。等到数据列表内再没有空位，我们重新把任务丢给小齿轮，由它来验证是否可以消除，确定接下来进入第几个流程。
成品展示
一点补充
原来是设计了0~9共10个彩色方块，实际测试过程中，发现8x8的方阵，有6个造型就足够了，5个难度稍嫌过低，6个偶尔也会有过不了关的现象，大家如果想修改一下难度的话，可以尝试调整克隆体的随机值的范围。
