支付宝App 3D动画和小游戏背后的故事

2020 年 7 月 29 日

支付宝App 3D动画和小游戏背后的故事

3D动画和游戏一直是前端领域的难点,支付宝App从2017年春节推出AR红包开始,一直在Web3D领域进行探索和实践。本文将以亲历者的角度,为你讲述这段不断探索和自我突破的经历。


很荣幸到了五年陈,我做的工作一直和 Web3D 相关,从头到尾经历了支付宝 Web3D 发展。本文把这段经历记录下,从技术和业务两方面分析,支付宝 Web3D 是如何在集团技术中逐渐上位的,并且尝试推演未来的各种可能性。


初生牛犊不怕虎


2016 年底,一款 Pokemon go 的手机 AR 游戏爆火,大家开始在现实生活中捕捉自己的宝可梦,AR 的概念也因此进入大众视野。


也许是受到 Pokemongo 的启发,2017 年春节,支付宝推出了 AR 红包,大家扫周围的环境,就能发现朋友藏的红包。产品中红包是一个 3D 模型,虽然是 2016 年,但是在支付宝里面做 3D 动画渲染,这还是第一次。



当年的 AR 红包是多个团队完成的,图像识别是写客户端代码团队实现的,而红包动画是前端团队实现的。其实当时红包动画是由一位游戏开发大佬通过 C 代码实现的,但这位大佬所在的团队是前端团队。新春之后,前端自然有发展 3D 渲染的打算,但是客户端团队出于各种的考虑并不想把 AR 的 3D 渲染交出去,所以支付宝当时 3D 渲染分成两条线发展,客户端做 AR 和 3D 渲染技术,而前端开始了真正意义上的 Web3D 探索,他们的代码是纯净的 JS,运行环境是任何一个支持 WebGL 的浏览器中。


摆在这个团队面前最大的问题是: Web3D 要怎么发展?


2017 年初,支付宝放弃了在社交方向的尝试,开始回到纯粹的金融理财工具定位,AR 因为富有科技感,被看作未来的一个重点方向,客户端渲染开始起飞。而失去 AR 支持的 Web3D,必须找到新的业务落地,否则这个前端技术团队将不复存在。


除了业务问题,技术上也是非常艰难。Web 上主流的 3D 渲染引擎是 ThreeJS,而这个引擎体积巨大,功能繁多,使用门槛很高,渲染一个 3D 模型到底是选择.obj 还是.fbx 文件,都没人知道。3D 模型的文件格式有很多种,而没有一种是适合在 Web 上渲染的。恰巧当年 Web 规范提出了 GLTF 的 Web 模型格式,这个格式在今后成为了每个 Web 引擎必须完美遵循的规范。


前端团队重新来过,不使用 ThreeJS,写了一个全新的渲染引擎 “R3”(Render for 3D) ,同时做了一个 Unity 的插件,可以直接将 Unity 的模型导出到 Web 进行展示,配套了组件开发模式和特效系统,解决了 3D 渲染的基本问题。当年“R3”团队的 Leader 开始奔走于支付宝的各个业务团队之间,开始进行业务推广,而这是运气给 Web3D 带来了第一次起飞,让它在客户端渲染面前站稳了脚跟。


2017 年,支付宝迎来了“公益红利”,蚂蚁森林和蚂蚁庄园成为最火爆的端内应用,和支付工具相比,它们能显著提高用户的停留时长,并且更用户也很乐意去通过支付宝进行公益活动,增强了支付宝的品牌效应。R3 配合蚂蚁庄园,上线了第一款 3D 小游戏—— 星星球 。用户通过玩星星球可以得到庄园道具奖励,这让星星球的用户量在一周之内用户达到了非常大的数量,从此所有的业务方都希望通过 Web3D 复制这个“增长奇迹”。


但其实,星星球的上线非常坎坷,在技术上遇到了诸多挑战。



因为第一次大量使用 WebGL,我们收到了很多底层的不兼容问题,这些问题大多数是由于系统驱动引起的,这部分代码对于前端来说是黑盒,由于支付宝的网页都是跑在 UC 浏览器内核,当时我们求助了 UC 团队,他们通过修改浏览器的行为来绕过系统兼容问题,让我们的 WebGL 相对稳定。而对于非常老版本的安卓系统,我们只能放弃,等待时间来清洗历史遗留问题。


时至今日,WebGL 在稳定性上已经完全达标,不可用率也低到忽略不计。


“下一个爆款”的困境


蚂蚁森林和蚂蚁庄园的狂奔,让更多业务方看到了游戏的力量,很多业务方都找过来要做“养成游戏”,R3 团队选择了做 “惠星球” ,游戏通过做任务升级建筑获得一定奖励,游戏的制作精细程度和开发工作量是“星星球”的 10 倍以上。



