从一个在少年宫带过三年社团课的角度说Scratch 和 Python 之间那道从积木到代码的坎用 3D 跑酷来跨是最顺的。原因很直接跑酷这个玩法的核心逻辑简单到能画在一张餐巾纸上——往前跑、左右挪、跳起来、别撞东西但它的画面呈现又足够唬人一个伪 3D 的透视通道加上雾化渐变就能让没接触过 3D 的人眼前一亮。孩子在 Scratch 里用积木搭出来的那一套投影公式、碰撞判定、关卡生成规则换到 Python 里几乎可以一比一翻译成函数和类中间不需要重新学一遍世界观。这篇东西面向三类人一是手里有 Scratch 基础、想往代码方向走的学生二是要带课的老师或者社团组织者需要一份能直接照着做的项目路线三是已经会写 Python、但一直没搞明白 3D 透视到底怎么算的入门开发者。我会把 Scratch 版和 Python 版两套实现都拆开讲两边的参数是刻意对齐的你可以拿同一套数值在两个环境里跑看画面是不是长一个样。至于 3D 建模、glTF 模型导入、把角色导出成能 3D 打印的实体摆件这些延伸玩法也放在后面聊。1. 项目整体设计与两条路线的选型逻辑做 3D 跑酷这件事最容易走的弯路是一上来就找 3D 引擎。我见过太多人打开引擎文档看到相机、光照、材质球、渲染管线半天时间就耗在配环境上跑酷游戏本身一行没动。所以第一步不是选工具是想清楚你要的3D到底是哪一种。1.1 三种3D的性价比对比市面上能被叫做 3D 跑酷的东西实现上其实分三档成本和效果差距非常大。假 3D2.5D所有画面元素还是二维的但通过越远越小、越远越靠中间的透视缩放伪造出纵深感。赛道就是一个梯形障碍物是几张会缩放的图。这种做法在 Scratch 里纯靠积木就能完成Python 里用 pygame 手写几十行投影代码也够性能压力极小。光线投射raycasting用一张二维地图数组从玩家位置向屏幕每一列打一条射线算撞墙距离来决定这一列画多高。上世纪那批第一人称迷宫游戏基本都是这套路子。它在 Scratch 里能做但要逐列计算克隆体和画笔的调用次数会瞬间爆掉掉帧很明显。引擎真 3D顶点变换、深度缓冲、光照全部交给引擎。画面质量最高但 Scratch 原生做不到Python 侧要靠 Ursina、Panda3D 这类库。实现路线核心做法Scratch 可行性Python 对应方案典型场景假 3D / 2.5D缩放加透视公式素材仍是平面高纯积木可完成pygame 手写投影跑酷、赛车、飞行射击光线投射地图数组加逐列射线求交中性能吃紧pygame 或 numpy 加速迷宫、室内探索引擎真 3D顶点、光照、深度由引擎处理低Ursina / Panda3D多角度、自由视角我选假 3D 作为主线不是因为简单而是因为它把3D 到底是怎么骗过眼睛的这件事完整地暴露在你面前。引擎真 3D 把数学全封装了你调的是参数假 3D 里那条k 焦距 / 深度的公式你得自己写、自己算、自己看着画面调学完之后再看引擎文档理解成本会低一个量级。1.2 从积木到代码真正要跨的是三个断层很多人以为 Scratch 转 Python 的难点在语法其实不是。语法三天就能背下来。真正的断层有三个第一个是数据组织方式。Scratch 里所有东西都是并列的列表——障碍X、障碍Z、障碍类型三条列表并排放用同一个索引串起来Python 里更自然的是{x: 0.0, z: 12.0, type: barrier}这样一个字典或者一个类实例。看起来只是形式差异实际影响很大列表方案在增删障碍时很容易出现三条列表长度不一致的脏数据而字典天然把同一实体的属性绑在一起。第二个是执行模型。Scratch 是事件驱动加协程当绿旗被点击当作为克隆体启动各跑各的Python 里没有这些东西你得自己写主循环一帧之内按顺序做完所有事。这一点在移植时要特别注意——Scratch 里每个克隆体自己动的写法到 Python 里会变成遍历障碍列表逐个更新。第三个是坐标系与单位。Scratch 舞台只有 480×360坐标范围 x∈[-240,240]、y∈[-180,180]Python 的窗口你可以自己定常见的 960×540 就是两倍关系。这意味着一整套常量需要换算我后面会给对照表。把这三个断层先想明白再动手整个过程会顺很多。2. 核心原理拆解不用引擎也能跑出立体感所有假 3D 的地基只有一条公式屏幕上的偏移量等于世界里的偏移量乘以焦距再除以深度。剩下的都是这条公式的包装。2.1 透视公式是怎么推出来的想象你站在两条平行铁轨正中间往远处看。近处的铁轨间距大远处的铁轨看起来越来越窄最后在地平线上交汇。这个近大远小的规律数学上就是反比关系。设焦距为FOCAL单位像素世界坐标里某个点到玩家横向的距离为dx这个点到玩家的深度为z那么它在屏幕上离画面中心的像素偏移就是屏幕偏移 FOCAL * dx / zFOCAL这个值决定了视场角——也就是你能看多宽。它和水平视场角hfov的关系是FOCAL (画面宽度 / 2) / tan(hfov / 2)我这边取FOCAL 260画面宽 960代进去算出hfov ≈ 123°。这个角度偏广角正常相机大概 60° 到 70°。但对跑酷来说广角恰恰是优点——边缘的赛道被拉伸速度感更强玩家能提前看到更远的障碍。我在实际调试中发现FOCAL从 260 调到 400视场角收窄到约 96°时画面会明显平整下来纵深感变弱跳跃的失重感也跟着减弱。所以这个值别轻易往上调。纵向的算法稍微绕一点。障碍物是站在地面上的地面在不同深度对应的屏幕高度需要单独算。我的做法是固定地平线的位置让地面线随深度收敛地面屏幕坐标 y 地平线 系数 / z其中系数等于地平线到底部的距离乘以近裁剪深度。这样当z等于近裁剪面时地面线正好落在画面底部z趋向无穷时地面线收敛到地平线。这是一条反比例曲线和真实透视是一致的。至于障碍物本身的高度直接用世界高度 × FOCAL / z就行——它和横向偏移用的是同一个缩放系数这也是为什么远处的物体会整体变小而不是被压扁。2.2 一套数值两个平台为了让 Scratch 和 Python 两侧的画面尽量一致我把所有常量做了按比例缩放。Scratch 舞台宽高是 480×360Python 窗口设 960×540横向正好是 2 倍关系。参数Scratch 取值Python 取值说明画面宽度480960横向 1:2 缩放地平线纵坐标y 29y 227屏幕坐标距顶部约 42%焦距130260视场角完全一致近裁剪深度0.60.6单位格远裁剪深度4040超过即回收地面系数125251由地平线位置推出车道世界坐标-1 / 0 / 1-1 / 0 / 1三条道间距 1 格有个坑我得提前说Scratch 舞台是 4:3Python 窗口我设成 16:9纵向比例不一样所以地面在 Scratch 里会显得更陡在 Python 里更平缓。这不是公式错了是画布宽高比不同导致的。你要是追求绝对一致把 Python 窗口设成 720×540纵向就对上了。我试过一次确实一致但 4:3 在现在的屏幕上看着别扭最后我还是回到了 16:9接受这点差异。2.3 雾化和图层顺序才是立体感的两块遮羞布公式算对了画面依然可能很平。真正让它看起来有深度的是两件事远处的物体变淡以及近处的物体挡住远处的。变淡这件事在 Scratch 里特别好办用亮度特效就行。做法是让亮度随深度线性变化亮度特效 -50 * (1 - 近裁剪深度 / 当前深度)深度等于近裁剪面时亮度是 0原色深度拉到远裁剪面时亮度接近 -48视觉上就是融进背景的暗色里。这里的 -50 别设太满我试过 -80远处的障碍直接黑成一团玩家根本看不出那是个障碍物游戏就没法玩了。除了亮度还可以配合虚像特效让极远端的物体稍微透明一点效果更柔和。图层顺序在 Scratch 里是个老大难。Python 侧简单把所有障碍按深度从大到小排个序依次绘制后画的自然盖住先画的。Scratch 没有这种按深度排序的原生能力——克隆体的图层顺序和它的创建顺序绑定一旦创建完就不好改了。我踩过的坑是两条车道上的障碍在深度上碰巧接近时会出现近的障碍被远的挡住这种穿模。后来的解决办法有两个一是把关卡生成时的深度间距拉到障碍物高度的 1.5 倍以上让重叠几乎不可能发生二是用克隆池加槽位重映射的进阶写法做真实排序代价是每帧多一轮循环。第二套方案我在第 3.2 节会单独讲。3. Scratch 版实操从零搭出一个能玩得下去的原型先明确目标三条车道、一条向前推进的通道、会从远处飞来的障碍、能左右换道和起跳的角色、撞到就结束。这个体量在 Scratch 里大概 200 到 300 块积木做熟了三个晚上能出原型。3.1 舞台准备与三个核心变量打开 Scratch删掉默认小猫换成你喜欢的角色用内置素材或者自己画都行。然后建这几条列表和变量列表障碍X、障碍Z分别存障碍的世界横向坐标和深度。列表障碍类型区分是路障还是矮墙还是金币。变量玩家X角色当前在世界坐标里的横向位置范围 -1 到 1对应三条车道。变量玩家Y跳跃时的高度落地为 0。变量竖直速度每帧的垂直位移量。变量速度跑道向前推进的速度单位是格/帧初始 0.12。变量k当前深度下的缩放系数每渲染一个障碍就重算一次。玩家X我建议不要直接用舞台坐标。舞台 x 从 -240 到 240而车道间距是 1 格如果直接用舞台坐标你得记住车道间距是 120 像素。用世界坐标就干净了玩家在中间车道就是 0左边车道就是 -1右边是 1。这就是数据抽象带来的好处Python 侧可以照搬这个约定。起跳的物理很朴素。按下空格时竖直速度设为 0.32 格/帧然后每一帧竖直速度减去 0.026重力加速度玩家Y加上竖直速度当玩家Y小于等于 0 时把玩家Y归零、竖直速度归零判定为落地状态。算一下这套参数的手感从 0.32 的初速度开始每帧减 0.026大约 12 帧后速度归零到达最高点最高高度约0.32²/(2×0.026) ≈ 1.97格滞空总时长约 24 帧。在 30 帧每秒的情况下是 0.8 秒滞空跳跃高度接近 2 格——比障碍物高度我设的 1.2 格高出一截跳过去的余量很舒服。刚开始我把初速度设成 0.2最高只有 0.77 格跳不过 1.2 格的障碍测试的时候一直撞墙排查了半天才发现是跳太低不是碰撞写错了。这里有个原则Scratch 的帧率不稳定所有物理量都按每帧来算不要试图按时间算。到了 Python 侧再改成按dt算这是移植时必须要改的一处。3.2 渲染用固定克隆池而不是动态克隆新手写渲染最直觉的做法是关卡里生成了一个障碍就创建一个克隆体跑过去之后删掉。这个写法在障碍少的时候没问题但 Scratch 的克隆体总数上限是 300跑酷游戏里障碍的生成频率很高一旦回收不及时会直接卡死。我的做法是固定克隆池开局创建 24 个克隆体每个克隆体认领一个槽位编号0 到 23之后再也不新建、不删除。每帧由本体把所有障碍按深度排好序然后把最近的那 24 个依次分配给这些槽位克隆体只负责读取自己槽位的障碍数据摆到对应位置。数据驱动画面克隆体数量恒定。这么做的好处是运行开销完全可预测24 个克隆体每帧只做一次坐标计算画面稳得住。Python 侧的对应思路叫对象池object pool你会发现在 pygame 里用pygame.sprite.Sprite预创建一批精灵、循环复用是完全一样的逻辑。这里就是两种环境在思路上真正对得上的地方。单个障碍的渲染脚本长这样当作为克隆体启动 把 [我的槽位 v] 设为 (槽位计数) 重复执行 如果 (我的槽位) (障碍数量) 那么 把 [深度 z v] 设为 (第 ((我的槽位) 1) 项 的 障碍Z) 把 [k v] 设为 (130 / (深度 z)) 把 [世界X v] 设为 (第 ((我的槽位) 1) 项 的 障碍X) 把 x 设为 (((世界X) - (玩家X)) * (k)) 把 y 设为 ((29) - ((125) / (深度 z)) ((玩家Y占位) * (k))) 把 [大小 v] 设为 ((1.2) * (k) / (某个基准)) 将大小设为 (大小) 将 [亮度 v] 特效设为 ((0) - ((50) * ((1) - ((0.6) / (深度 z))))) 显示 否则 隐藏这段里将大小设为那一步需要说明一下。Scratch 的大小是相对角色原始尺寸的百分比所以你得先量出角色图片在 100% 时有多少像素高再换算。假设原图是 60 像素高那么大小就等于世界高度 × k / 60 × 100。这个换算很容易出错我的习惯是在角色里加一个自制积木专门算这个参数化之后改起来方便。至于前面提到的真实深度排序进阶写法是本体维护一个序号表把障碍按深度从远到近排好然后循环里设好当前槽变量广播一条渲染本槽的消息。所有克隆体都收到这条消息但每个克隆体先检查我的槽位是不是等于当前槽只有相等的那一个才真正执行渲染并调用移到最前面。本体用广播并等待逐槽推进因为广播时当前槽已经被赋值所以实际执行的永远只有一个克隆体顺序完全可控。这套写法我在一个障碍密集的赛车里用过24 个障碍同屏帧率没掉。提醒一句不要用等待 0.01 秒来实现逐槽渲染那会把 24 个槽位摊到好几帧里画面会出现明显的抖动和撕裂。3.3 关卡生成永远给玩家留一条活路关卡生成看着简单实际上是最容易做崩的部分。我见过不少人的跑酷游戏有两种典型毛病要么三条车道同时被堵死玩家必死要么障碍物全挤在一条道上另外两条空得发慌。我的生成逻辑是这样的。维护一个生成指针表示下一个障碍要放在什么深度。每帧把生成指针减去速度因为它随着跑道一起向玩家逼近当它小于远裁剪深度 40 时就在这个深度生成一排障碍然后把指针重置成 40 加上一个随机间隔。生成一排障碍时先在三条车道里随机决定要堵几条——按经验堵 1 条的概率 55%堵 2 条的概率 45%绝不堵 3 条。堵 2 条时才需要玩家换道堵 1 条时玩家可以直接跳过去或者绕开难度曲线会自然形成梯度。间隔的随机范围我设的是 2.5 到 6 格最小值不能低于 2.5否则玩家的反应时间不够。按 0.12 格每帧的推进速度算2.5 格大约 21 帧也就是 0.7 秒这已经是human反应的极限了。定义 生成一排 把 [堵几条 v] 设为 (在 1 和 2 之间取随机数) 把 [已堵 v] 设为 0 把 [车道 1/2/3 v] 都设为 0 重复执行直到 (已堵) (堵几条) 把 [随机道 v] 设为 (在 1 和 3 之间取随机数) 如果 (第 (随机道) 项 的 车道) 0 那么 把 第 (随机道) 项 的 车道 设为 1 把 障碍X 添加 ((随机道) - 2) 把 障碍Z 添加 (40) 把 已堵 增加 1这套逻辑到 Python 里可以一行不改地翻译过去只是把三条变量换成列表而已。这正是我强调的两个环境共享同一套算法。3.4 碰撞判定与手感调参碰撞判定千万别用 Scratch 的碰到角色积木那是基于图片像素的矩形检测缩放之后判定框会跟着变远处的障碍判定框小到碰不到近处的又大到莫名其妙。正确的做法是纯数值判定玩家和障碍的横向距离小于阈值同时障碍的深度落在玩家的身体范围内就判定为撞上。如果 (绝对值((玩家X) - (障碍X))) (0.38) 并且 (障碍Z) (0.45) 并且 (障碍Z) ((0) - (0.25)) 那么 停止全部脚本这里的深度窗口是[-0.25, 0.45]宽度 0.7 格大致对应玩家身体的纵深。窗口偏大容易冤死偏小会穿模我调了三轮才定下来。横向阈值 0.38 也是个经验值车道间距是 1 格所以 0.38 意味着玩家偏离中心车道超过 38% 才会被判撞手感比较宽容。真要较真可以直接用 0.5判定会更严格。有一件事我必须提醒碰撞判定必须放在障碍更新之后、画面渲染之前。Scratch 里脚本执行顺序取决于角色列表的排列如果不注意会出现画面显示玩家已经躲过去了但判定用的是上一帧的位置这种鬼畜情况。我的做法是把所有逻辑都收进一个主控角色里用一个自制积木勾选运行时不刷新屏幕一口气把移动、生成、碰撞、渲染全跑完这样就完全不受角色执行顺序影响。这个运行时不刷新屏幕的勾选项是 Scratch 做复杂项目最重要的一把钥匙很多人做了半年都不知道。4. Python 版从移植到真正重构有了 Scratch 版打底Python 版就不需要重新设计玩法了直接搬。区别只在于工程结构、性能上限和画面质量。4.1 环境准备的顺序别搞反Python 版本我用 3.10 到 3.12 都测过没遇到兼容问题。安装的时候勾上Add Python to PATH这一步漏了后面命令行里敲python会提示找不到命令。虚拟环境我强烈建议加上不是为了显得专业是因为 pygame 和其他库的版本冲突真的很常见。项目文件夹里执行python -m venv .venv # Windows .venv\Scripts\activate # macOS / Linux source .venv/bin/activate pip install pygame2.5.2要跑真 3D 那条路线再补一个pip install ursina如果安装速度慢配置一下国内的 PyPI 镜像源能省不少时间。装完之后用pip list确认一下版本pygame 显示 2.5.x 就对了。在 VSCode 里的配置关键就一步CtrlShiftP打开命令面板选 Python: Select Interpreter选中项目里.venv目录下的那个解释器。选错解释器是最常见的坑表现是终端里import pygame正常但编辑器里全是黄色波浪线或者反过来。项目根目录再放一个requirements.txt把 pygame 的版本钉死换机器的时候pip install -r requirements.txt一把过。4.2 路线 Apygame 手写投影把 Scratch 公式搬过来先给投影函数。它和 Scratch 里那套算法是同源的只是把舞台坐标换成了屏幕坐标import pygame, random, math W, H 960, 540 HORIZON int(H * 0.42) # 地平线离顶部 42% FOCAL 260.0 # 焦距和 Scratch 的 130 是 1:2 关系 NEAR, FAR 0.6, 40.0 # 近远裁剪深度 C_GROUND (H - HORIZON) * NEAR # 地面线系数 LANES (-1.0, 0.0, 1.0) LANE_HALF 0.38 def project(wx, wy, z, player_x): 世界坐标 - 屏幕坐标。z 是深度越小越近。 z max(z, NEAR) k FOCAL / z # 当前深度下 1 格等于多少像素 sx W / 2 (wx - player_x) * k # 横向偏移除以深度实现透视 sy HORIZON C_GROUND / z - wy * k # 地面线收敛 跳跃高度 return sx, sy, k返回值里带上k是因为障碍物的绘制尺寸也要用它。这样避免在调用方重复算一遍除法。主循环的结构对应 Scratch 里那个运行时不刷新屏幕的自制积木def main(): pygame.init() screen pygame.display.set_mode((W, H)) clock pygame.time.Clock() font pygame.font.SysFont(arial, 28) player_x 0.0 # 当前车道连续值方便做平滑移动 player_y 0.0 # 跳跃高度 vy 0.0 # 垂直速度 speed 6.0 # 单位格/秒注意这里换成按秒算了 spawn_z FAR obstacles [] score 0.0 running True while running: dt clock.tick(60) / 1000.0 # 秒 for e in pygame.event.get(): if e.type pygame.QUIT: running False if e.type pygame.KEYDOWN and e.key pygame.K_SPACE: if player_y 1e-6: vy 5.6 # 起跳速度单位格/秒 keys pygame.key.get_pressed() if keys[pygame.K_LEFT]: player_x - 4.0 * dt if keys[pygame.K_RIGHT]: player_x 4.0 * dt player_x max(LANES[0], min(LANES[-1], player_x)) # 竖直方向的物理注意用 dt 而不是每帧 vy - 22.0 * dt player_y vy * dt if player_y 0: player_y, vy 0.0, 0.0 # 世界向前推进 for ob in obstacles: ob[z] - speed * dt obstacles [ob for ob in obstacles if ob[z] -1.0] ...起跳速度 5.6 格每秒、重力 22 格每平方秒这套参数算出来的最高点约5.6²/(2×22) ≈ 0.71 格——不够跳不过 1.2 格的障碍。得往上调。我最后用的是起跳 7.2、重力 18最高约 1.44 格滞空约 0.8 秒。你会发现这套数字和 Scratch 里的 0.32、0.026 是不同的因为一个是按帧、一个是按秒。移植时物理参数一定要重算直接抄数字必崩这是我踩过最实在的一个坑。障碍的绘制部分加上雾化def draw_obstacle(screen, ob, player_x, color): sx, sy, k project(ob[x], 0.0, ob[z], player_x) w 0.55 * k # 障碍世界宽 0.55 格 h 1.2 * k # 障碍世界高 1.2 格 # 雾化越远越接近背景色 t min(1.0, max(0.0, (ob[z] - NEAR) / (FAR - NEAR))) fog tuple(int(c (28 - c) * t) for c in color) pygame.draw.rect(screen, fog, (sx - w / 2, sy - h, w, h))fog那行是把障碍原本的颜色往背景色这里是 RGB 28 左右插值。用pygame.draw.rect画方块比加载图片快得多原型阶段完全够用。后期要换成图片把screen.blit的缩放尺寸设成(w, h)就行。最后是碰撞和 Scratch 里一模一样的数值判定def check_collision(obstacles, player_x, player_y): for ob in obstacles: if abs(ob[x] - player_x) LANE_HALF and -0.25 ob[z] 0.45: if player_y 1.2: # 跳得够高就不算撞 return True return False注意这里多了一行player_y 1.2。Scratch 版里我没有强调这点因为 Scratch 版的障碍高度和跳跃高度是配套调的到 Python 里因为物理参数重算了必须把这层判定补上否则玩家跳到最高点还是会被判定撞到路障。这个细节在真机上不测是发现不了的。4.3 路线 BUrsina 真 3D把数学交给引擎如果你想看看真 3D 长什么样Ursina 是最省事的入口。它的 API 设计几乎是把引擎概念翻译成英文单词上手很快。from ursina import * import random app Ursina() ground Entity(modelplane, scale(40, 1, 200), texturewhite_cube, texture_scale(40, 200), colorcolor.dark_gray, colliderbox) player Entity(modelcube, colorcolor.orange, scale(1, 1.6, 1), position(0, 0.8, 0)) camera.parent player camera.position (0, 2.6, -7) camera.rotation_x 12 speed 12 vy 0 lanes (-1.5, 0, 1.5) lane_index 1 obstacles [] def update(): global vy, lane_index, speed speed 0.35 * time.dt for ob in obstacles: ob.z - speed * time.dt obstacles[:] [ob for ob in obstacles if ob.z -8] target_x lanes[lane_index] player.x lerp(player.x, target_x, 10 * time.dt) vy - 30 * time.dt player.y vy * time.dt if player.y 0.8: player.y, vy 0.8, 0 if held_keys[a] and lane_index 0: lane_index - 1 if held_keys[d] and lane_index 2: lane_index 1 if held_keys[space] and player.y 0.81: vy 9.5 app.run()这段是骨架障碍生成和碰撞需要自己补。Ursina 把相机跟随、光照、深度测试全包了代价是你得理解 Entity、父级关系、坐标系这些概念。作为对比练习挺好但如果目标是讲清楚 3D 是怎么来的我还是更推荐 pygame 那条路线因为你能看见每一行投影计算的来龙去脉。4.4 打包、性能与资源管理pygame 项目打包用 PyInstallerpyinstaller --noconsole --onefile --name 3d-runner main.py有个必踩的坑打包成单文件后程序解压到临时目录运行代码里用相对路径读图片或字体会直接报错。标准解法是写一个资源路径函数import os, sys def res_path(rel): base getattr(sys, _MEIPASS, os.path.abspath(.)) return os.path.join(base, rel)之后所有pygame.image.load和pygame.font.Font都走这个函数问题就没了。我第一次打包的时候游戏在开发环境跑得好好的双击 exe 一片黑屏排查了四十分钟才发现是这个原因。性能方面pygame 的那个版本在 960×540 分辨率、同屏 20 个障碍的情况下帧率稳定在 60CPU 占用很低。真想压榨性能有两个方向把障碍绘制改成一次性渲染到 Surface 再 blit以及把不带透明通道的绘制换成pygame.draw的纯色块。至于 Scratch 版帧率瓶颈在克隆体数量和每帧的运算次数上只要把每帧的循环总数控制在 200 次以内一般不会掉帧。5. 常见问题与排查实录这部分是我和学生在两个环境里真真实实撞过的墙按侧分类列出来遇到问题的可以直接查。5.1 Scratch 侧的六个高频坑画面卡成一格一格。八成是每帧新建了克隆体。检查一下克隆自己是不是写在了重复执行里面。改用固定克隆池。远处的障碍看不见。亮度特效设太狠了或者大小算出来小于 2%。建议把亮度限制在 -50 以内并在大小低于 3% 时直接隐藏省下渲染开销。跳跃后落地判定失败。多半是浮点数精度问题玩家Y一直在 0.0001 附近震荡永远不满足等于 0。判定要写成小于或等于 0然后把玩家Y强制赋 0、竖直速度强制赋 0。三条道全被堵死。检查生成逻辑里已堵数量的循环终止条件常见写法错误是把判断写成随机道不等于已堵车道但忘了更新标记导致同一车道被重复计数。左右移动按一下动两格。这是事件重复触发或者把移动写在了当按下按键和主循环里各一次。统一收进主循环用按键是否按下的判断积木。克隆体消失后位置错乱。克隆体的位置是有记忆的隐藏后再显示可能停在上一次的位置。每次显示前必须把所有属性重新赋值一遍包括x、y、大小、亮度、虚像。5.2 Python 侧的典型故障现象大概率原因处理方式ModuleNotFoundError: pygame解释器选错装在了全局环境检查 VSCode 解释器确认是.venv里的那个窗口一闪就消失主循环外面没有事件处理或者running初始值写错确认while running里有pygame.event.get()障碍物移动速度忽快忽慢用了固定步长而不是dt所有位移量乘以clock.tick(60)/1000.0帧率掉到 30 以下每帧加载图片或者 Surface 转换没做图片在循环外加载加convert_alpha()跳跃高度不够必被撞物理参数从 Scratch 直接抄过来按秒重算起跳速度和重力打包后黑屏资源路径没走sys._MEIPASS加res_path()函数统一处理5.3 我在两个环境之间来回切换总结出的三条经验第一条算法先行实现后置。不要在 Scratch 里调好了画面才去想 Python 怎么移植先在一张纸上把投影公式、碰撞判定、生成规则写清楚两边都照着这张纸实现。我的习惯是先写 Python 版的数值版本跑得快改一行就能看结果参数定下来之后再按 1:2 的比例折算到 Scratch 里。这样比在 Scratch 里反复拖积木试参数快得多。第二条单位要写进注释里。speed 6.0到底是格每秒还是像素每帧一个月后你自己也记不住。我在所有涉及物理的变量后面都标了单位代码可读性提升非常明显尤其是当你在 Scratch帧驱动和 Python秒驱动之间来回看的时候。第三条别追求两个版本画面上完全一致。Scratch 的画布是 4:3Python 那边你多半会用 16:9纵向透视天生就对不齐。把精力放在玩法逻辑和参数手感的一致性上画面细节接受差异。我最后交付的两版玩家在 Scratch 里跳 2 格、在 Python 里跳 1.44 格数字不一样但滞空时间都在 0.8 秒左右玩起来的手感是一致的——这才是我真正想对齐的东西。顺带说一句延伸玩法想把跑酷角色从屏幕里拿出来可以用 Blender 按角色的比例建个简单模型导出 glTF 格式方便在网页端预览再导出 STL 就能送去 3D 打印。我给自己那版跑酷的主角打过一个 6 厘米高的摆件成本不到十块钱摆在桌上比任何奖状都直观。这一步和写代码没什么关系但它让整个项目有了一个实体的落点学生看到成品的时候那种我做的的感觉会强烈很多。
