1. 从零到一：为什么我选择微信小游戏作为独立开发的起点
1.1 一个前端老兵的转型思考
做了六年Web前端，我一直在浏览器和移动端H5之间来回切换。2023年底，公司项目收缩，我有了大把空闲时间，开始认真思考一个问题：能不能用我现有的技术栈，做出一款能直接触达用户、有完整商业闭环的小产品？App开发太重，上架审核周期长，推广成本高；H5页面太轻，留存和变现都很难做。微信小游戏恰好卡在中间——它既有原生App级别的用户体验，又具备H5的传播便利性，而且微信生态内的社交裂变能力是任何独立App都无法比拟的。
我给自己定了一个目标：一个人，一个月，从零做出一款能跑通广告变现的微信小游戏。这个目标听起来有点疯狂，但实际做下来，我发现技术门槛远比想象中低。微信小游戏本质上就是一个运行在微信环境里的JavaScript项目，核心渲染依赖Canvas，逻辑层和渲染层通过微信提供的适配层通信。如果你写过Canvas动画或者用过Cocos Creator，上手成本几乎为零。
1.2 微信小游戏的技术底座到底是什么
很多人以为微信小游戏是“阉割版的小程序”，其实两者在架构上有本质区别。小程序用的是WebView渲染，逻辑层和渲染层分离，通过setData通信；而小游戏直接调用微信封装的Canvas API，逻辑和渲染都在同一个JavaScript上下文中执行，性能更接近原生。你可以把它理解为一个“定制版的浏览器环境”——微信提供了wx.createCanvas()来创建画布，提供了wx.onTouchStart等触摸事件接口，提供了wx.createInnerAudioContext()来播放音频，剩下的就是你自己用JavaScript和Canvas API来画一切。
这里有一个关键概念叫适配层。微信小游戏运行环境并不是标准的浏览器，没有DOM，没有BOM，没有document对象。你熟悉的document.getElementById、window.addEventListener全都不存在。微信提供了一套自己的API来替代这些功能，比如用wx.createCanvas()代替document.createElement('canvas')，用wx.onTouchStart代替addEventListener('touchstart')。如果你用原生Canvas开发，需要自己写一层适配；如果你用Cocos Creator或LayaBox等引擎，引擎已经帮你处理好了这些差异。
1.3 为什么最终选了Cocos Creator而不是裸写Canvas
我最初尝试过裸写Canvas，用requestAnimationFrame驱动游戏循环，手动管理精灵的绘制和碰撞检测。做一个小Demo没问题，但当游戏逻辑稍微复杂一点——比如需要场景管理、动画状态机、物理碰撞、资源加载——代码量就会爆炸式增长。我算了一笔账：裸写Canvas开发一款中等复杂度的休闲游戏，至少需要自己实现场景图、资源管理器、动画系统、碰撞检测、UI布局，这些工作量加起来可能比游戏本身的逻辑还多。
Cocos Creator的优势在于它把这些基础设施都做好了。你只需要在编辑器里拖拽组件、配置属性，写少量的脚本就能实现复杂的游戏逻辑。更重要的是，Cocos Creator对微信小游戏的支持非常成熟，一键发布就能生成符合微信规范的game.json和项目结构。当然，代价是包体体积会大一些——Cocos Creator的引擎核心压缩后大约500KB左右，对于小游戏来说完全可以接受。
如果你只是想做一个简单的交互页面，比如“小金鱼捏捏”那种点击反馈类的小玩意，裸写Canvas反而更轻量。但如果你要做的是有完整玩法、有多个场景、有动画和音效的游戏，引擎是更好的选择。
2. 环境搭建与项目初始化：别在第一步就踩坑
2.1 工具链选型与安装避坑
开发微信小游戏需要三样东西：微信开发者工具、代码编辑器（我用VS Code）、游戏引擎（我选Cocos Creator 3.8）。微信开发者工具是必须的，它提供了小游戏的模拟器、调试器和真机预览功能。Cocos Creator负责编辑游戏场景和逻辑，最终导出成微信小游戏项目。
安装过程本身没什么难度，但有几个坑我踩过，这里直接给你标出来。第一，微信开发者工具的安装路径不要包含中文和空格，否则在某些Windows系统上会出现模拟器启动失败的问题。第二，Cocos Creator的版本选择很重要——3.8.x是目前对微信小游戏支持最稳定的版本，不要盲目追新。第三，安装完Cocos Creator后，需要在偏好设置里配置微信开发者工具的路径，这样发布时才能自动唤起微信开发者工具。
# 检查Node.js版本，Cocos Creator 3.8要求Node 14以上 node -v # 如果版本过低，建议用nvm切换 nvm install 16 nvm use 162.2 创建项目时的关键参数选择
打开Cocos Creator，新建项目时选择“Empty(2D)”模板。项目名称用英文，路径不要有中文。创建完成后，你会看到默认的场景结构：一个Canvas节点，下面挂着一个Camera。这个Canvas就是微信小游戏最终的渲染画布，所有游戏内容都画在这上面。
接下来要做一件很重要的事：设置设计分辨率。在项目设置里找到“项目数据”，把设计分辨率设为750 x 1334，适配模式选“Fit Height”。这个分辨率是移动端游戏的黄金比例，适配大多数手机屏幕。为什么选Fit Height而不是Fit Width？因为微信小游戏的屏幕比例千奇百怪，从16:9到20:9都有。Fit Height保证游戏内容在垂直方向完整显示，水平方向多出来的部分用背景填充或者留黑边，这样不会出现关键内容被裁切的情况。
2.3 微信小游戏构建配置详解
在Cocos Creator的构建发布面板里，选择“微信小游戏”平台。这里有几个参数需要特别注意：
| 参数名 | 推荐值 | 说明 |
|---|---|---|
| 设备方向 | Portrait | 竖屏游戏选Portrait，横屏选Landscape |
| 渲染后端 | WebGL | 微信小游戏支持WebGL和WebGL2，选WebGL兼容性更好 |
| 首屏加载 | 开启 | 减少用户等待时间，但会增加包体 |
| 分包加载 | 按需 | 主包控制在4MB以内，超出部分放分包 |
| 资源压缩 | 开启 | 自动压缩图片和音频，减小包体 |
构建完成后，Cocos Creator会生成一个build/wechatgame目录，里面包含game.json、project.config.json和game.js等文件。game.json是微信小游戏的配置文件，定义了屏幕方向、网络超时、分包信息等。你可以手动修改这个文件来调整一些引擎默认配置，比如把deviceOrientation改成landscape来强制横屏。
注意：每次在Cocos Creator里重新构建，
game.json都会被覆盖。如果你有自定义配置，建议写一个构建后脚本自动合并，或者把配置放在project.config.json里。
3. 核心玩法实现：从Canvas绘图到游戏循环
3.1 Canvas绘图基础与性能优化
微信小游戏的渲染核心是Canvas。你可以用wx.createCanvas()创建一个画布，然后获取2D上下文来绘制图形。但如果你用Cocos Creator，引擎已经帮你管理好了画布和渲染循环，你只需要关注游戏逻辑本身。
不过理解Canvas的底层原理仍然很重要，因为性能问题往往出在绘制环节。微信小游戏的Canvas有两种模式：2D模式和WebGL模式。2D模式适合简单的2D图形绘制，API简单但性能有限；WebGL模式利用GPU加速，适合复杂的图形渲染。Cocos Creator默认使用WebGL渲染，这也是我推荐的方式。
一个常见的性能陷阱是频繁的Canvas状态切换。每次调用ctx.fillStyle、ctx.strokeStyle、ctx.font都会触发状态切换，如果每帧切换几百次，性能会急剧下降。优化方法是把相同状态的绘制操作集中在一起，比如先画所有红色矩形，再画所有蓝色圆形。在Cocos Creator里，引擎的渲染合批机制会自动处理这个问题，但如果你自己写自定义渲染组件，就需要手动优化。
// 不推荐的写法：每画一个元素就切换状态 for (let i = 0; i < 100; i++) { ctx.fillStyle = i % 2 === 0 ? 'red' : 'blue'; ctx.fillRect(i * 10, 0, 8, 8); } // 推荐的写法：按状态分组绘制 ctx.fillStyle = 'red'; for (let i = 0; i < 100; i += 2) { ctx.fillRect(i * 10, 0, 8, 8); } ctx.fillStyle = 'blue'; for (let i = 1; i < 100; i += 2) { ctx.fillRect(i * 10, 0, 8, 8); }3.2 游戏循环与帧率控制
微信小游戏的游戏循环由requestAnimationFrame驱动，默认帧率是60fps。但并不是所有游戏都需要60fps——休闲游戏30fps就足够了，还能省电。Cocos Creator里可以通过game.frameRate来设置目标帧率。
游戏循环的核心逻辑是：每帧更新游戏状态，然后重新渲染。更新包括处理输入、移动物体、检测碰撞、更新动画；渲染就是把当前状态画出来。这里有一个关键原则：逻辑更新和渲染分离。逻辑更新应该基于时间增量（deltaTime），而不是固定步长，这样在不同帧率的设备上游戏速度才一致。
// Cocos Creator组件中的update方法 update(deltaTime) { // deltaTime是上一帧到这一帧的时间间隔，单位秒 // 移动速度是每秒100像素 this.node.position.x += 100 * deltaTime; // 不要这样写：每帧固定移动2像素 // this.node.position.x += 2; // 在30fps设备上速度会减半 }3.3 触摸输入与手势识别
微信小游戏的触摸事件通过wx.onTouchStart、wx.onTouchMove、wx.onTouchEnd来监听。Cocos Creator把这些事件封装成了节点上的TOUCH_START、TOUCH_MOVE、TOUCH_END事件，你只需要在节点上注册回调即可。
手势识别是休闲游戏的常见需求，比如滑动、拖拽、点击、长按。微信小游戏没有内置的手势识别库，需要自己实现。我的做法是记录触摸开始的位置和时间，在触摸结束时计算位移和时长，根据阈值判断手势类型。
// 手势识别示例 let touchStartPos = null; let touchStartTime = 0; node.on(Node.EventType.TOUCH_START, (event) => { touchStartPos = event.getLocation(); touchStartTime = Date.now(); }); node.on(Node.EventType.TOUCH_END, (event) => { if (!touchStartPos) return; const touchEndPos = event.getLocation(); const dx = touchEndPos.x - touchStartPos.x; const dy = touchEndPos.y - touchStartPos.y; const distance = Math.sqrt(dx * dx + dy * dy); const duration = Date.now() - touchStartTime; if (distance < 10 && duration < 300) { console.log('点击'); } else if (distance > 50 && duration < 500) { // 判断滑动方向 if (Math.abs(dx) > Math.abs(dy)) { console.log(dx > 0 ? '右滑' : '左滑'); } else { console.log(dy > 0 ? '下滑' : '上滑'); } } touchStartPos = null; });注意：微信小游戏的触摸坐标原点在左上角，而Cocos Creator的坐标原点在左下角。如果你直接用
event.getLocation()获取坐标，需要做一次Y轴翻转才能和Cocos的节点坐标对应。Cocos Creator的event.getUILocation()已经帮你处理好了这个转换，建议用这个。
4. 微信API深度集成：社交、广告与数据存储
4.1 微信登录与用户信息获取
微信小游戏的登录流程和普通小程序类似，但更简洁。调用wx.login()获取临时code，传给后端换取openid和session_key。如果你不需要后端，也可以直接用wx.getUserInfo()获取用户昵称和头像，但注意这个接口需要用户授权。
// 微信登录 wx.login({ success: (res) => { if (res.code) { // 将code发送到后端换取openid console.log('登录code:', res.code); } } }); // 获取用户信息（需要用户点击授权按钮触发） wx.getUserInfo({ success: (res) => { console.log('用户昵称:', res.userInfo.nickName); console.log('用户头像:', res.userInfo.avatarUrl); } });这里有一个重要的变化：微信在2022年之后收紧了用户信息获取权限，wx.getUserInfo不再返回真实昵称和头像，而是返回“微信用户”和默认头像。如果你需要用户真实信息，必须使用wx.getUserProfile，并且只能在用户主动点击按钮时调用。
4.2 激励视频广告接入实战
激励视频广告是休闲游戏最主要的变现方式。玩家看完一段15-30秒的视频广告，获得游戏内奖励（比如复活、金币、道具）。微信小游戏的激励视频广告接入非常简单：
// 创建激励视频广告实例 let videoAd = null; if (wx.createRewardedVideoAd) { videoAd = wx.createRewardedVideoAd({ adUnitId: '你的广告位ID' }); videoAd.onLoad(() => { console.log('广告加载成功'); }); videoAd.onError((err) => { console.error('广告加载失败', err); }); videoAd.onClose((res) => { if (res && res.isEnded) { // 用户完整观看了广告，发放奖励 console.log('发放奖励'); } else { // 用户中途关闭了广告，不发放奖励 console.log('未完整观看'); } }); } // 在需要展示广告的地方调用 function showRewardAd() { if (videoAd) { videoAd.show().catch(() => { // 失败后重新加载再展示 videoAd.load().then(() => videoAd.show()); }); } }实操心得：广告位ID需要在微信公众平台的小游戏后台创建。新游戏刚上线时广告填充率可能不高，建议在广告加载失败时给用户一个提示，而不是直接卡死。另外，激励视频广告的
onClose回调中，res.isEnded为true才表示用户完整观看了广告，不要用res.isEnded === undefined来判断，不同版本的微信基础库行为可能不一致。
4.3 本地数据存储与排行榜实现
微信小游戏提供了wx.setStorageSync和wx.getStorageSync来读写本地存储，容量上限是10MB。对于休闲游戏来说，存一些游戏进度、最高分、设置项完全够用。
// 存储数据 wx.setStorageSync('highScore', 1000); // 读取数据 const highScore = wx.getStorageSync('highScore') || 0; // 删除数据 wx.removeStorageSync('highScore');排行榜是提升留存的重要手段。微信小游戏提供了开放数据域来实现好友排行榜，但实现起来比较复杂，需要单独创建一个开放数据域项目，通过wx.getOpenDataContext()来通信。如果你不想折腾开放数据域，也可以自己用后端实现一个简单的排行榜，把分数存在服务器上，客户端拉取显示。
// 开放数据域通信示例（主域） const openDataContext = wx.getOpenDataContext(); openDataContext.postMessage({ type: 'updateScore', score: 1000 }); // 开放数据域中接收消息 wx.onMessage((data) => { if (data.type === 'updateScore') { // 更新排行榜显示 } });5. 性能调优与真机调试：让游戏跑得更流畅
5.1 包体优化：从10MB压到4MB的实战记录
微信小游戏的主包体积限制是4MB，总包体积限制是20MB（含分包）。我第一版构建出来主包有8MB多，远超限制。经过一系列优化，最终压到了3.2MB。以下是我用到的优化手段：
| 优化项 | 优化前 | 优化后 | 节省 |
|---|---|---|---|
| 图片压缩 | PNG原图 | TinyPNG压缩+WebP | 约2MB |
| 音频压缩 | WAV格式 | MP3 64kbps | 约1.5MB |
| 引擎裁剪 | 完整引擎 | 只保留2D模块 | 约800KB |
| 代码压缩 | 未压缩 | 构建时开启压缩 | 约500KB |
| 资源分包 | 全部在主包 | 非首屏资源放分包 | 约1MB |
图片压缩是最有效的优化手段。我所有的PNG图片都用TinyPNG过了一遍，平均压缩率在60%以上。对于不需要透明通道的图片，直接转成JPG，体积能再小一半。音频文件用Audacity重新导出为64kbps的MP3，音质损失几乎听不出来，但体积只有WAV的十分之一。
Cocos Creator的引擎裁剪功能也很关键。在项目设置里，你可以勾选需要保留的模块。对于一个纯2D休闲游戏，3D模块、物理模块、粒子模块都可以裁掉，引擎体积能从1.5MB降到700KB左右。
5.2 渲染性能调优：DrawCall从200降到30
DrawCall是衡量渲染性能的核心指标。每一次DrawCall意味着CPU向GPU发送一次绘制指令，DrawCall越高，CPU负担越重。微信小游戏在低端安卓机上的DrawCall承受能力大约在100-150之间，超过这个数就会明显掉帧。
我第一版游戏的DrawCall在200左右，在iPhone上跑60fps没问题，但在一些千元安卓机上只有30fps。优化后降到了30左右，所有设备都能稳定60fps。核心优化手段是合批——把使用相同材质和纹理的渲染对象合并成一个DrawCall。
在Cocos Creator里，合批是自动进行的，但有几个前提条件：节点必须使用相同的材质，纹理必须在同一张图集里，渲染顺序必须连续。我做了三件事：第一，把所有UI元素打包到一张图集里；第二，确保同一图集内的节点在层级管理器中连续排列；第三，避免在渲染过程中动态修改材质。
// 不推荐的写法：动态修改材质会导致合批中断 this.node.getComponent(Sprite).getMaterial(0).setProperty('color', new Color(255, 0, 0)); // 推荐的写法：使用顶点颜色或自定义材质变体 this.node.getComponent(Sprite).color = new Color(255, 0, 0);5.3 真机调试与常见问题排查
微信开发者工具的模拟器只能作为参考，真正的性能表现必须在真机上测试。微信开发者工具提供了“真机调试”功能，扫码后可以在手机上实时查看日志和性能面板。
我遇到过的几个典型问题：
问题一：iOS上音频播放延迟。iOS的音频上下文需要用户交互后才能激活，如果在游戏启动时自动播放背景音乐，iOS上会静默失败。解决方法是在用户第一次触摸屏幕时初始化音频上下文。
问题二：安卓上触摸事件丢失。部分安卓机型在快速滑动时，touchmove事件会丢失，导致拖拽操作不流畅。解决方法是在touchstart时记录初始位置，在touchend时根据最终位置计算位移，而不是依赖touchmove的中间事件。
问题三：微信开发者工具正常，真机白屏。这通常是资源加载路径问题。微信小游戏的资源路径是相对于项目根目录的，而Cocos Creator构建后的资源路径可能带有assets/前缀。检查game.json中的subpackages配置和资源引用路径是否正确。
排查技巧：在真机上打开调试模式（微信中点击右上角菜单→开发调试），可以看到console日志和网络请求。如果白屏，先看有没有报错，再看资源加载是否成功。
6. 发布上线与运营迭代：从0到1的完整闭环
6.1 提审流程与常见驳回原因
微信小游戏的提审流程和小程序类似，在微信公众平台提交代码包，填写版本信息和测试账号，等待审核。审核周期通常是1-3个工作日。我提交了三次才通过，前两次被驳回的原因分别是：类目选择错误和缺少隐私政策。
类目选择很重要。微信小游戏有专门的游戏类目，需要提供游戏版号或备案号。如果你没有版号，可以选择“休闲游戏”类目，但功能会受到一些限制（比如不能内购）。隐私政策是必须的，即使你的游戏不收集任何用户信息，也需要在后台配置隐私政策链接。
6.2 数据埋点与留存分析
游戏上线后，你需要知道玩家在哪里流失、哪些关卡难度过高、广告展示次数是否合理。微信小游戏提供了wx.reportAnalytics接口来自定义埋点：
// 上报关卡开始 wx.reportAnalytics('level_start', { level: 5, timestamp: Date.now() }); // 上报关卡完成 wx.reportAnalytics('level_complete', { level: 5, duration: 45000, score: 1200 });这些数据会在微信公众平台的数据分析页面展示。我重点关注三个指标：次日留存、关卡通过率、广告观看率。次日留存低于20%说明游戏吸引力不够；关卡通过率低于30%说明难度过高；广告观看率低于10%说明广告触发点设计不合理。
6.3 版本迭代与用户反馈处理
小游戏的迭代节奏很快，我基本保持每周一个小版本。迭代的依据主要来自三个方面：数据埋点、用户评论、自己试玩。用户评论在微信小游戏后台可以看到，虽然数量不多，但每一条都值得认真对待。
我遇到过一个典型问题：很多用户反馈“第三关太难”。我看了数据，第三关的通过率只有15%，远低于其他关卡。于是我调整了第三关的敌人数量和移动速度，通过率提升到了45%，次日留存也跟着涨了5个百分点。
实操心得：不要一次性改太多东西。每次迭代只改一个核心问题，然后观察数据变化。如果同时改了难度、UI和广告频率，你根本不知道是哪个改动导致了数据变化。
7. 一人工作室的效率工具与工作流
7.1 我的开发环境与工具链清单
一个人做游戏，效率就是生命。我花了大概一周时间搭建了一套顺手的工具链，后面开发效率至少提升了一倍。核心工具包括：
- 代码编辑器：VS Code + Cocos Creator的TypeScript插件，支持代码提示和跳转
- 版本管理：Git + GitHub私有仓库，每天提交一次，防止代码丢失
- 美术资源：Figma画UI，Aseprite画像素图，TinyPNG压缩
- 音频处理：Audacity剪辑和压缩，Bfxr生成音效
- 项目管理：Notion看板，记录待办、Bug和灵感
7.2 时间管理与精力分配
一个人做游戏，最大的敌人不是技术难题，而是精力分散。我给自己定了一个规矩：上午写代码，下午做美术和音效，晚上测试和调优。上午精力最充沛，适合处理复杂的逻辑问题；下午容易犯困，做美术这种不需要深度思考的工作；晚上安静，适合测试和调优。
另外，我每周会留出半天时间专门处理“杂事”——回复用户评论、看数据报表、更新开发日志。这些事不直接产生代码，但对游戏的长期运营很重要。
7.3 持续学习与社区资源
微信小游戏的生态在快速变化，微信基础库每隔几个月就会更新，Cocos Creator也在持续迭代。我保持学习的渠道主要有三个：微信开放社区（看官方公告和开发者问答）、Cocos Creator官方论坛（看教程和插件）、GitHub（看开源小游戏项目）。
我特别推荐看微信开放社区的“小游戏”板块，里面有很多开发者分享的踩坑经验和性能优化技巧。有些问题你搜一下就能找到答案，比自己去试错快得多。
8. 常见问题速查与避坑指南
8.1 开发阶段高频问题
| 问题现象 | 可能原因 | 解决方法 |
|---|---|---|
| 模拟器正常，真机白屏 | 资源路径错误 | 检查game.json中的资源路径，确保没有绝对路径 |
| 触摸事件无响应 | 节点未设置触摸区域 | 给节点添加UITransform组件，设置contentSize |
| 音频播放失败 | iOS未激活音频上下文 | 在用户第一次触摸时调用wx.createInnerAudioContext |
| 帧率不稳定 | DrawCall过高 | 合批优化，减少材质切换 |
| 包体超限 | 资源未压缩 | 图片转WebP，音频转MP3，开启引擎裁剪 |
8.2 上线后的运营问题
广告不展示怎么办？新游戏上线初期，广告填充率可能很低。建议在广告加载失败时给用户一个提示，比如“广告暂时不可用，请稍后再试”，而不是直接卡死。另外，广告位ID需要在微信公众平台创建，审核通过后才能使用。
用户反馈游戏卡顿怎么办？先让用户提供机型和微信版本，然后在相同机型上复现。如果确实是性能问题，优先优化DrawCall和内存占用。微信小游戏提供了性能面板，可以在真机上实时查看帧率、内存和DrawCall。
如何提升分享率？微信小游戏的分享接口是wx.shareAppMessage，可以自定义分享标题和图片。我的经验是，分享文案要具体、有吸引力，比如“我在XX游戏里得了1000分，你能超过我吗？”比“快来玩XX游戏”的点击率高3倍以上。
8.3 我的独家避坑清单
- 不要用
document和window：微信小游戏没有DOM和BOM，所有浏览器API都不可用。用wx.createCanvas()代替document.createElement('canvas')。 - 不要依赖
localStorage：用wx.setStorageSync和wx.getStorageSync代替。 - 不要在主包放太多资源：主包超过4MB就无法提交，非首屏资源一定要放分包。
- 不要在
update里做耗时操作：比如资源加载、网络请求，这些应该放在异步回调里。 - 不要忽略低端机测试：你的开发机可能是iPhone 15，但你的用户可能用着三年前的千元安卓机。至少找一台低端机测试。
9. 从技术到产品：一人工作室的思考
9.1 技术不是壁垒，产品思维才是
做小游戏最大的感悟是：技术实现只是第一步，真正决定游戏成败的是产品思维。我见过很多技术很强的开发者，做出来的游戏画面精美、性能优秀，但就是不好玩。原因很简单——他们从技术角度出发，而不是从玩家角度出发。
玩家不关心你用了什么引擎、DrawCall是多少、包体多大。玩家只关心一件事：这个游戏好不好玩。所以我在开发过程中，会花大量时间试玩自己的游戏，站在玩家角度思考：这个操作爽不爽？这个关卡有没有挑战性？这个奖励有没有吸引力？
9.2 小步快跑，快速验证
一人工作室最大的优势是决策快、执行快。我可以在一天内完成“想法→原型→测试→迭代”的完整循环。这种速度是大团队无法比拟的。我的做法是：任何新玩法先做一个最简原型，自己试玩10分钟，如果觉得有意思就继续做，如果觉得无聊就果断放弃。
不要在一个想法上死磕。我最初想做一款塔防游戏，做了两周后发现玩法太复杂，一个人根本做不完。果断转向休闲点击类游戏，两周就做出了可玩版本。有时候放弃比坚持更需要勇气。
9.3 持续运营比一次性开发更重要
游戏上线只是开始，不是结束。我见过太多开发者，游戏上线后就不管了，然后抱怨没有用户。微信小游戏有自然流量，但自然流量只占一小部分，大部分用户来自分享和广告。你需要持续运营：更新关卡、优化体验、回复评论、分析数据。
我的游戏上线三个月，更新了12个版本，每次更新都会带来一波留存回升。运营的秘诀就是：让玩家感觉到游戏在持续变好。哪怕只是修了一个小Bug，玩家也会觉得开发者是用心的。
最后分享一个我踩过的坑：不要一开始就追求完美。我的第一版游戏有很多粗糙的地方，但我还是上线了。因为只有上线了，你才能拿到真实数据，才知道玩家真正在意什么。完美主义是独立开发者的最大敌人。先完成，再完美。
