1. 一个人做微信小游戏为什么我选了这条技术路线去年年底我给自己定了个目标用业余时间独立完成一款微信小游戏从立项到上线全流程一个人扛。不是那种“三天做个demo”的玩票而是真正能跑通审核、有留存、能看后台数据的完整产品。当时身边朋友第一反应都是“你一个人美术、策划、程序、运营全包”说实话一开始我心里也没底但做完之后发现一人工作室在微信小游戏这个生态里反而是效率最高的组合方式。先说说为什么盯上了微信小游戏这个方向。最直接的原因是流量入口足够短——用户点开就能玩不用下载安装包不用跳转应用商店分享到群里就是一条卡片。对于独立开发者来说获客成本几乎为零这是任何App都比不了的优势。另一个原因是技术栈相对收敛微信小游戏运行在类Canvas的渲染环境里底层是JavaScript/TypeScript的运行时不需要考虑iOS和Android两套原生代码的适配问题一个人维护一套逻辑就够了。那为什么标题里提到了Cocos Creator、TypeScript、Phaser、Canvas这么多东西因为实际开发中这些技术点不是二选一的关系而是根据项目阶段和需求层次组合使用的。我最终的技术选型是Cocos Creator作为主引擎TypeScript作为开发语言Canvas API作为底层补充Phaser作为原型验证阶段的快速工具。这套组合不是拍脑袋定的下面我把每个选择的理由拆开讲。先说引擎选型。市面上做微信小游戏的引擎主要有三个方向Cocos Creator、LayaBox、Egret还有直接用原生Canvas手搓的。我试过用原生Canvas从零写一个游戏循环大概写了三天就放弃了——不是写不出来而是重复造轮子的成本太高。场景管理、资源加载、动画系统、碰撞检测、粒子效果这些东西如果全部手写一个人根本扛不住。Cocos Creator把这些都封装好了而且对微信小游戏的支持是一线的官方文档里直接有“发布到微信小游戏”的按钮点一下就能生成完整的项目结构。那Phaser呢Phaser是我在原型阶段用的。当时游戏核心玩法还没定我需要快速验证“这个玩法好不好玩”。Phaser的优势是轻量、上手快、社区示例多一个HTML文件引入CDN就能跑起来改几行代码就能看到效果。我用Phaser大概花了两天时间做了一个可玩的原型发给几个朋友试玩收集了一轮反馈之后才决定用Cocos Creator做正式版本。这个流程我强烈建议一人工作室都走一遍——原型阶段用最轻的工具验证玩法正式开发再用工程化引擎不要一上来就搭重型框架很容易在还没验证玩法的时候就耗尽热情。TypeScript的选择就更直接了。微信小游戏的底层是JavaScript但JS的弱类型在项目稍微大一点之后就是灾难。我试过用纯JS写一个超过2000行的游戏逻辑改一个变量名要全局搜索替换生怕漏掉哪个地方。TypeScript的静态类型检查能在编译阶段就发现大部分低级错误而且Cocos Creator对TypeScript的支持是原生的创建项目时直接选TypeScript模板就行。另外TypeScript的interface和类型声明文件.d.ts在对接微信API的时候特别有用微信官方的类型定义包安装之后调用wx.login、wx.createUserInfoButton这些接口都有完整的类型提示不用一边翻文档一边猜参数。Canvas API虽然被引擎封装了大部分但有些场景还是得直接调。比如我要做一个文字3D效果的标题动画Cocos Creator的Label组件不支持这种效果我就直接用Canvas的2D上下文手动绘制通过逐帧改变文字的缩放和透明度来模拟3D旋转。还有游戏里的小人形象我用Canvas的路径绘制API画了一个简单的火柴人配合骨骼动画的思路用代码控制每个关节的位置比用序列帧动画省资源得多。这些底层操作在引擎里都有对应的接口暴露出来关键是要知道什么时候该用引擎封装好的组件什么时候该直接操作Canvas。2. 从零搭建项目环境准备与工程结构设计2.1 开发环境搭建的完整清单正式开发之前我花了大半天时间把环境搭好。这里列一下我实际用到的工具和版本避免大家踩版本兼容的坑。工具版本用途备注Cocos Creator3.8.x主引擎3.8对微信小游戏支持最稳定Node.js18 LTS构建工具链不要用20部分插件不兼容TypeScript5.x开发语言随Creator自带不用单独装微信开发者工具稳定版预览与调试必须用最新版VS Code最新代码编辑装Cocos Creator插件Git最新版本管理一人工作室也要用安装顺序有讲究先装Node.js再装Cocos Creator最后装微信开发者工具。Cocos Creator安装时会自动检测Node环境如果顺序反了Creator可能找不到Node路径构建的时候会报错。微信开发者工具安装后要在设置里开启“服务端口”否则Creator无法自动唤起它进行预览。注意Cocos Creator 3.8的微信小游戏构建模板默认使用WebGL渲染但部分低端安卓机对WebGL支持不完整需要在构建配置里勾选“兼容WebGL 1.0”选项。这个坑我踩过测试机上一半的安卓设备黑屏排查了一天才发现是渲染后端的问题。2.2 工程目录结构的设计逻辑一人工作室最容易犯的错误就是目录结构随意想到哪写到哪。我第一个版本就是这么干的结果做到第三周的时候找一个脚本要翻五分钟。后来我重新设计了目录结构核心原则是按功能模块划分而不是按文件类型划分。assets/ scripts/ core/ # 核心框架事件系统、状态机、对象池 gameplay/ # 玩法逻辑关卡、角色、敌人、道具 ui/ # 界面相关弹窗、HUD、按钮 utils/ # 工具函数数学、字符串、时间 config/ # 配置数据关卡配置、数值表 prefabs/ # 预制体 textures/ # 图片资源 audio/ # 音效 scenes/ # 场景文件为什么按功能分而不是按类型分因为一人开发的时候你经常需要同时修改一个功能的多个文件。比如改“跳跃”这个功能可能要动gameplay里的角色脚本、ui里的按钮响应、config里的跳跃力度参数。如果按类型分这三个文件散落在三个目录里来回切换很烦。按功能分之后相关文件都在同一个目录下改起来顺手得多。另外我单独建了一个core目录放框架级代码比如事件总线、对象池、状态机。这些代码在整个项目生命周期里基本不会大改和业务逻辑隔离之后重构的时候不会互相影响。对象池这个东西在小游戏里特别重要微信小游戏的垃圾回收机制和浏览器不太一样频繁创建销毁对象容易导致卡顿用对象池复用子弹、敌人、特效这些高频对象帧率能稳定不少。2.3 TypeScript类型声明文件的实战用法TypeScript的.d.ts声明文件在一人工作室的项目里有两个核心用途对接微信API和扩展引擎类型。对接微信API这块微信官方提供了types/wechat-minigame包安装之后在tsconfig.json里配置types字段就能自动加载。但实际用的时候发现官方类型定义有些接口的参数类型不够精确比如wx.createRewardedVideoAd的返回值类型是any调用show()方法的时候没有类型提示。我的做法是在types目录下建一个wechat-extend.d.ts文件手动补充类型声明declare namespace WechatMinigame { interface RewardedVideoAd { show(): Promisevoid; load(): Promisevoid; onClose(callback: (res: { isEnded: boolean }) void): void; offClose(callback: (res: { isEnded: boolean }) void): void; } }这样在业务代码里调用ad.show()的时候就有完整的类型提示了参数写错编译阶段就会报错。扩展引擎类型也是类似的思路比如我给节点加了一个自定义属性node.userData就在.d.ts里声明一下避免到处写as any。实操心得.d.ts文件不需要手动import只要放在tsconfig.json的include路径下TypeScript编译器会自动加载。但要注意不要和已有的类型定义冲突如果扩展的接口名和官方定义重名编译器会报“重复定义”错误。解决办法是用declare module语法扩展而不是重新声明整个接口。3. 核心玩法实现从原型到正式版本的完整过程3.1 用Phaser快速验证玩法原型游戏的核心玩法是“闪避收集”玩家控制一个小人在不断滚动的场景里左右移动躲避障碍物收集金币。这个玩法听起来简单但手感调优的空间很大——移动速度、加速度、障碍物生成频率、金币吸引力每个参数都会影响体验。我用Phaser花了两天做了个原型。Phaser的API设计很直观创建一个场景、加载资源、写update循环基本就是照着文档抄。原型阶段我甚至没用图片资源所有东西都是用graphics对象画的矩形和圆形因为原型阶段验证的是玩法不是美术。这一点很多新手容易搞反花大量时间画素材结果玩法不好玩素材全白费。Phaser原型跑起来之后我找了五个朋友试玩收集到的反馈集中在两点一是“移动太滑了停不下来”二是“障碍物来得太突然来不及反应”。这两个问题都是手感参数的问题不是玩法本身的问题。我调整了移动的阻尼系数从0.9调到0.75让角色松手后更快停下障碍物的生成间隔从固定值改成随距离动态变化前期给玩家更多反应时间。调整之后反馈明显好转这才决定用Cocos Creator做正式版本。3.2 Cocos Creator中的角色控制与物理系统正式版本的角色控制我没有用Cocos Creator自带的物理引擎而是手写了移动逻辑。原因有两个一是微信小游戏的性能预算有限物理引擎的碰撞检测开销不小二是这个游戏的碰撞逻辑很简单就是矩形和矩形的相交判断没必要上物理引擎。手写移动逻辑的核心是一个update函数每帧根据输入更新角色的位置update(dt: number) { const input this.getInputDirection(); const targetSpeed input * this.maxSpeed; this.currentSpeed this.lerp(this.currentSpeed, targetSpeed, this.acceleration * dt); const pos this.node.position; this.node.setPosition(pos.x this.currentSpeed * dt, pos.y, pos.z); this.clampPosition(); }这里的lerp是线性插值用来实现平滑的加速和减速。acceleration参数控制加速的快慢值越大响应越灵敏但太大就会显得“滑”。我实测下来acceleration在8到12之间手感最好具体值要根据maxSpeed来调。clampPosition是边界限制防止角色跑出屏幕。障碍物的碰撞检测我用的是AABB包围盒每个障碍物和角色都有一个矩形包围盒每帧检测两个矩形是否相交。这个算法的复杂度是O(n)n是障碍物数量。因为同屏障碍物最多十几个性能完全没问题。如果障碍物数量上百就需要用空间分割或者四叉树优化但这个游戏用不上。3.3 Canvas绘图实现小人形象与文字3D效果游戏里的小人形象我没有用美术素材而是用Canvas的路径绘制API代码画出来的。为什么这么做一是省资源一个火柴人的绘制代码不到100行比一张序列帧图省内存二是灵活可以通过代码控制每个关节的角度实现简单的骨骼动画效果。绘制逻辑大概是这样的先画头圆形再画身体线段再画四肢线段每个部位的位置由关节角度决定。跑步动画就是让四肢的角度随时间做正弦变化const legAngle Math.sin(this.runTime * this.runSpeed) * this.legSwing;legSwing控制摆腿的幅度runSpeed控制摆腿的频率。这两个参数配合角色的移动速度来调速度越快摆腿频率越高看起来就越自然。文字3D效果是用Canvas的transform实现的。Cocos Creator的Label组件不支持3D变换我就把文字渲染到一个离屏Canvas上然后通过ctx.setTransform设置透视矩阵逐帧改变旋转角度最后把离屏Canvas的内容绘制到主Canvas上。这个方案的好处是完全可控想要什么效果就调什么参数坏处是性能开销比普通Label大所以只用在标题界面游戏内不用。注意Canvas的setTransform参数顺序是(a, b, c, d, e, f)分别对应缩放、旋转、平移的矩阵元素。如果搞不清楚矩阵怎么算可以用ctx.rotate()、ctx.scale()、ctx.translate()这三个方法组合虽然性能略差但可读性好得多。4. 微信小游戏打包与性能优化的实战记录4.1 从Cocos Creator到微信开发者工具的完整打包流程打包流程看起来简单但实际操作的坑不少。Cocos Creator的构建面板里选择“微信小游戏”平台填好AppID点构建等几分钟就能生成一个完整的项目目录。然后用微信开发者工具打开这个目录就能预览和上传了。但有几个细节要注意。第一构建时的“资源服务器地址”要填对如果填了本地地址上传之后线上用户加载不到资源。我一开始填的是http://localhost:8080本地预览没问题上传之后白屏排查了半天才发现是这个问题。第二分包加载要提前规划微信小游戏的主包限制是4MB超过之后必须分包。我的做法是把首屏需要的资源放主包关卡资源、音效、大图放分包通过wx.loadSubpackage按需加载。第三首屏渲染时间要控制。微信小游戏的启动流程是下载代码包→初始化引擎→加载首屏资源→渲染。每个环节都会影响用户的等待时间。我的优化手段是代码包开启压缩引擎初始化时只加载必要的模块首屏资源用雪碧图合并减少请求数。实测下来首屏渲染时间从最初的4.2秒降到了1.8秒这个提升对留存率的影响非常明显。4.2 性能优化的五个关键手段微信小游戏的性能瓶颈主要在渲染和内存两个方面。我踩过的坑和对应的优化手段整理如下问题现象根本原因优化手段效果帧率波动大DrawCall过高合图自动图集帧率稳定在55低端机卡顿粒子特效过多限制同屏粒子数卡顿明显减少内存持续增长对象未回收对象池手动GC内存曲线平稳加载慢资源未压缩图片压缩音频转码包体减少40%发热严重每帧计算量大降低逻辑帧率发热改善DrawCall是渲染优化的核心指标。每次切换纹理、切换材质都会产生一次DrawCallDrawCall越多CPU在渲染准备上的开销就越大。Cocos Creator的自动图集功能可以把多张小图合并成一张大图运行时只需要一次DrawCall就能渲染所有小图。我把游戏里所有UI元素和角色动画帧都打进了图集DrawCall从最初的80多降到了20左右。对象池的使用也有讲究。不是所有对象都适合放进对象池只有创建销毁频繁、初始化开销大的对象才值得池化。比如子弹、金币、飘字这些创建频率高每次都要分配内存和初始化属性用对象池复用能显著减少GC压力。但像场景、UI面板这种创建一次就长期存在的对象放对象池反而增加管理复杂度没必要。4.3 微信小游戏审核的避坑指南审核这块我被打回过两次第一次是因为诱导分享第二次是因为类目选择错误。这两个问题在独立开发者里非常常见我详细说一下。诱导分享的判定标准比想象中严格。我在游戏结束界面加了一个“分享给好友复活”的按钮被判定为诱导分享。后来改成“分享给好友获得金币奖励”还是被打回。最后改成分享按钮不附带任何奖励只是单纯提供一个分享入口才通过审核。微信的规则是分享必须是用户主动行为不能和游戏内的利益挂钩。类目选择也很关键。微信小游戏的类目分为很多种选错了会被打回。我的游戏是休闲益智类第一次选了“动作”类目被打回要求改选“休闲益智”。类目选择的原则是看游戏的核心玩法而不是看游戏的题材。比如一个跑酷游戏虽然角色在“跑”但核心是休闲玩法应该选休闲类目而不是体育类目。实操心得提交审核之前一定要用微信开发者工具的“体验版”功能自己完整走一遍流程包括登录、支付、分享、广告观看。很多问题在开发环境里不会暴露只有真机体验版才能发现。另外审核时间一般是1到3个工作日节假日会延长上线计划要留出缓冲。5. 一人工作室的效率工具与工作流5.1 用Playwright做自动化回归测试一人工作室没有测试团队但游戏上线之后每次更新都可能引入新bug。我的解决方案是用Playwright做自动化回归测试。Playwright可以模拟浏览器操作我用它来跑游戏的核心流程启动→进入主界面→开始游戏→操作角色→游戏结束→查看结算。每次更新之后跑一遍几分钟就能确认核心流程没有被破坏。Playwright和TypeScript的配合很顺畅测试脚本本身就是TypeScript写的可以直接复用游戏里的类型定义。比如测试“金币收集”功能我可以import游戏里的金币配置用相同的数值来验证收集逻辑是否正确。这种测试代码和业务代码共享类型的做法能避免很多因为类型不一致导致的测试误报。import { test, expect } from playwright/test; test(核心流程回归, async ({ page }) { await page.goto(http://localhost:7456); await page.waitForSelector(#game-canvas); await page.click(#start-button); await page.waitForTimeout(2000); const score await page.textContent(#score-label); expect(Number(score)).toBeGreaterThan(0); });这个测试脚本虽然简单但覆盖了最核心的流程。每次改完代码跑一遍心里踏实很多。5.2 版本管理与持续集成的轻量方案一人工作室不需要复杂的CI/CD流水线但基本的版本管理和自动构建还是要有的。我用的是Git GitHub Actions的组合。每次push到main分支Actions自动执行构建脚本生成微信小游戏的代码包然后上传到微信开发者工具的CI接口。这个流程的搭建成本大概半天但收益很大。以前每次发版都要手动构建、手动上传容易漏步骤。现在push代码之后等几分钟构建结果自动出来我只需要在微信后台点一下“提交审核”就行。Actions的配置文件也不复杂核心就是安装依赖、执行构建命令、调用微信的CI接口。注意微信开发者工具的CI接口需要先在微信公众平台开启“CI权限”并生成一个密钥。这个密钥要存在GitHub的Secrets里不要硬编码在配置文件里。另外CI构建的代码包大小可能和本地构建有差异因为CI环境的Node版本和依赖版本可能不同建议在CI配置里锁定版本号。5.3 时间管理与精力分配的真实体会一人工作室最大的挑战不是技术是时间管理和精力分配。我白天有正职工作只有晚上和周末能做游戏。一开始我试图每天做一点结果发现碎片化的时间根本做不了需要深度思考的事情比如架构设计、算法调优。后来我调整了策略工作日晚上只做机械性工作比如画UI、调参数、写文档周末整块时间做核心开发比如写玩法逻辑、优化性能。这个策略的效果很明显。机械性工作不需要太多脑力晚上做一两个小时也不会影响第二天上班核心开发需要连续思考放在周末整块时间做效率最高。另外我给自己定了一个规矩每天至少提交一次代码哪怕只改了一行。这个习惯保证了项目的持续推进不会因为某天太忙就断掉节奏。6. 上线后的数据观察与迭代方向游戏上线第一个月日活大概在200左右留存率次日35%、七日12%。这个数据不算亮眼但对一人工作室的第一个产品来说我觉得可以接受。通过后台数据我发现几个有意思的现象用户平均游戏时长只有3.2分钟说明单局时间太长或者难度曲线有问题分享率不到5%说明分享入口的曝光不够或者分享动机不足。针对这两个问题我做了两个调整一是把单局时间从平均90秒压缩到60秒降低难度曲线的陡峭程度二是在结算界面增加了一个“炫耀成绩”的分享按钮展示用户的最高分和排名。调整之后平均游戏时长提升到4.5分钟分享率提升到8%。虽然提升幅度不大但方向是对的。后续的迭代方向我还在思考。一个方向是增加社交元素比如好友排行榜、异步对战另一个方向是丰富关卡内容现在只有一种玩法模式玩久了会腻。但一人工作室的精力有限不可能同时做多个方向我倾向于先做社交元素因为微信小游戏的社交裂变是最大的流量来源把分享和排行榜做好获客成本能进一步降低。这个项目从立项到上线大概用了三个月代码量一万行左右美术资源大部分是代码生成的音效用了免费素材。整体投入的时间大概200个小时按我自己的时薪折算开发成本相当于一万多块钱。但收获的经验和成就感是钱买不到的。如果你也是一个人想做微信小游戏我的建议是先做最小可玩版本快速上线用真实数据指导迭代不要憋大招不要追求完美先跑起来再说。
一人开发微信小游戏：Cocos Creator+TypeScript技术选型与实战
1. 一个人做微信小游戏为什么我选了这条技术路线去年年底我给自己定了个目标用业余时间独立完成一款微信小游戏从立项到上线全流程一个人扛。不是那种“三天做个demo”的玩票而是真正能跑通审核、有留存、能看后台数据的完整产品。当时身边朋友第一反应都是“你一个人美术、策划、程序、运营全包”说实话一开始我心里也没底但做完之后发现一人工作室在微信小游戏这个生态里反而是效率最高的组合方式。先说说为什么盯上了微信小游戏这个方向。最直接的原因是流量入口足够短——用户点开就能玩不用下载安装包不用跳转应用商店分享到群里就是一条卡片。对于独立开发者来说获客成本几乎为零这是任何App都比不了的优势。另一个原因是技术栈相对收敛微信小游戏运行在类Canvas的渲染环境里底层是JavaScript/TypeScript的运行时不需要考虑iOS和Android两套原生代码的适配问题一个人维护一套逻辑就够了。那为什么标题里提到了Cocos Creator、TypeScript、Phaser、Canvas这么多东西因为实际开发中这些技术点不是二选一的关系而是根据项目阶段和需求层次组合使用的。我最终的技术选型是Cocos Creator作为主引擎TypeScript作为开发语言Canvas API作为底层补充Phaser作为原型验证阶段的快速工具。这套组合不是拍脑袋定的下面我把每个选择的理由拆开讲。先说引擎选型。市面上做微信小游戏的引擎主要有三个方向Cocos Creator、LayaBox、Egret还有直接用原生Canvas手搓的。我试过用原生Canvas从零写一个游戏循环大概写了三天就放弃了——不是写不出来而是重复造轮子的成本太高。场景管理、资源加载、动画系统、碰撞检测、粒子效果这些东西如果全部手写一个人根本扛不住。Cocos Creator把这些都封装好了而且对微信小游戏的支持是一线的官方文档里直接有“发布到微信小游戏”的按钮点一下就能生成完整的项目结构。那Phaser呢Phaser是我在原型阶段用的。当时游戏核心玩法还没定我需要快速验证“这个玩法好不好玩”。Phaser的优势是轻量、上手快、社区示例多一个HTML文件引入CDN就能跑起来改几行代码就能看到效果。我用Phaser大概花了两天时间做了一个可玩的原型发给几个朋友试玩收集了一轮反馈之后才决定用Cocos Creator做正式版本。这个流程我强烈建议一人工作室都走一遍——原型阶段用最轻的工具验证玩法正式开发再用工程化引擎不要一上来就搭重型框架很容易在还没验证玩法的时候就耗尽热情。TypeScript的选择就更直接了。微信小游戏的底层是JavaScript但JS的弱类型在项目稍微大一点之后就是灾难。我试过用纯JS写一个超过2000行的游戏逻辑改一个变量名要全局搜索替换生怕漏掉哪个地方。TypeScript的静态类型检查能在编译阶段就发现大部分低级错误而且Cocos Creator对TypeScript的支持是原生的创建项目时直接选TypeScript模板就行。另外TypeScript的interface和类型声明文件.d.ts在对接微信API的时候特别有用微信官方的类型定义包安装之后调用wx.login、wx.createUserInfoButton这些接口都有完整的类型提示不用一边翻文档一边猜参数。Canvas API虽然被引擎封装了大部分但有些场景还是得直接调。比如我要做一个文字3D效果的标题动画Cocos Creator的Label组件不支持这种效果我就直接用Canvas的2D上下文手动绘制通过逐帧改变文字的缩放和透明度来模拟3D旋转。还有游戏里的小人形象我用Canvas的路径绘制API画了一个简单的火柴人配合骨骼动画的思路用代码控制每个关节的位置比用序列帧动画省资源得多。这些底层操作在引擎里都有对应的接口暴露出来关键是要知道什么时候该用引擎封装好的组件什么时候该直接操作Canvas。2. 从零搭建项目环境准备与工程结构设计2.1 开发环境搭建的完整清单正式开发之前我花了大半天时间把环境搭好。这里列一下我实际用到的工具和版本避免大家踩版本兼容的坑。工具版本用途备注Cocos Creator3.8.x主引擎3.8对微信小游戏支持最稳定Node.js18 LTS构建工具链不要用20部分插件不兼容TypeScript5.x开发语言随Creator自带不用单独装微信开发者工具稳定版预览与调试必须用最新版VS Code最新代码编辑装Cocos Creator插件Git最新版本管理一人工作室也要用安装顺序有讲究先装Node.js再装Cocos Creator最后装微信开发者工具。Cocos Creator安装时会自动检测Node环境如果顺序反了Creator可能找不到Node路径构建的时候会报错。微信开发者工具安装后要在设置里开启“服务端口”否则Creator无法自动唤起它进行预览。注意Cocos Creator 3.8的微信小游戏构建模板默认使用WebGL渲染但部分低端安卓机对WebGL支持不完整需要在构建配置里勾选“兼容WebGL 1.0”选项。这个坑我踩过测试机上一半的安卓设备黑屏排查了一天才发现是渲染后端的问题。2.2 工程目录结构的设计逻辑一人工作室最容易犯的错误就是目录结构随意想到哪写到哪。我第一个版本就是这么干的结果做到第三周的时候找一个脚本要翻五分钟。后来我重新设计了目录结构核心原则是按功能模块划分而不是按文件类型划分。assets/ scripts/ core/ # 核心框架事件系统、状态机、对象池 gameplay/ # 玩法逻辑关卡、角色、敌人、道具 ui/ # 界面相关弹窗、HUD、按钮 utils/ # 工具函数数学、字符串、时间 config/ # 配置数据关卡配置、数值表 prefabs/ # 预制体 textures/ # 图片资源 audio/ # 音效 scenes/ # 场景文件为什么按功能分而不是按类型分因为一人开发的时候你经常需要同时修改一个功能的多个文件。比如改“跳跃”这个功能可能要动gameplay里的角色脚本、ui里的按钮响应、config里的跳跃力度参数。如果按类型分这三个文件散落在三个目录里来回切换很烦。按功能分之后相关文件都在同一个目录下改起来顺手得多。另外我单独建了一个core目录放框架级代码比如事件总线、对象池、状态机。这些代码在整个项目生命周期里基本不会大改和业务逻辑隔离之后重构的时候不会互相影响。对象池这个东西在小游戏里特别重要微信小游戏的垃圾回收机制和浏览器不太一样频繁创建销毁对象容易导致卡顿用对象池复用子弹、敌人、特效这些高频对象帧率能稳定不少。2.3 TypeScript类型声明文件的实战用法TypeScript的.d.ts声明文件在一人工作室的项目里有两个核心用途对接微信API和扩展引擎类型。对接微信API这块微信官方提供了types/wechat-minigame包安装之后在tsconfig.json里配置types字段就能自动加载。但实际用的时候发现官方类型定义有些接口的参数类型不够精确比如wx.createRewardedVideoAd的返回值类型是any调用show()方法的时候没有类型提示。我的做法是在types目录下建一个wechat-extend.d.ts文件手动补充类型声明declare namespace WechatMinigame { interface RewardedVideoAd { show(): Promisevoid; load(): Promisevoid; onClose(callback: (res: { isEnded: boolean }) void): void; offClose(callback: (res: { isEnded: boolean }) void): void; } }这样在业务代码里调用ad.show()的时候就有完整的类型提示了参数写错编译阶段就会报错。扩展引擎类型也是类似的思路比如我给节点加了一个自定义属性node.userData就在.d.ts里声明一下避免到处写as any。实操心得.d.ts文件不需要手动import只要放在tsconfig.json的include路径下TypeScript编译器会自动加载。但要注意不要和已有的类型定义冲突如果扩展的接口名和官方定义重名编译器会报“重复定义”错误。解决办法是用declare module语法扩展而不是重新声明整个接口。3. 核心玩法实现从原型到正式版本的完整过程3.1 用Phaser快速验证玩法原型游戏的核心玩法是“闪避收集”玩家控制一个小人在不断滚动的场景里左右移动躲避障碍物收集金币。这个玩法听起来简单但手感调优的空间很大——移动速度、加速度、障碍物生成频率、金币吸引力每个参数都会影响体验。我用Phaser花了两天做了个原型。Phaser的API设计很直观创建一个场景、加载资源、写update循环基本就是照着文档抄。原型阶段我甚至没用图片资源所有东西都是用graphics对象画的矩形和圆形因为原型阶段验证的是玩法不是美术。这一点很多新手容易搞反花大量时间画素材结果玩法不好玩素材全白费。Phaser原型跑起来之后我找了五个朋友试玩收集到的反馈集中在两点一是“移动太滑了停不下来”二是“障碍物来得太突然来不及反应”。这两个问题都是手感参数的问题不是玩法本身的问题。我调整了移动的阻尼系数从0.9调到0.75让角色松手后更快停下障碍物的生成间隔从固定值改成随距离动态变化前期给玩家更多反应时间。调整之后反馈明显好转这才决定用Cocos Creator做正式版本。3.2 Cocos Creator中的角色控制与物理系统正式版本的角色控制我没有用Cocos Creator自带的物理引擎而是手写了移动逻辑。原因有两个一是微信小游戏的性能预算有限物理引擎的碰撞检测开销不小二是这个游戏的碰撞逻辑很简单就是矩形和矩形的相交判断没必要上物理引擎。手写移动逻辑的核心是一个update函数每帧根据输入更新角色的位置update(dt: number) { const input this.getInputDirection(); const targetSpeed input * this.maxSpeed; this.currentSpeed this.lerp(this.currentSpeed, targetSpeed, this.acceleration * dt); const pos this.node.position; this.node.setPosition(pos.x this.currentSpeed * dt, pos.y, pos.z); this.clampPosition(); }这里的lerp是线性插值用来实现平滑的加速和减速。acceleration参数控制加速的快慢值越大响应越灵敏但太大就会显得“滑”。我实测下来acceleration在8到12之间手感最好具体值要根据maxSpeed来调。clampPosition是边界限制防止角色跑出屏幕。障碍物的碰撞检测我用的是AABB包围盒每个障碍物和角色都有一个矩形包围盒每帧检测两个矩形是否相交。这个算法的复杂度是O(n)n是障碍物数量。因为同屏障碍物最多十几个性能完全没问题。如果障碍物数量上百就需要用空间分割或者四叉树优化但这个游戏用不上。3.3 Canvas绘图实现小人形象与文字3D效果游戏里的小人形象我没有用美术素材而是用Canvas的路径绘制API代码画出来的。为什么这么做一是省资源一个火柴人的绘制代码不到100行比一张序列帧图省内存二是灵活可以通过代码控制每个关节的角度实现简单的骨骼动画效果。绘制逻辑大概是这样的先画头圆形再画身体线段再画四肢线段每个部位的位置由关节角度决定。跑步动画就是让四肢的角度随时间做正弦变化const legAngle Math.sin(this.runTime * this.runSpeed) * this.legSwing;legSwing控制摆腿的幅度runSpeed控制摆腿的频率。这两个参数配合角色的移动速度来调速度越快摆腿频率越高看起来就越自然。文字3D效果是用Canvas的transform实现的。Cocos Creator的Label组件不支持3D变换我就把文字渲染到一个离屏Canvas上然后通过ctx.setTransform设置透视矩阵逐帧改变旋转角度最后把离屏Canvas的内容绘制到主Canvas上。这个方案的好处是完全可控想要什么效果就调什么参数坏处是性能开销比普通Label大所以只用在标题界面游戏内不用。注意Canvas的setTransform参数顺序是(a, b, c, d, e, f)分别对应缩放、旋转、平移的矩阵元素。如果搞不清楚矩阵怎么算可以用ctx.rotate()、ctx.scale()、ctx.translate()这三个方法组合虽然性能略差但可读性好得多。4. 微信小游戏打包与性能优化的实战记录4.1 从Cocos Creator到微信开发者工具的完整打包流程打包流程看起来简单但实际操作的坑不少。Cocos Creator的构建面板里选择“微信小游戏”平台填好AppID点构建等几分钟就能生成一个完整的项目目录。然后用微信开发者工具打开这个目录就能预览和上传了。但有几个细节要注意。第一构建时的“资源服务器地址”要填对如果填了本地地址上传之后线上用户加载不到资源。我一开始填的是http://localhost:8080本地预览没问题上传之后白屏排查了半天才发现是这个问题。第二分包加载要提前规划微信小游戏的主包限制是4MB超过之后必须分包。我的做法是把首屏需要的资源放主包关卡资源、音效、大图放分包通过wx.loadSubpackage按需加载。第三首屏渲染时间要控制。微信小游戏的启动流程是下载代码包→初始化引擎→加载首屏资源→渲染。每个环节都会影响用户的等待时间。我的优化手段是代码包开启压缩引擎初始化时只加载必要的模块首屏资源用雪碧图合并减少请求数。实测下来首屏渲染时间从最初的4.2秒降到了1.8秒这个提升对留存率的影响非常明显。4.2 性能优化的五个关键手段微信小游戏的性能瓶颈主要在渲染和内存两个方面。我踩过的坑和对应的优化手段整理如下问题现象根本原因优化手段效果帧率波动大DrawCall过高合图自动图集帧率稳定在55低端机卡顿粒子特效过多限制同屏粒子数卡顿明显减少内存持续增长对象未回收对象池手动GC内存曲线平稳加载慢资源未压缩图片压缩音频转码包体减少40%发热严重每帧计算量大降低逻辑帧率发热改善DrawCall是渲染优化的核心指标。每次切换纹理、切换材质都会产生一次DrawCallDrawCall越多CPU在渲染准备上的开销就越大。Cocos Creator的自动图集功能可以把多张小图合并成一张大图运行时只需要一次DrawCall就能渲染所有小图。我把游戏里所有UI元素和角色动画帧都打进了图集DrawCall从最初的80多降到了20左右。对象池的使用也有讲究。不是所有对象都适合放进对象池只有创建销毁频繁、初始化开销大的对象才值得池化。比如子弹、金币、飘字这些创建频率高每次都要分配内存和初始化属性用对象池复用能显著减少GC压力。但像场景、UI面板这种创建一次就长期存在的对象放对象池反而增加管理复杂度没必要。4.3 微信小游戏审核的避坑指南审核这块我被打回过两次第一次是因为诱导分享第二次是因为类目选择错误。这两个问题在独立开发者里非常常见我详细说一下。诱导分享的判定标准比想象中严格。我在游戏结束界面加了一个“分享给好友复活”的按钮被判定为诱导分享。后来改成“分享给好友获得金币奖励”还是被打回。最后改成分享按钮不附带任何奖励只是单纯提供一个分享入口才通过审核。微信的规则是分享必须是用户主动行为不能和游戏内的利益挂钩。类目选择也很关键。微信小游戏的类目分为很多种选错了会被打回。我的游戏是休闲益智类第一次选了“动作”类目被打回要求改选“休闲益智”。类目选择的原则是看游戏的核心玩法而不是看游戏的题材。比如一个跑酷游戏虽然角色在“跑”但核心是休闲玩法应该选休闲类目而不是体育类目。实操心得提交审核之前一定要用微信开发者工具的“体验版”功能自己完整走一遍流程包括登录、支付、分享、广告观看。很多问题在开发环境里不会暴露只有真机体验版才能发现。另外审核时间一般是1到3个工作日节假日会延长上线计划要留出缓冲。5. 一人工作室的效率工具与工作流5.1 用Playwright做自动化回归测试一人工作室没有测试团队但游戏上线之后每次更新都可能引入新bug。我的解决方案是用Playwright做自动化回归测试。Playwright可以模拟浏览器操作我用它来跑游戏的核心流程启动→进入主界面→开始游戏→操作角色→游戏结束→查看结算。每次更新之后跑一遍几分钟就能确认核心流程没有被破坏。Playwright和TypeScript的配合很顺畅测试脚本本身就是TypeScript写的可以直接复用游戏里的类型定义。比如测试“金币收集”功能我可以import游戏里的金币配置用相同的数值来验证收集逻辑是否正确。这种测试代码和业务代码共享类型的做法能避免很多因为类型不一致导致的测试误报。import { test, expect } from playwright/test; test(核心流程回归, async ({ page }) { await page.goto(http://localhost:7456); await page.waitForSelector(#game-canvas); await page.click(#start-button); await page.waitForTimeout(2000); const score await page.textContent(#score-label); expect(Number(score)).toBeGreaterThan(0); });这个测试脚本虽然简单但覆盖了最核心的流程。每次改完代码跑一遍心里踏实很多。5.2 版本管理与持续集成的轻量方案一人工作室不需要复杂的CI/CD流水线但基本的版本管理和自动构建还是要有的。我用的是Git GitHub Actions的组合。每次push到main分支Actions自动执行构建脚本生成微信小游戏的代码包然后上传到微信开发者工具的CI接口。这个流程的搭建成本大概半天但收益很大。以前每次发版都要手动构建、手动上传容易漏步骤。现在push代码之后等几分钟构建结果自动出来我只需要在微信后台点一下“提交审核”就行。Actions的配置文件也不复杂核心就是安装依赖、执行构建命令、调用微信的CI接口。注意微信开发者工具的CI接口需要先在微信公众平台开启“CI权限”并生成一个密钥。这个密钥要存在GitHub的Secrets里不要硬编码在配置文件里。另外CI构建的代码包大小可能和本地构建有差异因为CI环境的Node版本和依赖版本可能不同建议在CI配置里锁定版本号。5.3 时间管理与精力分配的真实体会一人工作室最大的挑战不是技术是时间管理和精力分配。我白天有正职工作只有晚上和周末能做游戏。一开始我试图每天做一点结果发现碎片化的时间根本做不了需要深度思考的事情比如架构设计、算法调优。后来我调整了策略工作日晚上只做机械性工作比如画UI、调参数、写文档周末整块时间做核心开发比如写玩法逻辑、优化性能。这个策略的效果很明显。机械性工作不需要太多脑力晚上做一两个小时也不会影响第二天上班核心开发需要连续思考放在周末整块时间做效率最高。另外我给自己定了一个规矩每天至少提交一次代码哪怕只改了一行。这个习惯保证了项目的持续推进不会因为某天太忙就断掉节奏。6. 上线后的数据观察与迭代方向游戏上线第一个月日活大概在200左右留存率次日35%、七日12%。这个数据不算亮眼但对一人工作室的第一个产品来说我觉得可以接受。通过后台数据我发现几个有意思的现象用户平均游戏时长只有3.2分钟说明单局时间太长或者难度曲线有问题分享率不到5%说明分享入口的曝光不够或者分享动机不足。针对这两个问题我做了两个调整一是把单局时间从平均90秒压缩到60秒降低难度曲线的陡峭程度二是在结算界面增加了一个“炫耀成绩”的分享按钮展示用户的最高分和排名。调整之后平均游戏时长提升到4.5分钟分享率提升到8%。虽然提升幅度不大但方向是对的。后续的迭代方向我还在思考。一个方向是增加社交元素比如好友排行榜、异步对战另一个方向是丰富关卡内容现在只有一种玩法模式玩久了会腻。但一人工作室的精力有限不可能同时做多个方向我倾向于先做社交元素因为微信小游戏的社交裂变是最大的流量来源把分享和排行榜做好获客成本能进一步降低。这个项目从立项到上线大概用了三个月代码量一万行左右美术资源大部分是代码生成的音效用了免费素材。整体投入的时间大概200个小时按我自己的时薪折算开发成本相当于一万多块钱。但收获的经验和成就感是钱买不到的。如果你也是一个人想做微信小游戏我的建议是先做最小可玩版本快速上线用真实数据指导迭代不要憋大招不要追求完美先跑起来再说。