下载 App

十万积分的成果又回来了!手机端成功使用视频驱动!!

精华修改于04/03682 浏览开发交流 包含 AI 合成内容
作者:浠涫
一、问题背景:十万积分差点(已经)打水漂
在 TapTap Maker 聚光灯 24 小时 GameJam 中,我做了《方格屋》——一个叙事驱动的舒尔特方格游戏。为了最好的叙事体验,标题界面做了做了循环背景和开门过渡视频,序章做了 11 段 AI 生成视频(A 段 5 段 + B 段 6 段)。
总计约 13 段视频,消耗了近 10 万积分。
然后在上线前一天的手机端测试中,我发现:手机端视频全挂了!
二、问题复现:手机端视频为什么播不了
2.1 最初的情况(v0.9.29)
TapTap
根因分析:
  • 桌面端用 <video> 标签,支持 blob URL
  • 手机端用 Android WebView,blob URL 不稳定
  • TapTap Maker 的 Video.isSupported 在手机端返回 false
解决方案(v0.9.30):
  • 手机端检测后自动 fallback 到静态图片 + 文字 ADV 模式
  • 桌面端继续用视频
  • 结果:手机端勉强能玩,但花了 10 万积分的视频完全看不到
三、第一轮优化尝试(v0.9.30 - v0.9.34):治标不治本
3.1 视频格式优化(v0.9.34)
即使在 Video.isSupported 返回 true 的情况下,手机端视频加载还是经常超时(>3 秒)。进一步排查发现:
TapTap
用 ffmpeg 重编码全部 13 个视频:
bash
# faststart:moov 前置,支持渐进式加载
# Main profile + 无 B-frames:最大化移动端兼容性
# 降码率到 1.5 Mbps(AI 生成视频足够清晰)
ffmpeg -i input.mp4 \
  -movflags +faststart \
  -profile:v main -bf 0 \
  -b:v 1500k -maxrate 2000k \
  output.mp4
效果:
TapTap
3.2 非阻塞预加载(v0.9.33)
v0.9.32 的预加载是阻塞式的——用户必须等视频加载完才能继续,在手机端经常卡 10 秒以上。
核心理念转变:
不要让用户等一个注定失败的加载!
修复方案:
  1. 免责声明不再阻塞用户:1.5s 最短展示后即可点击继续
  2. 用户点击跳过时:未完成的预加载直接放弃 → videoWorks=false
  3. 标题页/序幕自动走 fallback:静态图/ADV 文字模式,零等待
  4. 进度条改为纯信息展示:呼吸动画不依赖预加载状态
3.3 问题:这些优化都没用
虽然做了很多工作,但视频在手机端还是没法正常播放——
核心原因:当时 TapTap Maker 官方没更新,没有对应通道!
所有优化都在绕路走,但核心问题没解决。
四、转折点:TapTap Maker 官方通道打通(v0.9.35)
4.1 关键转折点
直到VideoPlayer 原生支持 HTTPS URL 直接加载!昨天/前天才打通了这条路:
这是整个修复链条中的关键转折点——没有官方支持 HTTPS URL 直连是前提!
4.2 根因定位(跨 3 个会话深入分析)
终于找到了真正的根因:
plain text
WASM VideoPlayer 加载虚拟路径
    ↓
DWP 下载
    ↓
blob URL  ← 【问题就在这里!
    ↓
<video> 标签播放
blob URL 在 Android WebView 中不稳定,经常加载失败或超时。
4.3 解决方案:CDN 直连绕过 blob URL
VideoPlayer 原生支持 HTTPS URL 直接加载!绕过 blob URL 整条链路。
新增 video_url_resolver.lua(280 行):
  • 运行时异步探测 CDN base URL(6 个候选模式)
  • 用 VideoPlayer:AsyncLoad 验证可达性
新增 video_cdn_map.lua:
  • 从 manifest 提取 13 个视频虚拟路径 → CDN 文件名映射
修改 main.lua 和 prologue_video.lua:
  • 所有视频加载点都通过 resolver 解析为 HTTPS URL
  • 探测失败时优雅回退到虚拟路径(桌面端正常)
五、最终修复:分布式预加载架构(v0.9.56)
5.1 问题
CDN 直连解决了加载问题,但在手机端 WebView 中,VideoPlayer.GetVideoWidth/Height 经常返回 0,导致 widget.Render() 中跳过绘制 → 黑屏!
5.2 修复 1:视频尺寸 workaround
lua
--- 手机端 VideoPlayer.GetVideoWidth/Height 返回 0 的 workaround
--- 引擎 JS 层在 HTTPS 直链模式下可能无法获取视频原始尺寸,
--- 导致 widget.Render() 中跳过绘制 = 黑屏。用 textureWidth/Height 兜底。
function PatchVideoSizeForMobile(widget)
    if not isMobileWeb_ or not widget or not widget.player_ then return end
    local p = widget.player_
    local origGetW = p.GetVideoWidth
    local origGetH = p.GetVideoHeight
    local tw = widget.props.textureWidth or 1920
    local th = widget.props.textureHeight or 1080
    p.GetVideoWidth = function(self)
        local w = origGetW(self)
        return (w and w > 0) and w or tw
    end
    p.GetVideoHeight = function(self)
        local h = origGetH(self)
        return (h and h > 0) and h or th
    end
