微信小游戏的消息一拨接一拨但我真正被“小龙虾”这三个字击中是在深夜的朋友圈里看到一个朋友发来的链接点进去居然是养虾、炒虾、卖虾的小游戏。我玩了十分钟不仅没放下还顺手把链接转给了三个群。标题里那句“终于微信上也能玩小龙虾了”不是我说的是评论区一个玩家留下的原话后来这句话成了我们项目复盘时反复提起的注脚。这段经历说来其实挺平淡我们是个三人小团队花了一个月时间从零做了一款以小龙虾为主题的微信小游戏《虾池物语》上线四周累计超过七万玩家次留最好做到过35%。这个成绩谈不上爆款但作为一个没有买量、没有发行资源的原生小游戏项目足够让我认真回顾一遍我们踩过的坑和做对的事。本文不打算讲宏大叙事只讲实际操作怎么立项、怎么设计数值、怎么接微信生态、怎么控制包体和渲染、上线之后数据怎么调以及现在回头看最值得提醒新人的几个问题。1. 立项第一问“小龙虾”在微信里到底是什么玩法1.1 为什么偏偏是“小龙虾”而不是别的题材微信小游戏赛道里“鱼”“虾”“蟹”这类题材并不少见但大多数人在立项时会本能地避开“小龙虾”理由无外乎太土、太餐饮、很难做出游戏性。我们的判断恰恰相反。小龙虾在微信场景里有三张天然王牌第一大众辨识度极高不需要任何教育成本第二它的视觉特征极其鲜明红壳、长须、大钳子天然适合做卡通化美术第三小龙虾自带“夜市、夏天、啤酒、朋友”的场景联想这种联想很容易转化成社交话题。我当时做了一个简单的题材对比表把六个备选方向放在一起看候选题材大众认知度操作动作空间内容扩展性初期结论小龙虾极高抓、夹、炒、剥、卖图鉴、变异、皮肤、订单可做螃蟹高横走、夹品类少扩展一般偏弱皮皮虾中低弹射玩法偏猎奇偏弱生蚝中开壳动作单一不合适鱼极高钓、养、卖品类多但是红海竞争太激烈这个对比的价值不在于证明小龙虾有多好而在于把“感觉”变成“可判断的维度”。我们后来还加了一条“社交分享时能不能一眼看懂”小龙虾这个题材的分享卡片放上红油辣椒和大钳子朋友不用点开就知道是什么这在微信体系里很重要。1.2 头脑风暴之后我们砍掉的四个方向立项讨论时我们列了十几个玩法最后被砍掉的方向有四个经营龙虾餐厅、玩家对战捕虾、纯养成模拟器、龙虾主题拼图。很多人可能会觉得奇怪经营餐厅不是挺合适的吗但问题出在研发量餐厅经营需要完整的柜台、座位、菜谱、服务员AI我们三个人一个月根本做不完而且微信小游戏玩家对经营类产品的预期已经被拉得很高。对战捕虾需要实时同步开发成本和技术风险都大一个弱网环境下就会体验崩塌。纯养成模拟器虽然开发快但缺少“完成感”玩家养完一只虾之后没有下一步动作留存铁定起不来。拼图就更不用说了做完之后你会发现它在玩法上和小龙虾这个题材没有任何绑定关系换任何动物都能实现。最终我们保留的是“养虾、炒虾、卖虾”的轻量三合一。这个“三合一”不是三套系统硬拼在一起而是把收集、加工、消耗串成一根链条进入游戏领养一只基础虾等它成熟收获放进锅里炒熟变成订单交出去换金币金币再用来解锁新虾种和装饰物。链条越短玩家越容易理解链条末端是图鉴收集这又提供了长线动力。1.3 目标用户和核心钩子是怎么定下来的当时团队里争论过目标用户有人说做给年轻人有人说做给大爷大妈。最后我们用了一个很土的办法看微信里分享小龙虾表情包的是谁。统计下来大部分是二十多岁到三十出头的用户他们喜欢在群里约夜宵也喜欢发“虾红了”之类的梗图。这类用户玩微信小游戏的时间高度碎片化一次完整的游戏会话可能只有两三分钟但一天会打开三四次。于是核心钩子被定为“收集”而不是“升级”。所有数值设计都围着“图鉴缺了一只”转。我们设计的第一条玩家动线是这样的看到群里有人发分享卡片卡片上显眼地写着“你有X种虾没收集到”点进来直接领养一只基础青壳虾喂两下食料虾在几分钟内变红成熟收获后自动进入烹饪环节十秒钟后做出第一份麻辣虾球完成一个订单这时候图鉴角落里亮起一个“变异金虾”剪影提示还差两次捕捞概率就能遇到——大部分玩家会在这一步产生“再回来看看”的念头。这条动线是我们在纸上画了很多版才定下来的核心原则是第一次打开游戏的三分钟内必须完成一整个“付出—等待—收获—展示”的循环并且见到一个可期待的长期目标。2. 玩法主循环喂虾、收虾、炒虾、卖虾的数值怎么转起来2.1 把“等待”做成主循环而不是把“操作”做成主循环微信小游戏的玩家很少愿意一次性投入十分钟做连续操作他们更习惯“点一下等一会回来看一眼”。所以我们把主循环设计成“等待驱动型”养虾需要时间烹饪需要时间订单刷新需要时间玩家的每次回访都有明确的理由。具体数值是这样设计的基础青壳虾从投入虾池到成熟需要3分钟这是为了让玩家第一次体验时不会等太久黄金虾需要10分钟变异虾则是随机出现成熟时间在5到8分钟之间波动。烹饪环节固定10秒订单栏每5分钟刷新一次同时最多挂三个订单。玩家平均单次在线时长设计目标是2到3分钟但每天回访次数希望做到3到5次。这个设计的本质是在和用户的手机使用习惯做朋友每次回访都是一次“收菜”收菜本身就带来正向反馈顺手再播种下一轮然后心满意足地退出去等下一次提醒。我们内部管这个叫“刷存在感式玩法”。2.2 一张数值表如何决定玩家的情绪曲线数值表是整个项目最枯燥也最重要的部分。我们定了一版基础虾种的产出表一开始特别忌讳数值膨胀所以控制得很保守虾种成熟时长单个售价稀有度解锁条件青壳虾3分钟6金币普通初始稻田虾5分钟11金币普通累计10单黄金虾10分钟27金币稀有累计30单变异火虾随机5-8分钟40金币极稀有图鉴进度30%寒江冰虾15分钟65金币传说图鉴进度60%围绕这张表我们定了两条铁律第一单次会话内必须至少有一次正反馈也就是玩家每次进来哪怕只收一只普通虾也能看到一个明确的收入数字跳动第二想要回访就需要制造“刚刚好快成熟”的紧迫感所以我们会把最贵的那只虾的成熟时间控制在一个小时后玩家打开微信时刚好到期。数值调整的一个实际例子是内测时订单价格只给了售价的80%玩家攒钱速度极慢很多人做到第三单就没耐心了。后来我们改成首单溢价、后期回归常规前五分钟的体验立刻顺畅起来。2.3 为什么最强的“爽点”放在烹饪而不是养虾养虾的过程再有趣本质上都是“等待”等待不能带来击打感。但我们发现烹饪环节可以实现多重的即时反馈火焰在锅底窜起、翻炒时虾壳变色、出锅瞬间弹出一串香味粒子、金币增加的音效和震动几乎同步。玩家在这一步获得的是“我加工了东西”的完成感而不是“我等到了一个结果”。具体实现上烹饪动画用了很轻的方案火焰是有限数量的精灵粒子数量上限控制在24个翻炒动作是锅体位移动画配合约15度的旋转虾壳变色则是简单地切换三张预渲染序列帧。这套方案在低端安卓机上也能稳定跑60帧代价是没法做真实的物理流体效果但小游戏玩家并不需要这个他们需要的是“够快的爽”。后续内测也证明了烹饪环节的价值我们把烹饪时间从10秒改成5秒后订单完成率没有明显变化但把烹饪动画做得更华丽之后分享率提升了大约1.5个百分点。这让我意识到在微信这种轻量环境里“视觉完成感”有时候比“流程速度”更重要。2.4 内测时的一次数据事故玩家一个小时就流失了第一次内测我们只找了三十个测试用户结果第一次跑数据就发现了问题——用户升级太快快到毫无目标感。有人一小时就解锁了前二十个图鉴位然后告诉我们“没东西可玩了”。当时的等级曲线按连续在线时长设计每在线一分钟就给大量经验完全忽略了微信小游戏本来就是“间歇性打开”的产品。我们花了一整晚调整曲线方案很粗暴把前五个等级需要的经验值整体上调约3倍同时把变异虾的初始出现概率从2%提到8%。改完后重新测玩家从“一小时通关”变成“两天还在收集”流失拐点从第8级推迟到第14级。内测用户的反馈也从“没得玩”变成了“还差四个虾种得再看看”。这个教训后来写进了团队的开发备忘数值曲线永远要匹配玩家的真实使用频次而不是设计师想象里的“每天玩一小时”。3. 微信生态机制怎么接分享助力、订阅提醒、排行榜的取舍3.1 分享模块我们做了“值得分享”没做“强制分享”很多人做小游戏第一反应是加各种强制分享按钮领奖励必须分享不分享就不给玩。我们项目正好相反从头到尾没有做过一个强制分享。原因是两个一是微信对诱导分享的审核越来越严格强诱导极易被判违规二是即使侥幸上线强制分享带来的用户关系链破坏会让产品很快被拉黑。我们真正做的分享设计有三个。第一个是分享卡片内容定制卡片上除了游戏图标会显示当前玩家“图鉴已完成X/30”的进度以及一句“帮工坊点一下我就能解锁下一只稀有虾了”的请求文案。第二个是双向奖励发出分享的人和点进来帮工坊的好友都能获得一份小奖励前者是5金币后者是一份“见面虾苗”。第三个不是所有人都能发现的细节分享按钮的位置放在“图鉴页面”而不是“主界面”因为玩家在浏览图鉴时最容易产生“我比别人缺什么”的遗憾感这时候分享动力最强。这三招加起来我们的分享转化率大概做到了9%左右放在小游戏里不算高但胜在可持续没有为后续运营埋雷。3.2 订阅消息用“虾成熟了”换回访微信小游戏的订阅消息是回访利器但也很容易惹人烦。我们只申请了一类模板——“虾已经成熟可以收获了”触发场景是玩家种下一只虾之后主动点击“成熟提醒我”。这里有个关键限制订阅消息的“一次性授权”机制意味着用户每授权一次你只能发一条想持续触发就得每次都用不同的理由让用户再点一次授权。我们的处理方式是把授权按钮放在一个让人很难拒绝的位置当玩家同时养了三只虾且都接近成熟时页面会弹出一条“今晚九点前回来收就能解锁本日订单加成”的提示下面的按钮就是订阅授权。这个位置结合了利益点提示用户点击授权的意愿明显更高回访率比没消息提醒时提高了大约20%。当然也有翻车的时候。前期我们试过在用户授权后发送“你的虾池空了很久回来看看吧”这类无实质内容的提醒结果三天内订阅消息的打开率降到40%之后我们再也不发这种空泛文案了所有提醒必须包含具体收益。3.3 排行榜做不做我们只做了“收集度”弱排行和很多人想象的不同排行榜不总是提升留存的手段做得不好甚至会杀死一批不愿意被比较的玩家。我们最终只做了一个“好友虾种收集度”榜排行的唯一依据是图鉴数量不做等级榜、金币榜、战力榜。这样取舍的原因很简单玩家在微信小游戏里的挫败感往往不来自“玩得不够好”而来自“比别人落后”强排行会放大这种落差。收集度排行则不同它是“我也快齐了”的进度对比天然带有展示欲玩家看到好友比自己多一只虾第一反应往往是“我再回去养一只”而不是“我不玩了”。技术上说好友排行榜必须使用微信小游戏的开放数据域开放数据域里有独立的绘制环境不能和主域共享大部分接口。当时我们踩过一个坑想用主域Canvas画排行榜结果完全没有数据权限后来才发现必须在开放数据域内把排名绘制到共享画布上再通过主域去展示。这个机制不复杂但确实需要提前设计而不是等做到排行榜再改架构。3.4 聊天和群的关系链远比朋友圈更重要微信生态里“分享到聊天/群”和“分享到朋友圈”是两种不同强度的社交动作。朋友圈是公开表演聊天群是定向互动。我们的数据表明绝大部分分享来自聊天和群比例大概是84%对16%。所以开发时我们没有在朋友圈分享上投入太多精力而是把主要接口放在“转发给好友/群”上配合的文案也更像“帮个忙”而不是“快来看我多厉害”。后来我们还做了一个小功能在玩家确认完成订单后偶尔会弹出一个“把今晚的虾锅分享到群里的朋友能免费品尝一只”的卡片这个设计利用了“请客”的心理点击率明显高于普通分享按钮。这类轻互动机制比硬广有效得多也是我们后期迭代中最不后悔的一个决定。4. 包体、渲染与性能30天从原型到能上线的技术取舍4.1 为什么选了原生JavaScript而不是游戏引擎立项时我们讨论过要不要用Cocos Creator或Unity最后还是选了原生JavaScript小游戏适配层加上自研的极简动画系统。不是因为引擎不好而是因为三个现实约束团队里没人有成熟的Cocos经验Unity跨端包体动辄几兆对微信小游戏来说太重距计划上线只有30天我们没有时间去填引擎的坑。自研引擎听起来高大上其实我们只实现了三件事一个管理场景节点的树一个按帧执行的动画组件和一个简单的纹理图集加载器。这样的好处是代码完全可控出了问题能直接定位到源码坏处是需要自己处理的东西比用引擎多比如内存管理不当就可能出现Canvas上下文溢出的情况。如果你问我个人建议做休闲小游戏不必迷信引擎重要的是看团队已有的技术栈。如果团队都是Web前端出身直接用原生小游戏加轻量库往往比从零学引擎更快。我们后来在性能优化上省下的时间恰恰就是因为没有多余的框架层在中间捣乱。4.2 包体控制实战主包从3.2MB压到1.4MB微信小游戏主包有体积限制虽然可以通过分包加载扩展但用户体验上主包越小加载越快首启成功率越高。我们上线前专门做了一轮“资源瘦身”前后花了两天时间把主包从3.2MB压缩到了1.4MB。具体手段按性价比排序如下美术资源全部转成WebP格式这一步直接让图片总体从2.1MB降到0.9MB音频方面只保留了几个短循环音效总时长控制在30秒内其余所有音乐全部砍掉代码层面开启tree shaking把没用到的依赖函数能删尽删最后一个笨办法是每次构建后用脚本扫描产物找出超过5KB的未引用资源逐个确认后移除。值得一提的教训是压缩图片时不要无脑把所有图都压到极致烹饪环节和稀有虾展示界面需要清晰度我们保留了两张512×512的高清虾图放在分包里只在对应界面远程加载。这种“分层资源策略”比一刀切更适合小游戏。4.3 让小龙虾“动”起来但别让手机“烧”起来小龙虾题材的动画重点是大钳子、长须和烹饪时的火焰。我们用序列帧动画而不是骨骼动画原因是骨骼动画需要额外的动画库并且调试成本高。每只虾的动画控制在10帧以内每帧128×128像素全部放在一张雪碧图里用Canvas绘制时通过图集裁剪实现。更关键的是对象池。游戏里虾池同时存在的虾实体最多60只如果每只都创建独立DOM或Canvas对象低端机一定会卡所以我们把所有虾实体放进一个对象池产出、回收时只复用节点不重新创建。初期没有对象池时真机测试在iPhone 7上掉帧明显加完之后稳定在60帧。烹饪火焰的粒子效果更是重灾区。第一版我们写了一个300粒子的火焰系统结果在国产中低端安卓机上直接花屏。后来把粒子上限压到24个火焰改为两层预渲染动画叠加效果反而更干净性能也稳了。这再次说明小游戏的渲染必须顶着一个原则能预渲染绝不实时计算。4.4 真机调试里两个让人失眠的Bug第一个是iOS上的音频播放问题。安卓正常播放的背景音效在iOS上经常出现首次触摸屏幕后才有声音的情况原因是iOS网络音频上下文默认需要用户交互才能激活。解决方法是把音频初始化放到用户的第一次触摸事件回调里再触发play问题立刻消失。第二个Bug是低端安卓设备上Canvas随机花屏。查了很久发现是多个Canvas之间频繁切换绘制上下文造成的我们在一次渲染循环中切换了超过十次drawImage的source导致一些设备的显存读取异常。最终修复方式是合并绘制批次同一帧内先按图层排序能合成的全部合到一张离屏Canvas上再统一上屏。这个Bug没有完全根治但我们给低端机加了一个“画质开关”检测到设备帧率低于30时自动关闭动态光影之后再没有收到花屏投诉。5. 上线四周的数据复盘留存、转化、口碑里真实发生的变化5.1 没有买量的冷启动是怎么跑起来的我们没有推广预算第一波用户全来自微信群。上线首周我把游戏转发到七个无关的游戏交流群团队另外两人转发了约二十个行业群配合几个朋友自发的朋友圈晒图前三天积累了两千多用户。第四天一个美食领域的小公众号写了篇关于“微信里可以亲手做小龙虾”的短文当晚新增直接翻了四倍。首周数据大致是新增约1.2万当日次留35%次周七日留存11%平均在线时长2分40秒。这个数据在小游戏里不算顶级但足够支撑我们继续迭代。复盘时我们发现最大的流量入口不是我们熟人转发而是那些体验完烹饪动画后主动把锅沿截图发到社交平台的用户——他们才是真正的免费渠道。5.2 分享率从2%到9%改动只有一句文案项目刚上线那几天分享按钮文案是“分享给好友得50金币”分享率只有2%。我一度以为是小龙虾题材不行直到有一次看到玩家在群里说“能给金币的分享有什么好点的”才意识到奖励设置错了金币是消耗品用完就没了不会激起分享欲只有展示性的东西才值得被分享。我们当天把奖励改成“分享后解锁限定虾图鉴缘缘虾”并配合一个“还差多少次分享解锁”的进度条。结果分享率一路从2%爬到了9%左右新增用户里通过分享进入的比例从11%涨到42%。这次改动让我彻底明白一个道理微信小游戏的分享奖励应该给“身份凭证”而不是给“游戏资源”。5.3 用户骂得最狠的三个点以及我们的处理方式上线第二周评论区开始出现集中吐槽我们统计下来主要集中在三个点第一广告频率太高。原版设计是玩家每完成一次烹饪就弹一次激励视频广告换取双倍金币。用户普遍觉得“做一盘虾看一次广告”太烦。我们改成每三次操作才弹一次并在广告按钮旁边增加“跳过”入口广告点击率虽然下降了一个点但七日留存提升了四个点总体利大于弊。第二订单等待时间太长。基础订单刷新需要5分钟但玩家反馈等一盘虾要很久我们手动把订单刷新下限从5分钟调到了3分钟体感好很多。这里有个代价是金币产出变多于是同步下调了单笔订单的收益保证总产出平衡。第三变异虾概率太“玄学”。原本变异虾出现概率是8%但玩家感知完全随机有人一天出三只有人三天一只不出。后来我们把概率说明写进了帮助文档并加了一个“累计养虾30只必出变异”的保底机制。这个改动让负面评论数量大幅下降因为玩家至少知道自己在为什么而努力。5.4 一个反直觉的AB测试结果奖励减半留存反而提升上线第三周我们做了一次AB实验把每日登录奖励从100金币减到50金币同时把需要消耗金币解锁的装饰价格下调20%。本该是“福利变差”但结果显示实验组七日留存比对照组高了5个百分点。后来看用户行为才明白奖励过重时玩家每天打开游戏领完奖励就走根本没有进入“养虾—收虾—做虾—卖虾”的玩法循环奖励成了签到工具自然留不住。奖励减半后玩家为了攒钱买装饰反而会一天回来两三次收虾玩法和变现都更健康。这个实验结果对我们震动很大它提醒我们一个朴素的道理免费奖励不是越多越好关键是奖励能不能把玩家推进玩法反馈的循环里。后来我们所有活动奖励设计都会先问一句这个奖励是在鼓励玩家“玩”还是在鼓励玩家“领”。6. 现在回头看最想提醒新人的三个小坑6.1 最小可玩原型真的只需要一张桌子和一口锅我们的项目总耗时30天但其中有14天花在写系统设计文档和数值模拟表上真正做出第一个可玩原型只用了3天。如果让我重来我一定会在立项48小时内先做出一个“能点十下还想继续点”的原型哪怕是只有一只虾、一口锅、一个订单按钮的毛坯版本。原型的作用不是验证美术和数值而是验证一个最核心的问题玩家会不会因为“再等一分钟就能收虾”而在第二天回来。这个问题只要有了原型就能得到答案而停留在文档里则永远得不到答案。6.2 微信审核比想象中更细分享文案里的一个字都可能被卡我们第一次提审被驳回原因是一条分享引导语里出现了“必得”两个字——平台认为这属于诱导分享。我们改成“有机会获得”后顺利通过。那以后团队立了一条规矩所有对外文案都会做一次“诱导词自查”涉及奖品描述时一律用模糊性措辞。微信小游戏的审核不只是功能测试还包括隐私政策是否完整、用户数据收集是否透明、虚拟支付是否符合规范、青少年保护有没有设置特别是涉及用户头像昵称获取的权限声明很多小游戏都会在这个环节被打回。建议开发者在提审前把“用户隐私保护指引”从头到尾读一遍不要想当然。6.3 数据埋点一定要在写功能之前做别等上线了再后悔上线第一周我们其实做了十一个埋点覆盖了访问、点击、订单、分享等关键路径但当我们想分析“从分享卡片点击到进入游戏完成首单”的转化漏斗时发现少埋了“从分享页跳转成功”这一步导致整个漏斗断了一环只能等下一个版本再补。后来我们养成一个习惯每次设计一个新功能先画出用户在这个功能里的操作路径然后在这条路径的每一个关键节点写清楚“要记录什么参数、在哪个时机上报”。这个习惯的起点就是这次“漏斗断链”的事故。对所有做小游戏的朋友我的建议是埋点这事宁可多埋不可少埋多埋的数据可以不用少埋的数据永远补不回来。如果现在让我重新做一遍《虾池物语》我会把前两周的精力全部押在数据采集体系和最小原型上而不是一开始就追求功能大而全。微信小游戏的成功密码其实不复杂一个让人愿意等的东西一个让人愿意秀的东西和一个让人愿意再回来的理由只要这三件事成立哪怕题材只是小龙虾也能在微信里玩出一片天。 
长河君 · 2026/10/24 6:00:43 · 阅读 1.2k 微信小游戏独立开发复盘：以《虾池物语》为例谈留存与包体优化
微信小游戏的消息一拨接一拨但我真正被“小龙虾”这三个字击中是在深夜的朋友圈里看到一个朋友发来的链接点进去居然是养虾、炒虾、卖虾的小游戏。我玩了十分钟不仅没放下还顺手把链接转给了三个群。标题里那句“终于微信上也能玩小龙虾了”不是我说的是评论区一个玩家留下的原话后来这句话成了我们项目复盘时反复提起的注脚。这段经历说来其实挺平淡我们是个三人小团队花了一个月时间从零做了一款以小龙虾为主题的微信小游戏《虾池物语》上线四周累计超过七万玩家次留最好做到过35%。这个成绩谈不上爆款但作为一个没有买量、没有发行资源的原生小游戏项目足够让我认真回顾一遍我们踩过的坑和做对的事。本文不打算讲宏大叙事只讲实际操作怎么立项、怎么设计数值、怎么接微信生态、怎么控制包体和渲染、上线之后数据怎么调以及现在回头看最值得提醒新人的几个问题。1. 立项第一问“小龙虾”在微信里到底是什么玩法1.1 为什么偏偏是“小龙虾”而不是别的题材微信小游戏赛道里“鱼”“虾”“蟹”这类题材并不少见但大多数人在立项时会本能地避开“小龙虾”理由无外乎太土、太餐饮、很难做出游戏性。我们的判断恰恰相反。小龙虾在微信场景里有三张天然王牌第一大众辨识度极高不需要任何教育成本第二它的视觉特征极其鲜明红壳、长须、大钳子天然适合做卡通化美术第三小龙虾自带“夜市、夏天、啤酒、朋友”的场景联想这种联想很容易转化成社交话题。我当时做了一个简单的题材对比表把六个备选方向放在一起看候选题材大众认知度操作动作空间内容扩展性初期结论小龙虾极高抓、夹、炒、剥、卖图鉴、变异、皮肤、订单可做螃蟹高横走、夹品类少扩展一般偏弱皮皮虾中低弹射玩法偏猎奇偏弱生蚝中开壳动作单一不合适鱼极高钓、养、卖品类多但是红海竞争太激烈这个对比的价值不在于证明小龙虾有多好而在于把“感觉”变成“可判断的维度”。我们后来还加了一条“社交分享时能不能一眼看懂”小龙虾这个题材的分享卡片放上红油辣椒和大钳子朋友不用点开就知道是什么这在微信体系里很重要。1.2 头脑风暴之后我们砍掉的四个方向立项讨论时我们列了十几个玩法最后被砍掉的方向有四个经营龙虾餐厅、玩家对战捕虾、纯养成模拟器、龙虾主题拼图。很多人可能会觉得奇怪经营餐厅不是挺合适的吗但问题出在研发量餐厅经营需要完整的柜台、座位、菜谱、服务员AI我们三个人一个月根本做不完而且微信小游戏玩家对经营类产品的预期已经被拉得很高。对战捕虾需要实时同步开发成本和技术风险都大一个弱网环境下就会体验崩塌。纯养成模拟器虽然开发快但缺少“完成感”玩家养完一只虾之后没有下一步动作留存铁定起不来。拼图就更不用说了做完之后你会发现它在玩法上和小龙虾这个题材没有任何绑定关系换任何动物都能实现。最终我们保留的是“养虾、炒虾、卖虾”的轻量三合一。这个“三合一”不是三套系统硬拼在一起而是把收集、加工、消耗串成一根链条进入游戏领养一只基础虾等它成熟收获放进锅里炒熟变成订单交出去换金币金币再用来解锁新虾种和装饰物。链条越短玩家越容易理解链条末端是图鉴收集这又提供了长线动力。1.3 目标用户和核心钩子是怎么定下来的当时团队里争论过目标用户有人说做给年轻人有人说做给大爷大妈。最后我们用了一个很土的办法看微信里分享小龙虾表情包的是谁。统计下来大部分是二十多岁到三十出头的用户他们喜欢在群里约夜宵也喜欢发“虾红了”之类的梗图。这类用户玩微信小游戏的时间高度碎片化一次完整的游戏会话可能只有两三分钟但一天会打开三四次。于是核心钩子被定为“收集”而不是“升级”。所有数值设计都围着“图鉴缺了一只”转。我们设计的第一条玩家动线是这样的看到群里有人发分享卡片卡片上显眼地写着“你有X种虾没收集到”点进来直接领养一只基础青壳虾喂两下食料虾在几分钟内变红成熟收获后自动进入烹饪环节十秒钟后做出第一份麻辣虾球完成一个订单这时候图鉴角落里亮起一个“变异金虾”剪影提示还差两次捕捞概率就能遇到——大部分玩家会在这一步产生“再回来看看”的念头。这条动线是我们在纸上画了很多版才定下来的核心原则是第一次打开游戏的三分钟内必须完成一整个“付出—等待—收获—展示”的循环并且见到一个可期待的长期目标。2. 玩法主循环喂虾、收虾、炒虾、卖虾的数值怎么转起来2.1 把“等待”做成主循环而不是把“操作”做成主循环微信小游戏的玩家很少愿意一次性投入十分钟做连续操作他们更习惯“点一下等一会回来看一眼”。所以我们把主循环设计成“等待驱动型”养虾需要时间烹饪需要时间订单刷新需要时间玩家的每次回访都有明确的理由。具体数值是这样设计的基础青壳虾从投入虾池到成熟需要3分钟这是为了让玩家第一次体验时不会等太久黄金虾需要10分钟变异虾则是随机出现成熟时间在5到8分钟之间波动。烹饪环节固定10秒订单栏每5分钟刷新一次同时最多挂三个订单。玩家平均单次在线时长设计目标是2到3分钟但每天回访次数希望做到3到5次。这个设计的本质是在和用户的手机使用习惯做朋友每次回访都是一次“收菜”收菜本身就带来正向反馈顺手再播种下一轮然后心满意足地退出去等下一次提醒。我们内部管这个叫“刷存在感式玩法”。2.2 一张数值表如何决定玩家的情绪曲线数值表是整个项目最枯燥也最重要的部分。我们定了一版基础虾种的产出表一开始特别忌讳数值膨胀所以控制得很保守虾种成熟时长单个售价稀有度解锁条件青壳虾3分钟6金币普通初始稻田虾5分钟11金币普通累计10单黄金虾10分钟27金币稀有累计30单变异火虾随机5-8分钟40金币极稀有图鉴进度30%寒江冰虾15分钟65金币传说图鉴进度60%围绕这张表我们定了两条铁律第一单次会话内必须至少有一次正反馈也就是玩家每次进来哪怕只收一只普通虾也能看到一个明确的收入数字跳动第二想要回访就需要制造“刚刚好快成熟”的紧迫感所以我们会把最贵的那只虾的成熟时间控制在一个小时后玩家打开微信时刚好到期。数值调整的一个实际例子是内测时订单价格只给了售价的80%玩家攒钱速度极慢很多人做到第三单就没耐心了。后来我们改成首单溢价、后期回归常规前五分钟的体验立刻顺畅起来。2.3 为什么最强的“爽点”放在烹饪而不是养虾养虾的过程再有趣本质上都是“等待”等待不能带来击打感。但我们发现烹饪环节可以实现多重的即时反馈火焰在锅底窜起、翻炒时虾壳变色、出锅瞬间弹出一串香味粒子、金币增加的音效和震动几乎同步。玩家在这一步获得的是“我加工了东西”的完成感而不是“我等到了一个结果”。具体实现上烹饪动画用了很轻的方案火焰是有限数量的精灵粒子数量上限控制在24个翻炒动作是锅体位移动画配合约15度的旋转虾壳变色则是简单地切换三张预渲染序列帧。这套方案在低端安卓机上也能稳定跑60帧代价是没法做真实的物理流体效果但小游戏玩家并不需要这个他们需要的是“够快的爽”。后续内测也证明了烹饪环节的价值我们把烹饪时间从10秒改成5秒后订单完成率没有明显变化但把烹饪动画做得更华丽之后分享率提升了大约1.5个百分点。这让我意识到在微信这种轻量环境里“视觉完成感”有时候比“流程速度”更重要。2.4 内测时的一次数据事故玩家一个小时就流失了第一次内测我们只找了三十个测试用户结果第一次跑数据就发现了问题——用户升级太快快到毫无目标感。有人一小时就解锁了前二十个图鉴位然后告诉我们“没东西可玩了”。当时的等级曲线按连续在线时长设计每在线一分钟就给大量经验完全忽略了微信小游戏本来就是“间歇性打开”的产品。我们花了一整晚调整曲线方案很粗暴把前五个等级需要的经验值整体上调约3倍同时把变异虾的初始出现概率从2%提到8%。改完后重新测玩家从“一小时通关”变成“两天还在收集”流失拐点从第8级推迟到第14级。内测用户的反馈也从“没得玩”变成了“还差四个虾种得再看看”。这个教训后来写进了团队的开发备忘数值曲线永远要匹配玩家的真实使用频次而不是设计师想象里的“每天玩一小时”。3. 微信生态机制怎么接分享助力、订阅提醒、排行榜的取舍3.1 分享模块我们做了“值得分享”没做“强制分享”很多人做小游戏第一反应是加各种强制分享按钮领奖励必须分享不分享就不给玩。我们项目正好相反从头到尾没有做过一个强制分享。原因是两个一是微信对诱导分享的审核越来越严格强诱导极易被判违规二是即使侥幸上线强制分享带来的用户关系链破坏会让产品很快被拉黑。我们真正做的分享设计有三个。第一个是分享卡片内容定制卡片上除了游戏图标会显示当前玩家“图鉴已完成X/30”的进度以及一句“帮工坊点一下我就能解锁下一只稀有虾了”的请求文案。第二个是双向奖励发出分享的人和点进来帮工坊的好友都能获得一份小奖励前者是5金币后者是一份“见面虾苗”。第三个不是所有人都能发现的细节分享按钮的位置放在“图鉴页面”而不是“主界面”因为玩家在浏览图鉴时最容易产生“我比别人缺什么”的遗憾感这时候分享动力最强。这三招加起来我们的分享转化率大概做到了9%左右放在小游戏里不算高但胜在可持续没有为后续运营埋雷。3.2 订阅消息用“虾成熟了”换回访微信小游戏的订阅消息是回访利器但也很容易惹人烦。我们只申请了一类模板——“虾已经成熟可以收获了”触发场景是玩家种下一只虾之后主动点击“成熟提醒我”。这里有个关键限制订阅消息的“一次性授权”机制意味着用户每授权一次你只能发一条想持续触发就得每次都用不同的理由让用户再点一次授权。我们的处理方式是把授权按钮放在一个让人很难拒绝的位置当玩家同时养了三只虾且都接近成熟时页面会弹出一条“今晚九点前回来收就能解锁本日订单加成”的提示下面的按钮就是订阅授权。这个位置结合了利益点提示用户点击授权的意愿明显更高回访率比没消息提醒时提高了大约20%。当然也有翻车的时候。前期我们试过在用户授权后发送“你的虾池空了很久回来看看吧”这类无实质内容的提醒结果三天内订阅消息的打开率降到40%之后我们再也不发这种空泛文案了所有提醒必须包含具体收益。3.3 排行榜做不做我们只做了“收集度”弱排行和很多人想象的不同排行榜不总是提升留存的手段做得不好甚至会杀死一批不愿意被比较的玩家。我们最终只做了一个“好友虾种收集度”榜排行的唯一依据是图鉴数量不做等级榜、金币榜、战力榜。这样取舍的原因很简单玩家在微信小游戏里的挫败感往往不来自“玩得不够好”而来自“比别人落后”强排行会放大这种落差。收集度排行则不同它是“我也快齐了”的进度对比天然带有展示欲玩家看到好友比自己多一只虾第一反应往往是“我再回去养一只”而不是“我不玩了”。技术上说好友排行榜必须使用微信小游戏的开放数据域开放数据域里有独立的绘制环境不能和主域共享大部分接口。当时我们踩过一个坑想用主域Canvas画排行榜结果完全没有数据权限后来才发现必须在开放数据域内把排名绘制到共享画布上再通过主域去展示。这个机制不复杂但确实需要提前设计而不是等做到排行榜再改架构。3.4 聊天和群的关系链远比朋友圈更重要微信生态里“分享到聊天/群”和“分享到朋友圈”是两种不同强度的社交动作。朋友圈是公开表演聊天群是定向互动。我们的数据表明绝大部分分享来自聊天和群比例大概是84%对16%。所以开发时我们没有在朋友圈分享上投入太多精力而是把主要接口放在“转发给好友/群”上配合的文案也更像“帮个忙”而不是“快来看我多厉害”。后来我们还做了一个小功能在玩家确认完成订单后偶尔会弹出一个“把今晚的虾锅分享到群里的朋友能免费品尝一只”的卡片这个设计利用了“请客”的心理点击率明显高于普通分享按钮。这类轻互动机制比硬广有效得多也是我们后期迭代中最不后悔的一个决定。4. 包体、渲染与性能30天从原型到能上线的技术取舍4.1 为什么选了原生JavaScript而不是游戏引擎立项时我们讨论过要不要用Cocos Creator或Unity最后还是选了原生JavaScript小游戏适配层加上自研的极简动画系统。不是因为引擎不好而是因为三个现实约束团队里没人有成熟的Cocos经验Unity跨端包体动辄几兆对微信小游戏来说太重距计划上线只有30天我们没有时间去填引擎的坑。自研引擎听起来高大上其实我们只实现了三件事一个管理场景节点的树一个按帧执行的动画组件和一个简单的纹理图集加载器。这样的好处是代码完全可控出了问题能直接定位到源码坏处是需要自己处理的东西比用引擎多比如内存管理不当就可能出现Canvas上下文溢出的情况。如果你问我个人建议做休闲小游戏不必迷信引擎重要的是看团队已有的技术栈。如果团队都是Web前端出身直接用原生小游戏加轻量库往往比从零学引擎更快。我们后来在性能优化上省下的时间恰恰就是因为没有多余的框架层在中间捣乱。4.2 包体控制实战主包从3.2MB压到1.4MB微信小游戏主包有体积限制虽然可以通过分包加载扩展但用户体验上主包越小加载越快首启成功率越高。我们上线前专门做了一轮“资源瘦身”前后花了两天时间把主包从3.2MB压缩到了1.4MB。具体手段按性价比排序如下美术资源全部转成WebP格式这一步直接让图片总体从2.1MB降到0.9MB音频方面只保留了几个短循环音效总时长控制在30秒内其余所有音乐全部砍掉代码层面开启tree shaking把没用到的依赖函数能删尽删最后一个笨办法是每次构建后用脚本扫描产物找出超过5KB的未引用资源逐个确认后移除。值得一提的教训是压缩图片时不要无脑把所有图都压到极致烹饪环节和稀有虾展示界面需要清晰度我们保留了两张512×512的高清虾图放在分包里只在对应界面远程加载。这种“分层资源策略”比一刀切更适合小游戏。4.3 让小龙虾“动”起来但别让手机“烧”起来小龙虾题材的动画重点是大钳子、长须和烹饪时的火焰。我们用序列帧动画而不是骨骼动画原因是骨骼动画需要额外的动画库并且调试成本高。每只虾的动画控制在10帧以内每帧128×128像素全部放在一张雪碧图里用Canvas绘制时通过图集裁剪实现。更关键的是对象池。游戏里虾池同时存在的虾实体最多60只如果每只都创建独立DOM或Canvas对象低端机一定会卡所以我们把所有虾实体放进一个对象池产出、回收时只复用节点不重新创建。初期没有对象池时真机测试在iPhone 7上掉帧明显加完之后稳定在60帧。烹饪火焰的粒子效果更是重灾区。第一版我们写了一个300粒子的火焰系统结果在国产中低端安卓机上直接花屏。后来把粒子上限压到24个火焰改为两层预渲染动画叠加效果反而更干净性能也稳了。这再次说明小游戏的渲染必须顶着一个原则能预渲染绝不实时计算。4.4 真机调试里两个让人失眠的Bug第一个是iOS上的音频播放问题。安卓正常播放的背景音效在iOS上经常出现首次触摸屏幕后才有声音的情况原因是iOS网络音频上下文默认需要用户交互才能激活。解决方法是把音频初始化放到用户的第一次触摸事件回调里再触发play问题立刻消失。第二个Bug是低端安卓设备上Canvas随机花屏。查了很久发现是多个Canvas之间频繁切换绘制上下文造成的我们在一次渲染循环中切换了超过十次drawImage的source导致一些设备的显存读取异常。最终修复方式是合并绘制批次同一帧内先按图层排序能合成的全部合到一张离屏Canvas上再统一上屏。这个Bug没有完全根治但我们给低端机加了一个“画质开关”检测到设备帧率低于30时自动关闭动态光影之后再没有收到花屏投诉。5. 上线四周的数据复盘留存、转化、口碑里真实发生的变化5.1 没有买量的冷启动是怎么跑起来的我们没有推广预算第一波用户全来自微信群。上线首周我把游戏转发到七个无关的游戏交流群团队另外两人转发了约二十个行业群配合几个朋友自发的朋友圈晒图前三天积累了两千多用户。第四天一个美食领域的小公众号写了篇关于“微信里可以亲手做小龙虾”的短文当晚新增直接翻了四倍。首周数据大致是新增约1.2万当日次留35%次周七日留存11%平均在线时长2分40秒。这个数据在小游戏里不算顶级但足够支撑我们继续迭代。复盘时我们发现最大的流量入口不是我们熟人转发而是那些体验完烹饪动画后主动把锅沿截图发到社交平台的用户——他们才是真正的免费渠道。5.2 分享率从2%到9%改动只有一句文案项目刚上线那几天分享按钮文案是“分享给好友得50金币”分享率只有2%。我一度以为是小龙虾题材不行直到有一次看到玩家在群里说“能给金币的分享有什么好点的”才意识到奖励设置错了金币是消耗品用完就没了不会激起分享欲只有展示性的东西才值得被分享。我们当天把奖励改成“分享后解锁限定虾图鉴缘缘虾”并配合一个“还差多少次分享解锁”的进度条。结果分享率一路从2%爬到了9%左右新增用户里通过分享进入的比例从11%涨到42%。这次改动让我彻底明白一个道理微信小游戏的分享奖励应该给“身份凭证”而不是给“游戏资源”。5.3 用户骂得最狠的三个点以及我们的处理方式上线第二周评论区开始出现集中吐槽我们统计下来主要集中在三个点第一广告频率太高。原版设计是玩家每完成一次烹饪就弹一次激励视频广告换取双倍金币。用户普遍觉得“做一盘虾看一次广告”太烦。我们改成每三次操作才弹一次并在广告按钮旁边增加“跳过”入口广告点击率虽然下降了一个点但七日留存提升了四个点总体利大于弊。第二订单等待时间太长。基础订单刷新需要5分钟但玩家反馈等一盘虾要很久我们手动把订单刷新下限从5分钟调到了3分钟体感好很多。这里有个代价是金币产出变多于是同步下调了单笔订单的收益保证总产出平衡。第三变异虾概率太“玄学”。原本变异虾出现概率是8%但玩家感知完全随机有人一天出三只有人三天一只不出。后来我们把概率说明写进了帮助文档并加了一个“累计养虾30只必出变异”的保底机制。这个改动让负面评论数量大幅下降因为玩家至少知道自己在为什么而努力。5.4 一个反直觉的AB测试结果奖励减半留存反而提升上线第三周我们做了一次AB实验把每日登录奖励从100金币减到50金币同时把需要消耗金币解锁的装饰价格下调20%。本该是“福利变差”但结果显示实验组七日留存比对照组高了5个百分点。后来看用户行为才明白奖励过重时玩家每天打开游戏领完奖励就走根本没有进入“养虾—收虾—做虾—卖虾”的玩法循环奖励成了签到工具自然留不住。奖励减半后玩家为了攒钱买装饰反而会一天回来两三次收虾玩法和变现都更健康。这个实验结果对我们震动很大它提醒我们一个朴素的道理免费奖励不是越多越好关键是奖励能不能把玩家推进玩法反馈的循环里。后来我们所有活动奖励设计都会先问一句这个奖励是在鼓励玩家“玩”还是在鼓励玩家“领”。6. 现在回头看最想提醒新人的三个小坑6.1 最小可玩原型真的只需要一张桌子和一口锅我们的项目总耗时30天但其中有14天花在写系统设计文档和数值模拟表上真正做出第一个可玩原型只用了3天。如果让我重来我一定会在立项48小时内先做出一个“能点十下还想继续点”的原型哪怕是只有一只虾、一口锅、一个订单按钮的毛坯版本。原型的作用不是验证美术和数值而是验证一个最核心的问题玩家会不会因为“再等一分钟就能收虾”而在第二天回来。这个问题只要有了原型就能得到答案而停留在文档里则永远得不到答案。6.2 微信审核比想象中更细分享文案里的一个字都可能被卡我们第一次提审被驳回原因是一条分享引导语里出现了“必得”两个字——平台认为这属于诱导分享。我们改成“有机会获得”后顺利通过。那以后团队立了一条规矩所有对外文案都会做一次“诱导词自查”涉及奖品描述时一律用模糊性措辞。微信小游戏的审核不只是功能测试还包括隐私政策是否完整、用户数据收集是否透明、虚拟支付是否符合规范、青少年保护有没有设置特别是涉及用户头像昵称获取的权限声明很多小游戏都会在这个环节被打回。建议开发者在提审前把“用户隐私保护指引”从头到尾读一遍不要想当然。6.3 数据埋点一定要在写功能之前做别等上线了再后悔上线第一周我们其实做了十一个埋点覆盖了访问、点击、订单、分享等关键路径但当我们想分析“从分享卡片点击到进入游戏完成首单”的转化漏斗时发现少埋了“从分享页跳转成功”这一步导致整个漏斗断了一环只能等下一个版本再补。后来我们养成一个习惯每次设计一个新功能先画出用户在这个功能里的操作路径然后在这条路径的每一个关键节点写清楚“要记录什么参数、在哪个时机上报”。这个习惯的起点就是这次“漏斗断链”的事故。对所有做小游戏的朋友我的建议是埋点这事宁可多埋不可少埋多埋的数据可以不用少埋的数据永远补不回来。如果现在让我重新做一遍《虾池物语》我会把前两周的精力全部押在数据采集体系和最小原型上而不是一开始就追求功能大而全。微信小游戏的成功密码其实不复杂一个让人愿意等的东西一个让人愿意秀的东西和一个让人愿意再回来的理由只要这三件事成立哪怕题材只是小龙虾也能在微信里玩出一片天。