用 TRAE SOLO 打造全平台复古游戏云平台：支持 FC/MD/SFC/GB/GBA，云存档/云录像/联机对战全搞定

SOLO挑战赛专区
1

正文内容

1. 摘要

我是一名全栈开发者，使用 TRAE SOLO 在 10 天时间内完成了一个 全平台复古游戏云平台 的开发。项目在原有 FC 模拟器基础上，扩展支持了 Sega Genesis (MD)、Super Nintendo (SFC)、Game Boy、Game Boy Advance 共五大经典主机平台。实现了用户系统、云游戏加载、跨平台云存档、云截图、云录像、P2P 联机对战等完整功能。从架构设计到前后端代码、Docker 部署，全程由 SOLO 辅助完成，真正实现了「一个人就是一个游戏平台团队」。

2. 背景

【我的角色】：独立开发者，热衷于探索「云游戏 + 怀旧游戏」的技术结合点。在完成第一版 FC 云游戏 MVP 后，我决定挑战更复杂的场景：同时支持多个完全不同架构的游戏平台，并让所有云端功能（存档、录像、联机）统一工作。

【本次任务场景】：参加 TRAE × 脉脉「AI 无限职场」SOLO 挑战赛，我给自己设定了三个硬性目标：

  1. 多平台覆盖：不止 FC，还要支持 MD、SFC、GB、GBA

  2. 云端三件套：云存档、云截图、云录像（含转码） 全做齐

  3. 真·联机：实现 P2P 对战，不只是本地双打

为什么选择这个场景？

  • :video_game: 怀旧游戏受众极广，多平台能覆盖更多用户场景

  • :cloud: 不同主机的模拟器核心、手柄映射、存档格式差异巨大，是对 AI 复杂需求理解能力的极好测试

  • :movie_camera: 云录像涉及前端 MediaRecorder + 后端 FFmpeg 队列，是典型的「全链路」功能

  • :link: 联机功能涉及 WebRTC + 信令服务器，是传统全栈项目的难点

核心挑战拆解：

  1. 如何让一个前端同时加载 NES / Genesis / SNES / GB / GBA 五种不同的模拟器核心？

  2. 如何统一处理不同平台的存档（状态快照格式各自不同，但 EmulatorJS 做了抽象）？

  3. 如何实现跨平台的录像（录屏 + 混音）并转码存储？

  4. 如何在不增加复杂度的前提下加入 P2P 联机？

  5. 如何用一套数据库设计支撑所有平台的游戏元数据、存档、截图、录像？

3. 实践过程

整个开发周期 10 天，完全依赖 TRAE SOLO 辅助完成。开发顺序严格遵循依赖关系：数据库 → 用户认证 → 游戏大厅 → 模拟器核心（逐平台添加）→ 云存档 → 云截图 → 云录像 → 联机扩展。

第一阶段：架构升级与技术选型（约半天）

在第一版 FC 方案的基础上，与 SOLO 讨论多平台扩展方案。SOLO 给出的关键决策：

需求 推荐方案 理由
多平台模拟器 EmulatorJS multi-core 原生支持 NES/SNES/Genesis/GBA/GB，一套 API 统一存档/截图
平台识别 platform 字段枚举 数据库表统一扩展，前端按 platform 动态加载核心
录像转码 BullMQ + FFmpeg 解耦前端上传和后端处理，支持队列重试
联机方案 PeerJS + Socket.io 信令 浏览器端 WebRTC 封装简单，与 EmulatorJS 的联机示例兼容

SOLO 还生成了扩展后的 games 表结构，增加了 platform、emulator_core 等字段，并给出了五平台的核心映射表。

第二阶段：数据库与用户系统（约 1 天）

在第一版基础上，SOLO 帮助修改了所有相关表结构，统一添加 platform 字段，并生成了联合唯一索引 (user_id, game_id, platform, slot_id)，确保同一游戏不同平台的存档互不干扰。同时优化了 user_sessions 表，支持多设备登录时的 Refresh Token 轮换。

这一阶段 SOLO 的效率极高：我只需说「存档表需要区分平台」，它就能自动修改 DDL 并给出相应的 TypeScript 类型定义。

第三阶段：游戏大厅与 ROM 存储（约 1.5 天）