end
5.3 修复 2:分布式预加载
手机端必须走 AsyncLoad + swap 路径,不能同步加载。
分布式预加载架构:
  • 开门视频:在标题页 idle 时预加载
  • 序幕 B1 视频:在方格玩法期间预加载
  • 5 个视频分别在不同空闲时段 AsyncLoad + swap
lua
-- 二级预加载(标题页/游玩期间异步加载后续视频)
local preloadDoorPlayer_ = nil      -- 预加载的开门过渡视频
local preloadDoorDone_ = false
local preloadB1Player_ = nil        -- 预加载的序幕B1视频(方格玩法期间加载)
local preloadB1Done_ = false
六、完整修复链路总结
、
TapTap
七、最终效果(v0.9.56)
  • 开门视频:标题 idle 预加载 → 播放正常
  • 序幕 B1:方格期间预加载 → 播放正常
  • 分布式预加载架构:5 个视频分别在不同空闲时段 AsyncLoad + swap
  • 用户确认:全流程视频播放正常
✅ 手机端全流程视频修复完成
十万积分终于回来了! 🎉
八、避坑指南(给后来者)
8.1 TapTap Maker 手机端视频播放检查清单
TapTap
8.2 如果视频还是播不了
  1. 先确认官方通道有没有打通:TapTap Maker 刷新了吗?问嗒啦啦了吗?有没有 HTTPS URL 直连支持?
  2. 检查 blob URL:手机端尽量用 HTTPS 直链,绕过 blob
  3. 查看日志:VideoPlayer 的 AsyncLoad 回调返回什么?
  4. 简化测试:先放一个最简单的 5 秒视频测试
  5. 兜底方案:做 fallback 到静态图/文字模式
九、核心总结
一句话总结:在 TapTap Maker 手机端做视频,首先需要 TapTap Maker 官方提供 HTTPS URL 加载通道,这是前提!然后再配合格式、预加载策略、尺寸获取等多维度优化,才能让十万积分的视频真正在手机上播放出来!
关键要点:
  1. 官方通道是核心前提! HTTPS URL 直连是核心,之前 TapTap Maker 官方没更新,没有对应通道,其他优化都治标不治本!
  2. 视频格式:faststart + Main profile + 无 B-frames + 1.5 Mbps
  3. 加载方式:HTTPS URL 直连,绕过 blob URL
  4. 预加载策略:分布式异步预加载 + swap
  5. 尺寸获取:textureWidth/Height 兜底,防止 GetVideoWidth 返回 0
  6. 永远要有 fallback:静态图/文字模式兜底
