开维引擎打造2D赛车小游戏：从零实现到性能优化实战

开维引擎做赛车小游戏，这个组合是我从立项到跑完第一局觉得最值得记录的一次实践。很多朋友一提到“游戏引擎”就想到Unity、Unreal这种大而全的工具，但实际做2D轻量级游戏、做原型验证、甚至做教学演示时，一个像开维这样结构清楚、API精简的引擎反而更顺手。赛车游戏虽然看起来简单，但它把游戏开发里的核心场景几乎都覆盖了：场景管理、精灵渲染、输入控制、物理碰撞、相机跟随、UI叠加、音频和性能优化。这篇文章我会用一次真实的开发经历，把从零开始实现赛车小游戏的过程拆开来讲，包括为什么选择这种结构、每一步的具体做法、以及我实际踩过的坑和排查思路，希望能给正在学习游戏开发或者打算用开维引擎做项目的朋友提供一份可以直接抄作业的参考。

1. 项目整体构思与引擎选型

1.1 为什么用开维引擎做赛车游戏

先说结论：赛车小游戏是验证引擎能力的“完美试纸”，而开维引擎的体积和设计风格恰好适合这种场景。

很多引擎在设计上倾向于提供完整解决方案，比如内置庞大的编辑器、资源管线、跨平台打包工具链。这种引擎擅长做大型项目，但代价是学习曲线陡、启动成本高、代码里大量模板化内容。开维引擎走了相反的路线：它把游戏开发抽象成“场景 + 实体 + 组件 + 系统”，API面精简，没有强制性的编辑器依赖，纯代码构建游戏逻辑。这对赛车游戏这种玩法明确、边界清晰的2D项目来说非常合适，你不需要美术管线、不需要复杂资源打包，只要理解几个核心概念就能把游戏跑起来。

具体到这次项目，我选择开维引擎的三个理由：

• 轻量级启动：引擎核心库压缩后大约300KB级别，加载快，开发时修改代码后刷新浏览器立刻能看到效果，迭代速度极快。
• 内置2D物理与碰撞管理：赛车游戏需要精确的碰撞检测和速度、加速度模拟。开维引擎内置了基于刚体的2D物理系统，不用自己再封装一套物理计算逻辑。
• 场景切换机制清晰：赛车游戏至少需要“标题界面”“比赛场景”“结算界面”三个场景。开维的场景管理器用scene.add/scene.remove就能完成切换，状态管理非常直观。

还有一点很实际：引擎本身是MIT协议，我不需要为商业发布或二次开发担心授权问题。这放在团队技术选型时是必须考虑的约束。

1.2 游戏模块划分与启动流程

拿到需求后，我没有立刻写代码，而是先拆模块。赛车小游戏的功能面其实很大——赛车物理、赛道生成、AI对手、相机跟踪、计分逻辑、音效反馈、UI 界面——如果全部写在一起，后面调试会非常痛苦。按照开维引擎的架构习惯，我把整个项目划分成下面几个部分：

• 场景层（Scene）：负责组织游戏世界内的所有实体，相当于一个“游戏房间”。每个场景承载其中的精灵、文字、UI图层、摄像机。
• 实体层（Entity/Sprite）：游戏中的赛车、赛道边界、障碍物、终点线等，每个实体可以有独立的组件：物理碰撞体、贴图、动画、自定义脚本。
• 系统层（System）：引擎内置的物理系统、渲染系统、输入系统、音频系统，以及我自定义的AI更新逻辑和游戏状态机。
• UI层（HUD）：负责显示圈数、速度、倒计时、结束结算等界面信息。开维引擎把UI对象和世界对象分开，处理起来不会互相干扰。

启动流程我用一张伪代码来描述整个生命周期：

// 入口文件 main.js import * as Kaiwei from 'kaiwei-engine'; const game = new Kaiwei.Game({ width: 960, height: 540, physics: { gravity: 0, // 俯视赛车，不需要重力 iterations: 8 } // 物理迭代次数越大越稳定 }); game.scenes.register(loadingScene); game.scenes.register(raceScene); game.scenes.switchTo('race'); game.start();

整个流程设计成“注册场景 -> 切换场景 -> 启动主循环”，主循环内部由引擎自动处理：帧更新、物理计算、渲染、输入事件分发。开发时我不需要关心每帧的具体调度顺序，引擎已经把“更新逻辑 -> 物理步进 -> 碰撞回调 -> 渲染上屏”这套流程封装好了。传统开发里最烦人的“生命周期管理”在这里被统一接管，我只需要在场景和组件里写游戏内容就行。