然而“惠星球”并没有取得预期的效果,首先业务上线就一波三折,从开发到上线经历了 8 个月,对于 3 周迭代一次的前端项目来说,仿若隔世,上线后流量也远不及星星球。出于团队发展的考虑,“R3”团队不再进行支付宝的互动游戏开发,转到了其他项目,之后由支付宝的其他团队进行 Web3D 项目探索。


令人惊喜的是,“江山代有才人出”,农场团队的同学用星星球留下的 3D 模型,东拼西凑做出来一个 小鸡登山赛 。这是一个魔性的休闲竞技游戏,上线一个月用户量打破了星星球的记录,成为支付宝 2018 年流量最高的 Web3D 应用。



登山赛的兴起仍然依赖蚂蚁农场入口,而农场有‍了星星球和登山赛两款游戏后,必须探索农场之外的场景,“公益”性质的农场不会发展成一个“游戏中心”。


普通的支付宝业务大多数是 H5 页面,有一定的工具属性或者商品属性。支付宝像一个集市一样,保罗了各种业务,业务为了增强自己的认知,也会定期搞营销活动。营销活动大多数时候是发优惠券或者红包,而发放的形式比较单一,用户感知很差,很多时候用户都忘记自己领了红包,业务方花了钱,却没有达到效果。


设计团队和开发共同倒腾出来 “堆堆乐” 的休闲小游戏,并且第一次进行了“游戏化运营”的探索,从纯玩小游戏变成了“氪金”营销工具。堆堆乐在游戏模式上加入了技巧的成分,需要用户花时间练习才能玩得好,当然再厉害的用户也会有 Game Over 的时候,如果用户失败的时候,可以通过分享游戏链接的方式获得一次复活的机会,出于时间成本和损失厌恶的心理,大多数用户会选择分享。


堆堆乐上线之后,分享率是普通营销活动的 10 倍,这个数据吓到了当时所有的运营。



“无往不利”的商人们又在堆堆乐上进行进一步包装,换了一套场景皮肤,成为 2019 年余额宝 6 周年生日活动。


这次活动用户每天可玩次数只有 3 次,每日冲顶可以获得余额宝体验金奖励。如果 3 次内没有冲顶,就需要做任务来“充值”游戏次数,这些任务就是业务转化的指标。更有趣的是,活动期间还引入了游戏中的“限时购买”机制,限时任务的完成量是普通任务的 2 倍,可以说是一次教科书般的“游戏化运营”。


活动持续了两周,用户复访率居高不下,有非常高的粘性,当时能在微博上搜到很多用户炫耀自己分数高,或者吐槽手指不灵活,还有用户分享游戏攻略,吸引了相当多的年轻人参与。



余额宝的大活动,将堆堆乐的用户量级推到了登山赛两倍,成为 2019 年访问量最高的 Web3D 应用,余额宝活动结束后,堆堆乐通过几次换皮,又承接了其他的营销活动。值得一提的是,这款游戏采用了集团的 3D 引擎 Hilo3D,引入了物理引擎,增加了动态阴影和光照,在画面和可玩性上都有提升。


同样使用了 Hilo3D 的 2020 年 1 月的新春红包,让我们全球用户在浩瀚的星空中传递福气,在视觉渲染效果上达到了新的高度。我们在设计场景的时候,用了大量传统年俗的元素,春联,团聚,烟花等等,通过精美的画面让用户在手机端感受曾经的年味。


http://mpvideo.qpic.cn/0bf2r4aa2aaamyagxhawijpvbd6dbwhqadia.f10002.mp4?dis_k=a6b16561847b919b8d665df4ea2e9180&dis_t=1595748873


http://mpvideo.qpic.cn/0bf2leaa2aaamyaguwywlvpvawodbvmqadia.f10002.mp4?dis_k=57b1afb471b1ddf0de7ab99b2b00c8c4&dis_t=1595748873


随着这些尝试,Web3D 走出了农场,坐上了了大促的头把交椅,近几年支付宝的每次大促营销都会看到 Web3D 的炫酷作品。但 Web3D 也陷入了“开张吃半年”的窘境,每年的顶级大促只是是冰山一角,冰山下看不到的是普通 H5 页面,小型活动,这些业务基数大,单个业务开发时间短,上线快,流量相对较少,争取不到 3D 资源,如果需要做动画的时候,他们全部转向了 Lottie,一个来自 Airbnb 的技术。


Lottie 的爆发与挑战


