蓝桥杯Scratch国赛真题解析：捉迷藏之四的算法与工程实践

1. 项目概述与核心价值

“捉迷藏之四”这个项目，是第10届蓝桥杯Scratch国赛真题的第6题程序4。乍一看标题，很多刚接触竞赛的家长或孩子可能会觉得，这不就是个游戏吗？但作为带过好几届蓝桥杯队伍的指导老师，我必须说，这道题远不止一个简单的“捉迷藏”游戏。它是一道典型的、高水平的综合应用题，完美地融合了事件驱动、条件判断、循环控制、变量运算、克隆体管理以及复杂的逻辑推理等多个核心编程概念。对于想冲刺Scratch国赛高级奖项，或者想真正吃透图形化编程精髓的学习者来说，这道题是一个绝佳的“磨刀石”。

为什么这么说？因为蓝桥杯国赛级别的题目，早已脱离了“让小猫走几步、说句话”的入门阶段。它考察的是孩子将复杂问题分解为可执行步骤的“计算思维”，以及用有限的积木块构建出稳定、高效程序的“工程能力”。“捉迷藏之四”这个程序，要求角色在特定规则下进行搜索与躲避，其背后是对状态机思想和搜索算法雏形的巧妙应用。通过拆解和复现这道真题，你不仅能掌握一套解决复杂交互问题的通用思路，更能深刻理解如何用Scratch实现那些听起来很“算法”的东西。接下来，我就带你彻底拆解这道题，从题目解析到一行行积木的实现，再到调试中会遇到的那些“坑”，毫无保留地分享我的实战经验。

2. 题目深度解析与设计思路拆解

2.1 真题场景与规则还原

首先，我们必须回到题目本身。由于具体的题目描述原文较长，我在这里提炼出最核心的规则和需求，这也是我们编程的绝对依据：

1. 角色与舞台：通常包含至少两个角色，例如一个“寻找者”（如侦探、小猫）和多个“隐藏者”（如小动物、物品）。舞台背景可能划分为多个区域或包含障碍物。
2. 核心玩法：“寻找者”角色需要按照一定规则（如按键控制移动）在舞台上移动，去“找到”或“触碰到”隐藏者。而“隐藏者”们则可能处于静止隐藏状态，或者按照某种规律（如周期性移动、条件触发后移动）进行躲避。
3. 胜利与失败条件：程序需要明确判定游戏何时结束。例如，在规定时间内找到所有隐藏者则胜利；寻找者触碰到某个特定障碍或超时则失败。国赛题中，条件往往不是单一的，可能是多条件组合。
4. 交互与反馈：寻找者移动时，隐藏者应有相应的反应（如被发现时发出声音、改变造型、分数增加）。同时，舞台应有计时器、得分显示等UI元素。
5. 复杂度体现：这是区分普通题与国赛题的关键。题目可能会要求：
   • 多个隐藏者：它们的行为逻辑可能相同也可能不同。
   • 智能躲避：隐藏者不是傻站着，而是当寻找者接近到一定范围时，才开始向反方向或随机方向移动一段距离，实现“捉迷藏”的动态效果。
   • 状态切换：角色可能有“正常”、“警惕”、“被发现”等多种状态，不同状态下造型和行为不同。
   • 规则嵌套：例如，先找到A隐藏者，才能获得寻找B隐藏者的能力或线索。

设计思路的核心：面对这样的规则，切忌一上来就堆砌积木。我的习惯是“三步走”：

1. 角色分离：将寻找者和隐藏者完全独立开，分别思考他们的“一生”（从绿旗点击到结束）需要做什么。用流程图或草图画出来。
2. 消息驱动：确定角色之间如何通信。是使用“广播”消息来触发事件（如“游戏开始”、“被发现”），还是通过侦测“碰到”或“距离”来直接交互？国赛题通常需要两者结合。
3. 状态管理：为每个角色定义几个关键的状态变量。例如，寻找者可以用一个变量“模式”来控制是“移动中”还是“已找到”；隐藏者可以用“是否隐藏”和“警惕范围”来控制行为。用变量来管理状态，是让逻辑变清晰的不二法门。