希望这篇干货能帮大家节省大量调试时间,如果身边有 TapTap Maker 开发者正在头疼手机端视频问题,不妨把这篇文章分享给他~
> (注:文档部分内容可能由 AI 生成)
|(注:文档部分内容可能由 AI 生成)
注:文档核心内容由嗒啦啦生成![TapFamily庆生-万物皆可联动_飞吻]#
猜你想搜
taptap 制造视频加载失败修复
别再烧积分了!从每次 2000 到每次 50 的血泪经验截图
别再烧积分了!从每次 2000 到每次 50 的血泪经验
适用场景:所有在用 TapTap Code 开发游戏的小白 难度:★☆☆☆☆ 背景最近群里总有人"炫耀"一次操作花了几千积分,说实话这不是值得高兴的事——这是在告诉所有人你的开发方式有根本性问题。我也走过这条弯路,所以来说说怎么改。 积分消耗的本质是什么积分 = AI 处理的 token 数量 = 你发给 AI 的内容 + AI 回给你的内容所以烧积分的本质只有两种: 你让 AI 做了大量无效/重
精华
74 赞
23 回复
03:06
为了不被斩杀,我只能做到这些了截图
为了不被斩杀,我只能做到这些了
之前一直申请不到计划3,之前说太花哨,后面说体量完成度不足,在我一番小作文下,编辑终于给了我解答,什么原生质感,玩家开局体验啥的。 本来计划2也够用,准备以后再优化了,结果计划2赠送的积分要砍半了,学生党实在消费不起,于是只能再冲一波计划3了 从周六中午到现在一天半时间,优化了一遍角色卡,战斗卡,还有抽卡界面,优化了新手教程,该说不说确实比之前要舒服些。 前半部分为新版,后半部分为旧版。 明天再次
44 赞
9 回复
00:40
在TapTap上尝试2.5D的策略游戏截图
在TapTap上尝试2.5D的策略游戏
这是一个用KayingCodex做的最新的尝试,2.5d游戏画面的《小咖三国》,初见雏形。#taptap #taptap制造 #KayingCodex taptap上有喜欢SLG的伙伴吗?
2 赞
01:29
官方阅,申请积分计划2,希望官方继续支持我完成这款游戏,截图
官方阅,申请积分计划2,希望官方继续支持我完成这款游戏,
视频内容只是一部分, 本游戏耗时3个月,目前完成进度百分之80, 是生存游戏,进入修仙界,走剧情找到宗门加入, 这时游戏才是真正开始, 提升实力境界后就可以变强,获取功法法术法宝, @视频内是游戏里挑战妖族入侵一种主流玩法,游戏就是围绕着这个来进行, 还有很多地方可以战斗,获得资源修炼变强,比如去藏书阁学习功法, 去法宝楼抽法宝,每一个宗门数十个法宝抽取 去修仙界探索,获得各自的资源,可能遇见妖兽
1 赞
3 回复
本地部署 AI 对接 TapMaker 指南 —— 以 CodeBuddy 为例V1.1截图
本地部署 AI 对接 TapMaker 指南 —— 以 CodeBuddy 为例V1.1
写在前面 大家好,我是橘猫,和你一样也是TapMaker的萌新玩家。在"全能神"天哥的悉心指导下,我顺利完成了本地开发环境的部署。经过这段时间的实战测试,已经成功打通了「本地开发 → 同步至TapMaker」的完整流程。 以下内容全部来自我的个人实操经验,旨在为同样在探索本地部署的朋友提供一个参考。每个人的电脑环境、网络情况、AI工具版本都不尽相同,文中的步骤仅供交流学习。如果你照着操作后遇到问题
37 赞
19 回复
创作小队第一次集体大讨论,笑点最密的一集截图
创作小队第一次集体大讨论,笑点最密的一集
所有人灵感大爆发,谈美了。实际上,作为一个要参加21天计划的游戏,我们今天才正式开始拟大纲、起名字有些晚了,希望来得及。我们确认了双主角设定、故事主题与反转。计划按1:2人数分工完成主线、支线。我们准备用AI制作大部分游戏图,不过我们也就放弃了美术评选。计划后3天内尝试用workbuddy和塔啦啦搭建游戏雏形,希望我们可以。
5 赞
00:54
等距场景编辑器——自行编辑2D瓦片场景地图截图
等距场景编辑器——自行编辑2D瓦片场景地图
一个可嵌入任何 UrhoX 项目的完整等距瓦片地图编辑器,适用于 RPG、策略、模拟经营等类型游戏的关卡设计。 SKILL审核已通过,各位创作者可以根据自己的需要对工具进行调整修改 声明:该工具仅作为场景编辑以及序列化,交互等功能需要用户自行在项目中定义 后续会根据实际情况补充rule tile相关逻辑,实现tile map编辑自由 目录 1. 界面总览 2. 六种编辑工具 3. 双视图模式 4.
精华
21 赞
11 回复
00:26
塔啦啦科研:三渲二(风格1)截图
塔啦啦科研:三渲二(风格1)
最近在研究像素风格的三渲二,一直想做小丑牌那种风格,但是塔啦啦一直做不出来,发现是有一部分的功能做不了,只能实现简单的材质制作和描边,因此,我从零直接搭建了一整套引擎基础。目前进度可以看视频。 @嗒啦啦 什么时候出shader 评论区随意提问 #TapTap制造 #TapTap制造社区 #TapTap制造
4 赞
5 回复
【UI教程】如何将已有的效果图应用为实际的UI界面截图
【UI教程】如何将已有的效果图应用为实际的UI界面
在经过了一些折腾和比较折磨的尝试后,我总算是摸清楚了嗒啦啦怎么把UI效果图转换为实际游戏中的UI组件,今天就给大家带来这部分的经验分享。 tips:1.本篇教程需要各位掌握最基本的ps使用,具体的操作部分我会大致讲解,但仍需各位自行学习ps的基本操作,部分可以由ai代劳的环节我会注明。 2.本篇教程需要在以我前两篇教程作为前置环节,请在阅读这两篇前置教程后再进行本篇教程内容的学习 在按照前
12 赞
5 回复
我的第一个游戏截图
我的第一个游戏
#开发心得 用ai制作了一个算不上游戏的游戏 非常简单甚至是没有可玩性 选择了像素风 做完以后发现ai味太浓了 而且几乎没有关卡 接下来想尝试一下比较有故事的游戏 或者试试视觉小说 第一次自己上手制作 虽然只需要向哒啦啦发送提示词 但是发现自己对游戏的基本知识和类型知之甚少 昨天晚上才开始慢慢学习 进度也很慢 但是发现自己很喜欢这种手搓感 让我感受到我的生命还存在着 手搓游戏也是一种游戏 活着本身
3 赞