上周我在 GitHub 上翻开源小游戏本来想找一个 Canvas 的练手项目参考结果被一个叫“保持平衡”的 HTMLJSCSS 小游戏给黏住了。玩法一句话就能讲完一根横杆、一个小球你控制横杆左右倾斜的角度让球始终待在杆上不掉下去。听起来毫无门槛玩起来手心冒汗。我把项目拉下来跑通后又拆开重写了一遍才发现这个看似简单的小游戏其实把物理模拟、实时输入、Canvas 渲染、CSS 样式和移动端适配全串起来了。这篇文章就把整个开发过程完整拆开讲讲怎么用纯前端技术做出一款挑战控制力的物理平衡挑战游戏。1. 一个“保持平衡”玩法为什么让人一玩就停不下来1.1 极简规则背后的高频反馈机制“保持平衡”这类游戏的核心设计与大多数闯关游戏不同它没有敌人、没有关卡跳转、没有收集品所有乐趣都来自一个极短的操作反馈回路Game Feel 里常说的 tight loop你按一下方向键横杆立刻倾斜球马上有了加速度你必须在几百毫秒内反向修正否则球就滚向边缘。这种“输入→反馈→修正→再输入”的循环以每秒几十次的频率不断发生玩家的注意力始终被压在当下根本无暇分心于是很容易进入心流状态。从心理学角度看这类游戏还利用了人类的“手动追踪”本能。大脑会不自觉地不断预测球的运动轨迹然后通过手指或者鼠标把修正动作发射出去。你每次成功救回小球大脑都会给一点小小的正反馈每次失败几乎都只差那么一点于是你会下意识地点“再来一局”。这种“差一点就能成功”的挫败感与成就感交织是最容易让人上瘾的设计。我在实际测试中也有明确感受前 3 秒轻松第 10 秒开始紧张第 20 秒手心出汗第 30 秒屏住呼吸。整个过程中大脑的专注度是持续拉满的这就是好物理小游戏该有的状态。1.2 这个开源项目具体实现了什么我参考的这版开源项目由一个 HTML 文件、一个 CSS 文件和一个 JS 文件组成。没有任何第三方依赖也没有构建流程浏览器直接打开 index.html 就能玩。它把几个关键技术点完整展示了出来游戏主循环怎么拆解成 update更新物理状态和 render绘制画面两半怎么用 Canvas 绘制横杆、小球和边界背景怎么把键盘、鼠标、触摸屏三种输入源统一映射成同一个“目标角度”怎么用极简的几行物理积分公式表达“重力沿斜面分量”和“滚动阻尼”。我觉得它非常适合作为前端入门者研究第一个游戏项目的模板因为它足够小所有代码读完不超过 400 行但又足够完整能让你体验到从零到一开发一个小游戏的全过程。对已经会写页面、但没接触过游戏循环的人来说这个项目是一个性价比极高的上手案例。2. 核心物理模型一条公式讲清“倾倒”与“滚动”的本质2.1 从真实跷跷板到二维平面模型在写任何代码之前先把现实中的跷跷板抽象成一个适合浏览器模拟的二维模型。把横杆看成一条线段支点固定在 Canvas 正中央球抽象成一个只沿杆方向运动的小圆。这里需要定义四个核心状态变量变量含义初始值rodAngle横杆当前倾斜角度弧度0targetAngle玩家希望横杆达到的目标角度0ballPos球在杆上的相对位置0 为正中0ballVel球沿杆方向的速度0rodAngle 和 ballPos 是渲染时用到的真实状态targetAngle 则是一个中间量。之所以要区分“当前角度”和“目标角度”是因为现实中横杆不可能瞬间倾斜到玩家指定的角度它需要一个过渡过程否则物理反馈会变得极其生硬。接下来把横杆长度的一半设为常量 ROD_HALF_LENGTH当 ballPos 的绝对值超过这个值就表示球滚出了杆端触发掉落。整个模型的世界就这么简单真正复杂的部分在于角度和球的加速度之间到底是什么关系。2.2 重力分量、阻尼与速度积分先回忆一下高中力学当一个物体放在倾角为 θ 的斜面上时重力沿斜面方向的分量是 m * g * sin(θ)。质量 m 在计算加速度时会约掉所以加速度 a g * sin(θ)。放到这个游戏里g 不再是 9.8 m/s²而是换算成了屏幕上的像素单位我调参后定为 800。球的加速度还受阻力影响。如果没有阻力球会像在真空管里一样不断加速玩家永远不可能把它停在中间。我在模型里加了一个与速度成正比的阻尼项const accel GRAVITY * Math.sin(state.rodAngle) - DAMPING * state.ballVel;GRAVITY 是重力加速度常数DAMPING 是阻尼系数。这一步至关重要它决定了球滚起来之后会不会慢慢“泄力”。阻尼相当于滚动摩擦和空气阻力的综合效果。DAMPING 越大球越容易停下来但也不容易滚向边缘游戏会显得软绵绵DAMPING 太小球又像抹了油一样滑极难控制。拿到加速度后用最简单的欧拉积分来更新速度和位置state.ballVel accel * dt; state.ballPos state.ballVel * dt;其中 dt 是上一帧到这一帧的时间差单位是秒。欧拉积分虽然没有物理引擎中的 RK4 精度高但在这个自由度极低的系统里已经足够。关键是 dt 一定要取真实的帧间隔而不是固定写死 1/60这一点在第四章专门讲。我实测下来这组参数的手感是横杆总长约 560 像素球在全力倾斜时大约 0.8 秒内从中心滚到边缘给玩家留下了约 1.5 秒的反应窗口既有紧迫感又不至于完全反应不过来。你可以把它理解成“每次错误操作都还有一次补救机会”的难度曲线。2.3 为什么这种小游戏不需要物理引擎很多人看到“物理”两个字第一反应是上 Matter.js、Planck.js 这类库。我在初学阶段也踩过这个误区。但冷静分析一下这个游戏只有一个自由度球沿杆方向的位置横杆角度也是由玩家直接控制的不需要碰撞体之间的复杂交互更不需要刚体旋转、关节约束、材料摩擦系数这些引擎特性。用物理引擎反而要处理引擎的坐标系、碰撞回调、甚至引擎自身的性能开销完全是杀鸡用牛刀。自研物理模型最大的好处是可以精确掌控每一个参数背后的手感。比如我可以明确知道“DAMPING 设成 1.8 时球从边缘回滚的减速曲线长什么样”而如果用了物理引擎这些参数会被封装在一堆物体属性和材质配置里调试起来反而更绕。我在重写过程中把物理更新函数保持得极其干净只做“角度插值 加速度计算 速度位置积分 边界判断”四件事。后面不管加分数、加关卡、加粒子特效都不会污染这段核心逻辑。这也是小游戏项目一个非常重要的架构原则物理模型和表现层分离。3. 项目文件结构与三个语言的分工3.1 HTML 骨架给游戏一个容器HTML 文件承担的责任很轻但结构必须清晰。我的 index.html 核心部分大概长这样div idapp canvas idgameCanvas width800 height600/canvas div idhud span idtimeLabel0.0s/span /div button idstartBtn开始游戏/button /div script srcgame.js/script这里有几个容易被忽略的点。Canvas 的 width 和 height 属性是画布的实际像素尺寸CSS 里设置的宽高只是缩放后的展示尺寸两者不一致会导致画面模糊所以我直接让它们保持一致。其次把 HUD 和按钮放在 canvas 外面用普通 DOM 渲染这样省去在 Canvas 里绘制文字的麻烦CSS 控制样式也更方便。脚本标签放在 body 末尾而不是 head 里确保 DOM 结构先加载完game.js 在初始化时能直接拿到 canvas 元素不需要额外监听 DOMContentLoaded 事件。这是很多新手容易踩的坑脚本放 head 里document.getElementById 拿到 null程序直接报错。3.2 CSS 视觉设计让平衡状态“看得见”CSS 在这个游戏里的作用不只是美化它还能承担一部分“信息层级”的传达。我把页面背景做成中性的深灰色让视线集中在画布中央HUD 使用少量半透明背景避免遮挡游戏区域。真正有意思的是给“启动状态”做视觉反馈。初始状态下 HUD 的提示文字是暗的鼠标移入画布区域时通过 :hover 加上高亮效果可以让玩家感知到“这里是可以操作的”。我还用了一个很轻的过渡动画canvas { cursor: crosshair; transition: box-shadow 0.2s ease; } canvas:hover { box-shadow: 0 0 30px rgba(255, 255, 255, 0.1); }cursor: crosshair 很重要它暗示玩家这里需要精确瞄准和操作比默认箭头好很多。不过我需要提醒CSS 过渡动画不要加在游戏内实时变化的状态上因为 CSS 动画每帧触发的合成开销在低端设备上会影响帧率。所有高频变化的视觉元素比如球的位置、横杆的倾斜都必须在 Canvas 里每帧重绘CSS 只负责静态容器和低频状态。3.3 JS 状态与渲染解耦game.js 是整个游戏的核心我把它分成三个相对独立的部分状态对象、更新函数、渲染函数。state 对象集中存放所有可变数据const state { rodAngle: 0, targetAngle: 0, ballPos: 0, ballVel: 0, isRunning: false, lastTimestamp: 0, elapsed: 0, };update(dt) 只负责根据输入和物理模型修改 state 中的值render(ctx) 只负责读取 state 并绘制到 Canvas。这样做的最大好处是可以直接在浏览器控制台修改 state 来调试。比如我怀疑球的初始位置不对就在控制台手动执行 state.ballPos -100然后立刻能看到渲染结果完全不需要刷新页面。这种架构还有一个隐藏好处后续如果要给游戏加 AI 自动平衡、回放功能或者联机同步只要把 state 序列化即可渲染层完全没有感知。4. 渲染循环与交互控制的实现细节4.1 requestAnimationFrame 与帧率无关的物理游戏循环是每帧执行一次 update 和 render 的过程。前端最标准的方式是用 requestAnimationFramefunction loop(timestamp) { const dt Math.min((timestamp - state.lastTimestamp) / 1000, 0.05); state.lastTimestamp timestamp; if (state.isRunning) { update(dt); render(ctx); } requestAnimationFrame(loop); } requestAnimationFrame(loop);这个 dt 是“帧率无关物理”的关键。在 60Hz 屏幕上dt 大约是 0.0167 秒在 120Hz 屏幕上dt 大约是 0.0083 秒。如果不把 dt 传进 update而是假设每帧固定 1/60 秒那同样的球会在高刷屏上跑得快一倍物理速度就乱套了。Math.min(timestamp - lastTimestamp, 50) 这行是我加的防护。当浏览器标签页切到后台再切回来时timestamp 的差值可能非常大球会在恢复的第一帧跨越几秒的物理距离直接飞出边界。截断成最大 50 毫秒就能避免这种“闪现瞬移”的尴尬。4.2 键盘、鼠标与触摸屏的统一输入映射无论玩家用什么方式输入最终都只做一件事设置 state.targetAngle。键盘方案是按下左右方向键时让目标角度向对应方向持续增加并限制在最大角度范围内const KEY_STEP 0.002; if (keys.left) state.targetAngle Math.max(state.targetAngle - KEY_STEP, -ANGLE_LIMIT); if (keys.right) state.targetAngle Math.min(state.targetAngle KEY_STEP, ANGLE_LIMIT);鼠标方案更直接把鼠标 X 坐标与屏幕中心线的偏移量映射到目标角度const offsetX mouseX - centerX; state.targetAngle (offsetX / (window.innerWidth / 2)) * ANGLE_LIMIT;触摸屏方案和鼠标几乎一样只是把 touchmove 事件中的触摸点坐标当成 mouseX。这三种方案的统一接口一旦建立后面想支持手柄、体感甚至语音控制都只是新增一个输入源的问题。目标角度设定完之后横杆本身不能瞬间到位需要用插值让它物理“缓动”过去state.rodAngle (state.targetAngle - state.rodAngle) * Math.min(1, LERP_SPEED * dt);LERP_SPEED 我设为 12这个值直接决定横杆的反应速度。设得太小横杆像在水里一样慢玩家会感觉指令延迟感强设得太大横杆反应过快小球会频繁获得大幅度加速度控制难度陡增。12 是我在键鼠输入下试出来的折中值移动端触屏可以适当降到 8因为手指的移动本身已经比鼠标更细腻。4.3 手感调优的参数组合笔记我整理了一张调试记录表这里面每一组参数都会直接影响游戏体验参数范围手感影响GRAVITY600 ~ 1000值越大球加速越快游戏越难值越小手感越飘DAMPING0.5 ~ 3.0值越大球越容易静止但挑战性下降ANGLE_LIMIT0.3 ~ 0.8 弧度限制横杆最大倾斜角度等于限制球的最大加速度LERP_SPEED6 ~ 20横杆响应速度影响操作跟手程度ROD_HALF_LENGTH200 ~ 350杆越长玩家可用空间越大游戏相对越容易这几项参数是强耦合的不能孤立地调某一个。我给的顺序建议是先定 ROD_HALF_LENGTH决定画面整体比例再定 ANGLE_LIMIT决定最大难度然后调 GRAVITY决定紧张感最后微调 DAMPING 和 LERP_SPEED决定控制手感。调 DAMPING 时有一个小技巧把球放在杆的一端让它自己滚回中心观察它是不是会越过中心往另一端冲一小段。如果完全没有越过说明阻尼过大如果来回摆了好几次说明阻尼太接近临界状态了。理想手感是回到中心后只轻微越过一两个像素就停住。5. 调试实录小球抖动、角度漂移与边界穿透5.1 小球在平衡位置附近高频抖动第一次把完整循环跑起来时我发现球在杆中央附近像得了帕金森一样疯狂颤动。起初我以为是物理积分的问题后来排查下来罪魁祸首是鼠标输入的微小抖动。当鼠标位于页面中心附近时offsetX 可能在 -5 像素到 5 像素之间波动这段波动映射出的目标角度虽然很小但每一帧都会改变方向。在这个角度下球受到的力方向不断在正负之间切换小球自然就被“抖”起来了。我的解决方案很实用——引入一个输入死区dead zoneconst rawOffsetX mouseX - centerX; if (Math.abs(rawOffsetX) 8) { state.targetAngle 0; } else { state.targetAngle (rawOffsetX / (window.innerWidth / 2)) * ANGLE_LIMIT; }在屏幕正中间留出 8 像素左右的区域只要鼠标落在这个范围内就强行把目标角度设为零。这样既不会影响正常控制又能避免零位附近的物理抖动。C 游戏手柄摇杆上也有类似的 dead zone 设计思路完全一致。5.2 横杆角度回不到零累积误差与漂移另一个让我头疼的问题是有时候我用鼠标把横杆倾斜到某个角度再移回中心横杆却停在 2 度左右的偏移上不会完全归零。反复检查发现问题出在 lerp 收敛公式上。当 targetAngle 与 rodAngle 的差值非常小时(targetAngle - rodAngle) * Math.min(1, LERP_SPEED * dt) 这个增量也会变得非常小。在浮点精度下它可能永远无法让 rodAngle 精确等于 0最后就一直卡在一个肉眼勉强能看出来的微小偏移上。解决办法是给差值设一个阈值小于阈值时直接让 rodAngle 等于 targetAngleconst diff state.targetAngle - state.rodAngle; if (Math.abs(diff) 0.0005) { state.rodAngle state.targetAngle; } else { state.rodAngle diff * Math.min(1, LERP_SPEED * dt); }这个细节如果你不做玩家可能说不清哪里别扭但就是觉得横杆“不正”非常影响手感。物理模拟里这类由浮点收敛造成的微小漂移往往需要靠显式的阈值判断来兜底。5.3 高速小球的边界穿透小球在杆上高速运动时一次更新步长内可能移动超过 10 像素。如果只用Math.abs(state.ballPos) ROD_HALF_LENGTH来判断掉落小球可能已经“穿”到杆子外面一段距离后才触发掉落逻辑视觉效果上就像球从杆头漏了出去。标准做法是记录上一帧的位置做一个越界检测const prevPos state.ballPos; state.ballPos state.ballVel * dt; if (Math.abs(prevPos) ROD_HALF_LENGTH Math.abs(state.ballPos) ROD_HALF_LENGTH) { onBallFall(); }这种“上一帧在界内、这一帧在界外”的检测方式在游戏开发里叫 swept collision check扫掠碰撞检测比单纯检查位移后的位置更可靠。碰到这类问题我的经验是凡是涉及高速运动对象与边界碰撞都必须考虑“上一帧位置”否则最终都会出现肉眼可见的穿模。6. 升级方向从“能玩”到“耐玩”的改造路径6.1 难度曲线的渐进设计基础版游戏是一个无限挑战模式时间越长玩家越疲惫难度其实会自然上升。但为了让玩家更愿意反复打开我建议加一个简单的难度渐变每坚持 10 秒把横杆长度缩短 5%同时把 ANGLE_LIMIT 增加一点。这个改动只需要几行代码却能让玩家每隔一段时间就感受到新的挑战压力。更进一步可以做成关卡制。比如第一关要求坚持 15 秒第二关横杆变短且球速更快第三关引入移动障碍物。因为物理模型是独立于游戏的这些新机制只要添加到 update 函数末尾即可不会影响已经跑通的物理部分。6.2 视觉反馈与 Web Audio 音效好的物理小游戏视觉反馈一定要能反映“风险等级”。我设计了两个阶段当球离中心超过杆长的 60% 时背景色从深灰渐变为暗红当球距离边界只剩 20% 时球变成半透明并持续闪烁。这种从潜意识层面提醒玩家“危险了”的设计比在 HUD 上显示一个数字有效得多。音效可以直接用 Web Audio API 生成不需要加载任何音频文件。核心思路是用一个 oscillator 节点产生频率和音量随时间变化的声音function beep(frequency, volume, duration) { const ctx new AudioContext(); const osc ctx.createOscillator(); const gain ctx.createGain(); osc.frequency.value frequency; gain.gain.setValueAtTime(volume, ctx.currentTime); gain.gain.exponentialRampToValueAtTime(0.001, ctx.currentTime duration); osc.connect(gain).connect(ctx.destination); osc.start(); osc.stop(ctx.currentTime duration); }当球每远离中心 20 像素时调用一次 beep音调随距离升高玩家就能通过耳朵判断“快掉了”而不需要一直盯着球。这种跨模态反馈是很多独立小游戏让人“上头”的隐蔽原因。6.3 开源发布路径与魔改建议把项目整理好上传到 GitHub 或 Gitee 时README 不要只贴个截图。我建议至少包含这四块内容玩法说明、控制方式、参数调试表、在线 Demo 链接。其中参数调试表对后来者帮助最大因为别人 fork 之后第一件事一定是改手感没有参数说明就只能靠猜。如果你想拿这个项目练手或二次开发我建议从三个方向切入第一个方向是“换皮”把横杆换成独木桥、把球换成走钢索的人配合 CSS 换一套主题就是一个新游戏第二个方向是“加机制”比如在杆上增加第二个球、让支点缓慢移动、加入风力等第三个方向是“改物理”把单摆、弹性碰撞等模型加进去探索不同物理系统的趣味性。我个人在实际操作中最深刻的体会是这个游戏的核心物理模拟只有不到二十行代码但它撑起了完整的可玩性。真正难度不在物理公式本身而在于把“手感”调整到恰到好处的那个过程。如果你也想做一个给人带来挑战感的小游戏不妨从这个项目开始把它跑通、玩熟、再按自己的口味拆掉重来。等你把 DAMPING 和 LERP_SPEED 之间的微妙平衡调到让自己欲罢不能时你就明白这些小游戏为什么会让人忍不住一直点“再来一局”了。
用纯前端打造物理平衡小游戏：Canvas物理模拟与手感调优实战
上周我在 GitHub 上翻开源小游戏本来想找一个 Canvas 的练手项目参考结果被一个叫“保持平衡”的 HTMLJSCSS 小游戏给黏住了。玩法一句话就能讲完一根横杆、一个小球你控制横杆左右倾斜的角度让球始终待在杆上不掉下去。听起来毫无门槛玩起来手心冒汗。我把项目拉下来跑通后又拆开重写了一遍才发现这个看似简单的小游戏其实把物理模拟、实时输入、Canvas 渲染、CSS 样式和移动端适配全串起来了。这篇文章就把整个开发过程完整拆开讲讲怎么用纯前端技术做出一款挑战控制力的物理平衡挑战游戏。1. 一个“保持平衡”玩法为什么让人一玩就停不下来1.1 极简规则背后的高频反馈机制“保持平衡”这类游戏的核心设计与大多数闯关游戏不同它没有敌人、没有关卡跳转、没有收集品所有乐趣都来自一个极短的操作反馈回路Game Feel 里常说的 tight loop你按一下方向键横杆立刻倾斜球马上有了加速度你必须在几百毫秒内反向修正否则球就滚向边缘。这种“输入→反馈→修正→再输入”的循环以每秒几十次的频率不断发生玩家的注意力始终被压在当下根本无暇分心于是很容易进入心流状态。从心理学角度看这类游戏还利用了人类的“手动追踪”本能。大脑会不自觉地不断预测球的运动轨迹然后通过手指或者鼠标把修正动作发射出去。你每次成功救回小球大脑都会给一点小小的正反馈每次失败几乎都只差那么一点于是你会下意识地点“再来一局”。这种“差一点就能成功”的挫败感与成就感交织是最容易让人上瘾的设计。我在实际测试中也有明确感受前 3 秒轻松第 10 秒开始紧张第 20 秒手心出汗第 30 秒屏住呼吸。整个过程中大脑的专注度是持续拉满的这就是好物理小游戏该有的状态。1.2 这个开源项目具体实现了什么我参考的这版开源项目由一个 HTML 文件、一个 CSS 文件和一个 JS 文件组成。没有任何第三方依赖也没有构建流程浏览器直接打开 index.html 就能玩。它把几个关键技术点完整展示了出来游戏主循环怎么拆解成 update更新物理状态和 render绘制画面两半怎么用 Canvas 绘制横杆、小球和边界背景怎么把键盘、鼠标、触摸屏三种输入源统一映射成同一个“目标角度”怎么用极简的几行物理积分公式表达“重力沿斜面分量”和“滚动阻尼”。我觉得它非常适合作为前端入门者研究第一个游戏项目的模板因为它足够小所有代码读完不超过 400 行但又足够完整能让你体验到从零到一开发一个小游戏的全过程。对已经会写页面、但没接触过游戏循环的人来说这个项目是一个性价比极高的上手案例。2. 核心物理模型一条公式讲清“倾倒”与“滚动”的本质2.1 从真实跷跷板到二维平面模型在写任何代码之前先把现实中的跷跷板抽象成一个适合浏览器模拟的二维模型。把横杆看成一条线段支点固定在 Canvas 正中央球抽象成一个只沿杆方向运动的小圆。这里需要定义四个核心状态变量变量含义初始值rodAngle横杆当前倾斜角度弧度0targetAngle玩家希望横杆达到的目标角度0ballPos球在杆上的相对位置0 为正中0ballVel球沿杆方向的速度0rodAngle 和 ballPos 是渲染时用到的真实状态targetAngle 则是一个中间量。之所以要区分“当前角度”和“目标角度”是因为现实中横杆不可能瞬间倾斜到玩家指定的角度它需要一个过渡过程否则物理反馈会变得极其生硬。接下来把横杆长度的一半设为常量 ROD_HALF_LENGTH当 ballPos 的绝对值超过这个值就表示球滚出了杆端触发掉落。整个模型的世界就这么简单真正复杂的部分在于角度和球的加速度之间到底是什么关系。2.2 重力分量、阻尼与速度积分先回忆一下高中力学当一个物体放在倾角为 θ 的斜面上时重力沿斜面方向的分量是 m * g * sin(θ)。质量 m 在计算加速度时会约掉所以加速度 a g * sin(θ)。放到这个游戏里g 不再是 9.8 m/s²而是换算成了屏幕上的像素单位我调参后定为 800。球的加速度还受阻力影响。如果没有阻力球会像在真空管里一样不断加速玩家永远不可能把它停在中间。我在模型里加了一个与速度成正比的阻尼项const accel GRAVITY * Math.sin(state.rodAngle) - DAMPING * state.ballVel;GRAVITY 是重力加速度常数DAMPING 是阻尼系数。这一步至关重要它决定了球滚起来之后会不会慢慢“泄力”。阻尼相当于滚动摩擦和空气阻力的综合效果。DAMPING 越大球越容易停下来但也不容易滚向边缘游戏会显得软绵绵DAMPING 太小球又像抹了油一样滑极难控制。拿到加速度后用最简单的欧拉积分来更新速度和位置state.ballVel accel * dt; state.ballPos state.ballVel * dt;其中 dt 是上一帧到这一帧的时间差单位是秒。欧拉积分虽然没有物理引擎中的 RK4 精度高但在这个自由度极低的系统里已经足够。关键是 dt 一定要取真实的帧间隔而不是固定写死 1/60这一点在第四章专门讲。我实测下来这组参数的手感是横杆总长约 560 像素球在全力倾斜时大约 0.8 秒内从中心滚到边缘给玩家留下了约 1.5 秒的反应窗口既有紧迫感又不至于完全反应不过来。你可以把它理解成“每次错误操作都还有一次补救机会”的难度曲线。2.3 为什么这种小游戏不需要物理引擎很多人看到“物理”两个字第一反应是上 Matter.js、Planck.js 这类库。我在初学阶段也踩过这个误区。但冷静分析一下这个游戏只有一个自由度球沿杆方向的位置横杆角度也是由玩家直接控制的不需要碰撞体之间的复杂交互更不需要刚体旋转、关节约束、材料摩擦系数这些引擎特性。用物理引擎反而要处理引擎的坐标系、碰撞回调、甚至引擎自身的性能开销完全是杀鸡用牛刀。自研物理模型最大的好处是可以精确掌控每一个参数背后的手感。比如我可以明确知道“DAMPING 设成 1.8 时球从边缘回滚的减速曲线长什么样”而如果用了物理引擎这些参数会被封装在一堆物体属性和材质配置里调试起来反而更绕。我在重写过程中把物理更新函数保持得极其干净只做“角度插值 加速度计算 速度位置积分 边界判断”四件事。后面不管加分数、加关卡、加粒子特效都不会污染这段核心逻辑。这也是小游戏项目一个非常重要的架构原则物理模型和表现层分离。3. 项目文件结构与三个语言的分工3.1 HTML 骨架给游戏一个容器HTML 文件承担的责任很轻但结构必须清晰。我的 index.html 核心部分大概长这样div idapp canvas idgameCanvas width800 height600/canvas div idhud span idtimeLabel0.0s/span /div button idstartBtn开始游戏/button /div script srcgame.js/script这里有几个容易被忽略的点。Canvas 的 width 和 height 属性是画布的实际像素尺寸CSS 里设置的宽高只是缩放后的展示尺寸两者不一致会导致画面模糊所以我直接让它们保持一致。其次把 HUD 和按钮放在 canvas 外面用普通 DOM 渲染这样省去在 Canvas 里绘制文字的麻烦CSS 控制样式也更方便。脚本标签放在 body 末尾而不是 head 里确保 DOM 结构先加载完game.js 在初始化时能直接拿到 canvas 元素不需要额外监听 DOMContentLoaded 事件。这是很多新手容易踩的坑脚本放 head 里document.getElementById 拿到 null程序直接报错。3.2 CSS 视觉设计让平衡状态“看得见”CSS 在这个游戏里的作用不只是美化它还能承担一部分“信息层级”的传达。我把页面背景做成中性的深灰色让视线集中在画布中央HUD 使用少量半透明背景避免遮挡游戏区域。真正有意思的是给“启动状态”做视觉反馈。初始状态下 HUD 的提示文字是暗的鼠标移入画布区域时通过 :hover 加上高亮效果可以让玩家感知到“这里是可以操作的”。我还用了一个很轻的过渡动画canvas { cursor: crosshair; transition: box-shadow 0.2s ease; } canvas:hover { box-shadow: 0 0 30px rgba(255, 255, 255, 0.1); }cursor: crosshair 很重要它暗示玩家这里需要精确瞄准和操作比默认箭头好很多。不过我需要提醒CSS 过渡动画不要加在游戏内实时变化的状态上因为 CSS 动画每帧触发的合成开销在低端设备上会影响帧率。所有高频变化的视觉元素比如球的位置、横杆的倾斜都必须在 Canvas 里每帧重绘CSS 只负责静态容器和低频状态。3.3 JS 状态与渲染解耦game.js 是整个游戏的核心我把它分成三个相对独立的部分状态对象、更新函数、渲染函数。state 对象集中存放所有可变数据const state { rodAngle: 0, targetAngle: 0, ballPos: 0, ballVel: 0, isRunning: false, lastTimestamp: 0, elapsed: 0, };update(dt) 只负责根据输入和物理模型修改 state 中的值render(ctx) 只负责读取 state 并绘制到 Canvas。这样做的最大好处是可以直接在浏览器控制台修改 state 来调试。比如我怀疑球的初始位置不对就在控制台手动执行 state.ballPos -100然后立刻能看到渲染结果完全不需要刷新页面。这种架构还有一个隐藏好处后续如果要给游戏加 AI 自动平衡、回放功能或者联机同步只要把 state 序列化即可渲染层完全没有感知。4. 渲染循环与交互控制的实现细节4.1 requestAnimationFrame 与帧率无关的物理游戏循环是每帧执行一次 update 和 render 的过程。前端最标准的方式是用 requestAnimationFramefunction loop(timestamp) { const dt Math.min((timestamp - state.lastTimestamp) / 1000, 0.05); state.lastTimestamp timestamp; if (state.isRunning) { update(dt); render(ctx); } requestAnimationFrame(loop); } requestAnimationFrame(loop);这个 dt 是“帧率无关物理”的关键。在 60Hz 屏幕上dt 大约是 0.0167 秒在 120Hz 屏幕上dt 大约是 0.0083 秒。如果不把 dt 传进 update而是假设每帧固定 1/60 秒那同样的球会在高刷屏上跑得快一倍物理速度就乱套了。Math.min(timestamp - lastTimestamp, 50) 这行是我加的防护。当浏览器标签页切到后台再切回来时timestamp 的差值可能非常大球会在恢复的第一帧跨越几秒的物理距离直接飞出边界。截断成最大 50 毫秒就能避免这种“闪现瞬移”的尴尬。4.2 键盘、鼠标与触摸屏的统一输入映射无论玩家用什么方式输入最终都只做一件事设置 state.targetAngle。键盘方案是按下左右方向键时让目标角度向对应方向持续增加并限制在最大角度范围内const KEY_STEP 0.002; if (keys.left) state.targetAngle Math.max(state.targetAngle - KEY_STEP, -ANGLE_LIMIT); if (keys.right) state.targetAngle Math.min(state.targetAngle KEY_STEP, ANGLE_LIMIT);鼠标方案更直接把鼠标 X 坐标与屏幕中心线的偏移量映射到目标角度const offsetX mouseX - centerX; state.targetAngle (offsetX / (window.innerWidth / 2)) * ANGLE_LIMIT;触摸屏方案和鼠标几乎一样只是把 touchmove 事件中的触摸点坐标当成 mouseX。这三种方案的统一接口一旦建立后面想支持手柄、体感甚至语音控制都只是新增一个输入源的问题。目标角度设定完之后横杆本身不能瞬间到位需要用插值让它物理“缓动”过去state.rodAngle (state.targetAngle - state.rodAngle) * Math.min(1, LERP_SPEED * dt);LERP_SPEED 我设为 12这个值直接决定横杆的反应速度。设得太小横杆像在水里一样慢玩家会感觉指令延迟感强设得太大横杆反应过快小球会频繁获得大幅度加速度控制难度陡增。12 是我在键鼠输入下试出来的折中值移动端触屏可以适当降到 8因为手指的移动本身已经比鼠标更细腻。4.3 手感调优的参数组合笔记我整理了一张调试记录表这里面每一组参数都会直接影响游戏体验参数范围手感影响GRAVITY600 ~ 1000值越大球加速越快游戏越难值越小手感越飘DAMPING0.5 ~ 3.0值越大球越容易静止但挑战性下降ANGLE_LIMIT0.3 ~ 0.8 弧度限制横杆最大倾斜角度等于限制球的最大加速度LERP_SPEED6 ~ 20横杆响应速度影响操作跟手程度ROD_HALF_LENGTH200 ~ 350杆越长玩家可用空间越大游戏相对越容易这几项参数是强耦合的不能孤立地调某一个。我给的顺序建议是先定 ROD_HALF_LENGTH决定画面整体比例再定 ANGLE_LIMIT决定最大难度然后调 GRAVITY决定紧张感最后微调 DAMPING 和 LERP_SPEED决定控制手感。调 DAMPING 时有一个小技巧把球放在杆的一端让它自己滚回中心观察它是不是会越过中心往另一端冲一小段。如果完全没有越过说明阻尼过大如果来回摆了好几次说明阻尼太接近临界状态了。理想手感是回到中心后只轻微越过一两个像素就停住。5. 调试实录小球抖动、角度漂移与边界穿透5.1 小球在平衡位置附近高频抖动第一次把完整循环跑起来时我发现球在杆中央附近像得了帕金森一样疯狂颤动。起初我以为是物理积分的问题后来排查下来罪魁祸首是鼠标输入的微小抖动。当鼠标位于页面中心附近时offsetX 可能在 -5 像素到 5 像素之间波动这段波动映射出的目标角度虽然很小但每一帧都会改变方向。在这个角度下球受到的力方向不断在正负之间切换小球自然就被“抖”起来了。我的解决方案很实用——引入一个输入死区dead zoneconst rawOffsetX mouseX - centerX; if (Math.abs(rawOffsetX) 8) { state.targetAngle 0; } else { state.targetAngle (rawOffsetX / (window.innerWidth / 2)) * ANGLE_LIMIT; }在屏幕正中间留出 8 像素左右的区域只要鼠标落在这个范围内就强行把目标角度设为零。这样既不会影响正常控制又能避免零位附近的物理抖动。C 游戏手柄摇杆上也有类似的 dead zone 设计思路完全一致。5.2 横杆角度回不到零累积误差与漂移另一个让我头疼的问题是有时候我用鼠标把横杆倾斜到某个角度再移回中心横杆却停在 2 度左右的偏移上不会完全归零。反复检查发现问题出在 lerp 收敛公式上。当 targetAngle 与 rodAngle 的差值非常小时(targetAngle - rodAngle) * Math.min(1, LERP_SPEED * dt) 这个增量也会变得非常小。在浮点精度下它可能永远无法让 rodAngle 精确等于 0最后就一直卡在一个肉眼勉强能看出来的微小偏移上。解决办法是给差值设一个阈值小于阈值时直接让 rodAngle 等于 targetAngleconst diff state.targetAngle - state.rodAngle; if (Math.abs(diff) 0.0005) { state.rodAngle state.targetAngle; } else { state.rodAngle diff * Math.min(1, LERP_SPEED * dt); }这个细节如果你不做玩家可能说不清哪里别扭但就是觉得横杆“不正”非常影响手感。物理模拟里这类由浮点收敛造成的微小漂移往往需要靠显式的阈值判断来兜底。5.3 高速小球的边界穿透小球在杆上高速运动时一次更新步长内可能移动超过 10 像素。如果只用Math.abs(state.ballPos) ROD_HALF_LENGTH来判断掉落小球可能已经“穿”到杆子外面一段距离后才触发掉落逻辑视觉效果上就像球从杆头漏了出去。标准做法是记录上一帧的位置做一个越界检测const prevPos state.ballPos; state.ballPos state.ballVel * dt; if (Math.abs(prevPos) ROD_HALF_LENGTH Math.abs(state.ballPos) ROD_HALF_LENGTH) { onBallFall(); }这种“上一帧在界内、这一帧在界外”的检测方式在游戏开发里叫 swept collision check扫掠碰撞检测比单纯检查位移后的位置更可靠。碰到这类问题我的经验是凡是涉及高速运动对象与边界碰撞都必须考虑“上一帧位置”否则最终都会出现肉眼可见的穿模。6. 升级方向从“能玩”到“耐玩”的改造路径6.1 难度曲线的渐进设计基础版游戏是一个无限挑战模式时间越长玩家越疲惫难度其实会自然上升。但为了让玩家更愿意反复打开我建议加一个简单的难度渐变每坚持 10 秒把横杆长度缩短 5%同时把 ANGLE_LIMIT 增加一点。这个改动只需要几行代码却能让玩家每隔一段时间就感受到新的挑战压力。更进一步可以做成关卡制。比如第一关要求坚持 15 秒第二关横杆变短且球速更快第三关引入移动障碍物。因为物理模型是独立于游戏的这些新机制只要添加到 update 函数末尾即可不会影响已经跑通的物理部分。6.2 视觉反馈与 Web Audio 音效好的物理小游戏视觉反馈一定要能反映“风险等级”。我设计了两个阶段当球离中心超过杆长的 60% 时背景色从深灰渐变为暗红当球距离边界只剩 20% 时球变成半透明并持续闪烁。这种从潜意识层面提醒玩家“危险了”的设计比在 HUD 上显示一个数字有效得多。音效可以直接用 Web Audio API 生成不需要加载任何音频文件。核心思路是用一个 oscillator 节点产生频率和音量随时间变化的声音function beep(frequency, volume, duration) { const ctx new AudioContext(); const osc ctx.createOscillator(); const gain ctx.createGain(); osc.frequency.value frequency; gain.gain.setValueAtTime(volume, ctx.currentTime); gain.gain.exponentialRampToValueAtTime(0.001, ctx.currentTime duration); osc.connect(gain).connect(ctx.destination); osc.start(); osc.stop(ctx.currentTime duration); }当球每远离中心 20 像素时调用一次 beep音调随距离升高玩家就能通过耳朵判断“快掉了”而不需要一直盯着球。这种跨模态反馈是很多独立小游戏让人“上头”的隐蔽原因。6.3 开源发布路径与魔改建议把项目整理好上传到 GitHub 或 Gitee 时README 不要只贴个截图。我建议至少包含这四块内容玩法说明、控制方式、参数调试表、在线 Demo 链接。其中参数调试表对后来者帮助最大因为别人 fork 之后第一件事一定是改手感没有参数说明就只能靠猜。如果你想拿这个项目练手或二次开发我建议从三个方向切入第一个方向是“换皮”把横杆换成独木桥、把球换成走钢索的人配合 CSS 换一套主题就是一个新游戏第二个方向是“加机制”比如在杆上增加第二个球、让支点缓慢移动、加入风力等第三个方向是“改物理”把单摆、弹性碰撞等模型加进去探索不同物理系统的趣味性。我个人在实际操作中最深刻的体会是这个游戏的核心物理模拟只有不到二十行代码但它撑起了完整的可玩性。真正难度不在物理公式本身而在于把“手感”调整到恰到好处的那个过程。如果你也想做一个给人带来挑战感的小游戏不妨从这个项目开始把它跑通、玩熟、再按自己的口味拆掉重来。等你把 DAMPING 和 LERP_SPEED 之间的微妙平衡调到让自己欲罢不能时你就明白这些小游戏为什么会让人忍不住一直点“再来一局”了。