2.2 核心算法与逻辑剖析

“捉迷藏”类题目的算法核心，往往落在隐藏者的“躲避AI”上。这也是本题命名为“程序4”，暗示其复杂度较高的原因。常见的躲避逻辑有以下几种，我们需要根据题目描述选择或组合：

1. 范围触发式躲避：

   • 原理：隐藏者持续检测自己与寻找者之间的距离。当距离小于某个设定值（如100像素）时，触发躲避行为。
   • Scratch实现：使用“运算”类中的到 [寻找者] 的距离积木，结合“如果...那么”进行判断。
   • 关键点：躲避行为执行一次后，必须有一个“冷却时间”或状态切换，防止在同一帧内反复触发，导致角色抖动或行为异常。通常用“等待”积木或一个“正在躲避”的变量来控制。

2. 向量反方向移动：

   • 原理：这是一种更智能的躲避。当被发现时，隐藏者不是随机乱跑，而是朝着与寻找者连线相反的方向移动。这需要一点向量思想。
   • Scratch实现：计算隐藏者指向寻找者的方向，然后让隐藏者朝向（当前方向 + 180）度移动。或者，利用坐标计算：面向 [寻找者]后，立即右转 180 度，再移动。
   • 优势：躲避行为更真实、有效，能快速拉开距离。

3. 路径点巡逻与中断：

   • 原理：隐藏者原本沿着预设的路径点（舞台上的几个坐标）循环移动。当寻找者进入警戒范围，则中断巡逻，执行上述躲避逻辑；当寻找者离开范围后，再返回巡逻路径。
   • 实现难点：这涉及到多线程（在Scratch中是“并行脚本”）的管理。一个脚本控制巡逻循环，另一个脚本（或同一脚本内通过条件判断）监听警戒条件并中断循环。这里非常容易出错，需要精心设计标志变量。

对于“捉迷藏之四”，结合过往真题经验，它极有可能考察的是“多个隐藏者”+“范围触发与向量躲避”+“状态同步”的组合。这意味着你的程序里，克隆体管理、消息同步和逻辑判断会交织在一起，非常考验思维的严谨性。

3. 程序架构与关键模块实现

3.1 角色与变量规划

在动手写代码前，我们先做好蓝图。假设场景如下（根据常见题型推断）：

• 角色1：侦探（寻找者）- 由玩家通过上下左右键控制。
• 角色2：小偷（隐藏者）- 共有3个，由同一个角色原型通过克隆产生。它们初始随机隐藏，当侦探接近时智能躲避。
• 舞台：需要一个简单的背景，并显示“找到数量”和“剩余时间”。

需要创建的变量：

• 全局变量：
  • 已找到数量：用于记录游戏进度。
  • 游戏时间：倒计时计时器。
  • 游戏状态：可以是“进行中”、“胜利”、“失败”，用于控制所有角色的行为开关。
• 仅适用于当前角色（侦探）的变量：
  • 移动速度：控制侦探的移动快慢。
• 仅适用于当前角色（小偷）的变量：
  • 警戒范围：小偷开始逃跑的距离阈值。
  • 逃跑速度：小偷逃跑时的移动速度。
  • 我的编号（对于克隆体尤为重要）：用于区分不同的小偷克隆体，方便调试和实现差异化行为。

3.2 侦探（寻找者）控制模块实现

侦探的逻辑相对直接，主要是按键控制和碰撞检测。