前端游戏大厅增加了平台筛选标签（FC/MD/SFC/GB/GBA），每个游戏卡片显示平台图标。SOLO 帮助实现了：

  • 按平台分页加载的 API 封装

  • ROM 文件从 MinIO 流式加载，支持进度条

  • 前端 IndexedDB 缓存 ROM，第二次游玩瞬时启动

其中遇到一个挑战：不同平台的 ROM 文件大小差异巨大（GB 几 MB，GBA 最大 32MB），流式加载需要适配不同的 chunk 大小。SOLO 给出了基于 Range 请求的分块加载方案，并自动处理了浏览器兼容性。

第四阶段：多平台模拟器核心集成（约 2.5 天）

这是工作量最大的阶段。我的策略是 先集成 NES 作为基础框架，再逐平台添加。

SOLO 生成了 EmulatorService 类，核心代码如下：

typescript

const PLATFORM_CONFIG = {
  nes: { system: 'nes', core: 'fceumm' },
  md:  { system: 'sega/genesis', core: 'genesis_plus_gx' },
  sfc: { system: 'snes', core: 'snes9x' },
  gb:  { system: 'gb', core: 'mgba' },
  gba: { system: 'gba', core: 'mgba' }
};

async init(platform, romData) {
  const cfg = PLATFORM_CONFIG[platform];
  this.emulator = new EJS({
    system: cfg.system,
    core: cfg.core,
    gameUrl: URL.createObjectURL(new Blob([romData])),
    onSaveState: (state) => this.uploadSave(state),
    onFrame: () => this.checkForAutoScreenshot()
  });
}

调试过程中遇到的最大问题是 GBA 核心的音频延迟。SOLO 通过分析 EmulatorJS 文档，建议在初始化时增加 audioLatency: 0 配置，并将音频上下文采样率强制设为 44100Hz，问题解决。

移动端适配方面，SOLO 生成了动态手柄布局：根据当前平台显示不同的按键集合（FC 有 Select/Start，MD 有六键布局，GBA 有 L/R 肩键）。NippleJS 摇杆的方向映射对五大平台统一。

第五阶段：云存档与云截图（约 1.5 天）

云存档功能在多平台下保持一致的用户体验：手动保存（5 个槽位）+ 自动保存（每 60 秒 + 退出时）。SOLO 帮助实现了：

  • 前端定时器自动调用 emulator.saveState()，将 Base64 数据上传

  • 后端使用 INSERT ... ON CONFLICT DO UPDATE 实现 upsert

  • 存档列表页面支持按平台筛选，每个存档带缩略图预览

截图功能：利用 canvas.toDataURL() 捕获当前帧，添加水印（平台标签 + 游戏名称），上传到 MinIO。SOLO 自动生成了水印绘制的 Canvas 代码，并支持中英文文字换行。

第六阶段：云录像功能（约 2 天）

录像功能是本次项目的亮点之一。SOLO 提供的完整方案：

  1. 前端录制：使用 canvas.captureStream(60) 捕获游戏画面，AudioContext.createMediaStreamDestination() 捕获模拟器音频，通过 MediaRecorder 录制为 WebM 格式。

  2. 分块上传：支持录像时长最大 30 分钟，分块上传（每 10 秒一个 chunk），避免内存溢出。

  3. 后端转码：BullMQ 队列 + FFmpeg 将 WebM 转为 H.264 MP4，同时生成缩略图。

SOLO 自动生成了 recording-worker.ts 的完整代码，包括 FFmpeg 命令行构建、进度回调、错误重试。录制的视频文件存储在 MinIO 中，并关联到对应的游戏和平台。

其中遇到的坑：WebM 在部分浏览器无法直接播放。SOLO 建议使用 FFmpeg 添加 -movflags +faststart 参数，并将音频转为 AAC 格式，最终生成的 MP4 在所有现代浏览器中均可流畅播放。

第七阶段：P2P 联机对战（约 1.5 天）

联机功能利用了 EmulatorJS 内置的 NetPlay 能力 + PeerJS 封装。SOLO 帮助实现了：

  • 信令服务器：基于 Socket.io，处理房间创建、加入、用户列表同步。

  • WebRTC 连接：使用 PeerJS 简化 offer/answer 交换和 ICE 候选处理。

  • 输入同步：双方玩家的按键通过 DataChannel 实时广播，每个模拟器实例同时应用本地和远端的输入。

