微信小游戏这个赛道我从2019年就开始断断续续地折腾中间做过消除类、答题类、模拟经营类也帮朋友的工作室做过技术顾问。说实话一个人做小游戏这件事听起来挺酷但真正上手之后你会发现技术选型、性能优化、包体控制、平台适配每一个环节都够你喝一壶的。今天这篇分享我想把一人工作室从零到上线一款微信小游戏的完整实战经验摊开来聊包括我为什么最终选了Cocos Creator而不是PhaserTypeScript在小游戏项目里到底怎么用才不添乱Canvas绘图的性能天花板在哪里以及那些官方文档里不会写的坑。如果你是一个独立开发者或者小团队里负责技术选型的那个人正在纠结用什么引擎、怎么组织代码、怎么把包体压到微信要求的范围内那这篇内容应该能帮你省下不少试错时间。我不会只给你步骤还会告诉你每一步为什么这么做以及我踩过的那些坑。1. 为什么一人工作室选引擎比选语言更重要1.1 Cocos Creator、Phaser、裸Canvas三条路线的真实对比一个人做微信小游戏最先要做的决定不是写什么玩法而是用什么技术栈。我见过太多人在这上面反复横跳今天觉得Phaser轻量明天觉得Cocos Creator功能全后天又想着干脆用裸Canvas自己撸一个渲染层。结果时间全花在折腾工具上了游戏本身没写几行。先给一个结论如果你目标是微信小游戏平台Cocos Creator是目前综合成本最低的选择。但这句话有前提下面我把三条路线拆开说。Cocos Creator的核心优势在于它对微信小游戏的原生适配。它内置了微信小游戏的构建模板一键打包就能生成符合微信规范的代码包包括适配层、分包配置、远程资源加载这些。你不需要自己去处理wx.createCanvas、wx.onTouchStart这些平台API的差异引擎已经帮你封装好了。另外它的编辑器支持场景编辑、动画编辑、粒子系统、物理系统一个人可以同时兼顾策划和开发的工作。但Cocos Creator也有代价。它的运行时库体积不小一个空项目构建出来的微信小游戏包大概在1.5MB到2MB左右取决于你勾选了哪些模块。微信小游戏主包限制是4MB如果你玩法复杂一点很容易就顶到天花板必须做分包。另外它的学习曲线比Phaser陡编辑器本身就是一个需要花时间熟悉的大型工具。Phaser是一个纯JavaScript的2D游戏框架轻量、灵活、API设计得很舒服。如果你之前写过Web前端上手Phaser几乎没有什么门槛。它的社区也很活跃文档和示例都很全。但问题在于Phaser对微信小游戏的支持是社区层面的不是官方级别的。你需要自己引入适配层自己处理Canvas的创建和触摸事件的绑定自己解决资源加载在小游戏环境下的路径问题。这些事情单拎出来都不难但加在一起对于一个一人工作室来说就是额外的时间成本。裸Canvas这条路我只有在做极简原型的时候才会考虑。它的好处是极致轻量你可以精确控制每一行代码包体可以压到几百KB。但坏处也很明显你需要自己实现渲染循环、精灵管理、碰撞检测、动画系统、资源管理、场景切换。这些东西在游戏引擎里都是现成的你自己写一遍少说也要花掉一两周而且稳定性远不如成熟引擎。我当时的决策逻辑是这样的我的目标是快速验证玩法然后上线迭代。时间是最稀缺的资源所以我愿意用包体大小换开发效率。最终选了Cocos Creator 3.x版本TypeScript作为主要开发语言。1.2 TypeScript在小游戏项目里的真实收益与隐性成本选TypeScript这件事我当时犹豫了很久。原因很简单小游戏项目通常规模不大代码量可能就几千行TypeScript的类型系统带来的收益能不能覆盖它带来的额外复杂度实际做下来我的结论是对于一人工作室TypeScript的收益是正的但前提是你用对方式。收益方面最明显的是重构安全性。小游戏开发过程中玩法调整是家常便饭。今天觉得跳跃高度不对明天觉得敌人AI太蠢后天想把整个战斗系统推翻重做。在JavaScript里你改一个函数的参数签名可能要在十几个文件里手动搜索调用点漏掉一个就是运行时崩溃。TypeScript的编译器会直接告诉你哪里不匹配这种安全感在频繁重构的场景下非常值钱。另一个收益是代码提示。Cocos Creator的编辑器对TypeScript的支持很好组件的属性、节点的方法、事件的参数类型都有完整的提示。这在你记不清某个API怎么用的时候能省下大量查文档的时间。但隐性成本也是真实存在的。首先是构建时间TypeScript需要编译成JavaScript才能运行虽然Cocos Creator内部集成了编译流程但在项目变大之后每次修改后的热重载等待时间会明显变长。其次是类型定义的维护成本特别是当你引入第三方库的时候如果没有现成的.d.ts声明文件你需要自己写这本身就是一件费时费力的事情。我的建议是如果你之前没有TypeScript经验不要为了做小游戏专门去学。先用JavaScript把玩法跑通等代码量上来了、重构频繁了再逐步迁移到TypeScript。但如果你已经熟悉TypeScript那就直接用不要犹豫。1.3 一人工作室的模块取舍哪些引擎功能该关掉Cocos Creator在构建的时候允许你选择包含哪些模块。这个选项对于一人工作室来说极其重要因为每多勾一个模块包体就大一圈。我的做法是先全部关掉然后按需开启。具体来说3D相关的模块全部关掉物理引擎如果玩法不需要也关掉粒子系统如果不用也关掉。只保留2D渲染、UI系统、音频系统、资源管理这几个核心模块。这里有一个容易忽略的点Cocos Creator的构建配置里有一个引擎分离选项。开启之后引擎代码会被单独打包成一个文件和你的业务代码分开。这样做的好处是当你的业务代码更新时用户不需要重新下载引擎部分可以利用缓存。对于频繁迭代的小游戏来说这个选项能显著提升用户的更新体验。还有一个经验在开发阶段不要过早优化包体。先把功能做完确保玩法跑通然后再花时间做包体裁剪。因为玩法调整可能会导致你重新启用某些模块过早裁剪只会让你反复折腾。2. 微信小游戏项目从零搭建的完整链路2.1 项目初始化目录结构与命名规范一个人做项目最容易犯的错误就是目录结构混乱。反正没人管我文件随便放命名随便起。等到项目做到一半想找一个两年前写的工具函数翻遍整个项目都找不到。我的做法是在项目初始化阶段就定好目录结构并且严格执行。下面是我实际使用的目录结构assets/ scripts/ core/ # 核心框架代码与具体玩法无关 game/ # 玩法相关代码 ui/ # UI组件 utils/ # 工具函数 config/ # 配置数据 resources/ # 动态加载的资源 scenes/ # 场景文件 textures/ # 纹理资源 audio/ # 音频资源 prefabs/ # 预制体命名规范方面我遵循几条简单的规则脚本文件用大驼峰命名如PlayerController.ts工具函数用小驼峰如formatTime.ts场景文件用下划线分隔如main_scene.scene纹理资源用下划线分隔如player_idle.png。这些规则本身不重要重要的是统一。一旦定下来就不要随意更改。2.2 微信开发者工具的联调配置与常见连接问题Cocos Creator构建出微信小游戏包之后需要用微信开发者工具打开。这个环节有几个配置项容易出问题。首先是AppID。你需要在微信公众平台注册一个小游戏账号拿到AppID然后在Cocos Creator的构建配置里填入。如果没有AppID可以用测试号但测试号有一些功能限制比如不能真机预览。其次是服务器域名。如果你的游戏需要请求后端接口必须在微信公众平台配置合法域名。开发阶段可以在开发者工具里勾选不校验合法域名但上线前一定要配置好否则真机上请求会失败。还有一个常见问题是资源加载路径。Cocos Creator构建出来的资源路径和编辑器里的路径可能不一致特别是在使用了分包之后。我的经验是在代码里尽量使用resources.load这样的动态加载接口而不是直接引用资源路径。这样即使路径变了代码也不需要改。2.3 构建发布包体压缩与首屏加载优化微信小游戏的主包限制是4MB这个限制对于稍微复杂一点的游戏来说都很紧张。我的项目最终主包控制在3.2MB左右首屏加载时间在2秒以内。下面是我用到的几个关键优化手段。纹理压缩是最有效的包体优化手段。Cocos Creator支持多种纹理压缩格式对于微信小游戏推荐使用ASTC格式。但ASTC有一个问题不同机型的支持程度不一样。我的做法是在构建配置里同时生成ASTC和PNG两种格式运行时根据设备能力动态选择。音频压缩也很重要。小游戏里的背景音乐和音效如果不压缩很容易就占掉几百KB。我通常把背景音乐压成64kbps的MP3音效压成96kbps的MP3。对于短音效可以考虑用WAV格式但要注意采样率不要太高。代码混淆与压缩是构建时的默认选项但有一个细节需要注意Cocos Creator的构建配置里有一个压缩代码选项开启之后会用Terser对代码进行压缩。这个选项在开发阶段可以关掉方便调试发布时一定要开启。首屏加载优化的核心思路是把首屏不需要的资源放到分包里。比如游戏的设置界面、排行榜界面、商城界面这些都可以做成分包等用户点击的时候再加载。Cocos Creator支持分包配置你只需要在构建配置里指定哪些目录属于分包即可。3. TypeScript在小游戏项目中的工程化实践3.1 类型声明文件.d.ts的编写与第三方库接入在小游戏项目里使用TypeScript绕不开的一个问题就是类型声明文件。Cocos Creator自带的API都有完整的类型声明但当你引入第三方库的时候情况就不一样了。以lodash为例它是一个纯JavaScript库没有内置的TypeScript类型。你需要安装types/lodash这个包它提供了lodash的类型声明。安装之后TypeScript就能正确识别lodash的API了。但有些库没有现成的类型声明比如一些小的工具库或者你自己写的旧代码。这时候你需要自己写.d.ts文件。下面是一个简单的例子// types/myLib.d.ts declare module myLib { export function doSomething(input: string): number; export function getData(): Promiseany; }这个文件放在项目的types目录下TypeScript会自动识别。需要注意的是declare module后面的模块名必须和import语句里的模块名完全一致。还有一个常见的坑Cocos Creator的项目里tsconfig.json的配置会影响类型检查的行为。默认情况下Cocos Creator生成的tsconfig.json已经配置好了但如果你手动修改了它可能会导致类型检查失效。我的建议是不要随意修改tsconfig.json除非你清楚自己在做什么。3.2 接口继承与泛型在小游戏数据结构中的实际用法TypeScript的接口继承和泛型在小游戏开发中非常实用特别是处理游戏数据结构的时候。先看接口继承。假设你有一个基础的实体接口interface Entity { id: number; x: number; y: number; active: boolean; } interface Player extends Entity { hp: number; mp: number; level: number; } interface Enemy extends Entity { damage: number; dropRate: number; }这样定义之后Player和Enemy都自动拥有了Entity的所有属性不需要重复声明。当你在代码里处理一个Entity数组的时候可以统一调用entity.x、entity.y而不需要关心它具体是玩家还是敌人。泛型的用法更灵活。比如你需要一个对象池来管理游戏中的子弹class ObjectPoolT { private pool: T[] []; constructor(private factory: () T) {} get(): T { if (this.pool.length 0) { return this.pool.pop()!; } return this.factory(); } put(obj: T): void { this.pool.push(obj); } }使用的时候你可以指定具体的类型const bulletPool new ObjectPoolBullet(() new Bullet()); const bullet bulletPool.get();这样TypeScript就能确保你从对象池里拿到的对象类型是正确的不会出现类型错误。3.3 编译配置与热重载让开发体验不拖后腿Cocos Creator的TypeScript编译是自动的你保存文件之后编辑器会自动编译并刷新。但在项目变大之后这个编译过程会变慢影响开发效率。我的优化经验是把不常改动的代码放到单独的目录利用TypeScript的增量编译。Cocos Creator支持增量编译但需要正确配置。具体来说在tsconfig.json里开启incremental选项并指定tsBuildInfoFile的路径。这样TypeScript会缓存上一次编译的结果只重新编译改动的文件。另一个技巧是减少循环依赖。TypeScript在处理循环依赖的时候编译速度会显著下降。如果你的项目里有很多文件互相引用编译时间会越来越长。解决方法是把公共的类型定义抽到一个单独的文件里其他文件都引用这个文件而不是互相引用。热重载方面Cocos Creator支持场景热重载和脚本热重载。场景热重载在修改UI布局的时候非常方便脚本热重载在修改逻辑的时候也很实用。但有一个坑热重载不会重置游戏状态。如果你在游戏运行中修改了脚本热重载之后游戏状态还是修改前的状态可能会导致一些奇怪的问题。我的做法是修改脚本之后手动重启一下游戏确保状态是干净的。4. Canvas绘图在小游戏中的性能边界与优化手段4.1 Canvas 2D渲染的核心瓶颈在哪里微信小游戏的渲染底层是Canvas 2D虽然Cocos Creator帮你封装了渲染层但了解Canvas 2D的性能瓶颈对于优化游戏性能非常重要。Canvas 2D的主要瓶颈有三个绘制调用次数、纹理切换次数、像素填充率。绘制调用次数是指你调用drawImage、fillRect这些API的次数。每一次调用都有开销如果一帧内调用几千次性能就会明显下降。Cocos Creator的渲染层会自动合并一些绘制调用但如果你用了自定义的渲染逻辑就需要自己注意。纹理切换次数是指在一帧内切换不同纹理的次数。每次切换纹理GPU都需要重新绑定纹理这个开销比绘制调用更大。所以尽量把同一张纹理上的精灵放在一起渲染是优化的关键。像素填充率是指每帧需要填充的像素数量。如果你的游戏有大量的半透明效果、粒子效果、或者全屏的渐变像素填充率就会成为瓶颈。在低端机上这个瓶颈尤其明显。4.2 合批与图集把绘制调用压到最低合批是Canvas 2D优化的核心手段。简单来说就是把多个绘制调用合并成一个。Cocos Creator的自动合批机制会在满足条件的情况下自动合并但你需要做一些配置来帮助它。最关键的是图集。把多个小图打包成一张大图这样它们就共享同一张纹理可以合批渲染。Cocos Creator支持自动图集你只需要把图片放到同一个目录下然后在构建配置里开启自动图集即可。但图集也有代价。如果图集太大加载时间会变长内存占用也会增加。我的经验是把图集控制在1024x1024以内最多不超过2048x2048。另外把经常一起出现的图片放在同一个图集里不经常一起出现的分开放这样能最大化合批的效果。还有一个细节节点的层级顺序会影响合批。如果两个使用同一张纹理的节点之间插入了使用其他纹理的节点合批就会被打断。所以在UI布局的时候尽量把使用同一张纹理的节点放在相邻的层级。4.3 对象池与脏矩形减少不必要的重绘对象池是减少对象创建和销毁开销的经典手段。在小游戏里子弹、敌人、特效这些频繁创建和销毁的对象都应该用对象池管理。Cocos Creator内置了NodePool类可以直接使用。但有一个坑NodePool只是简单地复用节点不会重置节点的状态。如果你在回收节点的时候没有重置它的属性比如位置、旋转、缩放、透明度下次从池子里取出来的时候它可能还带着上次的状态。我的做法是在回收节点的时候手动重置所有关键属性。脏矩形是另一个优化手段但Cocos Creator没有直接提供这个功能。它的原理是只重绘屏幕上发生变化的区域而不是整个屏幕。对于静态背景比较多的游戏这个优化能显著降低GPU负载。如果你确实需要这个功能可以考虑自己实现一个简单的脏矩形系统但要注意实现不当反而会降低性能。4.4 低端机适配帧率控制与降级策略微信小游戏的用户设备跨度很大从高端旗舰机到几百元的低端机都有。如果你的游戏在高端机上跑60帧在低端机上可能只有20帧。这时候就需要做降级策略。我的做法是在游戏启动时检测设备性能然后动态调整渲染质量。具体来说可以检测设备的devicePixelRatio、屏幕分辨率、以及通过运行一个简单的性能测试来估算设备的渲染能力。对于低端机可以采取以下降级措施降低帧率上限从60帧降到30帧、关闭粒子效果、降低纹理质量、减少同屏对象数量。这些措施可以在游戏运行时动态调整不需要重新构建。还有一个经验不要追求在所有设备上都跑60帧。对于休闲类小游戏30帧已经足够流畅了。把帧率上限设为30帧可以显著降低GPU和CPU的负载延长设备的续航时间减少发热。5. 一人工作室的协作与迭代节奏5.1 版本管理一个人也需要Git很多人觉得一个人做项目不需要版本管理反正就自己写改错了撤销就行。但实际做下来你会发现版本管理对于一人工作室同样重要。原因很简单你需要回滚。当你尝试一个新的玩法改了十几个文件结果发现效果不好想回到之前的状态如果没有版本管理你只能手动改回去或者凭记忆重写。有了Git一条命令就能回滚。我的Git使用习惯是每完成一个独立的功能就提交一次提交信息写清楚做了什么。分支策略很简单main分支保持稳定开发新功能的时候开一个feature分支完成之后合并回main。还有一个技巧把美术资源和代码分开管理。美术资源通常比较大如果和代码放在同一个仓库里仓库体积会迅速膨胀。我的做法是代码用Git管理美术资源用网盘或者对象存储管理在代码里只保留资源的引用路径。5.2 玩法验证用最小可玩原型快速试错一人工作室最大的优势是决策快最大的劣势是资源有限。所以在玩法验证阶段一定要用最小可玩原型来快速试错。最小可玩原型的意思是只实现核心玩法不做UI不做音效不做特效用最简单的图形代替美术资源。比如玩家用一个小方块表示敌人用红色圆圈表示子弹用白色小点表示。这样你可以在几个小时之内就把核心玩法跑通然后自己玩几遍判断这个玩法是否有趣。如果玩法有趣再花时间做美术、做UI、做音效。如果玩法无趣直接放弃换下一个想法。这样可以避免在无趣的玩法上浪费大量时间。我自己的经验是十个想法里可能只有一两个值得做成完整的游戏。所以快速试错的能力比做好一个游戏的能力更重要。5.3 上线后的数据观察与快速迭代游戏上线之后工作并没有结束。你需要观察数据了解玩家的行为然后快速迭代。微信小游戏平台提供了数据分析工具可以查看用户的留存率、时长、分享率等指标。我的经验是重点关注次日留存和平均时长这两个指标。次日留存低于20%说明玩法可能有问题平均时长低于3分钟说明游戏可能不够吸引人。根据数据反馈快速迭代。如果发现某个关卡流失率特别高就去分析原因是难度太高还是引导不够清晰。如果发现某个功能使用率很低就考虑是否要砍掉。迭代的节奏也很重要。我的做法是上线后第一周每天更新一次修复紧急问题第二周开始每三天更新一次一个月之后每周更新一次。这样既能快速响应问题又不会让自己太累。6. 那些官方文档不会告诉你的坑6.1 微信小游戏包体限制的绕行方案与代价微信小游戏主包4MB的限制是每个开发者都要面对的问题。官方的建议是使用分包但分包也有一些坑。首先分包加载是异步的这意味着你不能在分包加载完成之前使用分包里的资源。如果你的游戏逻辑依赖于分包里的某个模块就需要处理好加载时机否则会出现资源找不到的错误。其次分包的数量和大小也有限制。微信小游戏最多支持10个分包每个分包最大4MB总包体最大20MB。对于大多数小游戏来说这个限制是够用的但如果你要做大型游戏就需要仔细规划分包策略。还有一个坑分包加载失败的处理。在网络不稳定的情况下分包加载可能会失败。你需要实现重试机制并且在重试失败之后给用户一个友好的提示而不是直接崩溃。6.2 真机与开发者工具的差异触摸、音频、性能微信开发者工具是一个模拟环境它和真机有很多差异。这些差异如果不注意会导致你在开发者工具里测试没问题一到真机上就出问题。触摸事件是最常见的差异之一。开发者工具里用鼠标点击模拟触摸但真机上是多点触摸。如果你的游戏需要处理多点触摸比如双指缩放在开发者工具里是测试不出来的必须用真机测试。音频播放也有差异。开发者工具里的音频播放是即时的但真机上可能会有延迟。特别是第一次播放音频的时候延迟可能达到几百毫秒。解决方法是在游戏启动时预加载音频或者用wx.createInnerAudioContext的onCanplay回调来确保音频准备好之后再播放。性能表现的差异更大。开发者工具运行在PC上性能远好于手机。在开发者工具里跑60帧的游戏在低端手机上可能只有20帧。所以性能测试一定要在真机上进行而且要在多种机型上测试。6.3 内存泄漏的排查从表现到根因的完整链路内存泄漏是小游戏开发中比较隐蔽的问题。它的表现是游戏运行一段时间后越来越卡最终崩溃。排查内存泄漏需要耐心和系统的方法。我的排查链路是这样的第一步确认是否存在内存泄漏。在微信开发者工具的性能面板里观察内存占用曲线。如果内存占用持续上升不下降就说明存在泄漏。第二步定位泄漏的类型。是JavaScript对象泄漏还是纹理资源泄漏还是节点泄漏可以通过开发者工具的内存快照来对比不同时间点的对象数量。第三步找到泄漏的源头。常见的泄漏原因有事件监听没有移除、定时器没有清除、节点从场景中移除但没有销毁、纹理资源没有释放。第四步修复并验证。修复之后重新运行游戏观察内存曲线是否恢复正常。我遇到过一个典型的泄漏案例在场景切换的时候旧场景的节点被移除了但节点上绑定的事件监听没有移除。这些监听器持有对旧场景的引用导致旧场景无法被垃圾回收。解决方法是在场景切换的时候手动移除所有事件监听。6.4 审核被拒的常见原因与规避方法微信小游戏的审核比较严格被拒的原因五花八门。我总结了几类常见的原因和规避方法。内容问题是最常见的被拒原因。游戏内容不能包含违规信息不能有诱导分享不能有虚假宣传。规避方法是在提交审核之前仔细阅读微信小游戏的运营规范确保游戏内容符合要求。技术问题也很常见。比如游戏在某些机型上崩溃、加载失败、或者有严重的性能问题。规避方法是在提交审核之前在多种机型上充分测试确保游戏稳定运行。资质问题是另一个常见原因。如果你的游戏涉及某些特殊品类比如棋牌、捕鱼需要提供相应的资质证明。规避方法是在开发之前就了解清楚所需的资质提前准备好。还有一个经验审核被拒之后不要急着重新提交。先仔细阅读被拒原因找到根本问题修复之后再提交。如果只是改了一点无关紧要的东西就重新提交很可能会再次被拒。7. 从一人工作室到可持续开发的节奏管理7.1 时间分配开发、学习、运营的平衡一人工作室最大的挑战不是技术而是时间管理。你既是开发又是策划又是美术又是运营。如果时间分配不好很容易陷入某个环节无法自拔。我的时间分配大致是这样的开发占50%学习占20%运营占20%其他占10%。开发是核心必须保证足够的时间。学习是为了保持技术更新了解新的工具和方法。运营包括数据分析、用户反馈处理、版本更新等。其他包括一些杂事比如服务器维护、财务处理等。但这个比例不是固定的。在游戏上线初期运营的时间会更多在开发新功能的时候开发的时间会更多。关键是要有一个大致的规划不要让自己在某个环节上花太多时间而忽略了其他环节。7.2 技术债的管理什么时候该重构什么时候该忍着技术债是每个项目都会有的。一人工作室的项目技术债可能更多因为没有人帮你做代码审查没有人提醒你哪里写得不好。我的原则是影响开发效率的技术债尽早还不影响开发效率的技术债可以先忍着。比如如果你的代码里有一个函数参数列表有十几个每次调用都要查文档这就是影响开发效率的技术债应该尽早重构。但如果你的代码里有一个模块写得比较乱但功能稳定很少改动那就可以先忍着等有时间再重构。还有一个经验不要为了重构而重构。重构的目的是提升开发效率如果重构本身花费的时间比它节省的时间还多那就不值得。特别是在一人工作室的场景下时间是最稀缺的资源要把时间花在刀刃上。7.3 心态调整一个人做游戏的孤独与坚持最后想聊一下心态。一个人做游戏最大的挑战不是技术而是孤独。没有人跟你讨论技术方案没有人帮你测试没有人给你反馈。你只能自己跟自己对话自己给自己打气。我的经验是找到自己的节奏不要跟别人比。看到别人的游戏上线了数据很好你可能会焦虑。但每个人的情况不一样有的人有团队有的人有资金有的人有经验。你只需要跟昨天的自己比今天比昨天进步了一点就够了。另外给自己设定小目标。不要想着一步到位做出一个爆款游戏先做出一个能跑通的小游戏然后逐步完善。每完成一个小目标就给自己一点奖励保持动力。还有一点很重要保持学习但不要盲目追新。技术更新很快今天流行这个框架明天流行那个引擎。但你的时间和精力是有限的不要什么都学。选一个方向深入下去比什么都懂一点但什么都不精要强。我在做小游戏的这几年最大的体会是技术只是工具真正决定成败的是你对玩法的理解和对用户的洞察。一个人做游戏虽然辛苦但也很自由。你可以完全按照自己的想法去做不用妥协不用开会不用写周报。这种自由是很多大厂开发者羡慕不来的。如果你也在做一人工作室或者正在考虑做我的建议是先做一个最小可玩原型跑通整个流程然后再决定要不要继续。不要一上来就想着做大作从小做起快速迭代持续学习。这条路不好走但走通了会很爽。
微信小游戏一人工作室实战：Cocos Creator与TypeScript从零到上线
微信小游戏这个赛道我从2019年就开始断断续续地折腾中间做过消除类、答题类、模拟经营类也帮朋友的工作室做过技术顾问。说实话一个人做小游戏这件事听起来挺酷但真正上手之后你会发现技术选型、性能优化、包体控制、平台适配每一个环节都够你喝一壶的。今天这篇分享我想把一人工作室从零到上线一款微信小游戏的完整实战经验摊开来聊包括我为什么最终选了Cocos Creator而不是PhaserTypeScript在小游戏项目里到底怎么用才不添乱Canvas绘图的性能天花板在哪里以及那些官方文档里不会写的坑。如果你是一个独立开发者或者小团队里负责技术选型的那个人正在纠结用什么引擎、怎么组织代码、怎么把包体压到微信要求的范围内那这篇内容应该能帮你省下不少试错时间。我不会只给你步骤还会告诉你每一步为什么这么做以及我踩过的那些坑。1. 为什么一人工作室选引擎比选语言更重要1.1 Cocos Creator、Phaser、裸Canvas三条路线的真实对比一个人做微信小游戏最先要做的决定不是写什么玩法而是用什么技术栈。我见过太多人在这上面反复横跳今天觉得Phaser轻量明天觉得Cocos Creator功能全后天又想着干脆用裸Canvas自己撸一个渲染层。结果时间全花在折腾工具上了游戏本身没写几行。先给一个结论如果你目标是微信小游戏平台Cocos Creator是目前综合成本最低的选择。但这句话有前提下面我把三条路线拆开说。Cocos Creator的核心优势在于它对微信小游戏的原生适配。它内置了微信小游戏的构建模板一键打包就能生成符合微信规范的代码包包括适配层、分包配置、远程资源加载这些。你不需要自己去处理wx.createCanvas、wx.onTouchStart这些平台API的差异引擎已经帮你封装好了。另外它的编辑器支持场景编辑、动画编辑、粒子系统、物理系统一个人可以同时兼顾策划和开发的工作。但Cocos Creator也有代价。它的运行时库体积不小一个空项目构建出来的微信小游戏包大概在1.5MB到2MB左右取决于你勾选了哪些模块。微信小游戏主包限制是4MB如果你玩法复杂一点很容易就顶到天花板必须做分包。另外它的学习曲线比Phaser陡编辑器本身就是一个需要花时间熟悉的大型工具。Phaser是一个纯JavaScript的2D游戏框架轻量、灵活、API设计得很舒服。如果你之前写过Web前端上手Phaser几乎没有什么门槛。它的社区也很活跃文档和示例都很全。但问题在于Phaser对微信小游戏的支持是社区层面的不是官方级别的。你需要自己引入适配层自己处理Canvas的创建和触摸事件的绑定自己解决资源加载在小游戏环境下的路径问题。这些事情单拎出来都不难但加在一起对于一个一人工作室来说就是额外的时间成本。裸Canvas这条路我只有在做极简原型的时候才会考虑。它的好处是极致轻量你可以精确控制每一行代码包体可以压到几百KB。但坏处也很明显你需要自己实现渲染循环、精灵管理、碰撞检测、动画系统、资源管理、场景切换。这些东西在游戏引擎里都是现成的你自己写一遍少说也要花掉一两周而且稳定性远不如成熟引擎。我当时的决策逻辑是这样的我的目标是快速验证玩法然后上线迭代。时间是最稀缺的资源所以我愿意用包体大小换开发效率。最终选了Cocos Creator 3.x版本TypeScript作为主要开发语言。1.2 TypeScript在小游戏项目里的真实收益与隐性成本选TypeScript这件事我当时犹豫了很久。原因很简单小游戏项目通常规模不大代码量可能就几千行TypeScript的类型系统带来的收益能不能覆盖它带来的额外复杂度实际做下来我的结论是对于一人工作室TypeScript的收益是正的但前提是你用对方式。收益方面最明显的是重构安全性。小游戏开发过程中玩法调整是家常便饭。今天觉得跳跃高度不对明天觉得敌人AI太蠢后天想把整个战斗系统推翻重做。在JavaScript里你改一个函数的参数签名可能要在十几个文件里手动搜索调用点漏掉一个就是运行时崩溃。TypeScript的编译器会直接告诉你哪里不匹配这种安全感在频繁重构的场景下非常值钱。另一个收益是代码提示。Cocos Creator的编辑器对TypeScript的支持很好组件的属性、节点的方法、事件的参数类型都有完整的提示。这在你记不清某个API怎么用的时候能省下大量查文档的时间。但隐性成本也是真实存在的。首先是构建时间TypeScript需要编译成JavaScript才能运行虽然Cocos Creator内部集成了编译流程但在项目变大之后每次修改后的热重载等待时间会明显变长。其次是类型定义的维护成本特别是当你引入第三方库的时候如果没有现成的.d.ts声明文件你需要自己写这本身就是一件费时费力的事情。我的建议是如果你之前没有TypeScript经验不要为了做小游戏专门去学。先用JavaScript把玩法跑通等代码量上来了、重构频繁了再逐步迁移到TypeScript。但如果你已经熟悉TypeScript那就直接用不要犹豫。1.3 一人工作室的模块取舍哪些引擎功能该关掉Cocos Creator在构建的时候允许你选择包含哪些模块。这个选项对于一人工作室来说极其重要因为每多勾一个模块包体就大一圈。我的做法是先全部关掉然后按需开启。具体来说3D相关的模块全部关掉物理引擎如果玩法不需要也关掉粒子系统如果不用也关掉。只保留2D渲染、UI系统、音频系统、资源管理这几个核心模块。这里有一个容易忽略的点Cocos Creator的构建配置里有一个引擎分离选项。开启之后引擎代码会被单独打包成一个文件和你的业务代码分开。这样做的好处是当你的业务代码更新时用户不需要重新下载引擎部分可以利用缓存。对于频繁迭代的小游戏来说这个选项能显著提升用户的更新体验。还有一个经验在开发阶段不要过早优化包体。先把功能做完确保玩法跑通然后再花时间做包体裁剪。因为玩法调整可能会导致你重新启用某些模块过早裁剪只会让你反复折腾。2. 微信小游戏项目从零搭建的完整链路2.1 项目初始化目录结构与命名规范一个人做项目最容易犯的错误就是目录结构混乱。反正没人管我文件随便放命名随便起。等到项目做到一半想找一个两年前写的工具函数翻遍整个项目都找不到。我的做法是在项目初始化阶段就定好目录结构并且严格执行。下面是我实际使用的目录结构assets/ scripts/ core/ # 核心框架代码与具体玩法无关 game/ # 玩法相关代码 ui/ # UI组件 utils/ # 工具函数 config/ # 配置数据 resources/ # 动态加载的资源 scenes/ # 场景文件 textures/ # 纹理资源 audio/ # 音频资源 prefabs/ # 预制体命名规范方面我遵循几条简单的规则脚本文件用大驼峰命名如PlayerController.ts工具函数用小驼峰如formatTime.ts场景文件用下划线分隔如main_scene.scene纹理资源用下划线分隔如player_idle.png。这些规则本身不重要重要的是统一。一旦定下来就不要随意更改。2.2 微信开发者工具的联调配置与常见连接问题Cocos Creator构建出微信小游戏包之后需要用微信开发者工具打开。这个环节有几个配置项容易出问题。首先是AppID。你需要在微信公众平台注册一个小游戏账号拿到AppID然后在Cocos Creator的构建配置里填入。如果没有AppID可以用测试号但测试号有一些功能限制比如不能真机预览。其次是服务器域名。如果你的游戏需要请求后端接口必须在微信公众平台配置合法域名。开发阶段可以在开发者工具里勾选不校验合法域名但上线前一定要配置好否则真机上请求会失败。还有一个常见问题是资源加载路径。Cocos Creator构建出来的资源路径和编辑器里的路径可能不一致特别是在使用了分包之后。我的经验是在代码里尽量使用resources.load这样的动态加载接口而不是直接引用资源路径。这样即使路径变了代码也不需要改。2.3 构建发布包体压缩与首屏加载优化微信小游戏的主包限制是4MB这个限制对于稍微复杂一点的游戏来说都很紧张。我的项目最终主包控制在3.2MB左右首屏加载时间在2秒以内。下面是我用到的几个关键优化手段。纹理压缩是最有效的包体优化手段。Cocos Creator支持多种纹理压缩格式对于微信小游戏推荐使用ASTC格式。但ASTC有一个问题不同机型的支持程度不一样。我的做法是在构建配置里同时生成ASTC和PNG两种格式运行时根据设备能力动态选择。音频压缩也很重要。小游戏里的背景音乐和音效如果不压缩很容易就占掉几百KB。我通常把背景音乐压成64kbps的MP3音效压成96kbps的MP3。对于短音效可以考虑用WAV格式但要注意采样率不要太高。代码混淆与压缩是构建时的默认选项但有一个细节需要注意Cocos Creator的构建配置里有一个压缩代码选项开启之后会用Terser对代码进行压缩。这个选项在开发阶段可以关掉方便调试发布时一定要开启。首屏加载优化的核心思路是把首屏不需要的资源放到分包里。比如游戏的设置界面、排行榜界面、商城界面这些都可以做成分包等用户点击的时候再加载。Cocos Creator支持分包配置你只需要在构建配置里指定哪些目录属于分包即可。3. TypeScript在小游戏项目中的工程化实践3.1 类型声明文件.d.ts的编写与第三方库接入在小游戏项目里使用TypeScript绕不开的一个问题就是类型声明文件。Cocos Creator自带的API都有完整的类型声明但当你引入第三方库的时候情况就不一样了。以lodash为例它是一个纯JavaScript库没有内置的TypeScript类型。你需要安装types/lodash这个包它提供了lodash的类型声明。安装之后TypeScript就能正确识别lodash的API了。但有些库没有现成的类型声明比如一些小的工具库或者你自己写的旧代码。这时候你需要自己写.d.ts文件。下面是一个简单的例子// types/myLib.d.ts declare module myLib { export function doSomething(input: string): number; export function getData(): Promiseany; }这个文件放在项目的types目录下TypeScript会自动识别。需要注意的是declare module后面的模块名必须和import语句里的模块名完全一致。还有一个常见的坑Cocos Creator的项目里tsconfig.json的配置会影响类型检查的行为。默认情况下Cocos Creator生成的tsconfig.json已经配置好了但如果你手动修改了它可能会导致类型检查失效。我的建议是不要随意修改tsconfig.json除非你清楚自己在做什么。3.2 接口继承与泛型在小游戏数据结构中的实际用法TypeScript的接口继承和泛型在小游戏开发中非常实用特别是处理游戏数据结构的时候。先看接口继承。假设你有一个基础的实体接口interface Entity { id: number; x: number; y: number; active: boolean; } interface Player extends Entity { hp: number; mp: number; level: number; } interface Enemy extends Entity { damage: number; dropRate: number; }这样定义之后Player和Enemy都自动拥有了Entity的所有属性不需要重复声明。当你在代码里处理一个Entity数组的时候可以统一调用entity.x、entity.y而不需要关心它具体是玩家还是敌人。泛型的用法更灵活。比如你需要一个对象池来管理游戏中的子弹class ObjectPoolT { private pool: T[] []; constructor(private factory: () T) {} get(): T { if (this.pool.length 0) { return this.pool.pop()!; } return this.factory(); } put(obj: T): void { this.pool.push(obj); } }使用的时候你可以指定具体的类型const bulletPool new ObjectPoolBullet(() new Bullet()); const bullet bulletPool.get();这样TypeScript就能确保你从对象池里拿到的对象类型是正确的不会出现类型错误。3.3 编译配置与热重载让开发体验不拖后腿Cocos Creator的TypeScript编译是自动的你保存文件之后编辑器会自动编译并刷新。但在项目变大之后这个编译过程会变慢影响开发效率。我的优化经验是把不常改动的代码放到单独的目录利用TypeScript的增量编译。Cocos Creator支持增量编译但需要正确配置。具体来说在tsconfig.json里开启incremental选项并指定tsBuildInfoFile的路径。这样TypeScript会缓存上一次编译的结果只重新编译改动的文件。另一个技巧是减少循环依赖。TypeScript在处理循环依赖的时候编译速度会显著下降。如果你的项目里有很多文件互相引用编译时间会越来越长。解决方法是把公共的类型定义抽到一个单独的文件里其他文件都引用这个文件而不是互相引用。热重载方面Cocos Creator支持场景热重载和脚本热重载。场景热重载在修改UI布局的时候非常方便脚本热重载在修改逻辑的时候也很实用。但有一个坑热重载不会重置游戏状态。如果你在游戏运行中修改了脚本热重载之后游戏状态还是修改前的状态可能会导致一些奇怪的问题。我的做法是修改脚本之后手动重启一下游戏确保状态是干净的。4. Canvas绘图在小游戏中的性能边界与优化手段4.1 Canvas 2D渲染的核心瓶颈在哪里微信小游戏的渲染底层是Canvas 2D虽然Cocos Creator帮你封装了渲染层但了解Canvas 2D的性能瓶颈对于优化游戏性能非常重要。Canvas 2D的主要瓶颈有三个绘制调用次数、纹理切换次数、像素填充率。绘制调用次数是指你调用drawImage、fillRect这些API的次数。每一次调用都有开销如果一帧内调用几千次性能就会明显下降。Cocos Creator的渲染层会自动合并一些绘制调用但如果你用了自定义的渲染逻辑就需要自己注意。纹理切换次数是指在一帧内切换不同纹理的次数。每次切换纹理GPU都需要重新绑定纹理这个开销比绘制调用更大。所以尽量把同一张纹理上的精灵放在一起渲染是优化的关键。像素填充率是指每帧需要填充的像素数量。如果你的游戏有大量的半透明效果、粒子效果、或者全屏的渐变像素填充率就会成为瓶颈。在低端机上这个瓶颈尤其明显。4.2 合批与图集把绘制调用压到最低合批是Canvas 2D优化的核心手段。简单来说就是把多个绘制调用合并成一个。Cocos Creator的自动合批机制会在满足条件的情况下自动合并但你需要做一些配置来帮助它。最关键的是图集。把多个小图打包成一张大图这样它们就共享同一张纹理可以合批渲染。Cocos Creator支持自动图集你只需要把图片放到同一个目录下然后在构建配置里开启自动图集即可。但图集也有代价。如果图集太大加载时间会变长内存占用也会增加。我的经验是把图集控制在1024x1024以内最多不超过2048x2048。另外把经常一起出现的图片放在同一个图集里不经常一起出现的分开放这样能最大化合批的效果。还有一个细节节点的层级顺序会影响合批。如果两个使用同一张纹理的节点之间插入了使用其他纹理的节点合批就会被打断。所以在UI布局的时候尽量把使用同一张纹理的节点放在相邻的层级。4.3 对象池与脏矩形减少不必要的重绘对象池是减少对象创建和销毁开销的经典手段。在小游戏里子弹、敌人、特效这些频繁创建和销毁的对象都应该用对象池管理。Cocos Creator内置了NodePool类可以直接使用。但有一个坑NodePool只是简单地复用节点不会重置节点的状态。如果你在回收节点的时候没有重置它的属性比如位置、旋转、缩放、透明度下次从池子里取出来的时候它可能还带着上次的状态。我的做法是在回收节点的时候手动重置所有关键属性。脏矩形是另一个优化手段但Cocos Creator没有直接提供这个功能。它的原理是只重绘屏幕上发生变化的区域而不是整个屏幕。对于静态背景比较多的游戏这个优化能显著降低GPU负载。如果你确实需要这个功能可以考虑自己实现一个简单的脏矩形系统但要注意实现不当反而会降低性能。4.4 低端机适配帧率控制与降级策略微信小游戏的用户设备跨度很大从高端旗舰机到几百元的低端机都有。如果你的游戏在高端机上跑60帧在低端机上可能只有20帧。这时候就需要做降级策略。我的做法是在游戏启动时检测设备性能然后动态调整渲染质量。具体来说可以检测设备的devicePixelRatio、屏幕分辨率、以及通过运行一个简单的性能测试来估算设备的渲染能力。对于低端机可以采取以下降级措施降低帧率上限从60帧降到30帧、关闭粒子效果、降低纹理质量、减少同屏对象数量。这些措施可以在游戏运行时动态调整不需要重新构建。还有一个经验不要追求在所有设备上都跑60帧。对于休闲类小游戏30帧已经足够流畅了。把帧率上限设为30帧可以显著降低GPU和CPU的负载延长设备的续航时间减少发热。5. 一人工作室的协作与迭代节奏5.1 版本管理一个人也需要Git很多人觉得一个人做项目不需要版本管理反正就自己写改错了撤销就行。但实际做下来你会发现版本管理对于一人工作室同样重要。原因很简单你需要回滚。当你尝试一个新的玩法改了十几个文件结果发现效果不好想回到之前的状态如果没有版本管理你只能手动改回去或者凭记忆重写。有了Git一条命令就能回滚。我的Git使用习惯是每完成一个独立的功能就提交一次提交信息写清楚做了什么。分支策略很简单main分支保持稳定开发新功能的时候开一个feature分支完成之后合并回main。还有一个技巧把美术资源和代码分开管理。美术资源通常比较大如果和代码放在同一个仓库里仓库体积会迅速膨胀。我的做法是代码用Git管理美术资源用网盘或者对象存储管理在代码里只保留资源的引用路径。5.2 玩法验证用最小可玩原型快速试错一人工作室最大的优势是决策快最大的劣势是资源有限。所以在玩法验证阶段一定要用最小可玩原型来快速试错。最小可玩原型的意思是只实现核心玩法不做UI不做音效不做特效用最简单的图形代替美术资源。比如玩家用一个小方块表示敌人用红色圆圈表示子弹用白色小点表示。这样你可以在几个小时之内就把核心玩法跑通然后自己玩几遍判断这个玩法是否有趣。如果玩法有趣再花时间做美术、做UI、做音效。如果玩法无趣直接放弃换下一个想法。这样可以避免在无趣的玩法上浪费大量时间。我自己的经验是十个想法里可能只有一两个值得做成完整的游戏。所以快速试错的能力比做好一个游戏的能力更重要。5.3 上线后的数据观察与快速迭代游戏上线之后工作并没有结束。你需要观察数据了解玩家的行为然后快速迭代。微信小游戏平台提供了数据分析工具可以查看用户的留存率、时长、分享率等指标。我的经验是重点关注次日留存和平均时长这两个指标。次日留存低于20%说明玩法可能有问题平均时长低于3分钟说明游戏可能不够吸引人。根据数据反馈快速迭代。如果发现某个关卡流失率特别高就去分析原因是难度太高还是引导不够清晰。如果发现某个功能使用率很低就考虑是否要砍掉。迭代的节奏也很重要。我的做法是上线后第一周每天更新一次修复紧急问题第二周开始每三天更新一次一个月之后每周更新一次。这样既能快速响应问题又不会让自己太累。6. 那些官方文档不会告诉你的坑6.1 微信小游戏包体限制的绕行方案与代价微信小游戏主包4MB的限制是每个开发者都要面对的问题。官方的建议是使用分包但分包也有一些坑。首先分包加载是异步的这意味着你不能在分包加载完成之前使用分包里的资源。如果你的游戏逻辑依赖于分包里的某个模块就需要处理好加载时机否则会出现资源找不到的错误。其次分包的数量和大小也有限制。微信小游戏最多支持10个分包每个分包最大4MB总包体最大20MB。对于大多数小游戏来说这个限制是够用的但如果你要做大型游戏就需要仔细规划分包策略。还有一个坑分包加载失败的处理。在网络不稳定的情况下分包加载可能会失败。你需要实现重试机制并且在重试失败之后给用户一个友好的提示而不是直接崩溃。6.2 真机与开发者工具的差异触摸、音频、性能微信开发者工具是一个模拟环境它和真机有很多差异。这些差异如果不注意会导致你在开发者工具里测试没问题一到真机上就出问题。触摸事件是最常见的差异之一。开发者工具里用鼠标点击模拟触摸但真机上是多点触摸。如果你的游戏需要处理多点触摸比如双指缩放在开发者工具里是测试不出来的必须用真机测试。音频播放也有差异。开发者工具里的音频播放是即时的但真机上可能会有延迟。特别是第一次播放音频的时候延迟可能达到几百毫秒。解决方法是在游戏启动时预加载音频或者用wx.createInnerAudioContext的onCanplay回调来确保音频准备好之后再播放。性能表现的差异更大。开发者工具运行在PC上性能远好于手机。在开发者工具里跑60帧的游戏在低端手机上可能只有20帧。所以性能测试一定要在真机上进行而且要在多种机型上测试。6.3 内存泄漏的排查从表现到根因的完整链路内存泄漏是小游戏开发中比较隐蔽的问题。它的表现是游戏运行一段时间后越来越卡最终崩溃。排查内存泄漏需要耐心和系统的方法。我的排查链路是这样的第一步确认是否存在内存泄漏。在微信开发者工具的性能面板里观察内存占用曲线。如果内存占用持续上升不下降就说明存在泄漏。第二步定位泄漏的类型。是JavaScript对象泄漏还是纹理资源泄漏还是节点泄漏可以通过开发者工具的内存快照来对比不同时间点的对象数量。第三步找到泄漏的源头。常见的泄漏原因有事件监听没有移除、定时器没有清除、节点从场景中移除但没有销毁、纹理资源没有释放。第四步修复并验证。修复之后重新运行游戏观察内存曲线是否恢复正常。我遇到过一个典型的泄漏案例在场景切换的时候旧场景的节点被移除了但节点上绑定的事件监听没有移除。这些监听器持有对旧场景的引用导致旧场景无法被垃圾回收。解决方法是在场景切换的时候手动移除所有事件监听。6.4 审核被拒的常见原因与规避方法微信小游戏的审核比较严格被拒的原因五花八门。我总结了几类常见的原因和规避方法。内容问题是最常见的被拒原因。游戏内容不能包含违规信息不能有诱导分享不能有虚假宣传。规避方法是在提交审核之前仔细阅读微信小游戏的运营规范确保游戏内容符合要求。技术问题也很常见。比如游戏在某些机型上崩溃、加载失败、或者有严重的性能问题。规避方法是在提交审核之前在多种机型上充分测试确保游戏稳定运行。资质问题是另一个常见原因。如果你的游戏涉及某些特殊品类比如棋牌、捕鱼需要提供相应的资质证明。规避方法是在开发之前就了解清楚所需的资质提前准备好。还有一个经验审核被拒之后不要急着重新提交。先仔细阅读被拒原因找到根本问题修复之后再提交。如果只是改了一点无关紧要的东西就重新提交很可能会再次被拒。7. 从一人工作室到可持续开发的节奏管理7.1 时间分配开发、学习、运营的平衡一人工作室最大的挑战不是技术而是时间管理。你既是开发又是策划又是美术又是运营。如果时间分配不好很容易陷入某个环节无法自拔。我的时间分配大致是这样的开发占50%学习占20%运营占20%其他占10%。开发是核心必须保证足够的时间。学习是为了保持技术更新了解新的工具和方法。运营包括数据分析、用户反馈处理、版本更新等。其他包括一些杂事比如服务器维护、财务处理等。但这个比例不是固定的。在游戏上线初期运营的时间会更多在开发新功能的时候开发的时间会更多。关键是要有一个大致的规划不要让自己在某个环节上花太多时间而忽略了其他环节。7.2 技术债的管理什么时候该重构什么时候该忍着技术债是每个项目都会有的。一人工作室的项目技术债可能更多因为没有人帮你做代码审查没有人提醒你哪里写得不好。我的原则是影响开发效率的技术债尽早还不影响开发效率的技术债可以先忍着。比如如果你的代码里有一个函数参数列表有十几个每次调用都要查文档这就是影响开发效率的技术债应该尽早重构。但如果你的代码里有一个模块写得比较乱但功能稳定很少改动那就可以先忍着等有时间再重构。还有一个经验不要为了重构而重构。重构的目的是提升开发效率如果重构本身花费的时间比它节省的时间还多那就不值得。特别是在一人工作室的场景下时间是最稀缺的资源要把时间花在刀刃上。7.3 心态调整一个人做游戏的孤独与坚持最后想聊一下心态。一个人做游戏最大的挑战不是技术而是孤独。没有人跟你讨论技术方案没有人帮你测试没有人给你反馈。你只能自己跟自己对话自己给自己打气。我的经验是找到自己的节奏不要跟别人比。看到别人的游戏上线了数据很好你可能会焦虑。但每个人的情况不一样有的人有团队有的人有资金有的人有经验。你只需要跟昨天的自己比今天比昨天进步了一点就够了。另外给自己设定小目标。不要想着一步到位做出一个爆款游戏先做出一个能跑通的小游戏然后逐步完善。每完成一个小目标就给自己一点奖励保持动力。还有一点很重要保持学习但不要盲目追新。技术更新很快今天流行这个框架明天流行那个引擎。但你的时间和精力是有限的不要什么都学。选一个方向深入下去比什么都懂一点但什么都不精要强。我在做小游戏的这几年最大的体会是技术只是工具真正决定成败的是你对玩法的理解和对用户的洞察。一个人做游戏虽然辛苦但也很自由。你可以完全按照自己的想法去做不用妥协不用开会不用写周报。这种自由是很多大厂开发者羡慕不来的。如果你也在做一人工作室或者正在考虑做我的建议是先做一个最小可玩原型跑通整个流程然后再决定要不要继续。不要一上来就想着做大作从小做起快速迭代持续学习。这条路不好走但走通了会很爽。