Lottie 的动画来源于 After Effect,一个设计界稳坐王位的视频后期软件。它最大的好处在于动画上线不需要写代码,设计师直接导出一个 JSON 文件,就可以在页面上播放,节省了非常多的开发时间。使用 After Effect 基本上是设计的必修课,受众非常广。


2018 下半年开始,支付宝中大量的营销活动开始使用 Lottie 做特效方案,其中比较有代表性的是 18 年双十一 “提鹅”“年年有余”




反观 3D 开发中不可缺少的建模,很少有互联网公司的设计师知道如何建模,对他们来说“减面”“烘培”“绑定骨骼”就和“JAVA”“C++”一样熟悉但又陌生。做一个 Web3D 项目,建模都可能会倒腾一个月,这对于小业务来说是完全不可接受的。但每年的顶级大促活动屈指可数,为了解决“开张一次吃半年”的窘境,降低开发成本成了 Web3D 推广的关键因素。


2018 年下半年,有团队重新拾起“R3”的衣钵,为了降低开发成本,他们做了一个网页 3D 编辑器。但实际上编辑器的开发难度远高于引擎本身。编辑器做了大半年,因为交互不友好,实际上开发成本并没有降低,甚至没有一个 3D 项目是用编辑器完成的,加上 Lottie 站上那年双十一的舞台中心,大家对于 Web3D 的态度又开始“暧昧”起来。


阿里有句老话“因为相信所以看见”,3D 的探索不但没有被砍掉,上层反而持续投入。 根据他们分析,业界比较有名的 H5 游戏引擎有两款:laya 和 cocos, 虽然 laya 的性能做得更好,但是 cocos 因为编辑器的优势,拥有了更多的用户。游戏行业 Unity 也是因为编辑器生态拥抱了很多的开发者。2019 年中旬,Web 编辑器的定位被加强,团队开始重视编辑器的交互,优化编辑器到 H5 的开发调试流程,让编辑器中的场景能够一行代码引入 H5 中调试。在内部做项目时,强制使用编辑器,让编辑器不再是个玩具。


尽管磕磕绊绊,一边修编辑器,一边做项目,终于在 2019 年下半年做出了大量的 Web3D 作品。从以前半年一个项目,到一个月发布 2-3 个 3D 项目,确实证明了生产力的提升。它们重启“R3”之后改名 “Oasis” ,oasis 是绿洲的意思,希望 3D 的绿洲能覆盖到未来的方方面面。




另外,因为建模问题始终无法绕开,而 2D 动画一直是主流,所以有人干脆提出“用 3D 渲染 2D”的想法,做出更炫酷的 2D 动画,这套方案被命名为 “火星(Mars)”


歌舞演出的时候,经常会有烟花和烟雾来衬托氛围,这类特效如果在动画里实现,需要用到粒子系统。粒子系统是由大量相似的小元素组成,比如说下雨动画,雨滴都很类似,但是雨滴的数量很大,这个时候用 3D 技术就展现出了绝对优势,因为 GPU 可以并行计算粒子的运动。而 Lottie 只支持图层动画,通过贴图的各种运动来进行动画,但贴图元素一旦多起来,就会遇到严重的性能问题。而粒子系统的调参非常消耗时间,也需要专门的编辑器配合。


为了能直接和 Lottie 竞争,火星的网页编辑器仿照了 AE,设计师在火星编辑器上的产物将直接被开发进行使用。对于图层动画进行自动合并渲染,精灵图优化,引入压缩纹理降低内存开销,充分发挥了 3D 渲染的技术优势,经实测,在元素较多的动画下内存比 CSS 动画还要低。



http://mpvideo.qpic.cn/0b78aaaaoaaamuagajqwjrpvaagda4aaabya.f10003.mp4?dis_k=8839cb13f634c7d8902c9d660dd1372b&dis_t=1595748873


虽然目前 3D 的业务占有量仍不及 Lottie,但生产成本已经降低了许多。戏谑地说,Oasis 的编辑器像是低配的 Unity,而 Mars 的编辑器则像是低配版的 AE,随着开发/设计师开始使用网页编辑器,Web3D 的生态会越来越大。


有趣的是,视觉效果就像是工资,一旦提升上去了,人们就很难接受下降。Lottie 的视觉表达能力有限,随着更多的炫酷 3D 特效出现,它将慢慢无法满足视觉需求。


推演未来


写历史不仅用来怀念过去,更重要的是推演未来。当然我也不是预言家,以下言论仅供参考。


我们能看到 Web3D 这三年来 “技术落地,业务探索,降低成本” 的整体发展路线,其实这是符合技术演进的基本模式的。《创新者的窘境》是很经典的技术分析书籍,其中就提到了新技术的发展路线:首先在新的领域扎根,随着新的领域不断扩大,新技术慢慢降低成本从而替代旧技术。