1.3 核心循环与状态机设计

这里要单独讲一下游戏状态机，因为赛车小游戏很容易被忽略。如果不做状态控制，玩家可能在没有进入比赛前就开始加速，比赛结束后赛车还能自由移动，倒计时期间碰撞已经生效，这些都会导致诡异的Bug。

我定义了5个状态：WAITING（开始前等待）、COUNTDOWN（倒计时）、RACING（比赛中）、FINISHED（冲线后）、GAMEOVER（结算）。状态之间通过一组明确的过渡条件切换：

• WAITING -> COUNTDOWN：玩家点击“开始比赛”按钮或按下回车键。
• COUNTDOWN -> RACING：倒计时播放完3、2、1，并且清零后的第一帧。
• RACING -> FINISHED：玩家或AI到达终点线。
• FINISHED -> GAMEOVER：结算动画播放完毕，显示排名和按钮。

实现方式是每个场景维护一个state变量，在每帧的update(dt)方法里根据当前状态决定是否处理玩家输入、是否更新物理、是否调用AI逻辑、是否更新HUD。这个设计让整个游戏流程清晰可见，也方便后面加暂停、重开等功能。

2. 赛车游戏核心细节与实操要点

2.1 赛道场景搭建的两种方式

赛道是赛车游戏的地基，也是最影响游戏手感的部分。我一开始想用美术做好的整张赛道图片直接铺在背景上，这样做开发效率最高，但有个致命问题：很难做基于像素的碰撞检测——赛车冲出赛道时无法精确判断是压线还是跑出白色路肩。后来我换成了“分段路径 + 路点”的方式。

开维引擎支持将自定义几何体注册为碰撞体，所以我把赛道简化成两组数据：

• 左边界点集合leftBoundary[]和右边界点集合rightBoundary[]
• 中心线路径点集合waypoints[]，用于AI导航和圈数判断

边界点和中心线的关系通过偏移量生成：

