微信小游戏工程骨架

定义

微信小游戏工程骨架是文中为一款原创题材的微信小游戏试玩版手工搭出的底层结构。它出现的直接背景不是“想做一个更优雅的架构”，而是作者在复刻 合成经营小游戏 时，先去 GitHub 和各类开源社区寻找同类项目，结果发现找不到一套能直接复用、又真正贴近微信小游戏环境的现成源码。

文中明确指出，这类接近《绯闻港口》《Merge Mansion》的商业品类“大家都在闷声发大财”，公开可得的内容通常只有两种：

• 要么只是一个干瘪的二维数组合成 Demo；
• 要么只是和微信环境关系不大的纯 Web 网页示例。

因此，这个骨架并不是从成熟开源项目改造出来的，而是在“找不到现成同类微信小游戏商业源码可抄”的前提下，只能硬着头皮从零搭建出来的最小可运转结构。

在本文中的语境

这个概念出现在作者使用 Codex 做 8 天高强度实战时，是整个小游戏项目能够继续迭代的第一个真正落脚点。该项目并不是一个只有单一合成功能的网页玩具，而是要同时满足以下闭环：

• 45 个主线任务；
• 57 个基础与高级道具；
• 10 个多级物品生成器；
• 12 条剧情线索；
• 8 个场景修复目标；
• 9 个支线委托任务；
• 奖励飞行特效、原生音效反馈与新手引导；
• 最终还能在微信开发者工具里流畅预览，不爆包、不报错。

在这种高数据耦合前提下，如果直接让 AI 从第一行主循环盲打，结果往往只是“功能上像个合成棋盘，体验上死气沉沉，而且后续一改就乱”。所以作者先把工程强行拆层，再让 Codex 一层一层去啃。

六个核心文件与职责

文中给出的骨架由 6 个核心文件构成，每个文件都对应微信小游戏场景下最关键的一层职责。

1. game.js：唯一入口与微信 Canvas 初始化

game.js 是整个游戏的唯一入口，负责初始化微信 Canvas 上下文。

这里的“入口”不是普通网页里随便挂几个脚本就结束了，而是要围绕微信小游戏运行时组织启动顺序：什么时候拉起 Canvas，什么时候接管主循环，什么时候初始化资源与全局对象，都会影响后续输入、渲染和音效是否能正常协同。

它在这个骨架里的意义，是给整个小游戏提供统一启动点，避免 AI 在多处重复创建上下文、重复注册逻辑，导致初始化顺序失控。

2. data.js：策划配置层

data.js 负责管理核心配置，文中明确点名它要承接 57 个道具与 45 个任务之间的联动关系。

这不是简单放几个常量，而是承接合成经营项目中最容易爆炸的数据关系，例如：

• 某个道具的前置是什么；
• 后续能合成什么；
• 某个生成器产出哪些物品、概率如何；
• 哪个任务会消耗哪些物品；
• 哪个任务完成后解锁哪些区域或流程。

文中在后续还强调，45 个任务、57 个道具、10 个生成器之间只要有一个 ID 没对上，游戏就可能在运行中直接卡死。因此 data.js 承担的是“把策划变成结构化、可执行数据”的职责，而不是写文档式说明。

3. state.js：全局状态机

state.js 是全局状态机，负责管理存档、金币、体力和棋盘格子状态。

对合成经营游戏来说，这一层尤其关键，因为玩家操作并不只是“点击一下产生一个视觉结果”，而是会同时改动多类状态：

• 棋盘某一格是否占用；
• 某个道具是否被拖起、合成、销毁或升级；
• 当前金币数量是否增加；
• 体力是否被消耗；
• 某个任务的进度是否推进；
• 场景修复或剧情线索是否被触发。

如果没有专门的状态层，输入、渲染、任务和奖励逻辑就会互相直连，AI 每改一处都可能把另一处打崩。把这些状态集中到 state.js，本质上是在给后续迭代建立统一真相源。

4. input.js：触控交互层

input.js 负责视口交互，文中明确写到它要精准处理手指点击、长按、拖拽、吸附逻辑。

这层之所以被单独拆出，是因为合成经营类游戏的“爽感”很大程度就来自输入响应是否细腻。文中后续对体验拆解时提到：

• 手指点下生成器时要有微微下凹的物理反馈；
• 还要伴随清脆的点击声；
• 道具拖到相邻格子时需要有零点几秒的磁力吸附感；
• 不能只是松手后生硬地弹回原位。

这些体验都不是纯渲染问题，而是输入层必须先正确识别“点了什么、按了多久、拖到了哪里、是否满足吸附或合成条件”。因此 input.js 实际上是棋盘交互的前线。

5. renderer.js：Canvas 渲染核心

renderer.js 是 Canvas 渲染核心，负责动效绘制、粒子特效和帧率控制。

文中项目采用的是微信小游戏里的 Canvas 渲染路线，因此这层不仅要“把画面画出来”，还要承担体验节奏：

• 合成瞬间的金色粒子爆点；
• 道具由小变大再回弹的 Juice 动画；
• 任务完成后的结算牌展示；
• 金币沿贝塞尔曲线飞向右上角资源栏；
• 顶部资源栏的闪烁反馈；
• 在设备端尽可能维持稳定帧率。

这也是文中所谓“纯手工调优的状态机与 Canvas 渲染”的一部分。若渲染与状态、输入写死在一起，AI 很难只改动效而不误伤玩法逻辑。

6. audio.js：音效管理器

audio.js 是声音管理器，负责控制 11 种高频反馈音效的并发播放。

文中项目最终从上万个音频文件中筛出 11 个高质感音效，并把它们用于点击、合成成功、金币飞行、错误提示等高频反馈节点。把音效单独拆层的原因有两个：

• 一是音效触发点和玩法状态高度耦合，但播放控制又不应散落在各业务逻辑里；
• 二是微信小游戏环境下资源装载与并发播放都受运行时限制，必须统一管理，避免重复加载、路径混乱或播放冲突。

这套拆分的真正目的

文中反复强调，这种分层的目的不是代码美观，也不是为了写出一份教科书式的软件工程示意图。

它的核心价值是：让 Codex 这类 AI 编码工具能够按层理解问题、逐层修改，并在多轮迭代中尽量不把整个工程搅成一锅粥。

更具体地说，这种骨架解决的是以下几个现实问题：