1. 为什么要给Scratch装上"游戏引擎"的骨架
三个多月前，我在一个少儿编程社群里看到有人问：Scratch能不能做出《空洞骑士》那样的横版动作游戏？底下的回答清一色是"能做个雏形，但手感很差"。这个回答本身没错，但它暴露了一个更根本的问题——大多数人用Scratch做游戏，做的是"一个游戏"，而不是"一套能做游戏的系统"。这两者的差别，就像用锤子钉了一颗钉子，和造一台能自动打钉子的机器。
Scratch本身是一个面向教育的可视化编程环境，它的设计目标是让初学者理解顺序、循环、条件、变量、消息这些编程概念。它自带舞台、角色、造型、声音、克隆体、画笔这些能力，拼起来确实能做出游戏，但当你真正想做一个稍微像样点的项目时，就会撞上一堵墙：没有帧的概念、没有实体管理、没有碰撞层、没有摄像机、没有对象池、没有状态机——什么都没有。你每做一个新游戏，就要把上一套脏逻辑扔掉重写一遍。
我们决定做的事情，就是把这堵墙拆掉。具体来说，我们花了大约三个月（严格算下来是十一个周末加若干深夜），在Scratch现有能力之上，搭出了一套可以复用的轻量级游戏引擎框架：它不改变Scratch的运行环境，不依赖任何外部插件，完全用积木块和少量扩展能力实现。它能提供稳定的帧循环、可复用的实体系统、手写AABB碰撞、可移动摄像机、瓦片地图渲染、简易状态机和对象池。做出来的三个Demo里，有一个横版卷轴跑酷、一个俯视角弹幕射击、一个简化版平台跳跃，都在低配笔记本上跑到了稳定的帧率。
这套东西适合谁？如果你只是想让小孩完成一节编程课，那它太复杂了。但如果你是一个想在Scratch里做出"手感接近正经游戏"的开发者，或者是一个想教学生项目架构的编程老师，又或者你单纯好奇"可视化编程的性能天花板到底在哪"，那接下来的内容应该能让你少走至少两个月的弯路。
下面我把这套框架的拆解思路、关键实现、踩过的坑，原原本本讲一遍。很多结论是我们在具体调参和反复推翻重做之后才得到的，文档里不会写，搜索也基本搜不到。
2. 动手之前先想清楚：Scratch到底缺了引擎的哪几块拼图
很多人做Scratch游戏的流程是这样的：新建角色，写一堆"当绿旗被点击"和"当按下空格键"，用广播在角色之间传消息，跑起来能玩，但加两个敌人就开始卡，加三个关卡就乱成一团。这不是开发者水平问题，而是Scratch的默认工作方式决定了它天然不是为"系统化游戏"设计的。
我们把一个标准游戏引擎应该具备的能力列出来，对照Scratch的现状，能清楚看到缺口在哪。
| 引擎能力 | 正经引擎的提供方式 | Scratch的默认状态 | 我们的补法 |
|---|---|---|---|
| 帧循环 | 引擎主循环固定每秒60次逻辑更新 | 无帧概念，循环速度随脚本复杂度变化 | 用"等待0秒"+计时器差分模拟固定步长 |
| 实体管理 | Entity/Component系统统一管理 | 每个角色各自为政，克隆体散落 | 克隆体池化+全局实体表 |
| 碰撞检测 | 内置物理引擎，支持多种碰撞体 | 只有"碰到角色/颜色"这类布尔判断 | 手写AABB+分轴移动+穿透修正 |
| 摄像机 | 变换视图矩阵，世界坐标转屏幕坐标 | 舞台固定，无法滚动 | 全局世界坐标+反向平移所有渲染层 |
| 瓦片地图 | 内置Tilemap组件 | 只能一个个角色摆，或用画笔硬画 | 画笔绘制+数据驱动+视口裁剪 |
| 状态机 | 内置动画状态机 | 无，靠变量和广播硬拼 | 状态表+消息驱动的简易FSM |
| 资源管理 | 异步加载+引用计数 | 造型声音全部常驻 | 分场景切换，显式释放 |
这张表里最要命的是前两项。没有帧循环，就没有游戏逻辑的稳定时间基准。在Scratch里，一个"重复执行"循环跑多快取决于里面有多少积木、有多少克隆体、舞台上有多少角色在同时响应消息。做动画还能凑合，做物理和AI就是灾难——同一个跳跃逻辑，在敌人多的时候会跳得更高，因为帧间隔被拉长了。
我们试过的最朴素方案，是在每个角色里各自写"重复执行，移动10步"，结果就是敌人和主角的运动速度完全脱节，主角像在冰面上滑，敌人像在泥里走。后来改成用计时器做全局节拍，才把这个基础问题解决掉。
第二个大缺口是实体管理。Scratch的克隆体很方便，但它的生命周期管理全靠开发者自觉：什么时候克隆、什么时候删除、删除后数据怎么回收，全没有约定。我们最初做弹幕射击，屏幕上两百个子弹克隆体，每次发射都新建、命中都删除，跑了两分钟帧率掉到个位数，而且内存明显上涨——Scratch虽然不暴露内存数据，但你能从表现上感觉到它在变慢。后来引入对象池，把子弹做成"藏着复用"，才把这个问题按住。
第三个容易忽视的是渲染层与逻辑层的耦合。在Scratch里，角色的位置既是逻辑坐标也是渲染坐标，摄像机一移动，所有东西都要跟着动。我们一开始的做法是给每个角色都加"位置减去摄像机偏移"，结果每个克隆体每帧都要多算四五步，性能直接吃掉一大块。正确做法是让渲染层统一处理偏移，逻辑层始终用世界坐标，两者只在最终显示时做一次转换。
把这三块想清楚之后，整个引擎的骨架才立得起来。很多人一上来就写具体游戏逻辑，写到一半发现架构撑不住，只能推倒重来，这就是我们前一个月反复返工的根源。
2.1 为什么不用现成扩展而选择纯积木实现
有人会问，Scratch不是有扩展吗，加个物理扩展、加个渲染扩展不就行了？我们认真评估过这条路，最后放弃了，原因有三个。
第一，大多数第三方Scratch扩展依赖外部加载，换台电脑、换个网络环境就可能失效，做出来的项目不具备可移植性，发给别人别人打不开，这在教学场景里是硬伤。第二，扩展的能力往往过于"黑盒"，你调不了它的内部参数，遇到手感问题只能干瞪眼，而游戏开发恰恰是细节决定手感。第三，纯积木实现虽然性能上限低一点，但它的每一行逻辑都是透明的，学生能看懂、能改、能学到东西——这恰恰是Scratch这个平台的核心价值。
所以我们定下的原则是：所有核心系统必须用原生积木实现，画笔和音乐等内置扩展可以用，但不引入任何外部依赖。这条原则后来被证明是对的，因为整套框架可以直接分享给任何一个装了Scratch的人。
2.2 全局坐标系的统一，是第一件必须做的事
在写任何一行游戏逻辑之前，我们先定了一套全局坐标系。Scratch舞台是480x360，中心为原点，x范围-240到240，y范围-180到180。这个尺寸做小游戏够用，但做卷轴游戏就太窄了，所以我们的世界坐标允许超出舞台范围，摄像机负责决定当前看哪一块。
具体约定是：世界坐标以左上角为原点或者以中心为原点都可以，但全项目必须统一。我们选的是以舞台中心为世界原点，这样和Scratch原生坐标一致，减少了转换成本。所有实体的位置、速度、碰撞盒都以世界坐标存储，只有渲染时才减去摄像机偏移。摄像机的偏移量本身也是一个世界坐标点，代表"当前屏幕中心在世界中的位置"。
这个约定看起来简单，但它带来的好处是巨大的：当你写AI时，你不需要关心摄像机在哪；当你写摄像机跟随逻辑时，你不需要关心实体怎么渲染。职责清晰了，bug就少了。我们踩过的最大的一个坑，是在项目中期临时改了坐标系，结果所有碰撞检测的符号全反了，排查了整整一个下午才发现是转换层没统一。
提示：坐标系统一这件事一定要在项目启动第一天就定死，并且写进项目注释。中途改坐标系的代价，远比你想象的大。
3. 用克隆体池化和全局帧调度撑起引擎的主循环
引擎的骨架说到底就两件事：谁在什么时候更新，以及更新的时候操作谁。前者是帧调度，后者是实体管理。这两块如果一开始就不设计好，后面所有功能都会长在烂地基上。
3.1 固定步长帧循环在Scratch里的可行实现
正经引擎的帧循环一般是这样的：记录上一帧时间，算出时间差delta，用delta去驱动物理和动画，同时用累加器保证逻辑以固定步长（比如每秒60次）更新。Scratch没有delta，但有个"计时器"积木，它返回的是自项目启动以来的秒数，精度足够。
我们的做法是：在舞台（或一个专门的主控角色）里跑一个"重复执行"循环，每次循环开头读取当前计时器，减去上一帧记录的计时器，得到delta。然后判断delta是否大于等于目标步长（1/30秒或1/60秒），如果够了就触发一次"逻辑帧"，把所有实体的更新脚本跑一遍，同时把累加器清掉。
伪代码大致是这样：
当绿旗被点击 将 [上一帧时间 v] 设为 (计时器) 将 [累加器 v] 设为 0 重复执行 将 [当前时间 v] 设为 (计时器) 将 [delta v] 设为 ((当前时间) - (上一帧时间)) 将 [上一帧时间 v] 设为 (当前时间) 将 [累加器 v] 增加 (delta) 如果 <(累加器) > (目标步长)> 那么 广播 [逻辑帧 v] 并等待 将 [累加器 v] 设为 0 结束 结束这里有一个关键点："广播并等待"是保证一帧内所有实体更新完成的核心。如果用普通的"广播"，消息发出后主循环会立刻继续跑，导致这一帧的逻辑和下一帧的计时重叠，实体的更新顺序也不可控。用"广播并等待"，主循环会阻塞到所有接收者处理完毕，这就形成了一个天然的同步屏障。
实测下来，这套调度在只有少量实体时能稳定跑到30帧以上，在画布元素较多时会掉到20帧左右，但至少时间基准是稳的，物理表现是一致的。这比"跑多快算多快"强太多。
3.2 克隆体池化：为什么不能每次需要就新建
对象池这个概念在正经引擎里很常见，但在Scratch里几乎没人提。原因大概是因为初学者觉得"克隆体反正能用，管它呢"。但只要你做过弹幕游戏就知道，新建和删除克隆体的开销远比复用大得多。
我们做过一个粗略对比：在一个场景里连续发射子弹，用"每次新建、命中删除"的方式，屏幕上维持100个子弹时就已经明显感觉到输入延迟；改成对象池之后，同样屏幕数量下操作流畅感有肉眼可见的提升。虽然Scratch不给我们帧率数字，但从操作响应上能明显感知到差别。
对象池的实现思路很朴素：在游戏开始时预生成一批克隆体，让它们进入"休眠"状态（隐藏+标记空闲），需要时从池里取一个激活，不需要时归还而不是删除。克隆体本身用一个局部变量记录自己的状态，比如状态=0表示空闲，1表示激活。再配合一个全局列表记录哪些克隆体编号是空闲的，取用和归还就变成了对列表的增删操作。
代码结构大致是：
当作为克隆体启动时 将 [我的状态 v] 设为 0 隐藏 重复执行 如果 <(我的状态) = 1> 那么 // 执行激活状态下的逻辑 结束 结束这套结构的好处是，克隆体的脚本主循环一直在跑，但只在激活时执行重逻辑，空闲时几乎不消耗什么。缺点是所有克隆体都在持续运行循环，数量太多时依然会有开销，所以池的大小要控制好。
3.3 全局实体表：让"谁存在"这件事变得可查
对象池解决了复用问题，但还有一个问题：当某个实体需要找到另一个实体时怎么办？比如子弹要判断是否打到敌人，如果每个子弹都去遍历所有敌人，那就是O(n²)的开销，屏幕上几十个敌人加几百个子弹直接卡死。
我们用一个全局列表来维护"当前所有激活实体的引用"，每个实体激活时把自己的唯一ID写入列表，休眠时移除。需要查找时，只遍历这个列表而不是遍历所有克隆体。为了进一步优化，我们还按类型分了几个列表，比如敌人列表、子弹列表、障碍列表，这样子弹只需要遍历敌人列表，范围大大缩小。
这里有个坑要提醒：列表的增删操作在Scratch里是有成本的。如果每帧都全量重建列表，性能会崩。我们的做法是只在实体状态发生变化时（激活/休眠）才更新列表，而不是每帧重建。这个改动把我们的弹幕Demo从"卡顿"救回了"可玩"。
4. 手写AABB碰撞：在积木块里复现物理引擎的基本功
Scratch原生的"碰到角色"和"碰到颜色"判断很好用，但它有两个致命问题：一是判断精度依赖造型，透明边缘也会算进去，导致碰撞判定比看起来更"胖"；二是"碰到颜色"在画笔绘制的地图上会非常慢，因为每次判断都要对像素做检测。做平台跳跃类游戏时，这两个问题会同时爆发。
所以我们决定手写一套基于AABB（轴对齐包围盒）的碰撞系统。AABB的意思是，每个实体用一个矩形来描述它的碰撞范围，矩形的边和世界坐标轴平行。判断两个实体是否碰撞，只需要比较它们在x轴和y轴上的投影是否重叠，也就是常说的"区间相交"判断。
4.1 AABB碰撞判断的具体实现
一个实体有位置（世界坐标）、宽、高，那么它的碰撞盒就是：
- 左边界 = x - 宽/2
- 右边界 = x + 宽/2
- 下边界 = y - 高/2
- 上边界 = y + 高/2
两个实体A和B发生重叠的条件是：A的右边界大于B的左边界，A的左边界小于B的右边界，同时A的上边界大于B的下边界，A的下边界小于B的上边界。这四个条件同时成立，才算碰撞。
用积木表达就是：
如果 <<<(A右边) > (B左边)> 且 <(A左边) < (B右边)>> 且 <<(A上边) > (B下边)> 且 <(A下边) < (B上边)>>> 那么 // 发生碰撞 结束这套判断用积木拼出来大概七八个积木块，单次判断非常快。实测下来，一个子弹和一百个敌人做碰撞检测，在30帧的预算里完全撑得住。
但AABB有个天然缺陷：它只能处理矩形，处理不了圆形和旋转后的形状。对于大多数2D游戏来说，矩形碰撞盒其实够了，主角和敌人都可以用略小于造型的矩形来近似，手感反而更精准。如果你要做圆形碰撞，可以把圆形也近似成矩形，或者额外写一个圆与圆的距离判断，这里就不展开了。
4.2 分轴移动：解决"卡墙"和"穿墙"的关键
有了碰撞判断还不够，真正难的是碰撞响应。初学者常犯的错误是：先算出新位置，再判断是否碰撞，如果碰撞就完全不动。这种做法会导致一个经典问题——角色斜着撞墙时，会卡住不动，因为x和y方向的移动被一起否决了。
正确做法是分轴移动：先只在x方向移动，判断碰撞，如果碰撞就把x方向的移动撤销或者贴边；再在y方向移动，同样处理。这样角色撞到竖直的墙时，x方向被挡住，但y方向还能自由移动，就能沿着墙滑行，手感自然得多。
我们的实现逻辑是这样的：
// 更新x 将 [新x v] 设为 ((x) + (vx)) 如果 <新位置碰撞> 那么 如果 <(vx) > 0> 那么 将 [x v] 设为 (墙的左边减去半宽) 否则 将 [x v] 设为 (墙的右边加上半宽) 将 [vx v] 设为 0 否则 将 [x v] 设为 (新x) 结束 // 更新y同理这段逻辑把"贴边"处理得很干净，角色不会嵌进墙里，也不会在墙上抖动。我们把这段代码封装成一个自定义积木块，任何实体只要调用它，就能获得稳定的碰撞响应。
4.3 穿透检测与速度上限
AABB有一个经典的失效场景：高速物体穿透薄墙。如果子弹每帧移动20像素，而墙只有10像素厚，那么子弹可能这一帧在墙左边，下一帧就在墙右边，中间的碰撞根本没被检测到。这在弹幕游戏里非常明显。
解决办法有两个。一是限制最大速度，让每帧位移不超过最薄障碍物的厚度，这是个简单粗暴但有效的方案，我们把它作为默认约束。二是做"扫掠检测"，也就是把这一帧的移动路径当作一条线段，和障碍物求交，取最早的碰撞点。扫掠检测更精确但实现复杂，我们只在必要的高速实体上使用简化版：把移动拆成若干子步，每步不超过墙厚的一半，逐步推进。这样虽然多几次判断，但避免了穿透。
实际上，对于大多数Scratch游戏，限制速度上限就够了，因为游戏节奏本来就不会特别快。我们在跑酷Demo里把主角最大水平速度定在每帧12像素，障碍物最薄处16像素，就再也没有出现过穿透。
5. 摄像机、瓦片地图与视口裁剪：让世界比舞台大一百倍
Scratch舞台只有480x360，做卷轴游戏时，世界可能有几千像素宽。如果只是把所有角色都放在世界里，然后让它们的位置减去摄像机偏移，性能会随着世界变大而崩塌，因为屏幕外的角色也在每帧更新和渲染。
5.1 摄像机跟随的平滑处理
摄像机本质上就是一个"当前视野中心的世界坐标"。最简单的实现是让摄像机直接等于主角的位置，但这样会有个问题：主角一动，屏幕就跟着猛动，玩久了会晕。所以真正好用的摄像机需要平滑跟随，也就是摄像机位置缓慢逼近主角位置，而不是瞬间到位。
我们的做法是每帧执行：
将 [摄像机x v] 设为 ((摄像机x) + ((主角x) - (摄像机x)) * 0.1)这个0.1叫跟随系数，值越大跟随越紧，值越小越"懒"。我们试过0.05到0.3之间的多个值，最后发现0.1到0.15之间最舒服。太紧会晕，太松会感觉角色在屏幕上飘。
还有一个细节是死区：当主角在屏幕中央附近小范围移动时，摄像机完全不动，只有超出死区才跟随。这能让画面更稳定。死区的实现是在判断是否跟随之前，先算主角与摄像机的距离，小于阈值就不更新摄像机。
5.2 瓦片地图：用画笔画出整张地图
Scratch的画笔扩展是我们在整个项目里唯一重度依赖的非核心能力。瓦片地图的思路是：把地图数据存在一个列表里，每个元素代表一个格子的类型（0为空，1为地面，2为墙等），渲染时遍历这个列表，根据摄像机位置决定哪些格子可见，然后用画笔在对应位置画矩形。
这样做的好处是，一张几百格的地图只需要渲染屏幕上可见的十几格，性能开销和地图大小无关。我们用这一套渲染了一张宽6400像素、高720像素的地图，在屏幕上只画可见区域，帧率几乎没受影响。
具体实现上，每一格的大小我们定为40x40像素，这样480宽的舞台正好显示12列。渲染时先遍历可见列和可见行，对每个格子判断类型，用"落笔移动到位置"加"画矩形"的方式绘制。为了让画笔不闪烁，每一帧先"全部擦除"，再重新画一遍，这在Scratch里是标准做法。
这里有个优化点：画笔的移动和落笔次数才是性能瓶颈，不是绘制面积。所以能一次画完的矩形不要拆成多次画，能合并的线条不要分开落笔。我们把地面格子做了行合并优化，同一行的连续地面只画一个长条，绘制次数减少了一半以上。
5.3 视口裁剪：屏幕外的东西一律不更新
视口裁剪的核心思想是：只在屏幕可见范围内的实体才执行重逻辑。对于屏幕外的敌人，我们只让它保持一个"冻结"状态，不执行AI、不做碰撞、不更新动画。这样即使世界里有上百个敌人，真正消耗性能的也只有屏幕上那十几个。
实现上，每个实体每帧先检查自己的世界坐标是否在摄像机视野的扩展范围内（我们额外加了100像素的缓冲，防止实体刚进屏幕时还没反应过来）。如果在范围内就标记为激活，执行完整逻辑；否则标记为休眠，只维持基本状态。
这个改动对性能的提升非常明显。我们的横版跑酷Demo里，整张地图上散落了大约80个敌人和道具，不做裁剪时帧率肉眼可见地掉，做完裁剪后和只放10个敌人时的表现几乎没差别。
6. 三个月里真正让我们卡住的几个坑
前面讲的都是"正确做法"，但这些东西不是一开始就想明白的。下面这几个坑，每一个都让我们花了不少时间去定位和修复，写出来希望能帮你省点时间。
6.1 广播风暴：消息太多反而拖慢主循环
我们最初设计实体通信时，大量使用了广播。主角受伤广播一次，敌人死亡广播一次，子弹命中再广播一次。结果在一个有50个敌人的场景里，每帧都有几十次广播，主循环被拖得很慢。
排查过程挺笨的：我们先怀疑是克隆体太多，把克隆体减半后没改善；又怀疑是碰撞检测太慢，把碰撞频率降低后还是没改善。最后我们做了个实验，把所有广播注释掉，用直接改变量代替，帧率立刻回来了。这才定位到问题在广播上。
Scratch的广播是一个全局事件，每个广播都要遍历所有脚本，判断是否有匹配的接收器响应，这个开销随着脚本数量增加而增加。所以后来我们定了个规矩：只有在"一对多"且"低频"的场景才用广播，比如游戏开始、游戏结束、关卡切换；高频的实体间通信一律用全局变量或列表。
6.2 克隆体上限：数量不是无限的
Scratch对克隆体数量是有上限的（不同版本数字略有差异，但通常在300左右）。我们做弹幕游戏时曾经同时存在200多个克隆体，一开始还能跑，但后来随着池子越开越大，突然有一天所有克隆体都不响应了，表现是所有子弹停在原地不动。
这个问题的隐蔽之处在于，它不会报错，只是"悄悄地失效"。我们排查了很久，最后是把克隆体数量统计打印出来，才发现已经逼近上限。解决办法就是严格控制池的大小，并且定期回收长时间空闲的克隆体。我们的经验值是任何时刻激活的克隆体不超过150个，池的总量不超过250个，这个范围比较安全。
6.3 浮点数精度：数值比较的坑
Scratch里的数字都是双精度浮点数，这意味着一系列加减乘除之后，一个本该等于0的值可能是0.0000001。我们在做碰撞贴边时，用了"如果x等于墙的左边"这样的判断，结果偶尔会失效。
修复方法很简单，所有浮点数比较都改用"绝对值小于某个极小值"的形式，比如把x = 0改成|x| < 0.001。这个改动虽然看起来啰嗦，但避免了很多偶发的定位偏差。后来我们把这条写进了项目规范。
6.4 计时器精度：不同设备不一样
我们用的计时器差分来做帧调度，这在大多数设备上没问题，但在一些性能较弱的设备上，计时器本身的更新频率可能不够高，导致delta算出来偏大或偏小。表现出来就是同样的游戏在不同电脑上手感有差异。
我们的应对是给delta加一个上限，比如单帧delta不超过0.1秒，超过就按0.1算。这样即使某一帧卡了一下，物理也不会因为delta过大而"瞬移"。这个处理叫"delta钳制"，是正经引擎里很常见的做法。
7. 用这套框架跑出来的三个Demo与实际表现
光讲架构容易空，说说我们实际用它做出来的东西，以及每个项目暴露出的问题。
第一个是横版卷轴跑酷。它用到了摄像机跟随、瓦片地图、AABB碰撞、对象池（金币和敌人）。整体跑下来，在主角速度较快时偶尔会有轻微的视觉抖动，后来发现是摄像机跟随系数太紧导致的，调松之后就好了。这个项目的经验是，跑酷类游戏的镜头必须有预判，也就是摄像机要略微朝主角运动方向偏移一点，否则玩家看不到前方的障碍。
第二个是俯视角弹幕射击。它用到了对象池（子弹）、全局实体表、视口裁剪。这个项目暴露的最大问题是碰撞检测的频率，一开始我们每帧对所有子弹和所有敌人做全量碰撞，帧率直接崩了。后来加了空间分区——把世界切成网格，每个格子维护自己的实体列表，子弹只和所在格子及相邻格子的敌人做检测，性能马上就回来了。这也是正经引擎里空间换时间的经典思路。
第三个是简化版平台跳跃。它用到了状态机、分轴移动、穿透检测。这个项目的教训是状态管理一定要集中，我们一开始把角色的各种状态散落在多个脚本里，导致"跳跃中受伤"这种组合状态处理起来一团乱。后来改成一张状态表驱动，每个状态定义进入、更新、退出三个动作，逻辑就清晰多了。
三个Demo加起来大概用了整套框架八成的能力，剩下两成是我们在做的过程中发现"其实不需要"而砍掉的，比如复杂的光照和粒子系统——在Scratch里做这些性价比太低，不如把精力放在手感和内容上。
8. 想复现这套思路的话，几个我个人的实操建议
如果你打算自己动手，我建议不要一上来就搭全套框架，那样很容易在细节里迷失。更靠谱的路径是从一个小项目出发，遇到问题再抽象。比如先做一个只有主角和地面碰撞的测试场景，把帧循环和AABB跑通；然后再加一个敌人，把实体表和状态管理加进来；再加一张大点的地图，把摄像机和瓦片地图加上。每一步都只解决一个具体问题，抽象自然就出来了。
关于性能调优，我个人的体会是，Scratch里真正的瓶颈通常不是计算，而是渲染和对象数量。你写再多的数学运算，只要不涉及画笔和克隆体的大规模操作，基本都不会卡。反过来，屏幕上多几十个角色，或者画笔每帧画上千个矩形，立刻就能感觉到。所以优化优先级应该是：先减少同时激活的对象数量，再优化渲染次数，最后才轮到优化计算逻辑。
还有一个很容易被忽视的点是脚本的组织方式。Scratch项目一复杂，脚本区就会变成一团毛线。我们的做法是每个角色只保留一个主入口脚本，其他逻辑全部封装成自定义积木，按功能命名，比如"更新物理""渲染自身""处理输入"。这样不管项目多大，看代码的时候都能顺着入口一步步读下去，改起来也不容易漏。
最后说个我踩过的坑：不要过早追求通用。我们中途曾经想把碰撞系统做成完全通用的，支持各种形状和任意旋转，结果越做越复杂，最后连最简单的矩形碰撞都跑不稳。后来全部砍掉，回到只支持AABB，反而什么项目都能做了。在Scratch这种表达能力有限的环境里，够用的抽象远比完美的抽象有价值。