Web3D 目前最大的短板在于生态,由于此领域相对复杂,入行的前端开发和设计都很少,随着技术门槛的降低,会有更多愿意尝鲜的人进入,当这些人做出产品后,又会正向吸引其他比较保守的人。所以 Web3D 会朝着平台化的方向发展,在平台上积累我们的最佳实践和经验素材。


相比于传统游戏行业,Web 上的 3D 一直显得“没有技术含量”,受困于手机的性能和网络的限制,Web3D 无法渲染很复杂的模型,模型的三角面数量是决定精致程度的关键因素,也是渲染性能的核心指标,可以从数据看到,这几年来,场景的三角面数量有增加,但不排除是因为手机换代升级导致渲染性能提升。



客户端游戏里,一个人物模型可能就有上万的三角面,而我们最大的场景全部面数也才不到 3 万。全局光照、后处理、蒙皮动画等常见的游戏渲染技术,在我们的应用中都还没有用到。渲染技术在这几年并不是 Web3D 发展的决定因素,模式创新和技术组合才是强劲的助推器。无论是 Unity 还是 AE,都是非常昂贵的专业软件,而 Web 编辑器只要一个链接就可以进行协作和分享,将能产生更大的生态。


但 Web3D 也不是高枕无忧,随着 5G 技术发展,视频加载速度会非常快,简单的实时渲染会被视频直接替代,游戏引擎 Unreal 已经开始探索 Pixel Streaming 技术,通过服务器渲染,将画面传回网页中,只要传输够快,手机的性能就不是问题。同时随着 WebAssembly 技术的发展,Native 代码可以直接被编译到 Web 运行,那么会有越来越多的跨平台互动游戏产生,从而解决游戏开发的成本问题。


也许,未来的战争会成为编辑器平台的战争,如果编辑器产物(视频,游戏,JSON)可以相互替代的话,决定胜负的,就是平台赋能的力量了。


作为成年人,面包和爱情都想要,良好的体验宛若初恋,但除了营销,哪里还有下一块蛋糕?


本文转载自公众号支付宝技术(ID:Ant-Techfin)。


原文链接


https://mp.weixin.qq.com/s?__biz=MzI0Nzc3MTQyMw==&mid=2247491652&idx=1&sn=f9d651872ca2323647adf0337051c25d&chksm=e9a85834dedfd1229b87911b408fde606db23b16f512fcddab9f7264f3e9fbe5d762c98e7d14&scene=27#wechat_redirect


2020 年 7 月 29 日 10:001972

评论 1 条评论

发布
用户头像
加油
2020 年 07 月 29 日 13:50
回复
没有更多评论了
发现更多内容

OAuth 2.0

陈皮

对微服务架构的理解

朱月俊

来自面试官的技术面试题

xcbeyond

Java 数据库 自我介绍 面试经验

对中台思维的思考

朱月俊

架构师训练营Week10作业

Frank Zeng

Eureka常见问题汇总及注意事项

xcbeyond

Java SpringCloud Eureka 服务注册与发现 常见问题

面试官:您能说说序列化和反序列化吗?是怎么实现的?什么场景下需要它?

xcbeyond

Java 面试题 序列化

【架构师训练营】第 10 周作业

花生无翼

week10 作业

雪涛公子

week10 总结

雪涛公子

【架构师训练营】第 10 周总结

花生无翼

架构师训练营 Week 10 作业

Wancho

架构师训练营 Week 10 总结

Wancho

week 10作业

a晖

微服务&DDD&中台

dony.zhang

中台 微服务 DDD

hive拉链表优化·百亿量级数据支持准实时更新

誓约·追光者

hive 实时数仓 海量数据库的设计与实践

微服务与DDD

走过路过飞过

架构训练营第十周感悟

张锐

week 10 总结

a晖

Dubbo微服务调用时序图及微服务架构个人见解

潜默闻雨

架构师训练营第十周作业

吴吴

极客大学架构师训练营 --第10周

李朋

【架构师训练营 - week10 -1】作业

早睡早起

微服务&DDD

极客大学架构师训练营

架构师第十周

Tulane

架构师课程第十周总结

dongge

练习 10-1

闷骚程序员

Dubbo微服务调用过程时序图

2流程序员

堆栈神奇应用之CXO让我做一个计算器!!

架构师修行之路

数据结构 堆栈

架构师训练营Week10学习总结

Frank Zeng

芯片破壁者(十二.上):“大头儿子”模式下的韩国半导体

脑极体

支付宝App 3D动画和小游戏背后的故事-InfoQ