森林冰火人游戏开发博客：从零到发布的完整技术路线

作者：Eddygit | 日期：2026-09-30 | 项目：森林冰火人游戏 (Forest Ice Fire)

一、技术路线

1.1 选型思考

开发一个双人合作闯关游戏，技术选型上有几个方向：

最终选择纯 Canvas + 原生 JavaScript，原因：

1. 游戏规模不大（3关、2角色），不需要重型引擎
2. 零依赖意味着任何浏览器直接打开即可游玩
3. 代码完全可控，适合学习和展示
4. 部署简单，只需静态文件托管

1.2 架构设计

index.html (入口)
    └── game.js (核心逻辑)
         ├── Player 类 (角色封装)
         ├── 关卡数据 (数据驱动)
         ├── 物理引擎 (重力/碰撞)
         ├── 粒子系统 (视觉效果)
         ├── 渲染系统 (Canvas绘制)
         └── 游戏循环 (状态机)

核心设计原则：数据与逻辑分离。关卡数据是纯 JSON 结构，游戏逻辑是通用引擎，添加新关卡只需增加数据，无需改逻辑。

二、技术心得

2.1 分轴碰撞检测的必要性

这是本次开发中最重要的技术决策之一。

错误做法（合并检测）：

// 先更新 x+y，再检测碰撞 → 角色可能卡进墙里
this.x += this.vx;
this.y += this.vy;
this.checkCollision(); // 无法确定是从哪个方向碰的

正确做法（分轴检测）：

this.x += this.vx;
this.collideX(); // 只处理水平碰撞，明确知道是左右碰墙
this.y += this.vy;
this.collideY(); // 只处理垂直碰撞，明确知道是上下碰地/碰头

分轴检测的好处：

• 碰撞方向明确，不会产生歧义
• 角色不会穿墙或卡在平台中
• onGround 状态判断准确（只有从上方碰撞才算落地）

2.2 数据驱动的关卡设计

每个关卡是一个独立的数据对象：

{
    name: "第一关：森林入口",
    p: [...平台],      // platforms
    h: [...障碍],      // hazards (fire/water/poison)
    g: [...宝石],      // gems
    d: [...门],        // doors
    m: [...移动平台],  // movingPlatforms
    fs: {x, y},        // fireStart
    ws: {x, y}         // waterStart
}

这种设计的好处：

• 添加关卡只需复制数据结构，修改坐标
• 关卡数据可以序列化为 JSON，未来可做关卡编辑器
• 游戏逻辑完全通用，不依赖具体关卡内容

2.3 粒子系统的轻量实现

没有使用物理引擎的粒子系统，而是用最简单的数组实现：

particles.push({x, y, vx, vy, life, color, size});
// 每帧更新：x+=vx, y+=vy, vy+=0.1, life--
// life<=0 时移除

关键优化：

• 粒子有生命周期，自动清理，不会内存泄漏
• 渲染时用 globalAlpha 实现渐隐，无需额外计算
• 限制粒子生成频率（每3帧生成一个），控制总量

2.4 角色类的封装

将火男孩和冰女孩封装为同一个 Player 类，通过 type 参数区分行为：

• 火男孩 type='f'：可过火池，碰水死
• 冰女孩 type='w'：可过水池，碰火死
• 毒池对两人都致命

这样避免了代码重复，新增角色类型只需扩展 checkHazards 方法。

三、实战经验

3.1 CodeArts 沙箱与文件系统

开发过程中尝试通过 CodeArts ACP 服务编写代码，发现沙箱使用 bwrap 隔离文件系统。虽然 CodeArts 日志显示文件写入成功，但主机文件系统不可见。

经验：在沙箱环境下开发时，需要注意文件系统的隔离性。最终选择直接在工作区编写代码，更可靠。

3.2 GitCode API 认证

创建 GitCode 仓库时，发现 token 认证方式有差异：

• Authorization: token <TOKEN> → 401 未授权
• private_token=<TOKEN> (query param) → ✅ 成功

