微信小游戏这个赛道我从2023年底开始认真投入到现在差不多一年半的时间踩过的坑比写过的代码还多。今天想聊的这个项目是我一个人从零到上线跑通的一款休闲小游戏整个开发周期大概六周用的是Cocos Creator TypeScript这套组合。之所以想把这套东西写出来是因为我发现网上关于微信小游戏开发的资料要么是官方文档那种告诉你API怎么调的说明书要么是培训机构那种三天学会月入十万的营销文真正讲一个人怎么从想法到上线、中间遇到什么坑、怎么取舍的内容少得可怜。这篇文章适合三类人看第一类是有一定前端基础想试试小游戏这个方向的独立开发者第二类是做Web开发想拓展技能栈对Canvas渲染和游戏循环感兴趣的同学第三类是已经在做小游戏但卡在某个环节想看看别人是怎么处理类似问题的。我会把整个项目的技术选型逻辑、核心模块实现、性能优化手段、以及上线后遇到的实际问题都摊开来讲不藏私也不吹牛。1. 为什么一个人做小游戏要选Cocos Creator而不是Phaser1.1 引擎选型背后的真实考量先说结论如果你是一个人做微信小游戏且目标是快速上线验证想法Cocos Creator是当前最稳妥的选择。但这个结论不是拍脑袋来的我当初在Phaser和Cocos Creator之间纠结了整整一周。Phaser是一个纯JavaScript的2D游戏框架轻量、灵活、社区活跃如果你做过Web前端上手Phaser几乎没有门槛。我一开始就是用Phaser写了个原型一个简单的点击消除玩法大概两百行代码就跑起来了。但问题出在微信小游戏的适配环节——Phaser本身不是为小游戏环境设计的你需要自己处理Canvas的适配、触摸事件的映射、资源加载的路径问题。这些在浏览器里跑没问题但到了微信小游戏的真机环境各种奇怪的兼容性问题就冒出来了。Cocos Creator则不一样它从设计之初就把小游戏平台作为一等公民来对待。你可以在编辑器里直接选择微信小游戏作为构建目标一键打包生成的包体结构、资源引用路径、API调用都是按照小游戏规范来的。更重要的是Cocos Creator提供了一套完整的UI系统、动画系统、物理系统、粒子系统这些东西如果你用Phaser要么自己写要么找第三方库要么妥协。我最终选择Cocos Creator的核心原因有三个第一构建流程自动化程度高省去了大量手动适配的工作第二TypeScript支持是原生的不是后加的类型提示和编译检查在开发过程中帮我省了很多调试时间第三社区里关于微信小游戏的问题Cocos Creator的解决方案最多遇到问题搜索成本低。当然Cocos Creator也不是没有缺点。它的编辑器比较重启动慢有时候改一行代码要等好几秒才能看到效果。而且它的API设计有时候比较绕比如节点系统、组件系统、资源管理系统初学者容易晕。但这些问题在项目规模变大之后反而变成了优势——因为它的结构化设计让代码更容易维护。1.2 TypeScript在小游戏开发中的实际收益很多人觉得TypeScript是大项目才需要的东西小游戏这种小体量项目用JavaScript就够了。我一开始也这么想但实际用下来TypeScript在小游戏开发中的收益比我想象的大得多。最直接的收益是类型检查。小游戏开发中经常要处理各种异步操作比如资源加载、网络请求、动画回调。这些操作的回调参数类型如果不明确很容易出现传了个undefined进去运行时才报错的情况。TypeScript的编译期检查能提前发现这类问题省去了大量真机调试的时间。第二个收益是代码提示。Cocos Creator的API数量不少光cc.Node就有几十个方法和属性。用JavaScript写的时候你得频繁查文档用TypeScript写的时候IDE会自动提示可用的方法和参数类型开发效率提升很明显。第三个收益是重构安全性。小游戏开发过程中需求变更是常态。今天觉得这个按钮应该放在左边明天觉得应该放在右边今天觉得这个数值应该是整数明天觉得应该支持小数。每次变更都涉及多个文件的修改TypeScript的类型系统能帮你快速定位所有需要修改的地方避免遗漏。不过TypeScript也不是没有代价。编译时间是一个问题特别是项目大了之后每次修改都要等编译完成才能看到效果。我的做法是在开发阶段用Cocos Creator的内置编译它做了增量编译优化大部分情况下等待时间可以接受。另外TypeScript的严格模式有时候会让人觉得太啰嗦比如处理null和undefined的时候需要写很多额外的判断。但这些都是值得的因为它们在编译期帮你排除了大量潜在的运行时错误。1.3 微信小游戏包体限制对技术选型的倒逼微信小游戏有一个硬性限制主包不能超过4MB总包不能超过20MB。这个限制对技术选型的影响非常大很多在Web上理所当然的做法在小游戏里行不通。比如图片资源你不能像Web那样随便用高清大图。一张1080p的PNG图片可能就占了几百KB几张图下来包体就爆了。我的做法是能用矢量图的地方用矢量图能用九宫格的地方用九宫格必须用位图的地方用压缩工具压到极限。Cocos Creator支持自动图集打包把多张小图合并成一张大图减少DrawCall的同时也减少了文件数量。音频资源也是一个大坑。微信小游戏对音频格式的支持有限而且音频文件通常比较大。我的做法是背景音乐用低码率的MP3音效用短小的WAV或者OGG而且尽量复用。比如按钮点击音效整个游戏就用同一个文件不要每个按钮都单独做一个。代码包体方面Cocos Creator的引擎本身就有一定体积但可以通过引擎裁剪功能去掉不用的模块。比如你的游戏不用物理系统就可以把物理模块裁掉不用3D功能就可以把3D模块裁掉。我实测下来裁剪后的引擎体积可以控制在1MB以内给业务代码留出了足够的空间。2. 从零搭建项目骨架时最容易忽略的五个细节2.1 目录结构设计决定后期维护成本我见过很多小游戏项目的目录结构是这样的所有脚本放在一个scripts文件夹里所有图片放在一个textures文件夹里所有场景放在一个scenes文件夹里。项目小的时候没问题但一旦超过二十个脚本、五十张图片找东西就变成了噩梦。我的做法是按功能模块划分目录。比如assets/ scripts/ core/ # 核心框架代码如事件管理、状态机、对象池 gameplay/ # 玩法相关代码如玩家控制、敌人AI、碰撞检测 ui/ # UI相关代码如弹窗管理、按钮组件、进度条 utils/ # 工具类如数学计算、时间格式化、存储封装 config/ # 配置数据如关卡配置、数值配置、本地化文本 textures/ common/ # 通用图片如按钮、图标、背景 gameplay/ # 玩法相关图片如角色、道具、特效 ui/ # UI相关图片如弹窗背景、边框 prefabs/ # 预制体按功能模块分 scenes/ # 场景文件 sounds/ # 音频文件这样划分的好处是当你需要修改某个功能时相关文件都在同一个目录下不需要在多个文件夹之间跳来跳去。而且当项目需要多人协作时每个人负责的模块边界清晰减少代码冲突。还有一个细节给文件和文件夹命名时尽量用英文且保持一致的命名风格。我见过用拼音的、用中文的、用英文但大小写混用的后期维护起来非常痛苦。我的习惯是文件夹用小写加下划线脚本文件用大驼峰资源文件用小写加下划线。2.2 场景切换与资源释放的时机把握微信小游戏的内存限制比浏览器严格得多如果不注意资源释放很容易出现玩了几关之后闪退的问题。Cocos Creator提供了自动释放资源的机制但默认是不开启的需要你在场景切换时手动调用。我的做法是每个场景在onDestroy生命周期里主动释放该场景独有的资源。比如游戏场景里的角色图片、特效图片在切换到主菜单场景时就应该释放掉。但要注意有些资源是多个场景共用的比如通用按钮图片、背景音乐这些不能释放否则下次进入游戏场景时又要重新加载。具体实现上我封装了一个ResourceManager类维护一个引用计数表。每次加载资源时引用计数加一每次释放资源时引用计数减一只有当引用计数为零时才真正调用cc.resources.release释放资源。这样可以避免释放了还在用的资源或者该释放的资源没释放这两种极端情况。还有一个容易忽略的点定时器和事件监听的清理。如果你在场景A里注册了一个定时器切换到场景B时没有取消这个定时器会继续运行不仅浪费性能还可能访问已经销毁的节点导致报错。我的习惯是所有定时器和事件监听都在onEnable里注册在onDisable里取消确保生命周期匹配。2.3 微信小游戏分包加载的配置陷阱微信小游戏支持分包加载主包只放必要的启动资源其他资源放在分包里按需加载。这个机制可以突破主包4MB的限制但配置起来有不少坑。第一个坑是分包路径的配置。在Cocos Creator的构建面板里你需要指定哪些文件夹属于哪个分包。如果配置错了构建出来的包体结构不对小游戏启动时会报找不到资源的错误。我的建议是先在本地用微信开发者工具打开构建产物确认包体结构正确再上传到微信后台。第二个坑是分包加载的时机。分包加载是异步的你不能在加载完成的回调之外访问分包里的资源。我的做法是在游戏启动时先加载主包资源显示一个加载界面然后异步加载分包资源加载完成后进入主菜单。这样用户看到的是一个连续的加载过程不会觉得卡顿。第三个坑是分包大小的限制。每个分包不能超过4MB总包不能超过20MB。如果你的某个分包超过了4MB构建时会报错。我的做法是把大资源进一步拆分比如把角色图片按角色拆分成多个分包用到哪个角色就加载哪个分包。2.4 触摸事件与Canvas坐标系的映射关系微信小游戏的触摸事件返回的是屏幕坐标而Cocos Creator的节点使用的是世界坐标。这两个坐标系之间的映射关系如果不处理好会出现点击位置和实际响应位置不一致的问题。Cocos Creator提供了cc.Camera的screenToWorld方法可以把屏幕坐标转换成世界坐标。但要注意如果你的游戏使用了多相机或者相机有缩放、旋转这个转换会更复杂。我的做法是在游戏初始化时获取主相机的引用然后在触摸事件回调里统一做坐标转换。还有一个细节微信小游戏的触摸事件有touchstart、touchmove、touchend、touchcancel四种类型。其中touchcancel在用户手指滑出屏幕或者被系统打断时触发如果不处理可能会出现按钮一直处于按下状态的问题。我的做法是在touchcancel里执行和touchend一样的逻辑确保状态正确重置。2.5 本地存储的容量限制与数据安全微信小游戏的本地存储有10MB的限制而且不同小游戏之间的存储是隔离的。这个容量对于大多数游戏来说够用但如果你要存储大量用户数据比如关卡进度、成就记录、统计数据就需要精打细算。我的做法是只存储必要的数据且尽量压缩。比如关卡进度不需要存储每一关的详细数据只需要存储已解锁到第几关和每关的最高分。成就记录可以用位运算压缩一个32位整数可以表示32个成就的解锁状态。统计数据可以定期上报到服务器本地只保留最近几天的数据。数据安全方面微信小游戏的本地存储是明文的用户可以通过开发者工具查看和修改。如果你的游戏有排行榜或者内购关键数据一定要在服务器端校验不能信任本地存储。我的做法是本地存储只用于单机玩法的进度保存涉及排行榜的数据全部走服务器。3. 核心玩法模块的实现与性能取舍3.1 游戏主循环的设计与帧率控制Cocos Creator的游戏主循环是基于requestAnimationFrame的默认帧率是60帧。但对于休闲小游戏来说60帧并不是必须的30帧完全可以接受而且能省电、省性能。我的做法是在游戏设置里提供一个帧率模式选项默认是30帧用户可以选择60帧。实现上通过cc.game.setFrameRate来控制。但要注意帧率降低后动画的流畅度会下降需要调整动画的时长和缓动曲线来补偿。主循环的逻辑我分成了三个部分输入处理、逻辑更新、渲染更新。输入处理在每帧开始时执行收集用户的触摸事件逻辑更新在固定时间间隔执行比如每33毫秒执行一次保证物理模拟的稳定性渲染更新在每帧结束时执行把最新的状态绘制到屏幕上。这种分离设计的好处是即使帧率波动逻辑更新的频率也是稳定的不会出现帧率低的时候游戏速度变慢的问题。还有一个细节当游戏进入后台时微信小游戏会暂停主循环。如果你的游戏有基于时间的逻辑比如倒计时、自动恢复体力需要在onShow回调里重新计算时间差而不是简单地继续计时。我的做法是记录游戏进入后台时的时间戳在onShow时计算时间差然后根据时间差更新游戏状态。3.2 对象池在频繁创建销毁场景中的应用休闲小游戏里经常有大量重复创建和销毁的对象比如子弹、金币、特效。如果每次都new一个节点然后destroy会产生大量的内存分配和垃圾回收导致帧率波动。对象池的思路是预先创建一批对象放在池子里需要的时候从池子里取不需要的时候放回池子而不是销毁。Cocos Creator提供了cc.NodePool类但我建议自己封装一个更通用的对象池因为cc.NodePool只支持节点不支持其他类型的对象。我的对象池实现大概是这样class ObjectPoolT { private pool: T[] []; private createFn: () T; private resetFn: (obj: T) void; constructor(createFn: () T, resetFn: (obj: T) void, initialSize: number 10) { this.createFn createFn; this.resetFn resetFn; for (let i 0; i initialSize; i) { this.pool.push(createFn()); } } get(): T { if (this.pool.length 0) { return this.pool.pop()!; } return this.createFn(); } put(obj: T): void { this.resetFn(obj); this.pool.push(obj); } }使用对象池时要注意放回池子之前一定要重置对象的状态比如位置、旋转、缩放、透明度、是否可见。否则下次取出来的时候对象还带着上次的状态会出现各种奇怪的问题。还有一个经验对象池的大小要合理设置。太小了频繁创建新对象失去池化的意义太大了浪费内存。我的做法是根据游戏的实际需求统计峰值时同时存在的对象数量然后设置池子大小为峰值的1.2倍左右。3.3 Canvas绘图在自定义渲染中的使用边界虽然Cocos Creator提供了丰富的渲染组件但有些效果还是需要直接用Canvas API来绘制比如动态生成的图形、复杂的遮罩、特殊的混合模式。在Cocos Creator里使用Canvas API需要通过cc.Graphics组件。它封装了常用的绘图命令比如moveTo、lineTo、arc、fill、stroke。但cc.Graphics的性能不如直接用原生Canvas因为每次绘制都会生成新的顶点数据。我的经验是静态的图形用cc.Graphics绘制一次就够了不需要每帧重绘动态的图形比如跟随鼠标的轨迹如果每帧重绘性能开销会比较大。这时候可以考虑用RenderTexture把绘制结果缓存到一张纹理上然后每帧只更新变化的部分。还有一个坑cc.Graphics的坐标系和节点的坐标系可能不一致。如果你在节点上设置了缩放或旋转绘制出来的图形也会跟着变换。我的做法是把cc.Graphics组件挂在一个独立的节点上这个节点不做任何变换确保绘制坐标和世界坐标一致。3.4 碰撞检测的精度与性能平衡休闲小游戏的碰撞检测通常不需要太高的精度用矩形碰撞或者圆形碰撞就够了。Cocos Creator提供了cc.BoxCollider和cc.CircleCollider但它们是物理系统的一部分如果你不用物理系统用它们会引入不必要的开销。我的做法是自己实现简单的碰撞检测。矩形碰撞就是判断两个矩形的x、y、width、height是否重叠圆形碰撞就是判断两个圆心的距离是否小于半径之和。这些计算非常简单性能开销可以忽略不计。如果需要更精确的碰撞检测比如不规则形状可以用多边形碰撞。但多边形的碰撞检测算法比较复杂性能开销也大。我的建议是先用简单的形状做粗略检测如果粗略检测通过再做精确检测。这样可以过滤掉大部分不可能碰撞的对象减少精确检测的次数。还有一个细节碰撞检测的频率不需要和帧率一致。对于大多数休闲游戏来说每两帧或者每三帧检测一次就够了。这样可以进一步减少性能开销而且玩家几乎察觉不到差异。4. 上线前后那些文档里不会写的事4.1 微信开发者工具的真机调试技巧微信开发者工具提供了模拟器但模拟器和真机的表现差异很大。比如触摸事件的响应速度、音频的播放延迟、渲染的性能表现这些在模拟器上都看不出来。所以真机调试是必须的。真机调试的流程是在微信开发者工具里点击预览生成一个二维码用手机微信扫描二维码就可以在手机上运行小游戏。但要注意预览版本和正式版本的环境不同有些API在预览版本里可用在正式版本里可能受限。我的调试技巧是在代码里加一个调试面板显示当前的帧率、内存占用、DrawCall数量。这些数据在真机运行时可以实时查看帮助定位性能问题。调试面板只在开发版本里显示正式版本里隐藏。还有一个技巧用微信开发者工具的性能监控功能可以查看CPU占用、内存占用、网络请求等数据。但这些数据是采样统计的不够精确。如果需要精确的数据可以在代码里手动打点记录关键操作的耗时。4.2 小游戏审核被拒的常见原因与应对微信小游戏的审核比小程序严格因为游戏涉及的内容更多。我遇到过几次审核被拒总结下来主要有几个原因第一个是内容不完整。审核人员打开游戏后如果发现某个功能不能用或者某个页面是空白的就会拒审。我的做法是提交审核前自己完整地玩一遍确保所有功能都能正常使用。第二个是诱导分享。微信不允许游戏强制用户分享才能继续玩也不允许用奖励诱导用户分享。我的做法是分享功能做成可选的不分享也能正常玩分享后给一点小奖励但不影响游戏平衡。第三个是版权问题。如果你用了别人的图片、音乐、字体没有授权会被拒审。我的做法是所有资源都用自己制作的或者用CC0协议的开源资源。字体用系统默认的避免版权问题。第四个是类目选择错误。微信小游戏有不同的类目比如休闲益智、动作射击、角色扮演等。类目选错了审核人员会认为你的游戏内容和类目不匹配。我的做法是仔细阅读微信的类目说明选择最匹配的类目。4.3 上线后的数据监控与版本迭代节奏小游戏上线后你需要知道玩家在干什么、在哪里卡住了、为什么流失了。微信小游戏提供了基础的数据统计比如日活跃用户、留存率、平均使用时长。但这些数据不够细你需要自己埋点。我的埋点策略是记录关键行为比如开始游戏、完成关卡、失败、分享、观看广告。每个行为记录时间戳、关卡编号、玩家等级等上下文信息。这些数据上传到服务器后可以分析出玩家的行为路径找出流失点。版本迭代的节奏也很重要。我的经验是上线后的第一周每天看数据快速修复明显的bug第二周到第四周每周发一个版本优化体验、调整数值一个月后根据数据决定是继续迭代还是放弃。还有一个细节微信小游戏的版本更新是灰度发布的你可以选择先让一部分用户看到新版本观察数据后再全量发布。这个机制可以降低更新风险避免新版本引入的问题影响所有用户。4.4 一个人维护小游戏的精力分配建议一个人做小游戏最大的挑战不是技术而是精力分配。你既要写代码又要做美术还要做运营还要处理审核和客服。如果什么都想做最后什么都做不好。我的建议是把精力集中在核心玩法上其他方面能省则省。美术可以用简单的几何图形加配色不需要精美的插画音效可以用免费的开源资源不需要原创运营可以先不做等游戏有了基础用户再说。具体的时间分配上我的做法是开发阶段70%的时间用于核心玩法20%用于UI和体验10%用于其他上线后30%的时间用于数据分析30%用于bug修复40%用于新内容开发。还有一个重要的原则不要追求完美。小游戏的生命周期通常很短快速上线、快速验证、快速迭代比精雕细琢更重要。我见过很多开发者花了好几个月做一个完美的游戏上线后发现没人玩所有的努力都白费了。5. 从Web前端转小游戏开发需要补哪些课5.1 游戏循环与事件驱动模型的思维转换Web前端开发是事件驱动的你写一个按钮的点击回调用户点击时触发不点击就不执行。游戏开发也是事件驱动的但多了一个游戏循环的概念。游戏循环每帧执行一次不管有没有用户输入都要更新游戏状态、渲染画面。这个思维转换对Web前端来说是一个挑战。你需要习惯每帧都在跑的代码模式而不是等事件触发才跑。比如角色的移动在Web里可能是点击按钮角色移动一次在游戏里是每帧检查角色是否有移动指令如果有就更新位置。还有一个区别是状态管理。Web前端的状态通常是离散的比如登录状态、购物车状态游戏的状态是连续的比如角色的位置、速度、血量这些值每帧都在变化。你需要设计一套状态管理机制确保状态的一致性和可预测性。5.2 资源加载与内存管理的重新认识Web前端对内存管理的要求不高浏览器会自动回收不再使用的内存。但小游戏环境对内存的限制严格得多你需要主动管理内存否则很容易出现闪退。资源加载方面Web前端通常是一次性加载所有资源或者按路由懒加载。小游戏需要更细粒度的控制因为包体有限制内存也有限制。我的做法是把资源分成必须加载和按需加载两类必须加载的在启动时加载按需加载的在用到时才加载用完就释放。内存管理方面Web前端通常不需要关心对象的销毁。小游戏需要关心因为垃圾回收会导致帧率波动。我的做法是频繁创建销毁的对象用对象池不频繁的对象正常创建销毁大对象用完立即释放。5.3 性能分析工具的使用与指标解读Web前端有Chrome DevTools可以分析性能、内存、网络。小游戏也有类似的工具但功能没那么强大。微信开发者工具提供了性能监控面板可以查看帧率、CPU占用、内存占用、DrawCall数量。解读这些指标需要一些经验。帧率低于30帧玩家会感觉到卡顿CPU占用持续高于80%说明逻辑计算太重内存占用持续增长说明有内存泄漏DrawCall数量高于100说明渲染批次太多需要合并。我的做法是在开发阶段就关注这些指标不要等到上线后才优化。每次添加新功能后都跑一下性能分析确保没有明显的性能退化。如果发现性能问题用二分法定位先注释掉一半的代码看性能是否恢复如果恢复了说明问题在被注释的代码里如果没有恢复说明问题在另一半代码里。重复这个过程直到找到问题代码。5.4 从Canvas绘图到游戏渲染的认知升级Web前端用Canvas绘图通常是我要画一个圆就调用arc然后fill。游戏渲染比这复杂得多因为游戏里有大量的对象每个对象都有自己的位置、旋转、缩放、透明度、混合模式。如果每个对象都单独绘制性能会非常差。游戏渲染的核心是批处理和合批。把使用相同材质、相同纹理的对象合并成一个批次一次性提交给GPU渲染。Cocos Creator的自动合批机制可以处理大部分情况但你需要了解它的工作原理才能写出高性能的代码。比如如果你频繁地切换纹理合批就会被打断DrawCall数量会增加。我的做法是把使用相同纹理的对象放在相邻的渲染层级减少纹理切换。另外尽量使用图集把多张小图合并成一张大图这样即使对象不同只要它们来自同一张图集就可以合批。还有一个概念是渲染层级。Cocos Creator的节点树决定了渲染顺序但你可以通过设置节点的zIndex或者使用不同的相机来调整渲染层级。合理的渲染层级设计可以减少Overdraw提升渲染性能。6. 一个人做小游戏这件事到底值不值得6.1 投入产出比的真实计算先说钱。一个小游戏从开发到上线如果算上时间成本投入是很大的。我这个小游戏开发六周按我平时的时薪算人力成本大概在两万左右。上线后的服务器费用、认证费用、推广费用加起来又是几千。总收入呢目前广告分成加上内购一个月大概几百到一千回本周期很长。但如果你不把时间成本算进去只算现金投入那其实不多。Cocos Creator是免费的微信小游戏的认证费用是300元服务器可以用云开发免费额度够用。所以如果你有技术愿意投入时间现金门槛其实很低。我的看法是不要把做小游戏当成赚钱的手段把它当成学习的机会和作品的积累。你在这个过程中学到的技术、积累的经验、做出的作品这些价值远超过金钱上的回报。6.2 技术成长与作品积累的双重收益从技术角度做小游戏让我学到了很多Web前端学不到的东西。比如游戏循环的设计、对象池的实现、碰撞检测的算法、渲染性能的优化。这些知识不仅适用于游戏开发也适用于其他需要高性能渲染的场景比如数据可视化、动画效果。从作品角度一个小游戏上线后你可以把它写进简历可以在面试时展示可以分享给朋友玩。这比一个只存在于本地的小demo有说服力得多。而且小游戏是一个完整的作品涉及需求分析、技术选型、开发实现、测试上线、数据分析这些经验对职业发展很有帮助。6.3 给想入坑的朋友几条实在建议第一条先做一个小而完整的东西不要一上来就想做大作。一个简单的点击消除、一个跑酷、一个答题都可以。重要的是把整个流程跑通从开发到上线到运营体验一遍。第二条技术选型不要纠结太久。Cocos Creator和Phaser都能用选一个就开始做。纠结的时间足够你写出一个原型了。第三条美术和音效不要追求完美。用简单的几何图形加配色用免费的开源音效先把玩法跑通。等玩法验证了再考虑美化。第四条上线后不要盯着数据焦虑。小游戏的数据波动很大今天一百个用户明天可能就十个。重要的是从数据里找问题而不是被数据影响情绪。第五条保持学习的心态。小游戏这个领域变化很快新的引擎、新的平台、新的玩法层出不穷。保持学习保持尝试才能跟上节奏。最后再分享一个小技巧如果你在开发过程中遇到了问题先去Cocos Creator的官方论坛搜一搜再去GitHub上看看有没有类似的项目。大部分问题别人都遇到过而且有现成的解决方案。不要自己闷头造轮子浪费时间。