企业官网建设流程全解析

跳一跳这类小游戏，玩法一句话就能说清：按住蓄力、松手起跳、落在下一个方块上。但真把源码摊开看，会发现它远比“按得久就跳得远”复杂——蓄力曲线、抛物线轨迹、落点判定、方块生成、相机跟随、打击反馈，这一整套东西组合起来才叫“手感”。我手上这份是早前做教学复刻时留下的一份小游戏工程，代码量不大，逻辑却很完整，非常适合拿来拆解。下文就基于这份模拟工程 X 的源码结构，把蓄力到距离的映射、抛物线飞行的实现、落点判定的边界处理、无限关卡的生成策略逐个拆开讲，同时给出可以照着写的参数和踩过的坑。适合两类人看：想搞懂这类小游戏底层逻辑的初学者，以及做过类似玩法但对“手感调参”一直没头绪的开发者。

1. 先把工程跑起来：目录结构与主循环骨架

拿到一份能跑的工程，别急着读业务代码。先看目录，再看主循环，最后才看具体玩法实现。这个顺序能省下大量时间，因为小游戏的绝大部分“诡异行为”都藏在主循环的时间处理里，而不是玩法逻辑里。

1.1 从入口文件看状态机的分层

这份工程的结构大致是这样的：

src/ index.js // 入口，初始化画布与资源加载 core/ loop.js // 主循环，固定步长 + 渲染插值 game.js // 游戏状态机 input.js // 按压输入归一化 entity/ player.js // 玩家，蓄力与飞行 block.js // 方块实体 system/ camera.js // 相机跟随 spawner.js // 方块生成与回收 judge.js // 落点判定 audio.js // 音效与连击 ui/ hud.js // 分数、提示

game.js里维护的是一个极简状态机：ready、charging、jumping、settling、dead。这五个状态划得很讲究——charging和jumping分开，是因为蓄力阶段玩家的输入要实时改变方块压缩比，而飞行阶段必须锁死输入；settling单独拉出来，是为了让落地后的压缩回弹动画跑完再接受下一次输入，否则连点会出现“起跳动画被下一跳打断”的穿模观感。

我特意数过，整个状态机不到 80 行，但每个状态的进入条件和退出条件写得很清楚。新手写这类游戏最容易犯的错是把“能不能跳”和“跳了没跳”混成一个布尔量，结果就是按住不放的时候角色反复起跳。

1.2 三个核心对象与它们的职责边界

player只管自己的蓄力值和轨迹参数，不关心落在哪；spawner只管造方块和回收方块，不关心玩家跳不跳得过去；judge只做一件事——拿到玩家落点的世界坐标和当前方块的坐标，返回一个判定结果枚举。这种切法的好处是调参时非常舒服：觉得跳太远，改player的映射常数；觉得方块间距离谱，改spawner的采样区间；觉得判定太宽松，改judge的阈值。三者互不影响。

反过来，如果你的判定逻辑写在player.js里，生成逻辑也写在player.js里，那这个工程基本就废了——因为你会发现在调手感的时候，改一个数字三个地方都变。

1.3 首次运行就踩的坑：时间步长与帧率解耦

主循环这一块，很多教学工程是这么写的：

// 错误示范：位移直接乘 deltaTime function frame(now) { const dt = (now - last) / 1000; last = now; player.x += player.speed * dt; requestAnimationFrame(frame); }

这段代码在 60Hz 屏幕上没问题，换到 120Hz 屏幕上，dt减半，如果speed是常量，位移速度其实是一致的——所以看起来好像没问题。真正的坑在蓄力：如果蓄力值按power += dt / maxPress累加，帧率越高累加次数越多但每次更小，理论上也一致。问题出在输入的采样粒度上——高刷屏上松手的时机精度更高，玩家在同样的操作感觉下，跳出的距离分布会明显不同。

这份工程的做法是固定步长累加器：

// 正确做法：固定 1/60 逻辑步长 + 渲染插值 const STEP = 1 / 60; let acc = 0; function frame(now) { let dt = (now - last) / 1000; last = now; dt = Math.min(dt, 0.1); // 关键：clamp，防止切后台回来一次性补几百帧 acc += dt; while (acc >= STEP) { update(STEP); // 逻辑永远按 1/60 推进 acc -= STEP; } render(acc / STEP); // alpha 用于插值渲染 }