联机测试时选择了《魂斗罗》（FC）和《怒之铁拳》（MD）两款双打游戏，延迟稳定在 30-70ms，体验流畅。SOLO 还生成了联机房间的 UI 组件，包括房间码展示、准备状态、聊天框。

第八阶段：部署上线与文档（约 0.5 天）

最终使用 Docker Compose 一键部署所有服务（PostgreSQL、Redis、MinIO、Coturn、后端、前端）。SOLO 生成了生产环境的 Nginx 配置（SSL、反向代理、静态资源缓存），以及 GitHub Actions 的 CI/CD 流程模板。

4. 成果展示

:video_game: 项目 GitHub 仓库

  • 地址：:green_circle: （EMU_Matrix）

  • 完整开源，包含前端、后端、数据库迁移脚本、Docker 配置、FFmpeg 转码 Worker 等

:globe_with_meridians: 在线 Demo

  • 演示链接：:green_circle: （还未申请云服务器部署，稍后补上）

  • 支持 PC / 手机 / 平板，五大平台游戏即点即玩，所有云端功能全平台通用

:package: 功能清单

功能 完成度 支持平台 说明
用户注册登录 :white_check_mark: 全部 JWT 双 Token，多设备管理
游戏大厅 :white_check_mark: FC/MD/SFC/GB/GBA 平台筛选、搜索、收藏、最近玩过
云游戏加载 :white_check_mark: 全部 CDN 流式加载 + IndexedDB 缓存
云存档 :white_check_mark: 全部 手动 5 槽位 + 自动存档，跨设备同步
云截图 :white_check_mark: 全部 一键截图，水印，画廊分享
云录像 :white_check_mark: 全部 前端录制 + 后端 FFmpeg 转码，支持 30 分钟
P2P 联机 :white_check_mark: FC/MD（可扩展） 房间系统，实时输入同步
移动端适配 :white_check_mark: 全部 动态虚拟手柄（按键布局适配平台）
Docker 部署 :white_check_mark: 全部 一键启动全部服务

:framed_picture: 可视化展示

（平台部署后会插入截图，包括：游戏大厅按平台筛选界面、任一平台的游戏运行画面 + 虚拟摇杆、云存档管理列表、云录像播放页面、联机房间界面）

5. 效果与总结

:bullseye: SOLO 帮我做了什么？

场景 传统方式 SOLO 辅助后
多平台核心映射 查阅 EmulatorJS 文档 2 小时 SOLO 直接给出配置表 + TypeScript 类型
GBA 音频延迟 Bug 调试半天未必找到原因 SOLO 分析后建议 audioLatency 配置，10 分钟修复
录像转码队列 需要自学 BullMQ + FFmpeg 命令行 SOLO 生成完整 Worker 代码，包含重试和错误处理
WebRTC 联机信令 手动处理 offer/answer 繁琐 SOLO 生成 PeerJS 封装，房间管理 + DataChannel 一行搞定
总开发周期 6-8 周（一人全栈） 10 天完成五大平台 + 录像 + 联机

:light_bulb: 可复用的方法

  1. “平台优先”思路：先让一个平台（NES）跑通全部流程，再通过配置文件扩展其他平台。SOLO 很容易理解这种「模板 + 配置」模式。

  2. 录像分块上传 + 队列转码：这种经典异步模式用自然语言描述后，SOLO 能直接生成完整代码，比手写快 10 倍。

  3. 联机先用信令模拟：在真实 WebRTC 连接之前，SOLO 帮我生成了一个「模拟联机」模式（通过信令服务器转发输入），便于调试 UI，然后再切换到 P2P。

:thinking: 关于 AI 工作方式的思考

本次项目让我深刻体会到：SOLO 是真的帮到了我，就这么简单。

对于其他想尝试全栈项目的开发者，我的建议是：

让 AI 做“开发伙伴”——把不同平台、不同服务的差异抽象成配置，然后让 SOLO 生成所有重复性代码。你只需要关注“哪些地方是对的”。

:pushpin: 作品提交信息

  • 参赛赛道：Code With SOLO

  • 作品类型：Web 全栈应用（多平台云游戏）

  • 提交时间：2026 年 5 月

  • GitHub 仓库：:green_circle: （EMU_Matrix）

  • 在线演示：:green_circle: （还未申请云服务器部署，稍后补上）

欢迎体验和留言互动！感谢大家的投票。