function buildTrack(centerPath, halfWidth) { const left = [], right = []; for (let i = 0; i < centerPath.length; i++) { // 获取当前路段的切线方向 const next = centerPath[(i + 1) % centerPath.length]; const tangent = { x: next.x - centerPath[i].x, y: next.y - centerPath[i].y }; const len = Math.hypot(tangent.x, tangent.y); const normal = { x: -tangent.y / len, y: tangent.x / len }; left.push({ x: centerPath[i].x + normal.x * halfWidth, y: centerPath[i].y + normal.y * halfWidth }); right.push({ x: centerPath[i].x - normal.x * halfWidth, y: centerPath[i].y - normal.y * halfWidth }); } return { left, right }; }

这段代码的关键是计算法线方向。道路上每个点的切线方向可以从前一个点和后一个点求出，法线就是切线逆时针旋转90度。左边加偏移、右边减偏移，就得到了左右边界。碰撞检测时，只要判断赛车中心点到左右边界线段的最近距离，如果小于赛车的碰撞半径，就视为撞上边界。

实际操作中我遇到了一个细节：赛道如果是一条闭环，首尾的位置必须重合，否则接缝处会产生不自然的“断点”，赛车经过时会突然碰撞。解决办法是在生成路径时，把第一个点也复制到末尾，组成闭合环。

2.2 玩家赛车移动控制的底层逻辑

赛车不是做简单的“按键移动精灵”，那样手感很差。我用的是经典赛车运动学模型：加速度、速度、角速度分开计算。

核心公式如下：

• 当前速度方向决定了赛车的朝向，默认情况下赛车移动方向与朝向一致。
• 油门产生沿朝向方向的加速度：speed += throttle * accelPower * dt
• 踏板松开后由阻力衰减速度：speed *= Math.pow(0.002, dt)，也就是指数衰减公式
• 转向只在一定速度范围内有效：angle += steerInput * steerSpeed * dt * (speed / maxSpeed)
• 位置更新：x += Math.cos(angle) * speed * dt，y += Math.sin(angle) * speed * dt

这里最大的坑是转向速度与速度的耦合。如果速度为零时还能原地转向，玩家可以转着圈“倒车入库”，这不真实。而且速度过快时转向力不足，赛车会推头。我加了一个速度因子(speed / maxSpeed)来控制转向灵敏度，低速时几乎不能转向，高速时转向幅度被限制到合理范围。

还有一个容易被忽略的问题：更新顺序。必须“先转向后位移”，如果反过来，赛车会在转向生效前移动一帧，造成视觉上的延迟漂移。

2.3 碰撞与边界检测的注意事项

2D碰撞检测最常用的有两种：一种是硬碰撞，用直角包围盒（AABB），适合方块类物体；另一种是圆体碰撞，适合赛车这种轮廓接近矩形的俯视游戏。开维引擎支持多种collider，但我不建议直接用矩形collider，因为赛车转弯时矩形会跟着旋转，碰撞区域会随角度变化而产生“抖动”感。

我实际上用的是“多个小圆覆盖车身”的方案：在赛车头、中、尾分别放置三个半径略小的圆形collider。这样碰撞检测更稳定，而且赛车撞墙时，可以检测到具体是哪个点碰撞，从而产生合理的反弹效果。

碰撞反弹的简单实现：

onCollision(other, contactPoint) { // 获取碰撞法线 const nx = contactPoint.x - this.center.x; const ny = contactPoint.y - this.center.y; const len = Math.hypot(nx, ny); // 法线方向归一化 const un = { x: nx / len, y: ny / len }; // 当前速度向量 const v = this.body.velocity; const vn = v.x * un.x + v.y * un.y; // 速度在法线方向的分量 // 如果朝碰撞方向运动，则反弹并衰减 if (vn < 0) { const restitution = 0.3; this.body.velocity.x -= (1 + restitution) * vn * un.x; this.body.velocity.y -= (1 + restitution) * vn * un.y; } }

需要注意的是碰撞回调里上千次触发时不能做复杂计算，否则帧率直接崩。我最初在碰撞回调中调用了console.log及绘制调试线条，结果一撞墙就卡成幻灯片。后来把调试绘制独立成一个debug开关，只在开发模式下绘制碰撞区域，发布时关闭。

3. 完整实现：从初始化到跑通一局

3.1 引擎初始化与比赛场景搭建

我从项目目录初始化开始说。用开维引擎的项目通常使用 Vite 或 Webpack 构建，这里我用 Vite，因为它热更新快，配置少。

npm create vite@latest kaiwei-race -- --template vanilla cd kaiwei-race npm install kaiwei-engine

在src/main.js中初始化引擎并创建场景：

import * as Kaiwei from 'kaiwei-engine'; const game = new Kaiwei.Game({ width: 960, height: 540, resolution: 'auto', physics: { gravity: { x: 0, y: 0 }, iterations: 10 } }); const raceScene = new Kaiwei.Scene('race'); raceScene.backgroundColor = 0x1a1f2b; // 绘制赛道地面 const ground = new Kaiwei.GameObject('ground'); ground.addComponent(new Kaiwei.SpriteComponent({ renderMode: 'custom', draw: (ctx) => drawTrackGround(ctx) })); raceScene.add(ground); // 添加碰撞边界 const colliders = createTrackColliders(); colliders.forEach(collider => { const go = new Kaiwei.GameObject('trackCollider'); go.addComponent(collider); raceScene.add(go); }); game.scenes.add(raceScene); game.scenes.switchTo('race'); game.start();

初始化时有一个参数值得说明：iterations。这是物理引擎每帧的迭代次数，数值越大，碰撞和堆叠效果越稳定，但代价是性能下降。对于赛车游戏，没有大量堆叠物体，8~10次足够，不要轻易调到20以上，那只会白白消耗CPU。

3.2 玩家赛车与AI对手的完整实现

玩家赛车的核心是VehicleController组件。我给它设计了对外暴露的输入接口，这样既支持键盘控制，也方便后续改成触屏或手柄。

class VehicleController extends Kaiwei.Component { constructor() { super(); this.maxSpeed = 320; // 最大速度 像素/秒 this.accelPower = 180; // 加速度 this.reversePower = 80; // 倒车加速度 this.steerSpeed = 2.2; // 转向速度 弧度/秒 this.friction = 0.98; // 摩擦阻尼 this.speed = 0; this.angle = -Math.PI / 2; // 初始朝向：向上 } update(dt) { const input = this.getInput(); // 加速度控制 if (input.throttle > 0) { this.speed += input.throttle * this.accelPower * dt; } else if (input.brake > 0) { this.speed -= input.brake * this.reversePower * dt; } else { this.speed *= Math.pow(this.friction, dt * 60); } // 转向，速度越大转向效率越低 const steerFactor = Math.max(0, 1 - (this.speed / this.maxSpeed) * 0.4); this.angle += input.steer * this.steerSpeed * steerFactor * dt; // 位置更新 const dx = Math.cos(this.angle) * this.speed * dt; const dy = Math.sin(this.angle) * this.speed * dt; this.gameObject.position.x += dx; this.gameObject.position.y += dy; } }

输入层我用键盘的 WASD 或方向键，通过引擎的game.input.keyboard读取：

const keys = game.input.keyboard; const input = { throttle: 0, brake: 0, steer: 0 }; if (keys.isDown('ArrowUp') || keys.isDown('KeyW')) input.throttle = 1; if (keys.isDown('ArrowDown') || keys.isDown('KeyS')) input.brake = 1; if (keys.isDown('ArrowLeft') || keys.isDown('KeyA')) input.steer -= 1; if (keys.isDown('ArrowRight') || keys.isDown('KeyD')) input.steer += 1;

这个输入状态在每帧开始前读取，然后传入控制器。这里有个细节：getInput()不应该直接读键盘，而应该读取一个由外部写入的“输入状态”，这样任何输入方式（键盘、触屏、手柄）都能驱动同一套车辆逻辑。我封装了setInputSource(fn)接口，比如触屏时把虚拟摇杆的输出注入进去，车辆代码一行不改。

AI对手的实现就要复杂一些。我用了基于路点（waypoint）的追踪算法：AI赛车不知道玩家在哪里，它只知道下一个路点在哪，然后朝路点方向打方向，同时根据前方弯道情况控制油门。

class AIController extends Kaiwei.Component { constructor(waypoints) { super(); this.waypoints = waypoints; this.currentTargetIndex = 0; this.steerSensitivity = 3.0; } update(dt) { // 找到最近的路点，切换目标 this.currentTargetIndex = findNextWaypoint( this.waypoints, this.gameObject.position, this.currentTargetIndex ); const target = this.waypoints[this.currentTargetIndex]; const dx = target.x - this.gameObject.position.x; const dy = target.y - this.gameObject.position.y; const targetAngle = Math.atan2(dy, dx); // 角度差，需要归一化到 [-PI, PI] let diff = targetAngle - this.angle; while (diff > Math.PI) diff -= Math.PI * 2; while (diff < -Math.PI) diff += Math.PI * 2; this.steer = Math.max(-1, Math.min(1, diff * this.steerSensitivity)); // 弯道越急越要提前减速 this.throttle = Math.abs(diff) > 0.4 ? 0.5 : 1.0; } }

findNextWaypoint的方法不是找“距离当前路点最近”的点，而是继续往后找，判断赛车是否已经越过当前目标点。具体判断是计算赛车位置到目标点连线方向是否已经超过90度，或者用点积判断：

// 当前前进方向向量 const forward = { x: Math.cos(vehicleAngle), y: Math.sin(vehicleAngle) }; // 从车到目标路点的向量 const toTarget = { x: target.x - pos.x, y: target.y - pos.y }; // 如果目标点在车后方，切换下一个路点 if (toTarget.x * forward.x + toTarget.y * forward.y < 0) { currentTargetIndex = (currentTargetIndex + 1) % waypoints.length; }

这个实现简单但有效，唯一要注意的是当AI卡住时（比如撞墙后），它不会主动倒车，我后来加了一个检测：连续2秒速度低于阈值就给他一个“倒车加转弯”的指令。这个小修正在后面的测试里帮了大忙。

3.3 HUD显示与圈数判定

HUD包含四样东西：当前圈数、单圈时间、总时间、速度值。开维引擎的UI对象是独立于世界空间的，坐标原点在屏幕左上角，这让我不用关心摄像机移动带来的坐标偏移。

const hud = new Kaiwei.UIContainer('hud'); const lapText = new Kaiwei.Text('圈数: 1/3', { position: { x: 20, y: 20 }, fontSize: 24, color: '#ffffff', fontFamily: 'monospace' }); hud.add(lapText); const speedText = new Kaiwei.Text('速度: 0', { position: { x: 20, y: 56 }, fontSize: 20, color: '#ffcc00' }); hud.add(speedText);

圈数判定的设计比较讲究。如果简单用“经过起点线”来判断，可能会出现赛车在起点线附近反复横跳刷圈的Bug。我用“路点累计”的方式：把赛道按路点分成若干个检查段，玩家必须按顺序依次经过每个检查点，当经过的检查点数量等于赛道总检查点数时，圈数加1，然后重置计数。

具体实现是给检查点一个范围（半径为15像素的圆形区域），当赛车进入该区域且当前checkpointIndex与该检查点编号一致时，就推进索引：

function findNextCheckpoint(checkpoints, pos, currentIndex) { const point = checkpoints[currentIndex]; if (distance(pos, point) < 15) { return (currentIndex + 1) % checkpoints.length; } return currentIndex; }

一圈完成的判断是currentIndex从最大值回到0，此时lap + 1。用这个方法后，无论玩家怎么绕路、掉头，都不会产生误记。这个设计也适用于AI对手。

积分和胜负判定在FINISHED状态处理。玩家和三个AI对手中，谁先完成指定圈数谁获胜。我在比赛开始时记录了每个车辆的“总路点索引”，索引大的领先，索引相同则比较距离下一个路点的距离。这样就可以实时渲染一个简易排名显示在HUD顶部。

3.4 音效和视觉反馈的小技巧

音效这块，我用开维引擎的音频模块配合简单的合成音：引擎轰鸣声用噪声源加低通滤波处理，碰撞时播放一个短促的“砰”声。不要用MP3整段循环，文件大，加载慢，而且不好控制节奏。合成音的好处是运行时生成，占用几乎为零。

视觉反馈关键在于速度感。俯视赛车游戏最容易显得“静止”，因为画面里赛道边缘的参照物少。我做了三个增强：

• 路面上绘制距离标记（短线），赛车经过时这些标记快速掠过，速度感立刻就有了。
• 赛车加速时给赛车稍微拉长一点贴图，或者增加残影效果。残影实现方式是保留最近几帧赛车的位置和角度，用半透明材质绘制。
• 用摄像机微小的抖动来体现碰撞冲击。开维引擎的摄像机支持shake(duration, intensity)方法，碰撞时调用它就够了。

代码里最重要的还是残影：

class TrailingGhost extends Kaiwei.Component { constructor(maxGhosts = 6) { super(); this.maxGhosts = maxGhosts; this.positions = []; } update(dt) { const pos = this.gameObject.position; const angle = this.gameObject.rotation; // 每隔几帧记录一次，而不是每帧记录 this.timer = (this.timer || 0) + dt; if (this.timer >= 0.04) { this.timer = 0; this.positions.push({ x: pos.x, y: pos.y, angle, alpha: 0.5 }); if (this.positions.length > this.maxGhosts) { this.positions.shift(); } } // 更新透明度并绘制残影 this.positions.forEach(p => p.alpha *= 0.9); } }

残影记录间隔太小会导致残影过多，反而看不清赛车本体；间隔太大又没有连续感。我调的0.04秒每帧记录一次，在60帧率下大约每2~3帧一个残影，效果比较自然。

4. 常见问题排查与性能调优实录

4.1 帧率掉到30以下的问题

第一次完整跑起来，发现问题不是出在赛车数量多，而是出在UI文字每帧刷新上。我每帧都在创建新的字符串对象并赋值给Text.text，引擎底层要重新创建字体图集，这比想象中要昂贵得多。优化方案是：

• 只在数值变化时更新文字，用一个缓存值比较，相同则跳过。
• 减少文字刷新频率，比如圈数每秒刷新4次即可，速度值可以每帧更新，但使用预分配字符串，避免反复拼接新字符串。

开维引擎的调试工具game.debug.showFPS()可以实时显示帧率，建议开发时一直开着。碰到掉帧的第一步是打开开发者工具的Performance面板，查看是不是出现了密集的GC（垃圾回收）标记。如果是，说明代码里有大量临时对象产生。针对赛车游戏，最常见的是每帧new对象用于物理计算回调。解决方法是对象池：

class VectorPool { constructor() { this.pool = []; } get(x, y) { if (this.pool.length) { const v = this.pool.pop(); v.x = x; v.y = y; return v; } return { x, y }; } release(v) { this.pool.push(v); } }

4.2 碰撞穿透和“卡进墙里”的解法

如果赛车速度过快，在一帧内移动的距离大于碰撞体的厚度，就可能出现穿透。物理引擎默认的连续碰撞检测（CCD）并不总是开启，因为计算开销较大。

我遇到的具体情况是：赛车全速320像素/秒，游戏帧率如果掉到30，单帧移动就超过10像素；如果碰撞体比较薄，确实有可能穿过去。我采用了两个手段：

• 开启赛车的连续碰撞检测：把赛车碰撞体标记为ccd: true，物理引擎会按子步进方式检测碰撞。
• 限制最大速度：虽然物理上允许赛车更快，但我不希望它超过400像素/秒。在控制器速度更新后加一个钳位：this.speed = Math.min(this.speed, 420)，从源头减小穿透概率，同时避免赛道过大时极限速度下玩家根本控制不住。

至于“卡进墙里”，这通常是碰撞反弹方向错误导致的。排查方法：先把赛车初始位置放到墙壁正前方，速度设为0，然后手动施加一个恒力，观察碰撞后的分离方向是否正确。用开维引擎的调试绘制把碰撞接触点和法线画出来，一目了然。

4.3 资源加载与长时间运行的稳定性

赛车游戏虽然资源不多，但也会有贴图和音频加载顺序问题。我遇到过场景切换后贴图闪烁，原因是在资源没加载完成时就开始创建精灵。解法是加载完再进场景：

const loader = new Kaiwei.AssetLoader(); loader.addTexture('car', 'assets/car.png'); loader.addTexture('bg', 'assets/bg.png'); loader.addSound('boom', 'assets/boom.mp3'); loader.load().then(() => { game.scenes.switchTo('race'); });

在长时间运行上，最需要注意的是音频句柄泄漏和粒子残留。如果碰撞时持续创建新的音频实例而不释放，内存会一路涨上去。开维引擎的音频方法playSound(name)会自动管理实例，但如果你手动用createSound()，一定要在播放结束后调用stop()和destroy()。

还有一个看似不重要的点：本地存储。如果我实现了“最佳圈速记录”，每次比赛结束写入一个高分数值，长时间运行后如果频繁写localStorage，也可能产生性能问题。我的做法是只在比赛结算时写入，不在每帧写入。

4.4 一张常见问题速查表

5. 从这次实例中沉淀的一些体会

赛车小游戏是个好项目，规模不大，但五脏俱全。做完这个项目后，我最大的感受是游戏开发里80%的工作都是在与“帧”打交道：物理要按帧计算，输入要按帧读取，资源要保证不阻塞帧，优化要减少单帧工作量。开维引擎把这些底层逻辑封装得足够简洁，让我能把精力放在游戏玩法本身上，而不是反复造轮子。

如果让我给后来者提三个建议：

第一，赛车的物理参数不要拍脑袋定，建议写一个简单的参数调试面板，用滑块实时调整加速度、最大速度、转向灵敏度，找到手感最好的组合再固定下来。手感这个东西不实际跑起来根本不知道，只有在预览界面反复试车。

第二，碰撞调试一定打开绘制模式。面对“撞墙穿过去了”“被弹飞到天上”这类肉眼很难定位的问题，把碰撞体轮廓、法线、接触点全部画出来，几乎立刻就能锁定原因。

第三，预留输入抽象层。哪怕现在只做键盘，也把getInput()抽出来，后边接触屏摇杆、游戏手柄只是多写一个输入源的事，不然到最后接手柄时得在车辆逻辑里改一堆if (keys.isDown(...))，非常容易引入回归Bug。

这个项目后续还可以继续扩展的方向不少，比如加入多张地图选择、游戏内音效设置、不同性能参数的赛车选择、以及局域网对战等。文本后面我打算做的方向是加入一个简单的“漂移积分”系统，让玩家在弯道漂移时获得积分，并在HUD上显示漂移评级。开维引擎里实现这个功能不需要改动底层，只需要在赛车控制器里加入一个检测漂移状态的组件，然后每帧检测横向速度和纵向速度的比例即可。到时候有实际成品的体验数据，我会再整理一篇补充记录。

最后分享一个我在开发过程中觉得最值得的小技巧：引擎提供的物理步进模式有“固定步长”和“变长”两种，默认是变长，但在赛车这种对碰撞稳定性要求高的项目里，建议开启固定步长并锁定60Hz，把渲染用插值做平滑。虽然这个改动需要额外写一点插值逻辑，但换来的是极其稳定的物理表现，高速碰撞时的反馈完全一致，不会出现“有时穿墙有时不穿”的随机性问题。对我这种追求稳定复现的开发习惯来说，这个投入非常值得。