Math.min(dt, 0.1)这一行是必须的。浏览器标签页切到后台时requestAnimationFrame会暂停，切回来那一帧的dt可能是几十秒，累加器一算就要跑几千个逻辑步，页面直接卡死，玩家回来发现自己已经死了。我第一次遇到这个问题时以为是内存泄漏，排查了半天。

提示：固定步长 + 插值渲染这套结构，不只是为了跨设备一致，更是为了让“回放”和“手感测试”变得可复现——同样的输入序列，逻辑结果永远相同。

2. 蓄力到距离：那行被抄了无数遍的换算公式

整个游戏最核心的一行逻辑，就是把“按了多久”翻译成“跳多远”。这行代码看起来简单，但里面的取舍和参数决定了游戏是“舒服”还是“别扭”。

2.1 按压时长、蓄力系数与跳跃距离的三段映射

工程里player.js的蓄力部分是这样的：

const MAX_PRESS = 1.0; // 秒，满蓄力所需时长 const MIN_DIST = 0.55; // 单位：方块宽（unit） const MAX_DIST = 3.10; function updateCharge(dt) { this.pressTime = Math.min(this.pressTime + dt, MAX_PRESS); const raw = this.pressTime / MAX_PRESS; // 0 ~ 1 线性 const p = Math.pow(raw, 1.15); // 轻微压缩前段 this.power = p; this.jumpDistance = MIN_DIST + p * (MAX_DIST - MIN_DIST); }

Math.pow(raw, 1.15)这个指数值得说一下。指数大于 1，意味着前段蓄力增长更慢、后段更快。为什么这么设计？因为真实的操作里，玩家长按到接近满蓄力的时间占比很高，如果完全线性，那么“差一点点”和“差很多”在距离上的表现几乎一样，玩家会觉得缺乏控制感。加一点指数压缩后，中段的距离变化更平缓，玩家在中间区间的微调精度更高——这就是所谓的“手感”。

三个参数之间的关系是有约束的：MAX_DIST必须大于生成器可能产生的最大方块间距，否则会出现玩家蓄满力也跳不过去的情况。这一点在第 4 章还会展开。

2.2 为什么用线性映射而不是真实物理的加速度积分

有人会问：现实里用力跳，应该是加速度积分，距离和时间的平方相关，为什么不干脆用物理引擎算？

答案很直接：游戏要的是可控，不是真实。如果按d = 0.5 * a * t²来算，蓄力时间翻倍，距离变四倍，这会带来两个问题：一是难度曲线完全失控，玩家很难建立稳定预期；二是可跳范围两端都会变得极端——要么根本跳不动，要么一按就飞出屏幕。线性映射（或者说带轻微缓动的伪线性）让“按久一点就远一点”这个直觉成立，玩家可以在几十次尝试内建立起相当精确的手感。

这也是这类轻量小游戏普遍不引入物理引擎的原因。一个完整的刚体物理库要处理质量、摩擦、碰撞检测、休眠，一套下来代码量翻十倍，而这些在“一跳一个方块”的场景里全是负担。

2.3 手感调参：把公式里的常数换成手感刻度

调参的时候不要对着数字瞎试，而是把它翻译成“手感语言”。我整理了一张对照表，改参数的时候先问自己想改什么感觉：

这张表是我在反复调了十几轮之后总结的。有个反直觉的点：很多人第一反应是把MAX_PRESS调小来让游戏“更刺激”，结果发现难度暴增，因为玩家根本没有足够的反应时间来形成肌肉记忆。短按时长和操作精度之间是个取舍，不是越短越好。

注意：MIN_DIST不建议低于方块宽度的 0.5 倍。低于这个值，短按和极短按的距离差会小到玩家分辨不出来，容易出现“我明明点了却没跳出去”的错觉。

3. 抛物线飞行与落点判定：判定盒比模型更关键

飞行动画是玩家看得最久的部分，但真正决定游戏体验好坏的，是飞行动画结束那一刻的判定。这两块在工程里分属player和judge，我分开讲。

