这两年我在开发者群里被问得最多的问题差不多就是这一句我想成为 TikTok 小游戏开发者应该从哪儿开始问的人里有一半是只会写点前端脚本的零基础新人另一半则是有完整游戏项目经验但完全不熟悉短内容平台逻辑的科班出身。你会发现单纯讲“注册一个开发者账号、上传一个 HTML5 游戏”并不能解决问题因为真正的门槛并不在“写代码”那一步而在于你对这个生态的认知是不是完整。这篇文章想聊的内容是我自己从一个只会做网页小 Demo 的人到做成第一个 TikTok 小游戏提审上线的完整判断路径。不保证你看完就能立刻赚到钱但至少能让你在动手之前就想清楚一圈问题这个平台到底需要什么形态的游戏、开发者注册要过哪些环节、技术栈怎么选、提审有哪些坑以及上线之后怎么做数据迭代。全程会直接围绕 TikTok 小游戏的实际情况展开也会把我在踩坑过程中总结的那些文档里不会明说的经验放进来。1. 先把这个产品形态拆干净TikTok 小游戏到底是怎么跑的1.1 它不是一个 App也不是一个原生游戏很多人第一次听到“TikTok 小游戏”的时候脑子里的第一反应是“给手机装一个游戏 App再用 TikTok 账号登录”。这个理解是错的。TikTok 小游戏本质上是一类运行在 TikTok 客户端容器里的 HTML5 游戏用户刷视频刷到对应内容之后通过点击挂载的组件直接拉起一个游戏界面不需要跳转去应用商店也不需要额外下载安装包。这个形态和过去大家熟悉的网页游戏有点相似区别在于它被装进了一个带宿主能力约束的容器里。这个容器有明确的限制它不能直接读取用户手机里的文件不能随意拉起摄像头和通讯录也不能像原生 App 那样常驻后台。游戏的全部运行环境都建在一个浏览器内核之上你可以把它理解成“带了一层平台 API 的浏览器页面”。正因为跑在网页容器里所以小游戏天然有跨端的优势。iOS 和安卓端你不用各写一套原生的逻辑只要把游戏代码整理成一个标准的 Web 工程处理好不同机型的兼容性打包提审之后两端基本都能跑。这一点对个人开发者特别友好因为它意味着你前期的研发成本可以被压得很低一个人同时承担程序、策划和美术的工作量完全有可能做出一个完成度高的作品。1.2 三类典型开发者看看你在哪一类要不要进入这个领域我建议你先判断自己的角色因为不同角色准备的东西差别很大。第一类是个人开发者。你的优势是灵活、决策快一天能试好几个玩法原型。你的劣势是时间碎片化尤其如果还有全职工作想靠下班后的时间推进一个完整项目非常考验目标管理。我见过有的人半年过去了还在改首页 UI而有的人用四个周末就上线了一个休闲小游戏。区别不在于能力在于一开始有没有把范围控制住。第二类是有两到五个人的小团队。团队里有程序也有美术出活速度会明显快很多但沟通成本也会上升。小团队最容易犯的错是追求“大而全”比如想着加入联网对战、排行榜、道具商城最后把自己拖进泥潭。我的建议是最早两个项目都做单机玩法只把分享做进去尽可能少碰实时通信。第三类是原本就在做广告系统、Web 外包或者传统网页游戏的团队。你们转型做小游戏其实是降维打击因为核心的渲染、交互、性能优化经验都是通用的唯一要补的课是平台的宿主能力接入和审核规范。你不需要从零学游戏开发只需要把原来那套网页工程的构建方式切到平台要求的运行时上。1.3 海外侧与国内侧的同源关系先搞清楚再说市面上聊 TikTok 小游戏时很容易把海外侧的开发文档、国内同类型小游戏的开发文档混在一起。这里我先给一个结论性的判断两者底层技术方向同源但账号体系、开放能力、审核环境和分成政策并不完全一样你要在哪个市场做就去看哪一套文档不要拿 A 平台的代码示例硬套 B 平台。如果你是很早以前接触过国内短内容平台小游戏开发的会发现很多 API 思路非常熟悉比如初始化、登录态同步、分享埋点、激励视频广告这些能力都能找到对应物。因为产品底层一脉相承迁移的成本确实很低。但请一定注意海外侧的合规要求更强调用户隐私和数据边界弹窗授权策略要重新检查一遍不能把国内习惯“先拿权限再说”的做法带过去。看到这里你应该明白TikTok 小游戏是一个有明确边界的产品形态它降低了下分发门槛但也增加了平台规则对作品形态的约束。接受这套约束后面所有步骤才有意义。2. 注册和资质环节开发者账号的每一步都是埋坑重灾区2.1 先决定主体类型再决定账号注册方式成为 TikTok 小游戏开发者的第一步当然是到官方开发者平台注册一个账号。这个环节听起来很简单但你在注册之前必须想清楚一个事用个人主体注册还是用企业主体注册个人主体注册起来快实名信息填好就能开始更适合测试玩法、验证自己想法的阶段。但它也有明显缺陷部分实功能接口开放得比企业主体晚而且个人在资质审核、结算合规上能走的路相对窄。如果你一开始就预估这个游戏能产生收入并且希望走得正规一点那注册一个企业主体账号会更省事前提是你得有一个合法的企业资质。有人会问那我先用个人身份做出来等跑通了再换成企业主体行不行可以但换主体意味着原来账号关联的游戏、数据和结算关系都要重新迁移中间的成本并不小。我的建议是纯学习阶段用个人账号打算商业化之前尽早切换企业主体。2.2 创建应用时类目选择比填写名称更关键账号注册通过之后下一步要创建一个“应用”。这里说的应用不是手机 App而是你在这个开发者后台里管理小游戏项目的一个载体。你会发现创建时有一堆字段要填其中最重要的是产品类型和游戏类目。选错类目的后果是后端的审核策略完全不一样。比如同一个休闲玩法的游戏如果你把它归到“工具类”审核人员看你的角度就会变成“这是个工具为什么界面像游戏”大概率会驳回。反过来把工具内容归到游戏类也会因为核心功能缺失被卡。所以填写类目之前先去文档里看一圈当前开放了哪些类目找和你玩法最接近的那一个。有些新手会犯一个更隐蔽的错误在类目里选了“游戏”但应用名称又起得不像游戏。审核人员对不上号第一轮就驳回。起名这件事不要玩梗最好让名字直说玩法比如“方块消除大挑战”就比“天天闪亮”容易过审也能让用户一眼看懂你在玩什么。2.3 域名校验、测试白名单和开发者角色分配创建完应用之后后台会让你绑定一个域名并且完成域名归属校验。这个动作的作用是平台只允许你在自己拥有的域名下面托管游戏包资源防止盗用他人的空间地址。我记得第一次做的时候就是因为这步漏填导致构建出来的包在开发者工具里能跑但一提交就被系统提示资源不可访问。除了域名你还需要配置一个测试设备白名单。平台的逻辑是这样的你在开发阶段调试时只有白名单里的设备才能通过扫码方式拉起调试版小游戏等上线之后这个限制才会解除真实用户才能通过平台看到你的游戏。所以在你准备让团队里的策划、美术都能上手体验之前先把他们的设备统一加进白名单不然他们拿到二维码扫了也是白屏。如果你们是一个团队记得在后台把不同成员的权限分配好。至少要分管理员、开发者、运营这三种角色不要所有人共用一个账号去操作风险太大了。万一有人误操作把测试配置删了轻则影响迭代效率重则可能触发风控给账号带来不必要的麻烦。3. 技术选型怎么做三条路有各自的小九九3.1 引擎路线对比别只看渲染效果当你进入真正写代码的阶段首先要定的是技术路线。市面上的选择归纳起来就是这三类直接写原生网页脚本、使用通用游戏开发框架、使用重引擎构建导出。我给一个表格方便你对着看方案上手难度包体控制适合场景典型短板原生脚本 Canvas低极小休闲玩法、原型验证复杂物理效果难实现通用游戏框架中小到中2D 休闲、消除、跳跳类官方文档依赖社区维护重引擎导出高中到大3D、复杂渲染、跨端复用初始工程体积大、加载慢我见过很多新人一上来就选重引擎理由是“以后能做更牛的作品”。但你要知道小游戏场景里的核心指标并不是画面多惊艳而是首包加载速度。用户刷到你的视频之后如果点开游戏要等五秒才能看到界面大部分人会直接退出。所以我的经验是第一个作品尽量走更轻的路线把玩法想清楚、把反馈做顺手比追求画面高级重要得多。3.2 宿主能力接入真正让你区别于普通网页游戏的是这套 API小游戏之所以叫“小游戏”是因为它不只是能玩还能和宿主平台做互动。这个互动就是通过平台的开放能力实现的典型能力有这么几个拉起登录、读取头像昵称、发起分享、记录排行榜、播放激励视频广告、拉起支付。你得把这些能力想象成“游戏里可以调用的公共工具”。比如你做了一个跑酷游戏玩家跑到了一个新的里程碑就可以弹出一个分享按钮把成绩卡片分享到短视频内容流里。这个动作一旦被其他用户看到就形成了一个新的曝光入口等于是让玩家帮你做推广。具体怎么调用按官方文档走就行但有一个细节值得提醒登录和静默初始化要放在最前面最好在加载页就完成避免用户进入主界面后再看到登录弹窗。如果一个休闲游戏开场五分钟才要用户授权登录流失率会高到让你怀疑人生。3.3 包体、视口适配和内存占用三件容易被忽略的事技术选型结束后我建议你立刻做三件事设置好固定视口策略限制资源包体规划好内存占用。视口适配的问题尤其容易出现。TikTok 小游戏通常要在各种不同屏幕比例的机型上运行有些机型是全面屏有些还有大下巴。如果你只按一种设计分辨率做画面会出现拉伸或者黑边。最省心的做法是采用安全区适配方案把关键按钮放进安全区内背景图则做宽一点专门用来覆盖裁切区域。包体方面尽量压制到预期范围内。能放在云端加载的素材就不要全部塞进首包能用矢量图的地方就不要切高清大图。至于内存则要注意及时释放不再使用的大资源尤其是切场景时要清掉上一关的纹理引用不然几关下来内存越占越大最后在低端机上直接闪退。闪退一旦被用户反馈到平台对游戏评级的影响很直接。4. 从零做出第一款 Demo 的全过程复盘4.1 目标要小到“无聊但完整”而不是“大而完美”如果这是你的第一个小游戏我强烈建议不要以“创新”为第一目标先以“走通全流程”为目标。什么叫走通全流程就是你把一个最简单的玩法做好账号注册、代码构建、真机调试、提审、上线这一整条链路全部走一遍。整个价值不在游戏本身而在让你知道每个环节会产生什么意外。我给自己定的第一个 Demo 目标非常朴素做一个三分钟能完成一局的翻牌配对游戏一共就四组卡牌翻对了消除翻错了翻回全部消完显示用时和分享按钮。这个玩法没有任何创新的地方但它覆盖了资源加载、点击交互、计时逻辑、结果分享这四块基础能力足够把工具的坑都踩一遍。4.2 搭建工程和本地调试关键是不让它水土不服我先用通用游戏框架建了一个标准工程目录大致是这样的入口脚本负责初始化一个场景脚本管理牌组数据一个渲染脚本负责绘制卡牌一个控制脚本接收点击事件。为了后续能接支付和广告我把这些能力都拆成了独立模块保证“业务逻辑”和“宿主调用”不混在一起。本地调试的时候开发者工具可以模拟大部分环境但模拟器和真机之间始终有差异最典型的差异是屏幕比例和内存性能。我在模拟器里跑得流畅的游戏在低端测试机上出现了掉帧后来排查发现是阴影滤镜太重去掉了立竿见影。真机调试建议准备两台不同性能的安卓机和一个开发用 iPhone覆盖面足够才有安全感。4.3 构建产物、提审准备和第一次提交的状态确认Demo 功能完成后接下来就是构建产物。小游戏平台一般会要求你把代码打包成一个压缩包压缩包内部的结构得符合要求。这个过程最容易出的问题是本地资源路径用错了导致上传之后图片全部加载失败。我第一次提审时还犯了一个低级错误就是忘记把自己测试时用的一行打印日志从代码里删掉。那个日志会每秒钟往控制台输出一次虽然不影响运行但审核人员在打开游戏时很容易看到满屏日志直接影响专业印象。所以提审前的最后一步一定要做全局检索把所有调试输出、临时代码、已废弃接口全部清理干净。上线前的状态确认我还给了一张清单每次提审前都过一遍首屏加载小于 3 秒、无调试日志、无不可点击的页面残留、分享按钮真实有效、后台配置的域名可以正常访问。这五项确认完我才敢点那个提交按钮。5. 审核阶段最容易踩的坑提前替你挨个踩一遍5.1 内容规范带来的驳回往往不是因为你游戏不好玩审核阶段被驳回是最磨人的体验因为它常常不给你具体到哪一帧的反馈。我在社区里见过最典型的驳回原因是“内容与所选类目不符”和“存在诱导性话术”。你以为小游戏想怎么写引导文案都可以但实际上平台对“强制点赞、强制关注、诱导分享”这类行为是零容忍的。比如你在失败界面上写“分享给好友才能复活”这在很多平台会被判定为强制分享但如果写成“分享给好友可额外获得一个复活机会”语气上变成了鼓励分享同时给一种“可不分享”的自由感审核就会宽松很多。差之毫厘理失千里。还有一类驳回理由是素材问题。一些人直接用搜索引擎里找的网红背景图做游戏封面这种做法一旦被告发问题会很严重。正确的做法是所有图片、音频都自己制作或者使用明确支持商用的公开素材并把来源记录保存好。5.2 版本号错误、隐私弹窗和醒目组件这些暗坑要单独排审核问题里有一类特别冤的功能正常但是版本号填错了。平台对每次提交的版本号有严格要求如果你上一次提交是 1.0.0这次还填 1.0.0系统可能直接拦截或者导致测试设备上加载的缓存不是最新包。永远记得在每次提审前把构建包里的版本号、后台填写的版本号、包内信息里展示的版本号三个位置对齐。隐私弹窗也是一个高频驳回项。游戏涉及登录或者读取用户信息时必须一开始就有明确的弹窗说明而且要提供“拒绝”选项。有一个测试反馈很典型隐私弹窗里已经写了“同意”按钮却没有“不同意”按钮这就不符合最小化授权原则直接被要求整改。另外如果你在游戏里用了旋转、震动、陀螺仪这些比较突出的手机能力审核阶段一定要让测试者能明显感知到这些功能。“我明明做了震动反馈为什么审核人员没发现”因为振动只在特定关卡触发而且很轻微审核人员根本意识不到。正确做法是在前五分钟就安排一段演示流程让核心能力明显呈现。5.3 被驳回之后怎么沟通和重新提审被驳回不要急着和审核“硬刚”。先冷静分一下是哪一类驳回如果是内容问题最好直接根据反馈调整如果是误判就通过站内申诉渠道提交一段录屏和文字说明。我个人经验是证据越具体越好比如“在 XX 秒处可见完整的隐私授权弹窗用户可拒绝”然后再附上一张截图或者录屏附件效率最高。重新提审时修改说明也要认真写。尽量简单直接地列出改了什么、为什么这样改不要含糊其辞。审核问题永远是一次一次迭代出来的极少有人一次通过。重点是不要因为挫折就放弃养成把每次驳回原因整理成自己文档的习惯后面做第二个、第三个作品时会高效太多。6. 上线之后不是结束前 90 天的数据迭代才是分水岭6.1 冷启动阶段看什么数据别被表面数据骗了游戏上线并不代表事情做完了恰恰相反真正的开发周期这时候才算拉开。前 90 天你要做的不是盲目加玩法而是盯住几个核心数据把它们转成清晰的产品迭代动作。我最关注的是首日留存、三日留存和七日留存以及单人单局平均时长。首日留存看出的是“玩家点开后愿不愿意玩第二局”七日留存看的是“有没有形成重复访问的惯性”单局时长则直接反映玩法节奏一般休闲游戏单局控制在三分钟以内最舒服超过太久玩家会觉得累。有个很容易被骗的场景是次留很高但始终没有自然新增。这说明你现有的内容只在老用户圈子里流传没有通过短视频分享、推荐算法带来新用户。这时候要优先优化分享场景让每局结束后的成绩展示更夸张、更有分享欲而不是去调整玩法难度。6.2 商业化配置激励视频、插屏和付费点的平衡小游戏的收入通常来自广告和内购。广告配置不是越多越好而是要在“不破坏体验”的前提下找到平衡点。激励视频是最温和的一种广告形式玩家自己主动选择观看换来复活、双倍奖励或额外道具。这个模式适合放在关键失败节点比如“差一步就过关了看视频拿个提示”。插屏广告则要非常克制尽量只在完成一个大阶段后展示一次游戏会话内不要超过两次否则玩家烦了直接关掉游戏广告收入再高也补不回来损失。如果你的游戏里准备做付费道具更得小心。休闲小游戏的核心矛盾是“免费玩家也要玩得爽”付费点应该落在“更方便”而不是“更强”。比如让玩家省去一段时间的等待、解锁一个好看的皮肤都比直接卖数值优势更安全。6.3 三个月的成长周期两次完整迭代足够形成自己的能力闭环如果给你 90 天我建议这样安排第一个月专注上线和稳定修复第二个月根据数据做一次大版本更新最后一个月梳理沉淀。第一个月的目标不是做新玩法而是把崩溃率、闪退率、加载耗时这些基础指标打磨好。即使你只想做一个小玩法也有可能因为兼容问题丢掉大量用户。第二个月的数据更新尽量围绕一个主题发力比如“提高分享率”改完看数据有没有变化有变化就留下没变化就回滚。第三个月你要做的事情是把你这三个月里遇到的每一个问题、每一次决策判断都归档形成自己的错误清单和优化清单。如果你能做到这一步那你不只是会做游戏而是真正建立了对 TikTok 小游戏生态的判断力。以后不管平台规则怎么更新、市场风向怎么变你都有了快速调整方向的底气。这也是我和许多同行聊下来大家都认可的真相这个行业不缺做游戏的人缺的是能把一件事从零走通并持续迭代下去的人。 
长河君 · 2026/10/21 4:17:53 · 阅读 1.2k TikTok小游戏开发入门：从HTML5技术栈到提审上线的完整路径
这两年我在开发者群里被问得最多的问题差不多就是这一句我想成为 TikTok 小游戏开发者应该从哪儿开始问的人里有一半是只会写点前端脚本的零基础新人另一半则是有完整游戏项目经验但完全不熟悉短内容平台逻辑的科班出身。你会发现单纯讲“注册一个开发者账号、上传一个 HTML5 游戏”并不能解决问题因为真正的门槛并不在“写代码”那一步而在于你对这个生态的认知是不是完整。这篇文章想聊的内容是我自己从一个只会做网页小 Demo 的人到做成第一个 TikTok 小游戏提审上线的完整判断路径。不保证你看完就能立刻赚到钱但至少能让你在动手之前就想清楚一圈问题这个平台到底需要什么形态的游戏、开发者注册要过哪些环节、技术栈怎么选、提审有哪些坑以及上线之后怎么做数据迭代。全程会直接围绕 TikTok 小游戏的实际情况展开也会把我在踩坑过程中总结的那些文档里不会明说的经验放进来。1. 先把这个产品形态拆干净TikTok 小游戏到底是怎么跑的1.1 它不是一个 App也不是一个原生游戏很多人第一次听到“TikTok 小游戏”的时候脑子里的第一反应是“给手机装一个游戏 App再用 TikTok 账号登录”。这个理解是错的。TikTok 小游戏本质上是一类运行在 TikTok 客户端容器里的 HTML5 游戏用户刷视频刷到对应内容之后通过点击挂载的组件直接拉起一个游戏界面不需要跳转去应用商店也不需要额外下载安装包。这个形态和过去大家熟悉的网页游戏有点相似区别在于它被装进了一个带宿主能力约束的容器里。这个容器有明确的限制它不能直接读取用户手机里的文件不能随意拉起摄像头和通讯录也不能像原生 App 那样常驻后台。游戏的全部运行环境都建在一个浏览器内核之上你可以把它理解成“带了一层平台 API 的浏览器页面”。正因为跑在网页容器里所以小游戏天然有跨端的优势。iOS 和安卓端你不用各写一套原生的逻辑只要把游戏代码整理成一个标准的 Web 工程处理好不同机型的兼容性打包提审之后两端基本都能跑。这一点对个人开发者特别友好因为它意味着你前期的研发成本可以被压得很低一个人同时承担程序、策划和美术的工作量完全有可能做出一个完成度高的作品。1.2 三类典型开发者看看你在哪一类要不要进入这个领域我建议你先判断自己的角色因为不同角色准备的东西差别很大。第一类是个人开发者。你的优势是灵活、决策快一天能试好几个玩法原型。你的劣势是时间碎片化尤其如果还有全职工作想靠下班后的时间推进一个完整项目非常考验目标管理。我见过有的人半年过去了还在改首页 UI而有的人用四个周末就上线了一个休闲小游戏。区别不在于能力在于一开始有没有把范围控制住。第二类是有两到五个人的小团队。团队里有程序也有美术出活速度会明显快很多但沟通成本也会上升。小团队最容易犯的错是追求“大而全”比如想着加入联网对战、排行榜、道具商城最后把自己拖进泥潭。我的建议是最早两个项目都做单机玩法只把分享做进去尽可能少碰实时通信。第三类是原本就在做广告系统、Web 外包或者传统网页游戏的团队。你们转型做小游戏其实是降维打击因为核心的渲染、交互、性能优化经验都是通用的唯一要补的课是平台的宿主能力接入和审核规范。你不需要从零学游戏开发只需要把原来那套网页工程的构建方式切到平台要求的运行时上。1.3 海外侧与国内侧的同源关系先搞清楚再说市面上聊 TikTok 小游戏时很容易把海外侧的开发文档、国内同类型小游戏的开发文档混在一起。这里我先给一个结论性的判断两者底层技术方向同源但账号体系、开放能力、审核环境和分成政策并不完全一样你要在哪个市场做就去看哪一套文档不要拿 A 平台的代码示例硬套 B 平台。如果你是很早以前接触过国内短内容平台小游戏开发的会发现很多 API 思路非常熟悉比如初始化、登录态同步、分享埋点、激励视频广告这些能力都能找到对应物。因为产品底层一脉相承迁移的成本确实很低。但请一定注意海外侧的合规要求更强调用户隐私和数据边界弹窗授权策略要重新检查一遍不能把国内习惯“先拿权限再说”的做法带过去。看到这里你应该明白TikTok 小游戏是一个有明确边界的产品形态它降低了下分发门槛但也增加了平台规则对作品形态的约束。接受这套约束后面所有步骤才有意义。2. 注册和资质环节开发者账号的每一步都是埋坑重灾区2.1 先决定主体类型再决定账号注册方式成为 TikTok 小游戏开发者的第一步当然是到官方开发者平台注册一个账号。这个环节听起来很简单但你在注册之前必须想清楚一个事用个人主体注册还是用企业主体注册个人主体注册起来快实名信息填好就能开始更适合测试玩法、验证自己想法的阶段。但它也有明显缺陷部分实功能接口开放得比企业主体晚而且个人在资质审核、结算合规上能走的路相对窄。如果你一开始就预估这个游戏能产生收入并且希望走得正规一点那注册一个企业主体账号会更省事前提是你得有一个合法的企业资质。有人会问那我先用个人身份做出来等跑通了再换成企业主体行不行可以但换主体意味着原来账号关联的游戏、数据和结算关系都要重新迁移中间的成本并不小。我的建议是纯学习阶段用个人账号打算商业化之前尽早切换企业主体。2.2 创建应用时类目选择比填写名称更关键账号注册通过之后下一步要创建一个“应用”。这里说的应用不是手机 App而是你在这个开发者后台里管理小游戏项目的一个载体。你会发现创建时有一堆字段要填其中最重要的是产品类型和游戏类目。选错类目的后果是后端的审核策略完全不一样。比如同一个休闲玩法的游戏如果你把它归到“工具类”审核人员看你的角度就会变成“这是个工具为什么界面像游戏”大概率会驳回。反过来把工具内容归到游戏类也会因为核心功能缺失被卡。所以填写类目之前先去文档里看一圈当前开放了哪些类目找和你玩法最接近的那一个。有些新手会犯一个更隐蔽的错误在类目里选了“游戏”但应用名称又起得不像游戏。审核人员对不上号第一轮就驳回。起名这件事不要玩梗最好让名字直说玩法比如“方块消除大挑战”就比“天天闪亮”容易过审也能让用户一眼看懂你在玩什么。2.3 域名校验、测试白名单和开发者角色分配创建完应用之后后台会让你绑定一个域名并且完成域名归属校验。这个动作的作用是平台只允许你在自己拥有的域名下面托管游戏包资源防止盗用他人的空间地址。我记得第一次做的时候就是因为这步漏填导致构建出来的包在开发者工具里能跑但一提交就被系统提示资源不可访问。除了域名你还需要配置一个测试设备白名单。平台的逻辑是这样的你在开发阶段调试时只有白名单里的设备才能通过扫码方式拉起调试版小游戏等上线之后这个限制才会解除真实用户才能通过平台看到你的游戏。所以在你准备让团队里的策划、美术都能上手体验之前先把他们的设备统一加进白名单不然他们拿到二维码扫了也是白屏。如果你们是一个团队记得在后台把不同成员的权限分配好。至少要分管理员、开发者、运营这三种角色不要所有人共用一个账号去操作风险太大了。万一有人误操作把测试配置删了轻则影响迭代效率重则可能触发风控给账号带来不必要的麻烦。3. 技术选型怎么做三条路有各自的小九九3.1 引擎路线对比别只看渲染效果当你进入真正写代码的阶段首先要定的是技术路线。市面上的选择归纳起来就是这三类直接写原生网页脚本、使用通用游戏开发框架、使用重引擎构建导出。我给一个表格方便你对着看方案上手难度包体控制适合场景典型短板原生脚本 Canvas低极小休闲玩法、原型验证复杂物理效果难实现通用游戏框架中小到中2D 休闲、消除、跳跳类官方文档依赖社区维护重引擎导出高中到大3D、复杂渲染、跨端复用初始工程体积大、加载慢我见过很多新人一上来就选重引擎理由是“以后能做更牛的作品”。但你要知道小游戏场景里的核心指标并不是画面多惊艳而是首包加载速度。用户刷到你的视频之后如果点开游戏要等五秒才能看到界面大部分人会直接退出。所以我的经验是第一个作品尽量走更轻的路线把玩法想清楚、把反馈做顺手比追求画面高级重要得多。3.2 宿主能力接入真正让你区别于普通网页游戏的是这套 API小游戏之所以叫“小游戏”是因为它不只是能玩还能和宿主平台做互动。这个互动就是通过平台的开放能力实现的典型能力有这么几个拉起登录、读取头像昵称、发起分享、记录排行榜、播放激励视频广告、拉起支付。你得把这些能力想象成“游戏里可以调用的公共工具”。比如你做了一个跑酷游戏玩家跑到了一个新的里程碑就可以弹出一个分享按钮把成绩卡片分享到短视频内容流里。这个动作一旦被其他用户看到就形成了一个新的曝光入口等于是让玩家帮你做推广。具体怎么调用按官方文档走就行但有一个细节值得提醒登录和静默初始化要放在最前面最好在加载页就完成避免用户进入主界面后再看到登录弹窗。如果一个休闲游戏开场五分钟才要用户授权登录流失率会高到让你怀疑人生。3.3 包体、视口适配和内存占用三件容易被忽略的事技术选型结束后我建议你立刻做三件事设置好固定视口策略限制资源包体规划好内存占用。视口适配的问题尤其容易出现。TikTok 小游戏通常要在各种不同屏幕比例的机型上运行有些机型是全面屏有些还有大下巴。如果你只按一种设计分辨率做画面会出现拉伸或者黑边。最省心的做法是采用安全区适配方案把关键按钮放进安全区内背景图则做宽一点专门用来覆盖裁切区域。包体方面尽量压制到预期范围内。能放在云端加载的素材就不要全部塞进首包能用矢量图的地方就不要切高清大图。至于内存则要注意及时释放不再使用的大资源尤其是切场景时要清掉上一关的纹理引用不然几关下来内存越占越大最后在低端机上直接闪退。闪退一旦被用户反馈到平台对游戏评级的影响很直接。4. 从零做出第一款 Demo 的全过程复盘4.1 目标要小到“无聊但完整”而不是“大而完美”如果这是你的第一个小游戏我强烈建议不要以“创新”为第一目标先以“走通全流程”为目标。什么叫走通全流程就是你把一个最简单的玩法做好账号注册、代码构建、真机调试、提审、上线这一整条链路全部走一遍。整个价值不在游戏本身而在让你知道每个环节会产生什么意外。我给自己定的第一个 Demo 目标非常朴素做一个三分钟能完成一局的翻牌配对游戏一共就四组卡牌翻对了消除翻错了翻回全部消完显示用时和分享按钮。这个玩法没有任何创新的地方但它覆盖了资源加载、点击交互、计时逻辑、结果分享这四块基础能力足够把工具的坑都踩一遍。4.2 搭建工程和本地调试关键是不让它水土不服我先用通用游戏框架建了一个标准工程目录大致是这样的入口脚本负责初始化一个场景脚本管理牌组数据一个渲染脚本负责绘制卡牌一个控制脚本接收点击事件。为了后续能接支付和广告我把这些能力都拆成了独立模块保证“业务逻辑”和“宿主调用”不混在一起。本地调试的时候开发者工具可以模拟大部分环境但模拟器和真机之间始终有差异最典型的差异是屏幕比例和内存性能。我在模拟器里跑得流畅的游戏在低端测试机上出现了掉帧后来排查发现是阴影滤镜太重去掉了立竿见影。真机调试建议准备两台不同性能的安卓机和一个开发用 iPhone覆盖面足够才有安全感。4.3 构建产物、提审准备和第一次提交的状态确认Demo 功能完成后接下来就是构建产物。小游戏平台一般会要求你把代码打包成一个压缩包压缩包内部的结构得符合要求。这个过程最容易出的问题是本地资源路径用错了导致上传之后图片全部加载失败。我第一次提审时还犯了一个低级错误就是忘记把自己测试时用的一行打印日志从代码里删掉。那个日志会每秒钟往控制台输出一次虽然不影响运行但审核人员在打开游戏时很容易看到满屏日志直接影响专业印象。所以提审前的最后一步一定要做全局检索把所有调试输出、临时代码、已废弃接口全部清理干净。上线前的状态确认我还给了一张清单每次提审前都过一遍首屏加载小于 3 秒、无调试日志、无不可点击的页面残留、分享按钮真实有效、后台配置的域名可以正常访问。这五项确认完我才敢点那个提交按钮。5. 审核阶段最容易踩的坑提前替你挨个踩一遍5.1 内容规范带来的驳回往往不是因为你游戏不好玩审核阶段被驳回是最磨人的体验因为它常常不给你具体到哪一帧的反馈。我在社区里见过最典型的驳回原因是“内容与所选类目不符”和“存在诱导性话术”。你以为小游戏想怎么写引导文案都可以但实际上平台对“强制点赞、强制关注、诱导分享”这类行为是零容忍的。比如你在失败界面上写“分享给好友才能复活”这在很多平台会被判定为强制分享但如果写成“分享给好友可额外获得一个复活机会”语气上变成了鼓励分享同时给一种“可不分享”的自由感审核就会宽松很多。差之毫厘理失千里。还有一类驳回理由是素材问题。一些人直接用搜索引擎里找的网红背景图做游戏封面这种做法一旦被告发问题会很严重。正确的做法是所有图片、音频都自己制作或者使用明确支持商用的公开素材并把来源记录保存好。5.2 版本号错误、隐私弹窗和醒目组件这些暗坑要单独排审核问题里有一类特别冤的功能正常但是版本号填错了。平台对每次提交的版本号有严格要求如果你上一次提交是 1.0.0这次还填 1.0.0系统可能直接拦截或者导致测试设备上加载的缓存不是最新包。永远记得在每次提审前把构建包里的版本号、后台填写的版本号、包内信息里展示的版本号三个位置对齐。隐私弹窗也是一个高频驳回项。游戏涉及登录或者读取用户信息时必须一开始就有明确的弹窗说明而且要提供“拒绝”选项。有一个测试反馈很典型隐私弹窗里已经写了“同意”按钮却没有“不同意”按钮这就不符合最小化授权原则直接被要求整改。另外如果你在游戏里用了旋转、震动、陀螺仪这些比较突出的手机能力审核阶段一定要让测试者能明显感知到这些功能。“我明明做了震动反馈为什么审核人员没发现”因为振动只在特定关卡触发而且很轻微审核人员根本意识不到。正确做法是在前五分钟就安排一段演示流程让核心能力明显呈现。5.3 被驳回之后怎么沟通和重新提审被驳回不要急着和审核“硬刚”。先冷静分一下是哪一类驳回如果是内容问题最好直接根据反馈调整如果是误判就通过站内申诉渠道提交一段录屏和文字说明。我个人经验是证据越具体越好比如“在 XX 秒处可见完整的隐私授权弹窗用户可拒绝”然后再附上一张截图或者录屏附件效率最高。重新提审时修改说明也要认真写。尽量简单直接地列出改了什么、为什么这样改不要含糊其辞。审核问题永远是一次一次迭代出来的极少有人一次通过。重点是不要因为挫折就放弃养成把每次驳回原因整理成自己文档的习惯后面做第二个、第三个作品时会高效太多。6. 上线之后不是结束前 90 天的数据迭代才是分水岭6.1 冷启动阶段看什么数据别被表面数据骗了游戏上线并不代表事情做完了恰恰相反真正的开发周期这时候才算拉开。前 90 天你要做的不是盲目加玩法而是盯住几个核心数据把它们转成清晰的产品迭代动作。我最关注的是首日留存、三日留存和七日留存以及单人单局平均时长。首日留存看出的是“玩家点开后愿不愿意玩第二局”七日留存看的是“有没有形成重复访问的惯性”单局时长则直接反映玩法节奏一般休闲游戏单局控制在三分钟以内最舒服超过太久玩家会觉得累。有个很容易被骗的场景是次留很高但始终没有自然新增。这说明你现有的内容只在老用户圈子里流传没有通过短视频分享、推荐算法带来新用户。这时候要优先优化分享场景让每局结束后的成绩展示更夸张、更有分享欲而不是去调整玩法难度。6.2 商业化配置激励视频、插屏和付费点的平衡小游戏的收入通常来自广告和内购。广告配置不是越多越好而是要在“不破坏体验”的前提下找到平衡点。激励视频是最温和的一种广告形式玩家自己主动选择观看换来复活、双倍奖励或额外道具。这个模式适合放在关键失败节点比如“差一步就过关了看视频拿个提示”。插屏广告则要非常克制尽量只在完成一个大阶段后展示一次游戏会话内不要超过两次否则玩家烦了直接关掉游戏广告收入再高也补不回来损失。如果你的游戏里准备做付费道具更得小心。休闲小游戏的核心矛盾是“免费玩家也要玩得爽”付费点应该落在“更方便”而不是“更强”。比如让玩家省去一段时间的等待、解锁一个好看的皮肤都比直接卖数值优势更安全。6.3 三个月的成长周期两次完整迭代足够形成自己的能力闭环如果给你 90 天我建议这样安排第一个月专注上线和稳定修复第二个月根据数据做一次大版本更新最后一个月梳理沉淀。第一个月的目标不是做新玩法而是把崩溃率、闪退率、加载耗时这些基础指标打磨好。即使你只想做一个小玩法也有可能因为兼容问题丢掉大量用户。第二个月的数据更新尽量围绕一个主题发力比如“提高分享率”改完看数据有没有变化有变化就留下没变化就回滚。第三个月你要做的事情是把你这三个月里遇到的每一个问题、每一次决策判断都归档形成自己的错误清单和优化清单。如果你能做到这一步那你不只是会做游戏而是真正建立了对 TikTok 小游戏生态的判断力。以后不管平台规则怎么更新、市场风向怎么变你都有了快速调整方向的底气。这也是我和许多同行聊下来大家都认可的真相这个行业不缺做游戏的人缺的是能把一件事从零走通并持续迭代下去的人。