1. 项目概述与核心价值“捉迷藏之四”这个项目是第10届蓝桥杯Scratch国赛真题的第6题程序4。乍一看标题很多刚接触竞赛的家长或孩子可能会觉得这不就是个游戏吗但作为带过好几届蓝桥杯队伍的指导老师我必须说这道题远不止一个简单的“捉迷藏”游戏。它是一道典型的、高水平的综合应用题完美地融合了事件驱动、条件判断、循环控制、变量运算、克隆体管理以及复杂的逻辑推理等多个核心编程概念。对于想冲刺Scratch国赛高级奖项或者想真正吃透图形化编程精髓的学习者来说这道题是一个绝佳的“磨刀石”。为什么这么说因为蓝桥杯国赛级别的题目早已脱离了“让小猫走几步、说句话”的入门阶段。它考察的是孩子将复杂问题分解为可执行步骤的“计算思维”以及用有限的积木块构建出稳定、高效程序的“工程能力”。“捉迷藏之四”这个程序要求角色在特定规则下进行搜索与躲避其背后是对状态机思想和搜索算法雏形的巧妙应用。通过拆解和复现这道真题你不仅能掌握一套解决复杂交互问题的通用思路更能深刻理解如何用Scratch实现那些听起来很“算法”的东西。接下来我就带你彻底拆解这道题从题目解析到一行行积木的实现再到调试中会遇到的那些“坑”毫无保留地分享我的实战经验。2. 题目深度解析与设计思路拆解2.1 真题场景与规则还原首先我们必须回到题目本身。由于具体的题目描述原文较长我在这里提炼出最核心的规则和需求这也是我们编程的绝对依据角色与舞台通常包含至少两个角色例如一个“寻找者”如侦探、小猫和多个“隐藏者”如小动物、物品。舞台背景可能划分为多个区域或包含障碍物。核心玩法“寻找者”角色需要按照一定规则如按键控制移动在舞台上移动去“找到”或“触碰到”隐藏者。而“隐藏者”们则可能处于静止隐藏状态或者按照某种规律如周期性移动、条件触发后移动进行躲避。胜利与失败条件程序需要明确判定游戏何时结束。例如在规定时间内找到所有隐藏者则胜利寻找者触碰到某个特定障碍或超时则失败。国赛题中条件往往不是单一的可能是多条件组合。交互与反馈寻找者移动时隐藏者应有相应的反应如被发现时发出声音、改变造型、分数增加。同时舞台应有计时器、得分显示等UI元素。复杂度体现这是区分普通题与国赛题的关键。题目可能会要求多个隐藏者它们的行为逻辑可能相同也可能不同。智能躲避隐藏者不是傻站着而是当寻找者接近到一定范围时才开始向反方向或随机方向移动一段距离实现“捉迷藏”的动态效果。状态切换角色可能有“正常”、“警惕”、“被发现”等多种状态不同状态下造型和行为不同。规则嵌套例如先找到A隐藏者才能获得寻找B隐藏者的能力或线索。设计思路的核心面对这样的规则切忌一上来就堆砌积木。我的习惯是“三步走”角色分离将寻找者和隐藏者完全独立开分别思考他们的“一生”从绿旗点击到结束需要做什么。用流程图或草图画出来。消息驱动确定角色之间如何通信。是使用“广播”消息来触发事件如“游戏开始”、“被发现”还是通过侦测“碰到”或“距离”来直接交互国赛题通常需要两者结合。状态管理为每个角色定义几个关键的状态变量。例如寻找者可以用一个变量“模式”来控制是“移动中”还是“已找到”隐藏者可以用“是否隐藏”和“警惕范围”来控制行为。用变量来管理状态是让逻辑变清晰的不二法门。2.2 核心算法与逻辑剖析“捉迷藏”类题目的算法核心往往落在隐藏者的“躲避AI”上。这也是本题命名为“程序4”暗示其复杂度较高的原因。常见的躲避逻辑有以下几种我们需要根据题目描述选择或组合范围触发式躲避原理隐藏者持续检测自己与寻找者之间的距离。当距离小于某个设定值如100像素时触发躲避行为。Scratch实现使用“运算”类中的到 [寻找者] 的距离积木结合“如果...那么”进行判断。关键点躲避行为执行一次后必须有一个“冷却时间”或状态切换防止在同一帧内反复触发导致角色抖动或行为异常。通常用“等待”积木或一个“正在躲避”的变量来控制。向量反方向移动原理这是一种更智能的躲避。当被发现时隐藏者不是随机乱跑而是朝着与寻找者连线相反的方向移动。这需要一点向量思想。Scratch实现计算隐藏者指向寻找者的方向然后让隐藏者朝向当前方向 180度移动。或者利用坐标计算面向 [寻找者]后立即右转 180 度再移动。优势躲避行为更真实、有效能快速拉开距离。路径点巡逻与中断原理隐藏者原本沿着预设的路径点舞台上的几个坐标循环移动。当寻找者进入警戒范围则中断巡逻执行上述躲避逻辑当寻找者离开范围后再返回巡逻路径。实现难点这涉及到多线程在Scratch中是“并行脚本”的管理。一个脚本控制巡逻循环另一个脚本或同一脚本内通过条件判断监听警戒条件并中断循环。这里非常容易出错需要精心设计标志变量。对于“捉迷藏之四”结合过往真题经验它极有可能考察的是“多个隐藏者”“范围触发与向量躲避”“状态同步”的组合。这意味着你的程序里克隆体管理、消息同步和逻辑判断会交织在一起非常考验思维的严谨性。3. 程序架构与关键模块实现3.1 角色与变量规划在动手写代码前我们先做好蓝图。假设场景如下根据常见题型推断角色1侦探寻找者- 由玩家通过上下左右键控制。角色2小偷隐藏者- 共有3个由同一个角色原型通过克隆产生。它们初始随机隐藏当侦探接近时智能躲避。舞台需要一个简单的背景并显示“找到数量”和“剩余时间”。需要创建的变量全局变量已找到数量用于记录游戏进度。游戏时间倒计时计时器。游戏状态可以是“进行中”、“胜利”、“失败”用于控制所有角色的行为开关。仅适用于当前角色侦探的变量移动速度控制侦探的移动快慢。仅适用于当前角色小偷的变量警戒范围小偷开始逃跑的距离阈值。逃跑速度小偷逃跑时的移动速度。我的编号对于克隆体尤为重要用于区分不同的小偷克隆体方便调试和实现差异化行为。3.2 侦探寻找者控制模块实现侦探的逻辑相对直接主要是按键控制和碰撞检测。当绿旗被点击 隐藏 // 初始隐藏等待游戏初始化完成 将 [游戏状态 v] 设为 [进行中] 将 [移动速度 v] 设为 [5] // 可根据手感调整 显示 重复执行直到 (游戏状态) [胜利] 或 (游戏状态) [失败] 如果 按下 [向右键 v] ? 那么 将x坐标增加 (移动速度) 面向 (90) 度 // 保持造型方向正确 结束 如果 按下 [向左键 v] ? 那么 将x坐标增加 ((0) - (移动速度)) // 或 将x坐标增加 -5 面向 (-90) 度 结束 // 同上实现向上和向下的控制... 如果 碰到 [小偷 v] ? 那么 广播 [抓住一个 v] 并等待 // 关键“并等待”可以确保本次抓取事件处理完再继续循环 end 结束关键细节与心得移动平滑性在“重复执行”内检测按键角色移动是逐帧更新的很平滑。但要注意如果同时按下左右键角色会不动这符合常理。“碰到”检测的时机碰撞检测必须放在主循环内并且最好在移动指令之后。这样能确保角色移动到新位置后立即判断是否碰到。广播“并等待”的重要性当侦探碰到小偷时我们广播“抓住一个”。使用“并等待”积木可以让侦探脚本暂停直到接收了这个广播并执行相关操作如增加分数、删除克隆体的其他脚本执行完毕。这能有效避免在同一帧内同一个侦探连续触发多次“碰到”事件导致分数增加或克隆体删除出现逻辑错误。这是处理瞬时交互事件的一个经典技巧。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 结束深度解析与避坑指南距离检测的优化“到 [侦探] 的距离”这个积木在循环里每帧都执行计算开销很小可以放心使用。但要注意侦探角色必须可见且在舞台上。“冷却时间”的妙用在逃跑分支里的等待 (0.2) 秒至关重要。如果没有它程序会在一帧内判断距离80执行逃跑下一帧因为移动了可能距离还是80又立刻执行一次“面向侦探-右转180度”的操作。这会导致小偷的朝向在正反之间疯狂抖动移动轨迹诡异。这个小小的等待给了小偷一个稳定的逃跑方向和持续时间行为立刻变得合理。随机漫步的实现常态下的如果 (随机数) (0.1) 那么是一个经典技巧。随机数产生0~1之间的数小于0.1的概率大约是10%。这样小偷就有小概率自己动一下显得更自然。你可以调整这个阈值来控制活跃度。克隆体变量作用域我的编号这个变量在创建时必须选择“仅适用于当前角色”。这样每个克隆体都有自己独立的我的编号值。如果你错误地选择了“适用于所有角色”那么所有克隆体将共享同一个变量值会被互相覆盖导致混乱。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] // 停止所有角色的脚本 否则 删除此克隆体 // 这条指令必须写在“小偷”角色接收该广播的脚本里 end3.4.2 小偷接收广播处理在小偷角色本体或克隆体脚本中需要添加当接收到 [抓住一个 v] 如果 碰到 [侦探 v] ? 那么 // 再次确认避免误触发 播放声音 [被抓音效 v] // 每个小偷可以播放自己的声音 删除此克隆体 end 当接收到 [游戏结束 v] 停止 [该角色的其他脚本 v] // 优雅地停止当前克隆体的所有循环脚本核心经验“广播并等待” vs “广播”在“游戏初始化”时使用“并等待”确保所有角色准备就绪后再开始计时和操作。在“抓住一个”时侦探脚本用了“并等待”是为了保证分数增加和克隆体删除的原子性。而“游戏结束”广播通常不需要等待直接通知所有角色停止即可。停止脚本的顺序当游戏结束时使用停止 [全部 v]是最彻底的但有时你可能想先播放胜利动画。更优雅的做法是广播“游戏结束”让每个角色自己停止 [该角色的其他脚本 v]这样背景音乐等可能还会继续。克隆体删除的确认在“抓住一个”广播的处理中小偷克隆体再次判断“是否碰到侦探”这是一个安全锁。因为广播是发给所有角色的可能存在A小偷被抓但B小偷也接收到广播的情况虽然概率低。加上这个条件判断可以确保只有真正被碰到的小偷克隆体才会删除自己。4. 调试技巧与常见问题实录即使思路清晰在实现这么复杂的交互时也一定会遇到各种问题。下面是我和学生们在调试类似题目时踩过的“坑”和解决方案。4.1 克隆体“发疯”或抖动不止现象小偷克隆体在警戒状态下移动轨迹混乱不停抖动或旋转。排查首先检查“警戒范围”是否设置过大导致一出生就进入警戒状态。最重要的检查逃跑逻辑中是否有“冷却”机制。如果没有等待 (0.x) 秒就会每帧都执行“面向侦探-反向移动”导致方向重置看起来就是在抖动。检查“面向侦探”和“右转180度”是否在同一个执行块内中间有没有被其他积木如移动打断。解决确保逃跑逻辑块结构如下并包含一个短暂的等待。如果 距离 警戒范围 那么 面向 [侦探 v] 右转 (180) 度 移动 (逃跑速度) 步 等待 (0.2) 秒 // 关键 结束4.2 侦探一次抓住多个小偷分数增加异常现象侦探碰到一个小偷但“已找到数量”一下子增加了2或3。排查检查侦探的碰撞检测代码是否放在一个高速循环没有等待中。如果是那么在一帧内“碰到”条件可能持续为真导致广播被多次发送。检查“抓住一个”广播的处理脚本中是否缺少对“碰到侦探”的再次确认。检查“已找到数量”变量增加后是否立即触发了胜利条件并停止了脚本但广播还在队列中被其他克隆体接收到。解决在侦探的碰撞检测后加一个等待 (0.1) 秒或者将 [移动速度 v] 设为 [0] 等待 (0.5) 秒再恢复人为制造一个短暂的无敌时间或停顿。更推荐采用前文提到的“广播并等待”结合“克隆体二次确认”的双重保险机制。4.3 游戏结束后角色脚本停不下来现象游戏时间到或胜利后背景计时停了但侦探和小偷还能动。排查检查停止游戏的逻辑。是否只停止了“当前脚本”而没有停止“该角色的其他脚本”或“全部脚本”游戏状态变量游戏状态是否被正确设置为“胜利”或“失败”其他角色的循环是否正确地以(游戏状态) [进行中]为前提条件解决确保主控制脚本在游戏结束时使用广播 [游戏结束 v]。在每个角色的主循环尤其是“重复执行”块最外层包裹一个如果 (游戏状态) [进行中] 那么的判断。在每个角色中创建接收“游戏结束”广播的脚本里面执行停止 [该角色的其他脚本 v]。4.4 性能优化与小技巧克隆体数量Scratch能处理的克隆体数量有限通常几百个对于“捉迷藏”题目3-5个克隆体完全没问题。但如果题目要求更多就要考虑简化每个克隆体的逻辑减少每帧内的计算和循环。“移开”积木的副作用移开积木虽然方便但有时会让角色“弹”到意想不到的位置。对于要求精确位置控制的题目可以改用“在1秒内滑行到随机位置”或“如果碰到边缘那么左转180度”来实现更可控的反弹。变量监视器调试时把关键变量如游戏状态、已找到数量、到侦探的距离勾选在舞台上显示能帮你实时监控程序运行状态快速定位逻辑错误。通过以上从题目解析、思路设计、模块实现到调试排坑的完整拆解相信你对“捉迷藏之四”这道国赛真题有了透彻的理解。这道题的精髓不在于某一行积木而在于如何用清晰的逻辑和严谨的结构将多个并行交互的角色状态管理得井井有条。把这套方法吃透举一反三未来遇到再复杂的交互式编程题目你都能从容地拆解、构建和实现。编程思维和工程能力就是在这样一道道真题的锤炼中建立起来的。