3.1 用二次函数算轨迹，而不是用刚体物理

飞行段的实现只有几行：

startJump() { const d = this.jumpDistance; this.flightT = 0.30 + 0.055 * d; // 距离越远，飞得越久 this.arcH = 0.85 + 0.22 * d; // 弧顶高度随距离增加 this.from = { x: this.x, y: this.y }; this.to = { x: this.x + d, y: this.y }; // 本工程为横向跳跃 } updateFlight(dt) { this.flightT0 += dt; const t = Math.min(this.flightT0 / this.flightT, 1); this.x = lerp(this.from.x, this.to.x, t); // 水平匀速 this.y = this.from.y - this.arcH * 4 * t * (1 - t); // 抛物弧 this.rotation += this.spinSpeed * dt; // 空中翻转 }

4 * t * (1 - t)这个写法值得记下来。它是一条标准的抛物线，t=0和t=1时值为 0，t=0.5时值为 1，所以乘上arcH就是最高点。用它替代sin(πt)的好处是计算便宜，而且顶点在中点，视觉上更符合“跳起来”的直觉（真实的抛体运动顶点其实也在中点，因为水平匀速）。

水平方向用lerp匀速，是不真实但好用的选择。真按抛体算，水平也是匀速的，所以这里其实并不失真——失真的是“蓄力时间→初速度”那段映射，我们把它变成了直接指定距离。

3.2 落点判定的三个圆圈：中心、有效、失败

判定逻辑的完整代码如下：

const JUDGE_CENTER = 0.14; // 单位：方块宽，完美区半径 const JUDGE_EDGE = 0.50; // 有效区半径（等于半宽） function judge(landX, blockCenterX) { const dx = Math.abs(landX - blockCenterX); if (dx <= JUDGE_CENTER) return 'perfect'; if (dx <= JUDGE_EDGE) return 'ok'; return 'fail'; }

三个区间的含义很直白，但有一个细节常被忽略：JUDGE_EDGE严格等于方块半宽时，意味着玩家落在边缘的那一个像素都算成功。视觉上玩家会觉得“我半个身子悬在外面了怎么还算过了”，所以很多实现会把有效区稍微收一点，比如0.46，让判定比视觉更严格，玩家会觉得这游戏“实在”。这份工程取的是0.5，属于宽松路线。

我用一张表把判定区间和对应的表现整理清楚：

3.3 边缘落点与“半悬空”的处理争议

这里有个挺典型的取舍：判定到底该用中心点，还是用两个包围盒求交？

用中心点判定，实现简单，但玩家会觉得“明明脚踩上去了还是掉下来了”。用包围盒相交判定，视觉上更宽容，但对距离的敏感性会下降——偏差到 0.7 倍方块宽时，两个盒子还重叠着，玩家感觉不到临近失败的危险。这份工程选了中心点方案，是因为它和“完美区加分”这套机制配合更自然：玩家的目标从一开始就是瞄准中心，而不是“踩上去就行”。

真正麻烦的是失败动画。玩家没跳中时，角色要往下掉，这个下坠过程必须和相机动起来配合：镜头要轻微下移跟随一小段，然后停住，角色继续掉出画面，再淡出重开。这个时序如果做糙了，会出现角色掉下去了但镜头还停在半空、背景方块依然排列的诡异画面。工程里的做法是给失败状态单独一条时间轴，dead状态下不再处理输入，只推进动画计时器。

提示：失败动画的时长建议控制在 0.8~1.2 秒。短了玩家看不清自己是怎么死的，长了会不耐烦想直接重开。

4. 方块生成、回收与相机运动：无限关卡的障眼法

玩家眼里这个游戏是“一直往前跳”，开发者眼里它是“一列固定数量的方块在移动”。这个转换是整个工程里最有意思的地方。

4.1 随机距离区间的设计与难度曲线

spawner.js的核心是一个采样函数：

function nextGap(score) { const diff = clamp(score / 45, 0, 1); // 0 到 1 const minD = lerp(0.88, 0.62, diff); // 最近间距收紧 const maxD = lerp(1.52, 1.86, diff); // 最远间距放宽 const r = Math.random(); // 用平方偏置，让大部分间距落在偏小一侧，偶尔来个大的 const biased = minD + (maxD - minD) * (r * r); return clamp(biased, 0.60, MAX_DIST * 0.94); // 硬约束：必须跳得到 }

三件事值得展开。

第一，r * r是个廉价但有效的偏置。r在 [0,1] 均匀分布，平方之后大部分值集中在 0 附近，也就是小间距出现得更频繁，大间距变得稀有。这符合玩家的心理预期：连续几个容易的，偶尔来一个需要满蓄力的，节奏有起伏。如果改成均匀分布，玩起来会觉得很“平”，没有记忆点。

第二，难度是按分数螺旋推进的。分数涨到 45 分左右时难度封顶，minD从 0.88 收到 0.62，玩家必须更精确地控制短按；maxD从 1.52 放到 1.86，需要接近满蓄力。两端的区间同时收窄，但可跳范围没变，等于把难度压进了精度要求里。

第三，那行clamp(biased, 0.60, MAX_DIST * 0.94)是保命的。MAX_DIST是 3.10，乘 0.94 得 2.91，意味着任何生成的间距都不会超过这个值。为什么要留 6% 的余量？因为玩家实际能跳到的距离，除了MAX_DIST，还受蓄力采样精度影响——理论上限不等于必达上限。留余量是给“差一点点”留活路。

4.2 对象池与相机平移的相对坐标系

方块的数量永远是有限的。工程里维护了 9 个方块实例，循环复用：

function recycle() { const camLeft = camera.x - viewW * 0.2; for (const b of blocks) { if (b.x + b.w < camLeft) { b.resetTo(lastBlock.x + lastBlock.w + nextGap(score)); // 关键：重置时同时清空视觉状态 b.squash = 1; b.flash = 0; b.highlight = false; lastBlock = b; } } }

resetTo里的三行清理是最容易漏的。如果只改坐标不重置squash（压扁系数），回收再出现的方块会带着上一次被踩扁的样子飘回来，看起来像渲染层级出错了。我第一次遇到这个现象时以为是把同一个对象加进了渲染队列两次。

坐标系统这块，工程采用的是“世界坐标不动，相机移动”的方案。玩家和方块都用世界坐标做逻辑，渲染时统一减掉camera.x。另一种解法是“相机不动，所有物体左移”，写起来简单，但只要物体数量一多，每次更新都要遍历全场改坐标，而且浮点数累积误差会让远处的方块慢慢“漂”。用相机偏移就没有这个问题。

4.3 相机跟随的平滑插值参数

相机跟随的代码只有三行，但参数选错了会导致眩晕或者迟钝：

const target = player.x - viewW * 0.32; // 玩家保持在屏幕偏左 32% 处 function updateCamera(dt) { const k = 1 - Math.pow(1 - 0.10, dt * 60); // 帧率无关的插值系数 camera.x += (target - camera.x) * k; }

1 - Math.pow(1 - 0.10, dt * 60)这个写法必须记住。如果直接写camera.x += (target - camera.x) * 0.1，那么帧率 120Hz 时相机会比 60Hz 时快一倍，不同设备上的跟随手感完全不同。用幂函数把系数换算成“每秒 60 次、每次 10%”，就跟帧率彻底解耦了。

0.10这个值本身代表跟随的“软硬”。调到 0.3，相机几乎贴着玩家走，跳跃时整个画面跟着晃，容易晕；调到 0.03，相机会明显滞后，玩家跳到远处时角色跑到屏幕边缘去了才开始追，观感很拖沓。0.08 到 0.12 是舒服的区间。

5. 分数、动画与反馈：让“跳”这件事有手感

前面四章解决的是“跳得对不对”，这一章解决的是“跳得爽不爽”。这两件事在玩家侧是同一个东西，在代码侧是两套系统。

5.1 命中中心的连续加分与音效递进

连击机制的设计很简单：连续命中完美区，加成递增；一旦落在有效区但非中心，连击清零。

function onLand(result) { if (result === 'perfect') { combo += 1; const bonus = Math.min(combo, 8) * 2; // 封顶 16 分 score += 1 + bonus; audio.play('perfect', combo); // 音高随 combo 提升 particle.burst(player.x, player.y); } else if (result === 'ok') { combo = 0; score += 1; audio.play('land'); } }

音效递进用的是同一个音频文件播放时提高playbackRate，而不是准备一堆音频素材。playbackRate = 1 + Math.min(combo, 8) * 0.06，连击越高音调越尖，这个低成本的做法效果出奇地好——玩家会下意识地追求那个“越来越高的调子”。封顶很重要，不封顶的话音高会飞出人耳舒适区，听起来像故障。

分数封顶也有讲究。Math.min(combo, 8) * 2意味着最高单次 16 分，配合每秒一次的跳跃节奏，不会出现分数爆炸式的通胀。如果加成不封顶，一个技术好的玩家连续命中 20 次，单次分数就接近 40 分，后面所有难度曲线全废了。

5.2 压缩-回弹的缓动曲线

落地的那一下“压扁再弹回”，是这类游戏最关键的观感细节。工程里的实现：

// 落地瞬间 block.squash = 0.78; // 压到 78% player.vy = 0; // 触发回弹动画 function updateSquash(dt) { const t = Math.min((now - squashStart) / 0.22, 1); // 220ms const e = 1 - Math.pow(1 - t, 3); // easeOutCubic block.squash = lerp(0.78, 1.0, e); }

0.22秒、easeOutCubic、压缩到 0.78——这三个数是试出来的。压缩幅度再大一点（比如 0.65）会显得方块像橡皮泥，失去“站得稳”的感觉；再小一点（0.9）玩家几乎察觉不到。回弹时长超过 0.35 秒，节奏就拖了，尤其是在连续快速跳跃时，上一个方块还在弹，玩家已经跳到下一个了。

蓄力阶段的压缩是另一套：按住时方块纵向缓慢压到1 - 0.18 * power，同时横向略微拉伸到1 + 0.06 * power。这个“压扁”不只是美观，它是唯一的蓄力反馈——玩家没有进度条可看，全靠方块被压下去多少来判断还有多久到满力。所以这个映射必须是单调的、可感知的。

5.3 落地反馈的时序表

把一次完整的跳跃拆成时间轴，能看清哪些事情必须串行、哪些可以并行：

settle阶段锁定输入，是很多复刻作品翻车的地方。如果不锁，玩家在回弹动画期间按下，会出现“新一次蓄力叠加在动画上”的情况，方块一边回弹一边被压扁，视觉上会抖一下。这一下抖动很小，但玩久了会明显感觉“这游戏有点飘”。

注意：锁定不代表要忽略输入。工程里在settle期间会记录一次按下事件，如果玩家在锁定窗口内按下了，settle结束的瞬间立刻进入charging，这样快速连跳时不会有“我按了但没反应”的空档。这个细节叫输入缓冲，值得抄。

6. 复刻实操：从零把核心玩法搭起来的最小清单

看懂和写出来是两回事。这一章是我复刻时的实际操作顺序，按这个顺序走，每一步都有能跑起来的东西，不会写到一半发现自己卡在某个环节。

6.1 六步落地顺序

第一步，画布与主循环。先把固定步长 + 渲染插值这套骨架搭好，屏幕上跑一个匀速移动的方块，确认帧率无关性。这一步不做完，后面所有东西都建立在不稳的地基上。

第二步，按压输入。只做两件事：按下记录时间戳，松开算时长。屏幕上把时长数值打出来，人肉测试一下手感。

第三步，蓄力映射 + 一次跳跃。把第 2 章的公式抄进去，让方块能从一个位置跳到“距离等于映射结果”的位置，弧线先用最简单的抛物线。这一步做完，游戏的核心已经成立了。

第四步，方块生成与回收。加入采样函数和对象池，让画面能无限往前滚。这里的关键是先把相机固定，只测生成逻辑对不对。

第五步，判定与状态机。把perfect/ok/fail三条路走通，加上失败动画和重开。

第六步，反馈层。压扁回弹、音效、粒子、连击。这一步纯体验优化，可以在核心玩法稳定后慢慢加。

这个顺序的价值在于：每一步都有可验证的产出，出问题时能快速定位在哪一层。我见过不少人是先把 UI、粒子、音效全搭好，最后发现跳跃距离的映射常数和生成器对不上，回头改要牵动一大片。

6.2 本地存档与数据校验的简单做法

小游戏要存最高分，最省事的做法是localStorage.setItem('best', score)。但如果你想让成绩稍微可靠一点，可以加一层轻量校验：

function saveScore(score, jumps) { const sig = (score * 31 + jumps * 17) % 100003; localStorage.setItem('rec', JSON.stringify({ score, jumps, sig })); } function loadScore() { try { const rec = JSON.parse(localStorage.getItem('rec')); if (!rec) return 0; if ((rec.score * 31 + rec.jumps * 17) % 100003 !== rec.sig) return 0; return rec.score; } catch (e) { return 0; } }

这不是加密，只是一种“防止手改数字改得太随意”的手段——改分数不改签名，读出来就归零了。真正的反作弊要靠服务端，但一个单机小游戏搞服务端验证，成本收益不划算。另外可以加一条合理性检查：如果score / jumps远高于理论上限（比如每次跳跃最多 17 分），就判定数据异常。这个上限的计算方式在 5.1 里已经给出来了。

6.3 我在复刻过程中踩的四个坑

坑一：120Hz 手机上跳得更远。最早我用的是“每帧power += 0.016”的写法，60Hz 下满蓄力需要 62 帧约 1 秒，120Hz 下同样的 62 帧只需要 0.5 秒。玩家在低刷屏上练出来的手感，换机就废了。修法是改成按dt累加，并且把逻辑放进固定步长循环里。

坑二：相机滚动后判定全部偏移。判定时我用了屏幕坐标去和世界坐标比，结果相机一移动，所有判定都偏了camera.x。这个 bug 的表现很有意思：刚开始几分能正常判定，跳得越远越离谱。修法是把所有逻辑统一到世界坐标系，渲染层才做减法。

坑三：对象池回收后状态残留。前面提过，squash没重置，被踩扁的方块复活后还是扁的。这个坑的隐蔽之处在于它是概率性出现的——只有被踩过的方块被回收时才会触发，测试的时候十次里可能只出现一次。

坑四：随机间距生成出“必死局”。有一次采样出了 3.4 的间距，而MAX_DIST是 3.10，玩家蓄满力也过不去，游戏没法继续。这个坑的教训是：随机一定要有硬约束，不能指望概率分布天然落在安全区间里。修法是加clamp，并且这个上限必须是“留了余量的实际上限”，而不是理论值。

7. 从这份源码里真正值得带走的东西

拆完这份工程，最大的收获不是“知道跳一跳怎么实现的”，而是几个可以搬到别处去的模式。

输入驱动的数值映射，永远是先定手感再定公式。不要一开始就去推导物理模型，先用最粗糙的线性映射跑起来，然后不断问自己“这个手感哪里不对”，再回头改映射的曲线形状。物理正确在游戏里不是目标，可预期才是。

任何随机都要有硬边界。生成间距、掉落位置、敌人刷新点，只要有一项随机超出了系统能承受的范围，就会出现无法继续的局面。把约束写在采样函数的出口处，是最省事的保险。

所有与帧率相关的插值，都要做帧率无关化。1 - Math.pow(1 - k, dt * 60)这个公式我用在了相机跟随、UI 淡入、颜色渐变上，效果都很好。记住它，能省下大量“为什么换个屏幕就不对”的排查时间。

状态机比布尔量可靠。什么时候能接受输入、什么时候要缓冲输入、什么时候必须忽略输入，这三个问题用布尔量是回答不了的，用状态机就能一句话说清楚。

如果还想往下挖，有两个方向值得看：一是把这套逻辑改成纵向跳跃或者斜向跳跃，看看坐标变换要动多少地方（答案是比想象中少，因为核心的距离映射和判定逻辑完全不依赖方向）；二是给判定加入“落点回显”，在跳跃结束时画一个半透明的落点标记，用来观察蓄力映射的精度分布——这个调试工具帮我定位过两次映射参数写错的问题。