当绿旗被点击 隐藏 // 初始隐藏，等待游戏初始化完成 将 [游戏状态 v] 设为 [进行中] 将 [移动速度 v] 设为 [5] // 可根据手感调整 显示 重复执行直到 <(游戏状态) = [胜利]> 或 <(游戏状态) = [失败]> 如果 <按下 [向右键 v] ?> 那么 将x坐标增加 (移动速度) 面向 (90) 度 // 保持造型方向正确 结束 如果 <按下 [向左键 v] ?> 那么 将x坐标增加 ((0) - (移动速度)) // 或 将x坐标增加 -5 面向 (-90) 度 结束 // 同上，实现向上和向下的控制... 如果 <碰到 [小偷 v] ?> 那么 广播 [抓住一个 v] 并等待 // 关键！“并等待”可以确保本次抓取事件处理完再继续循环 end 结束

关键细节与心得：

1. 移动平滑性：在“重复执行”内检测按键，角色移动是逐帧更新的，很平滑。但要注意，如果同时按下左右键，角色会不动，这符合常理。
2. “碰到”检测的时机：碰撞检测必须放在主循环内，并且最好在移动指令之后。这样能确保角色移动到新位置后立即判断是否碰到。
3. 广播“并等待”的重要性：当侦探碰到小偷时，我们广播“抓住一个”。使用“并等待”积木，可以让侦探脚本暂停，直到接收了这个广播并执行相关操作（如增加分数、删除克隆体）的其他脚本执行完毕。这能有效避免在同一帧内，同一个侦探连续触发多次“碰到”事件，导致分数增加或克隆体删除出现逻辑错误。这是处理瞬时交互事件的一个经典技巧。

3.3 小偷（隐藏者）克隆体与AI模块

这是本题最核心、最复杂的部分。我们将小偷的行为分为三个阶段：初始化生成、常态隐藏、警戒逃跑。

3.3.1 克隆体生成与初始化

当绿旗被点击 隐藏 // 隐藏本体 将 [警戒范围 v] 设为 [80] 将 [逃跑速度 v] 设为 [4] 删除本克隆体 // 清除旧克隆体 重复 (3) 次 // 生成3个小偷 创建 [自己 v] 的克隆体 结束 当作为克隆体启动时 显示 将 [我的编号 v] 设为 (克隆体ID) // 利用Scratch自带的克隆体ID来标识 移到 x: (在 (-200) 到 (200) 间随机选一个数) y: (在 (-150) 到 (150) 间随机选一个数) // 随机初始位置 将角色的大小设为 (在 (40) 到 (70) 间随机选一个数) // 增加视觉变化 重复执行 // 每个克隆体独立运行的主循环 // 这里将放入常态和警戒逻辑 结束

3.3.2 状态判断与智能躲避AI

现在，我们在克隆体的“重复执行”循环中，实现其核心AI。

重复执行 如果 <(游戏状态) = [进行中]> 那么 如果 <(到 [侦探 v] 的距离) < (警戒范围)> 那么 // 状态：警戒/逃跑 换成 [逃跑造型 v] // 可选，增强表现力 面向 [侦探 v] 右转 (180) 度 // 立刻转向侦探的反方向 移动 (逃跑速度) 步 // 边缘检测：防止跑出舞台 如果 <碰到边缘？> 那么 移开 // 使用“移开”积木简单处理，更复杂的可以反弹 右转 (在 (150) 到 (210) 间随机选一个数) 度 // 碰到边缘后随机转向 end 等待 (0.2) 秒 // “冷却时间”，防止过度频繁转向导致抖动 否则 // 状态：常态/隐藏 换成 [正常造型 v] 如果 <(随机数) < (0.1)> 那么 // 以10%的概率进行随机漫步，让角色更“活” 右转 (在 (-45) 到 (45) 间随机选一个数) 度 移动 (2) 步 // 常态移动速度较慢 如果 <碰到边缘？> 那么 移开 end end end end 结束

深度解析与避坑指南：

