开维引擎做赛车小游戏这个组合是我从立项到跑完第一局觉得最值得记录的一次实践。很多朋友一提到“游戏引擎”就想到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 * dty 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 vitelatest 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 一张常见问题速查表现象可能原因定位思路解决方案赛车转弯不跟手转向速度因子设置不当打印速度与转向效率的关系曲线调整steerFactor公式降低高速时的转向衰减速度高速穿墙单帧移动距离超过碰撞体厚度开启CCD或降低最大速度给碰撞体设置ccd: true并做速度钳位圈数乱计数起跑线判断逻辑过于简单单步走路径经过起跑线打印计数变化改用检查点顺序累计法帧率逐渐降低内存泄漏或对象池溢出观察内存曲线检查每帧创建的对象数对碰撞临时向量做对象池释放音频实例碰撞后赛车反弹异常碰撞法线方向错了开启调试绘制碰撞法线统一法线方向朝外为正UI文字闪烁或模糊每帧更新同一文本导致重绘关闭UI图集缓存再观察值变化时才更新文字内容AI车反复撞墙目标路点选择条件不对打印AI当前路点索引和目标点优化点积判断逻辑加入卡死恢复5. 从这次实例中沉淀的一些体会赛车小游戏是个好项目规模不大但五脏俱全。做完这个项目后我最大的感受是游戏开发里80%的工作都是在与“帧”打交道物理要按帧计算输入要按帧读取资源要保证不阻塞帧优化要减少单帧工作量。开维引擎把这些底层逻辑封装得足够简洁让我能把精力放在游戏玩法本身上而不是反复造轮子。如果让我给后来者提三个建议第一赛车的物理参数不要拍脑袋定建议写一个简单的参数调试面板用滑块实时调整加速度、最大速度、转向灵敏度找到手感最好的组合再固定下来。手感这个东西不实际跑起来根本不知道只有在预览界面反复试车。第二碰撞调试一定打开绘制模式。面对“撞墙穿过去了”“被弹飞到天上”这类肉眼很难定位的问题把碰撞体轮廓、法线、接触点全部画出来几乎立刻就能锁定原因。第三预留输入抽象层。哪怕现在只做键盘也把getInput()抽出来后边接触屏摇杆、游戏手柄只是多写一个输入源的事不然到最后接手柄时得在车辆逻辑里改一堆if (keys.isDown(...))非常容易引入回归Bug。这个项目后续还可以继续扩展的方向不少比如加入多张地图选择、游戏内音效设置、不同性能参数的赛车选择、以及局域网对战等。文本后面我打算做的方向是加入一个简单的“漂移积分”系统让玩家在弯道漂移时获得积分并在HUD上显示漂移评级。开维引擎里实现这个功能不需要改动底层只需要在赛车控制器里加入一个检测漂移状态的组件然后每帧检测横向速度和纵向速度的比例即可。到时候有实际成品的体验数据我会再整理一篇补充记录。最后分享一个我在开发过程中觉得最值得的小技巧引擎提供的物理步进模式有“固定步长”和“变长”两种默认是变长但在赛车这种对碰撞稳定性要求高的项目里建议开启固定步长并锁定60Hz把渲染用插值做平滑。虽然这个改动需要额外写一点插值逻辑但换来的是极其稳定的物理表现高速碰撞时的反馈完全一致不会出现“有时穿墙有时不穿”的随机性问题。对我这种追求稳定复现的开发习惯来说这个投入非常值得。