经验：不同平台的 API 认证方式可能不同，需要查阅文档或尝试多种方式。

3.3 华为云开发者作品展览馆发布

发布流程涉及多个步骤：

1. IAM Domain 解析和 STS 凭证生成
2. DevBridge 隧道创建（暴露本地服务）
3. 封面截图生成（需要 Chromium + CJK 字体）
4. 详情文档打包
5. 训练营选择和作品提交

经验：

• preflight 检查需要安装 CJK 字体和 Chromium，首次运行较慢
• 华为云镜像源（mirrors.huaweicloud.cn）可以显著加速 yum 安装
• DevBridge 隧道可以安全暴露本地服务供外部访问
• STS 临时凭证比永久 AK/SK 更安全

3.4 游戏物理参数调优

物理参数对游戏体验影响巨大，经过多次调整：

• 重力 0.55：太小角色飘，太大角色重
• 跳跃 -12：需要能跳上大多数平台
• 速度 3.5：太快难控制，太慢无聊
• 摩擦 0.8：松开按键后平滑减速

经验：物理参数需要反复测试调整，建议从经典平台游戏参数参考开始。

四、存在问题与优化空间

4.1 当前问题

1. 无音效：游戏缺少背景音乐和音效，体验不够完整

   • 优化方案：使用 Web Audio API 生成简单音效，或引入音频文件

2. 无本地存储：通关进度不保存，刷新页面后丢失

   • 优化方案：使用 localStorage 保存通关记录和最佳成绩

3. 单人游玩限制：需要两人共用一个键盘，远程无法游玩

   • 优化方案：引入 WebSocket 实现在线双人联机

4. 关卡数量有限：目前仅3关，内容量不足

   • 优化方案：设计关卡编辑器，支持社区创作

5. 碰撞检测精度：AABB 碰撞在高速移动时可能穿透

   • 优化方案：引入连续碰撞检测（CCD）或限制最大速度

6. 移动端不支持：键盘操作无法在手机上游玩

   • 优化方案：添加虚拟摇杆和按钮

4.2 架构优化

1. 代码模块化：目前 game.js 是单文件，可拆分为多个模块

   • player.js、level.js、physics.js、renderer.js、particle.js
   • 使用 ES6 import/export 或打包工具

2. 状态管理：游戏状态切换较简单，可引入状态机模式

   • 更清晰的状态转换逻辑
   • 支持暂停、恢复等更多状态

3. 渲染优化：

   • 离屏 Canvas 缓存静态背景
   • 视口裁剪，只渲染可见区域
   • 批量绘制减少 Canvas API 调用

4. 测试覆盖：

   • 添加单元测试验证物理引擎
   • 端到端测试验证游戏流程
   • 性能基准测试

4.3 功能扩展

1. 更多角色：毒男孩、电女孩等新角色类型
2. 道具系统：加速、跳跃增强、无敌等
3. 排行榜：在线排行榜和成绩分享
4. 成就系统：收集所有宝石、不死亡通关等
5. 关卡编辑器：可视化编辑关卡并分享

五、总结

这次开发经历覆盖了从游戏设计、编码实现到云端发布的完整流程：

• 游戏开发：纯 Canvas + JS 实现完整的平台跳跃游戏
• 版本管理：Git + GitCode 仓库托管
• 云端发布：华为云开发者作品展览馆全流程

最深刻的体会是：简单技术栈也能做出有趣的游戏。不需要 Unity、不需要 Phaser，纯 Canvas + JS 就能实现一个有物理引擎、粒子系统、多关卡的双人合作游戏。关键在于把基础做好——分轴碰撞、数据驱动、面向对象封装。

发布到华为云开发者作品展览馆的流程虽然步骤多，但每一步都有明确的脚本和自动化支持，整体体验流畅。DevBridge 隧道让本地服务可以安全暴露给外部访问，STS 临时凭证保证了安全性。

本文原创发布于 GitCode 仓库，转载请注明出处。