1. 距离检测的优化：“到 [侦探] 的距离”这个积木在循环里每帧都执行，计算开销很小，可以放心使用。但要注意，侦探角色必须可见且在舞台上。
2. “冷却时间”的妙用：在逃跑分支里的等待 (0.2) 秒至关重要。如果没有它，程序会在一帧内判断距离<80，执行逃跑；下一帧因为移动了，可能距离还是<80，又立刻执行一次“面向侦探->右转180度”的操作。这会导致小偷的朝向在正反之间疯狂抖动，移动轨迹诡异。这个小小的等待，给了小偷一个稳定的逃跑方向和持续时间，行为立刻变得合理。
3. 随机漫步的实现：常态下的如果 <(随机数) < (0.1)> 那么是一个经典技巧。随机数产生0~1之间的数，小于0.1的概率大约是10%。这样小偷就有小概率自己动一下，显得更自然。你可以调整这个阈值来控制活跃度。
4. 克隆体变量作用域：我的编号这个变量，在创建时必须选择“仅适用于当前角色”。这样，每个克隆体都有自己独立的我的编号值。如果你错误地选择了“适用于所有角色”，那么所有克隆体将共享同一个变量，值会被互相覆盖，导致混乱。

3.4 游戏逻辑与广播通信

游戏的整体流程控制，以及角色间的协作，主要通过“广播”来协调。

3.4.1 游戏控制脚本（可以写在背景或一个隐藏的管理员角色上）

当绿旗被点击 将 [已找到数量 v] 设为 [0] 将 [游戏时间 v] 设为 [30] // 假设30秒 将 [游戏状态 v] 设为 [进行中] 广播 [游戏初始化 v] 并等待 // 通知所有角色准备 重复执行直到 <(游戏状态) != [进行中]> 等待 (1) 秒 将 [游戏时间 v] 增加 (-1) 如果 <(游戏时间) < [0]> 那么 将 [游戏状态 v] 设为 [失败] 广播 [游戏结束 v] 停止 [全部 v] end 结束 当接收到 [抓住一个 v] 将 [已找到数量 v] 增加 (1) 播放声音 [抓住音效 v] 直到播放完毕 如果 <(已找到数量) = [3]> 那么 // 如果找到所有小偷 将 [游戏状态 v] 设为 [胜利] 广播 [游戏结束 v] 停止 [全部 v] // 停止所有角色的脚本 否则 删除此克隆体 // 这条指令必须写在“小偷”角色接收该广播的脚本里！ end

3.4.2 小偷接收广播处理

在小偷角色（本体或克隆体脚本中）需要添加：

当接收到 [抓住一个 v] 如果 <碰到 [侦探 v] ?> 那么 // 再次确认，避免误触发 播放声音 [被抓音效 v] // 每个小偷可以播放自己的声音 删除此克隆体 end 当接收到 [游戏结束 v] 停止 [该角色的其他脚本 v] // 优雅地停止当前克隆体的所有循环脚本

核心经验：

1. “广播并等待” vs “广播”：在“游戏初始化”时使用“并等待”，确保所有角色准备就绪后再开始计时和操作。在“抓住一个”时，侦探脚本用了“并等待”，是为了保证分数增加和克隆体删除的原子性。而“游戏结束”广播通常不需要等待，直接通知所有角色停止即可。
2. 停止脚本的顺序：当游戏结束时，使用停止 [全部 v]是最彻底的，但有时你可能想先播放胜利动画。更优雅的做法是广播“游戏结束”，让每个角色自己停止 [该角色的其他脚本 v]，这样背景音乐等可能还会继续。
3. 克隆体删除的确认：在“抓住一个”广播的处理中，小偷克隆体再次判断“是否碰到侦探”，这是一个安全锁。因为广播是发给所有角色的，可能存在A小偷被抓，但B小偷也接收到广播的情况（虽然概率低）。加上这个条件判断，可以确保只有真正被碰到的小偷克隆体才会删除自己。

4. 调试技巧与常见问题实录

即使思路清晰，在实现这么复杂的交互时，也一定会遇到各种问题。下面是我和学生们在调试类似题目时踩过的“坑”和解决方案。

4.1 克隆体“发疯”或抖动不止

