1. 一个人做微信小游戏为什么我选了这条最难走的路去年年底我做了个决定把手上接的外包项目全推掉用三个月时间独立做一款微信小游戏。身边做开发的朋友第一反应都是你疯了第二反应是一个人做游戏美术、策划、程序、运营全包你扛得住吗。说实话当时我心里也没底但我想验证一件事在现在这个工具链成熟度下一个人到底能不能跑通从零到上线的完整闭环。先说说我为什么盯上了微信小游戏这个方向。最直接的原因是流量入口。微信小游戏不需要用户去应用商店下载点开就能玩分享到群里就是天然的传播链路。对于独立开发者来说获客成本这一项就能省下一大笔。另一个原因是技术栈的收敛。微信小游戏本质上是跑在微信环境里的 JavaScript 应用底层渲染依赖 Canvas这意味着我只要把 Canvas 这一套吃透前端那点功底就能直接复用不用再去啃 Android 或 iOS 的原生开发。但真正让我下定决心的是 Cocos Creator 这个引擎的成熟。早几年做小游戏要么用原生 Canvas 手撸要么用 Egret、LayaAir 这些引擎各有各的坑。Cocos Creator 现在的版本对微信小游戏的适配做得相当到位一键构建、一键预览甚至能直接在微信开发者工具里调试。我试过用纯 Canvas 写一个简单的消除类游戏光是处理触摸事件和帧同步就写了一周换成 Cocos Creator 之后同样的逻辑两天就跑通了。这篇文章我想聊的不是微信小游戏有多好而是一个人怎么用最少的资源把这件事做成。我会把整个流程拆开从技术选型、项目结构、核心玩法实现到打包上线、踩过的坑全部摊开来讲。如果你也是独立开发者或者想试试用业余时间做个小游戏这篇内容应该能帮你省下不少试错的时间。2. 技术选型为什么是 Cocos Creator 而不是纯 Canvas2.1 纯 Canvas 方案的诱惑与陷阱刚开始我确实想过用纯 Canvas 来写。理由很简单没有引擎的包袱。微信小游戏的基础库本身就提供了wx.createCanvas()接口拿到 Canvas 上下文之后fillRect、drawImage、arc这些 API 直接就能用。对于一个简单的 2D 游戏来说理论上几百行代码就能跑起来。我实际动手试了一个下午写了个小金鱼捏捏的交互 demo——就是那种点击屏幕金鱼会膨胀、会游动的小玩意。用 Canvas 画一条鱼用requestAnimationFrame驱动动画触摸事件用wx.onTouchStart监听确实能跑。但问题很快就暴露了资源管理全靠手动。图片加载、音频播放、场景切换每一个都要自己写加载器和状态机。我写了一个简单的资源管理器代码量直接飙到 800 行。坐标系和适配是噩梦。不同机型的屏幕比例不一样Canvas 的尺寸要动态计算UI 元素的位置要按比例缩放。我试过用wx.getSystemInfoSync()拿到屏幕宽高然后手动算缩放系数结果在 iPad 上测试的时候按钮直接跑到屏幕外面去了。动画和缓动要自己实现。一个简单的弹跳效果我得手写贝塞尔曲线插值。虽然不难但每个动画都要重复这套逻辑代码复用率极低。最要命的是调试成本。纯 Canvas 方案没有场景编辑器所有元素的位置、层级、动画都要靠代码控制。改一个按钮的位置我得改代码、重新编译、再预览一轮下来五分钟没了。这种反馈速度做复杂一点的游戏根本扛不住。2.2 Cocos Creator 的核心优势换成 Cocos Creator 之后最大的感受是可视化编辑带来的效率提升。场景里的节点可以拖拽、可以嵌套、可以实时预览UI 布局用 Widget 组件自动适配屏幕不用再手算坐标。我那个金鱼 demo 用 Cocos 重写代码量从 800 行降到了 200 行出头而且适配问题引擎已经帮我处理好了。具体来说Cocos Creator 对微信小游戏的支持体现在几个层面构建流程的自动化。在 Cocos Creator 的构建面板里选择微信小游戏平台填上 AppID点构建引擎会自动生成game.json、project.config.json这些配置文件还会把资源打包成微信小游戏要求的格式。构建完成后直接用微信开发者工具打开构建目录就能预览和调试。整个过程不需要手动改任何配置文件。渲染层的适配。微信小游戏的渲染环境是基于 Canvas 2D 的Cocos Creator 的渲染引擎会自动把场景里的节点转换成 Canvas 的绘制指令。我试过在场景里放 200 个精灵节点帧率依然稳定在 60 帧说明引擎的合批优化做得不错。API 的桥接。微信小游戏提供的wx系列 API比如登录、分享、广告、支付Cocos Creator 都有对应的封装。比如调用wx.login获取用户 code引擎提供了cc.sys和wx的全局对象直接调用就行不用再写额外的适配层。2.3 引擎选型的对比表格为了让你更直观地看到差异我整理了一个对比表格基于我实际使用和测试的结果对比维度纯 CanvasCocos Creator其他引擎如 LayaAir上手难度低但复杂逻辑难维护中等需要学编辑器中等文档相对少可视化编辑无完整场景编辑器有但体验一般微信小游戏适配手动处理一键构建需要额外配置资源管理全手写内置资源系统内置但不够灵活动画系统手写插值内置缓动和动画编辑器有但功能较弱包体大小最小中等引擎约 1.5MB中等社区活跃度低高中文文档完善中等适合场景极简 demo中小型完整游戏特定类型游戏提示包体大小是微信小游戏的一个硬指标主包不能超过 4MB。Cocos Creator 的引擎核心加上一个简单游戏构建后大约在 2MB 左右还有空间放资源。如果包体紧张可以在构建时勾选分离引擎把引擎放到分包里。2.4 我的最终选择逻辑选 Cocos Creator 的核心逻辑是用引擎的复杂度换我的开发效率。一个人做游戏时间是最稀缺的资源。引擎带来的那点包体开销和学习成本比起手写资源管理、动画系统、适配逻辑的时间完全不值一提。当然如果你的游戏极其简单比如就是一个点击计数的工具那纯 Canvas 确实更轻。但只要涉及到多场景、多动画、多资源引擎就是必选项。我后来做的那个小游戏场景有五个精灵资源上百个动画几十组用纯 Canvas 写我估计得两个月用 Cocos Creator 三周就搞定了。3. 项目结构拆解一个人怎么组织代码和资源3.1 目录结构的规划原则一个人做项目最容易犯的错就是文件乱放。今天写个脚本扔在根目录明天加个图片扔在 assets 外面过两周自己都找不到东西。我在项目开始前花了半天时间规划目录结构后面三个月基本没再调整过。Cocos Creator 的项目结构有它自己的约定assets目录是资源根目录所有脚本、图片、音频、场景都必须放在这里面。在这个基础上我按功能模块做了二级划分assets/ scripts/ # 所有脚本 core/ # 核心逻辑如游戏管理器、事件系统 ui/ # UI 相关脚本 gameplay/ # 玩法逻辑 utils/ # 工具函数 textures/ # 图片资源 ui/ # UI 图片 characters/ # 角色图片 effects/ # 特效图片 audio/ # 音频资源 bgm/ # 背景音乐 sfx/ # 音效 scenes/ # 场景文件 prefabs/ # 预制体 animations/ # 动画文件这个结构的好处是职责清晰。找脚本去 scripts找图片去 textures不会混在一起。而且 Cocos Creator 的构建系统会按目录打包资源合理的目录划分能让构建后的包体更小——因为没被引用的资源会被自动剔除。3.2 核心脚本的分层设计脚本层面我分了三层核心层、逻辑层、表现层。核心层放的是游戏管理器、事件总线、存档系统这些全局单例。比如GameManager.ts负责游戏状态切换EventBus.ts负责模块间通信StorageManager.ts负责本地存档。这些脚本不依赖具体的玩法换一个游戏也能复用。逻辑层是具体的玩法实现。比如我做的是一个合成类游戏那MergeLogic.ts负责合成规则LevelManager.ts负责关卡数据ScoreManager.ts负责分数计算。这一层只处理数据不碰渲染。表现层是 UI 和动画。UIManager.ts负责面板的打开关闭EffectPlayer.ts负责特效播放AudioManager.ts负责音频控制。这一层只负责怎么显示不关心数据是什么。分层的核心目的是解耦。玩法逻辑改了不用动 UI 代码UI 改版了不用动玩法逻辑。我一个人维护整个项目最怕的就是改一处崩三处分层能把这个风险降到最低。3.3 资源命名的规范资源命名我踩过坑。刚开始用中文命名比如背景图.png、按钮_开始.png在编辑器里看着挺清楚但构建的时候偶尔会出问题而且代码里引用中文路径很别扭。后来统一改成英文加下划线的格式图片ui_bg_main.png、btn_start.png、char_fish_01.png音频bgm_main.mp3、sfx_click.mp3、sfx_merge.mp3预制体prefab_item.prefab、prefab_popup.prefab场景scene_main.scene、scene_game.scene前缀的作用是分类ui_是界面元素btn_是按钮char_是角色sfx_是音效。在编辑器的资源面板里按名称排序同类型的资源会自动聚在一起找起来很快。注意微信小游戏的资源路径对大小写敏感。在 Windows 上开发时可能没问题但构建到微信开发者工具里Btn_Start.png和btn_start.png会被当成两个不同的文件。统一用小写能避免这个坑。3.4 版本管理的实操建议一个人做项目也要用 Git。我见过太多独立开发者因为没做版本管理改崩了代码只能重写。Cocos Creator 项目用 Git 有几个注意点library和temp目录要加到.gitignore这两个是编辑器生成的缓存不需要提交。assets目录下的.meta文件必须提交这些文件记录了资源的 UUID 和导入设置丢了会导致引用断裂。场景文件.scene是 JSON 格式合并冲突很难处理。我的做法是同一时间只在一个分支上改场景避免多人虽然我就一个人同时修改。我用的分支策略很简单main分支放稳定版本dev分支放开发中的代码每完成一个功能就合并回main并打一个 tag。这样即使改崩了也能随时回滚到上一个稳定版本。4. 核心玩法实现从 Canvas 绘图到游戏逻辑4.1 Canvas 绘图在 Cocos Creator 中的实际应用虽然 Cocos Creator 封装了渲染层但有些效果还是得直接操作 Canvas。比如我做的一个捏捏乐玩法需要根据触摸位置实时绘制形变效果这种动态绘制用引擎的节点系统反而麻烦直接拿 Canvas 上下文来画更直接。在 Cocos Creator 里获取 Canvas 上下文的方式是// 获取微信小游戏的 Canvas 上下文 const canvas wx.createCanvas(); const ctx canvas.getContext(2d); // 在 Cocos Creator 中可以通过 cc.game.canvas 获取当前 Canvas const engineCanvas cc.game.canvas; const engineCtx engineCanvas.getContext(2d);但要注意Cocos Creator 的渲染和直接操作 Canvas 是两套体系。引擎每帧会清空 Canvas 并重新绘制所有节点如果你在引擎渲染之后画东西下一帧就会被覆盖。正确的做法是创建一个自定义的 RenderComponent在引擎的渲染流程中插入自己的绘制逻辑。我实际用的方案是用 Graphics 组件代替直接操作 Canvas。Cocos Creator 的cc.Graphics组件封装了常用的绘图 API比如moveTo、lineTo、circle、fill而且它会被引擎的渲染系统管理不用担心被覆盖。对于那个捏捏乐效果我用 Graphics 画了一个可变形的圆形触摸时根据力度调整控制点效果和直接操作 Canvas 差不多但代码更干净。4.2 触摸事件的处理与优化微信小游戏的触摸事件通过wx.onTouchStart、wx.onTouchMove、wx.onTouchEnd来监听。Cocos Creator 对这些事件做了封装在节点上添加cc.Node.EventType.TOUCH_START等监听器就能用。但有个坑我踩过触摸事件的穿透问题。当两个 UI 面板叠在一起时点击上层面板的按钮下层面板也会收到事件。解决方案是在上层面板的根节点上添加一个BlockInputEvents组件它会拦截所有触摸事件阻止向下传递。另一个优化点是触摸频率。微信小游戏的触摸事件触发频率和屏幕刷新率相关大概每秒 60 次。如果每次触摸都做复杂计算会导致帧率下降。我的做法是在TOUCH_MOVE事件里只记录位置实际的计算放到update里做这样能把计算频率和渲染帧率对齐。// 触摸事件只记录数据 onTouchMove(event) { this.touchPos event.getLocation(); } // 实际逻辑在 update 中处理 update(dt) { if (this.touchPos) { this.handleTouch(this.touchPos); } }4.3 游戏状态机的设计一个人做游戏状态管理很容易写成一团乱麻。我一开始用一堆布尔变量来标记状态比如isPlaying、isPaused、isGameOver结果状态一多就出现矛盾——比如isPlaying和isGameOver同时为 true。后来改成了有限状态机的模式。定义几个明确的状态Ready、Playing、Paused、GameOver每个状态有进入和退出的回调状态之间的切换有明确的规则。const GameState { READY: ready, PLAYING: playing, PAUSED: paused, GAME_OVER: game_over }; class StateMachine { constructor() { this.currentState GameState.READY; this.transitions { [GameState.READY]: [GameState.PLAYING], [GameState.PLAYING]: [GameState.PAUSED, GameState.GAME_OVER], [GameState.PAUSED]: [GameState.PLAYING, GameState.GAME_OVER], [GameState.GAME_OVER]: [GameState.READY] }; } changeState(newState) { const allowed this.transitions[this.currentState]; if (allowed allowed.includes(newState)) { this.onExit(this.currentState); this.currentState newState; this.onEnter(newState); } } }这套状态机的好处是不可能出现非法状态。比如游戏结束后不能直接跳到暂停必须先回到 Ready 再开始。代码逻辑清晰调试的时候一眼就能看出当前处于什么状态。4.4 数据存储与排行榜微信小游戏提供了wx.setStorageSync和wx.getStorageSync来做本地存储容量上限是 10MB。对于存档数据来说完全够用。我的做法是把游戏进度序列化成 JSON 字符串存进去读取的时候反序列化。排行榜这块微信小游戏有开放数据域的概念。开放数据域是一个独立的 JavaScript 运行环境可以访问微信的好友关系链数据但不能访问主域的资源。主域和开放数据域之间通过postMessage通信。我实现排行榜的流程是这样的主域在需要显示排行榜时调用wx.getOpenDataContext()获取开放数据域上下文。主域通过postMessage把当前分数传给开放数据域。开放数据域调用wx.getFriendCloudStorage获取好友的分数数据排序后绘制到共享 Canvas 上。主域把共享 Canvas 的内容渲染到屏幕上。这里有个坑开放数据域的 Canvas 尺寸是固定的不能动态调整。我一开始想做一个全屏的排行榜结果发现共享 Canvas 只有 960x640 的分辨率放大后会模糊。后来改成只占屏幕中间一块区域效果就好多了。5. 打包上线从构建到发布的完整流程5.1 构建配置的关键参数Cocos Creator 的构建面板里有一堆参数我挑几个关键的讲。主包压缩类型。默认是合并依赖会把所有脚本打包成一个文件。如果脚本很多可以改成分离依赖按模块拆分加快加载速度。我试过两种方式对于中小型游戏来说差异不大默认的就行。资源服务器地址。如果游戏资源超过了主包 4MB 的限制需要把部分资源放到远程服务器。填上 CDN 地址后构建时会生成远程资源的清单游戏运行时自动下载。我做的游戏资源不多主包 2.3MB没用远程资源。引擎分离。勾选后引擎代码会被单独打包成一个文件可以放到分包里。这个选项能有效减小主包体积但会增加一次加载请求。我的建议是如果主包接近 4MB就勾上如果主包很宽裕不勾也行。MD5 缓存。勾选后资源文件名会带上 MD5 哈希值用于版本更新时的缓存控制。微信小游戏本身有缓存机制但加上 MD5 更保险能确保用户拿到的是最新版本。5.2 微信开发者工具的调试技巧构建完成后用微信开发者工具打开构建目录就能预览游戏了。调试这块我总结了几个实用技巧真机调试。模拟器上的表现和真机有差异尤其是性能相关的。点击工具栏的真机调试用手机扫码就能在真机上运行同时电脑上会显示 console 输出。我遇到过一个 bug模拟器上正常真机上触摸没反应最后发现是触摸事件的坐标系在真机上不一样用真机调试才定位到。性能面板。开发者工具的性能面板可以看帧率、内存、DrawCall 等指标。微信小游戏的 DrawCall 建议控制在 100 以内超过的话要考虑合批。我的游戏在场景复杂的时候 DrawCall 会到 80 左右还在安全范围内。vConsole。微信小游戏内置了 vConsole在真机上可以通过特定操作调出日志面板。具体是在游戏的game.json里配置debug: true然后在真机上摇一摇手机就能看到。这个对于排查真机上的问题非常有用。5.3 上线前的检查清单上线前我列了一个检查清单逐项确认检查项说明是否必须包体大小主包不超过 4MB总包不超过 20MB必须首屏加载时间控制在 3 秒以内建议适配测试至少覆盖 3 种不同比例的机型必须网络异常处理断网时有提示不崩溃必须分享功能分享卡片能正常显示必须广告接入激励视频能正常播放和回调按需隐私协议符合平台要求必须版本号每次提交递增必须提示微信小游戏的审核比较严格尤其是涉及用户数据和广告的。提交前仔细阅读平台的运营规范避免因为小问题被驳回。我第一次提交就因为隐私协议弹窗的文案不规范被退回来了改了一版才过。5.4 上线后的数据监控游戏上线后我在后台接入了微信小游戏的数据分析。主要看几个指标新增用户、次日留存、平均时长、分享率。这些数据能反映游戏的基本健康度。我上线第一周的数据新增用户 500 左右次日留存 25%平均时长 4 分钟。留存偏低分析下来是新手引导太长很多用户没玩到核心玩法就流失了。后来把引导从 5 步压缩到 2 步次日留存提到了 35%。数据监控的另一个作用是发现崩溃。微信小游戏后台会收集错误日志我每天都会看一眼。有一次发现某个机型上频繁报错定位到是某个 API 在该机型上不支持加了个兼容判断就解决了。6. 踩坑实录那些文档里不会写的问题6.1 常见问题速查表问题现象可能原因解决方案真机上触摸无反应坐标系差异用event.getLocation()而非event.getUILocation()音频不播放微信小游戏音频限制首次触摸后再播放或使用wx.createInnerAudioContext图片显示模糊分辨率适配问题检查图片的原始尺寸和节点的缩放比例场景切换卡顿资源未预加载用cc.resources.preload提前加载内存持续增长资源未释放场景切换时调用cc.resources.release分享卡片无图图片尺寸不符分享图片建议 500x400格式用 PNG构建后白屏脚本报错检查构建日志确认没有引用不存在的模块帧率不稳定DrawCall 过高合并同类型节点使用图集6.2 音频播放的坑微信小游戏的音频播放有个限制首次播放必须在用户交互之后。这是浏览器的自动播放策略微信小游戏也遵循这个规则。我一开始在游戏启动时就播放背景音乐结果真机上完全没声音模拟器上却正常。解决方案是在用户第一次触摸屏幕时初始化音频上下文之后再播放就没问题了let audioInitialized false; function initAudio() { if (audioInitialized) return; const audio wx.createInnerAudioContext(); audio.src audio/bgm.mp3; audio.loop true; audio.play(); audioInitialized true; } // 在第一次触摸时调用 wx.onTouchStart(() { initAudio(); });另一个坑是音频格式。微信小游戏对音频格式的支持有限MP3 和 AAC 是稳妥的选择。我用过 OGG 格式在部分 Android 机型上无法播放换成 MP3 就正常了。6.3 屏幕适配的实战经验微信小游戏的屏幕比例五花八门从 16:9 到 21:9 都有。Cocos Creator 的 Canvas 组件有几种适配模式SHOW_ALL完整显示设计分辨率可能有黑边。NO_BORDER铺满屏幕可能裁剪内容。FIXED_WIDTH固定宽度高度自适应。FIXED_HEIGHT固定高度宽度自适应。我试过所有模式最后选了FIXED_WIDTH。原因是我的游戏是竖屏的宽度固定能保证 UI 元素的相对位置不变高度多出来的部分用背景填充。对于刘海屏和挖孔屏用wx.getSystemInfoSync()拿到safeArea数据把 UI 元素避开安全区域。const systemInfo wx.getSystemInfoSync(); const safeArea systemInfo.safeArea; // safeArea.top 是顶部安全距离 // safeArea.bottom 是底部安全距离6.4 性能优化的几个关键点微信小游戏的性能瓶颈主要在DrawCall和内存上。我做了几项优化帧率从 45 提到了稳定 60图集合并。把同类型的图片打包成图集能大幅减少 DrawCall。Cocos Creator 有自动图集功能在assets目录下创建 AutoAtlas 资源把需要合并的图片拖进去就行。我把所有 UI 图片合并成一个图集DrawCall 从 60 降到了 25。节点复用。列表类的 UI 不要每次都创建新节点用对象池复用。Cocos Creator 提供了cc.NodePool我用来管理列表项的节点滚动时只更新数据不创建节点内存占用稳定了很多。延迟加载。不是所有资源都需要在启动时加载。我把非首屏的资源放到分包里用到的时候再加载。这样首屏加载时间从 5 秒降到了 2 秒。减少透明重叠。半透明元素的重叠会导致 overdraw增加 GPU 负担。我检查了场景里的半透明元素能合并的合并能去掉的去掉帧率有肉眼可见的提升。6.5 我个人的几条经验做了三个月踩的坑远不止上面这些。有几条经验我觉得值得单独拎出来说第一不要追求完美先跑通再优化。我一开始花了两周时间设计架构结果真正写的时候发现很多设计用不上。后来改成先写一个能跑的版本再根据实际问题重构效率高多了。第二多用真机测试。模拟器和真机的差异比想象中大。我遇到过一个 bug模拟器上完全正常真机上必现最后发现是某个 API 在真机上的返回值类型不一样。从那以后我养成了每天用真机跑一遍的习惯。第三日志要打够。一个人开发没有测试团队出问题只能靠自己排查。我在关键流程都加了日志上线后通过 vConsole 看日志定位问题。日志不用多但关键节点的状态一定要打出来。第四备份很重要。我用 Git 管理代码但资源文件图片、音频没有全部提交。有一次硬盘出问题丢了一批美术资源只能重新做。后来我把所有资源都提交到 Git LFS虽然仓库大了点但安心。第五别闭门造车。我加了一个独立开发者的交流群遇到问题在群里问经常能得到意想不到的解决方案。有些坑别人已经踩过了问一句能省半天时间。这个项目从立项到上线一共用了 11 周比我预期的三个月要快。上线后第一个月积累了 2000 多用户虽然不算多但验证了一个人也能跑通小游戏开发这件事。后续我打算把玩法再打磨一下接入激励视频广告看看能不能把留存和收益再提一提。如果你也在做类似的事情希望这篇内容能帮你少走点弯路。