• 现象：小偷克隆体在警戒状态下移动轨迹混乱，不停抖动或旋转。
• 排查：
  1. 首先检查“警戒范围”是否设置过大，导致一出生就进入警戒状态。
  2. 最重要的：检查逃跑逻辑中是否有“冷却”机制。如果没有等待 (0.x) 秒，就会每帧都执行“面向侦探->反向移动”，导致方向重置，看起来就是在抖动。
  3. 检查“面向侦探”和“右转180度”是否在同一个执行块内，中间有没有被其他积木（如移动）打断。
• 解决：确保逃跑逻辑块结构如下，并包含一个短暂的等待。

  如果 <距离 < 警戒范围> 那么 面向 [侦探 v] 右转 (180) 度 移动 (逃跑速度) 步 等待 (0.2) 秒 // 关键！ 结束

4.2 侦探一次抓住多个小偷，分数增加异常

• 现象：侦探碰到一个小偷，但“已找到数量”一下子增加了2或3。
• 排查：
  1. 检查侦探的碰撞检测代码，是否放在一个高速循环（没有等待）中。如果是，那么在一帧内，“碰到”条件可能持续为真，导致广播被多次发送。
  2. 检查“抓住一个”广播的处理脚本中，是否缺少对“碰到侦探”的再次确认。
  3. 检查“已找到数量”变量增加后，是否立即触发了胜利条件并停止了脚本，但广播还在队列中，被其他克隆体接收到。
• 解决：
  1. 在侦探的碰撞检测后，加一个等待 (0.1) 秒或者将 [移动速度 v] 设为 [0] 等待 (0.5) 秒再恢复，人为制造一个短暂的无敌时间或停顿。
  2. 更推荐：采用前文提到的“广播并等待”结合“克隆体二次确认”的双重保险机制。

4.3 游戏结束后角色脚本停不下来

• 现象：游戏时间到或胜利后，背景计时停了，但侦探和小偷还能动。
• 排查：检查停止游戏的逻辑。
  1. 是否只停止了“当前脚本”，而没有停止“该角色的其他脚本”或“全部脚本”？
  2. 游戏状态变量游戏状态是否被正确设置为“胜利”或“失败”？其他角色的循环是否正确地以<(游戏状态) = [进行中]>为前提条件？
• 解决：
  1. 确保主控制脚本在游戏结束时，使用广播 [游戏结束 v]。
  2. 在每个角色的主循环（尤其是“重复执行”块）最外层，包裹一个如果 <(游戏状态) = [进行中]> 那么的判断。
  3. 在每个角色中创建接收“游戏结束”广播的脚本，里面执行停止 [该角色的其他脚本 v]。

4.4 性能优化与小技巧

• 克隆体数量：Scratch能处理的克隆体数量有限（通常几百个），对于“捉迷藏”题目，3-5个克隆体完全没问题。但如果题目要求更多，就要考虑简化每个克隆体的逻辑，减少每帧内的计算和循环。
• “移开”积木的副作用：移开积木虽然方便，但有时会让角色“弹”到意想不到的位置。对于要求精确位置控制的题目，可以改用“在1秒内滑行到随机位置”或“如果碰到边缘，那么左转180度”来实现更可控的反弹。
• 变量监视器：调试时，把关键变量如游戏状态、已找到数量、到侦探的距离勾选在舞台上显示，能帮你实时监控程序运行状态，快速定位逻辑错误。

通过以上从题目解析、思路设计、模块实现到调试排坑的完整拆解，相信你对“捉迷藏之四”这道国赛真题有了透彻的理解。这道题的精髓不在于某一行积木，而在于如何用清晰的逻辑和严谨的结构，将多个并行交互的角色状态管理得井井有条。把这套方法吃透，举一反三，未来遇到再复杂的交互式编程题目，你都能从容地拆解、构建和实现。编程思维和工程能力，就是在这样一道道真题的锤炼中建立起来的。