从《淘特斗地主》说起,前端如何做 h5 游戏的游戏体验

本文涉及的产品
图像搜索,7款服务类型 1个月
简介: 从《淘特斗地主》说起,前端如何做 h5 游戏的游戏体验

图片.png


游戏是一个比标准h5页面更要追求体验的一种应用类型。因为游戏的特性通常需要用户花更多的心思沉浸在其中,能够充分的进入游戏世界中才能够更好的感受其中的乐趣。


游戏体验的组成


游戏体验是一个庞大、复杂的话题,目前没有权威的分门别类的说法,比如做到哪些点就可以称之为体验好或者是一个好的游戏。游戏体验它即可以是玩法设计,也可以是视觉效果,还可以是算法智能等,方方面面都可以给游戏体验带来正向或者负向的影响。

而我们作为前端,主要从前端的角度来讨论下,作为前端我们可以如何优化游戏的体验。

图片.png

游戏项目中的前端角色定位

如上图,每个点都有大量可以去做的事情。然而游戏涉及的方面如此庞大,而我们的精力却是有限的。我们可以选择其中某一点或者某几点深入其中,这样会做出技术深度,而代价则是游戏中的其他方面难以兼顾到,未必有利于游戏整体的体验


就像做加载性能,从 5s -> 2s 的方案并不算难,但是从 2s - > 1s 那真是难度高出好几个维度,也需要投入的大量的资源、时间。但是最终对项目整体的价值,相对于付出真的值得吗?用户真的会因为这个游戏加载特别快,而喜欢这个游戏吗?

酒舟小比喻1:"《欢乐斗地主》和《淘特斗地主》你喜欢哪个呀" “《淘特斗地主》” “为什么呀?” “因为它加载速度太快了,加载快的游戏最好玩了”

酒舟小比喻2: “我们作为业界领先的游戏工作室,计划打造一款迪士尼级别的手游,这个游戏最大的优点是加载速度快”

酒舟小比喻3: “我们厨师团队今年 S1 的 OKR 是做出的菜不难吃”



“如何把 h5 做出 native 的感觉”


"I have known orcs who have been as honorable as the most noble of knights and humans who have been as vile as the most ruthless of Scourge."

"种族不能代表荣耀,我见过最高尚的兽人,也见过最卑劣的人类" --- 提里奥·弗丁

我不认可native的体验始终高于h5,这个问题我理解是在问“如何把h5游戏的品质做好,让它比起网页更像游戏。

所以其实它包含了2个点:

  1. 游戏本身品质高
  2. 去除 h5 的(负面)感觉


自身品质


1、帧率要稳定60帧


帧率一方面意味着画面流畅,另一方面意味着操作跟手,也就是影响输入延迟的问题。

举个例子,如果当前游戏是 30 帧模式,也就意味着每 33ms 更新一次画面。每一帧的渲染都是先计算再上屏。包括操作输入,也是要加入这个 33ms 的循环。因此玩家操作的最悲观的情况下,需要 33ms 才会响应并被用户看到。

而 60 帧模式大约 16ms 更新一次画面,响应时长也就是 16ms。从而玩家能够更快的看到自己的操作反馈,也就是更跟手。

比如电竞显示器,他们是 144hz 甚至 240hz 的刷新率。在高帧率低延迟下,能够更快的看到对方角色的动作意图,更及时的输入操作,更及时的响应操作。实际上影响输入延迟的不止是是刷新率这一个点,输入设备以及网络延迟等都会有影响。

受pc浏览器的限制,我们的 canvas(webgl)的刷新率上限就是 60 帧。如果未来用户普遍习惯高刷屏,而pc浏览器的 60 帧限制依然存在的话,那么这个将是 h5 游戏的致命伤。

题外话:为了能更好的让自己的游戏在不同帧率的设备上渲染。需要尽可能的把动画播放与时间关联,而非帧数关联。否则在高帧率下并不会让你的游戏更流畅,而是播放速度变快。

2、优质素材

在优质素材这一分类下,实际上还要再继续做细分,分别是:

  • 核心素质
  • 通用素质
  • 性能素质


2.1 核心素质

风格统一,符合主题设定

游戏不能没有统一的主题设定,就像公司不能缺少使命愿景价值观,就像西方不能失去耶路撒冷。

主题设定应该是在立项之初就确定的核心概念,它会影响整个游戏的方方面面。它能够提升玩家的沉浸感,更好的进入这个游戏世界。

举个例子,《淘特斗地主》是一个多人在线的纸牌游戏,基于最初的沟通,最终 ISV 输出一套武侠风格的视觉素材,那么基于武侠这一设定:

  • 文案自然要符合设定。(比如 loading 文案要代入武侠世界)
  • UI 细节,需要尽可能避免出现现代化产物(比如大奖赛的门票选择了令牌的形象而非纸票)
  • 交互动画效果应该使用干净利落一点的风格(比如使用了大量的先快后慢类似 ease-out 的动画曲线)
  • 音乐&音效需要注意一下,不能像欢乐斗地主那样热闹(没见过喜气洋洋的大侠)
  • 等等等等

主题设定能够让我们在面临选择时,找到更符合整体价值的选项。那么反之再想一下,如果一个游戏没有统一风格,那么体验会是怎样?

图片.png图片.png

来源自google图片搜索

(关公画的很好,自行车画的也很好,放在一起就很可爱;异形画的很好,中国水墨风格很好,放在一起就很可爱。)

图片.png

(都是高级品质,但是主题冲突于主题统一带来的整体感受不同,来源见参考文档)

图片.png

2.gif

(风格统一的把游戏战斗+界面UI都保持在高水准的游戏,来源自google图片搜索)

审美在线

主题风格确认之后,内在的品质还是有差别的。就拿文案举例,有个问题很有趣:为什么霜之哀伤听起来很酷,火之高兴听起来很逗?- 知乎

大概是说文案也是分层的,“火之高兴”对应的是“冰之难过”,同样不酷。同等级的文案可以是“炎之欢愉”。

文案有差别,素材也有。同样是武侠风格的人物素材,有的就很精致,有的就感觉回到了21世纪初。这方面的内部原因我也没办法给出相对专业的说法,就像我们不是专业的厨师,不了解每盘菜是如何做出来的,但是依然能吃出哪家饭店的菜更好吃。

而这个"审美在线"对游戏品质的价值,可能不亚于厨师对于饭店的价值。同样是卡通风格,有的作品是《喜羊羊》,有的作品是《疯狂动物城》。在做出高品质游戏这件事上,专业的视觉资源投入必不可少

图片.png图片.pngimage.gif

来源自google图片搜索

互动行为合理

游戏是一种富交互的艺术载体,它不同于小说、画、电影,玩家会与游戏进行大量的互动。因此在游戏中,会有大量的交互(动画)效果与玩家的操作息息相关,好的游戏往往会让玩家长时间沉浸其中,在长时间的频繁交互中,动画效果需要经得起考验&推敲。

我们都是生活在现实生活中的人,对于游戏的理解,往往也会从过往的经历进行尝试学习带入。比如看到一个按钮就应该可以点;看到锁之后就会去找钥匙。也就是说我们需要让游戏世界的互动方式更加的符合直觉,从而可以降低玩家的上手门槛,更加增强代入感。

反之如果看到不符合直觉的互动效果,就会很出戏,会一下子把玩家的精神从游戏世界拉回现实世界,十分影响整体品质的高级感。

优秀的动画效果应该不止是合理,更是应该为游戏体验加分,让玩家从这个效果上感受到爽感、乐趣。

image.gif图片.png

image.gif来源自google图片搜索

2.2 通用素质

多屏幕尺寸兼容

这个问题的本质在于互联网产品的设计师与游戏的视觉设计师专注的方向是不同的。互联网产品的h5页面通常都是向下滚动的,兼容性问题无非就是“是否出现在首屏”。而游戏通常都是全屏且没有滚动条的。这就意味着游戏需要在不同尺寸、不同比例的显示设备下都能完美地展示。需要素材乃至设计本身就考虑到兼容问题。除了尺寸需要考虑兼容,素材的位置也同样需要考虑,甚至是页面元素的布局方案都需要考虑多套来适配不同尺寸的屏幕。要做到完美的兼容,仅靠前端是不够的,如果前端“上游”就不完美,下游就更难处理了。

我们的设计师使用的标准稿尺寸是 750*1624 ,即 iPhone X 的尺寸,基本上是长宽比最极端的比例,这就容易出现“短屏手机展示不全”的情况。在我们当前的环境下难以根治这个问题,只能在视觉评审时始终保持对设备尺寸兼容的思考,并及时向设计师反馈。

清晰度高

目前手机上最高的大概是3x的屏幕,而我们的视觉稿都是基于2x的标准画的。如果正常导出会导致在部分高端机上看起来不够清晰,但是这是有办法解决的,只要导出多份素材,针对不同设备做判断加载即可。比较麻烦的是我们目前的psd(意味着非矢量素材)底稿是2x的,这部分要做高清适配成本就比较高了,需要在前期对接时,就确认好需要3x的底稿。

可扩展性强

好的素材是可以多次复用的,不仅风格统一,而且开发复用成本低,性能更好。

比如按钮,最好是可以分成按钮的底图和文字,这样多个地方的按钮都可以保持一致,甚至按钮的尺寸也是标准的。

比如各种道具icon,都充分的做好标准留白,统一一份素材。在游戏中各个地方使用、甚至接口投放时,有效减少联调成本。

2.3 性能素质

体积合理

原始素材为了能够方便修改,保存了很多过程信息,往往体积比较大。有些素材哪怕是导出之后,体积依然过大。

h5 的特点之一是“无需下载,即来即用”,但是这对游戏是比较致命的要求。游戏中往往会使用到大量的素材,中型游戏大概有成百上千个。而且游戏中往往对这些素材都会有更精密的使用要求,很多逻辑都是需要素材加载完成之后才能触发,依赖性强。

实际上作为一个合格的前端,都知道可以做一些优化,比如压缩、雪碧图、按需加载、甚至离线包等。但这些都是属于下游的方案了,本质上如果能在素材本身上做优化,那么对加载性能,甚至运行性能都是会有极大的提升的。

比如有些动画素材是使用了“帧动画”,也就是动画的每个状态都是一张图片,播放动画只是按时间间隔切换图片,这样素材必然占体积呀。而好一些的方案则是“骨骼动画”,它加载的素材都是一个个的小图片,然后配合一个动画描述文件,让这些小图片动起来。这样的体积自然就会小很多,内存占用也会更低。

当然优化体积的方式有很多,比如通过骨骼复用,替换素材的方式来制作多种人物皮肤;移除可视范围之外的素材等等形式。这些优化都需要设计师或者技术美术参与其中,根据具体的内容做定制的优化。素材的体积往往是内存占用量的大头,如果素材无法优化,那么内存就难以优化

动画节点合理

上面提到“骨骼动画”是一种更好动画素材方案,但其内部的实现也同样重要。

如果动画的节点数量多、动画描述冗余,那么依然也不是一个优质的动画素材。复杂的描述同样意味着描述文件体积大,动画细节多,对加载时长和运行效率同样不友好。拿《淘特斗地主》举例,其中的某个人物素材 图片压缩后 93KB,而骨骼动画描述文件压缩后 364KB。单个人物素材的体积已经大于游戏逻辑代码本身了,而像这样的人物最多需要加载20个。

正是因为游戏中需要的素材数量多,对于素材的优化才显得格外重要。游戏的品质往往是多个方面的综合体现,素材质量是游戏品质中的关键,因此对于素材会有各个方面的高要求。非专业的游戏美术设计师的产出大多是不面向线上用户的,比如给前端看到视觉稿,然后前端再根据看到的画面,通过一个个div重新画出来。而游戏中的需要大量的素材是设计师直接产出的。因此在非专业游戏公司的情况下,设计师往往缺少对素材性能优化的意识,这也是我们需要额外关注并持续推进优化的点。


3、交互细节

游戏区分于其他的艺术形式的一大特点就是可交互,让用户有参与感。我们需要正向鼓励用户进行操作,相对而言更多的交互能够让用户更投入,更能从中获得乐趣。

交互反馈

我们需要尽可能全面的捕捉用户的输入行为,并且给出明显的反馈

比如最常见的点击,在点击时,我们应该要给到点击的反馈,至少应包括 被点击元素的动画效果、播放音效。如果条件允许,甚至还可以做轻微的震动。

另外手机上的陀螺仪其实是很好的输入方式,兼容性很好。但是实际上利用它的项目并不多,稍微用一下,就会给人带来眼前一亮的效果。

图片.png

(点击都有动画效果+音效)

图片.png

(陀螺仪效果)


画面变化

游戏画面的变化需要是连续的,这样效果看起来更舒服,不应该出现“闪入闪出”的情况。

要解决并不难,只要这几个点做好了即可:

  • 在屏幕内大场景发生变化时,应优先考虑做个转场动画。
  • 如果不适合做转场动画,那么至少要做到场景变化是渐隐渐显的。
  • 屏幕中的抽屉、弹窗、toast等都需要完整的入场,避免突然出现。
  • 离场同理,最差情况也要做渐隐出场。

图片.png

图片.png

(能够做转场的做了转场;无法做转场的也加了渐变消失)

image.gif

图片.png图片.png

image.gif

(局部模块、toast等都要有入场、离场的效果,保持画面连贯)


去 h5 感觉


1、避免 h5 的典型问题

无点击反馈

h5的开发与发布过于便捷,以至于大家逐渐把体验细节都忽略了,导致h5几乎不做点击反馈效果。

而点击是用户交互的高频操作,把这个做好之后,在交互体验的提升会比较明显,而且与通常的h5做出了明显的区分。

图片.png

2、与 h5 的特征做出一些区分

模块懒加载

h5页面内容大都比较简单,追求短平快,页面停留时长也不高,导致加载时长在用户访问的整个生命周期相对较高。因此这部分的优化方案,最终也都绕不开懒加载,在体验上很容易导致用户在使用过程中,频繁的出现模块加载状态。

而游戏与 h5 有所不同,内容相对更精致,用户停留时长也远大于常见的h5。因此首次加载时长相对于整个使用周期而言,占比没那么大。反而是在使用期间如果频繁出现加载样式对用户的影响更大。而且这种形式更容易让用户跟h5的感觉联系在一起。

区分toast样式

我们的h5都会使用标准toast样式。

而标准 toast 样式过于经典(审美疲劳),以至于一看到它就会有h5的感觉,一下子就联想到h5的各种体验。实际上 toast 这种交互形式是没问题的,但是在游戏场景内应该更精致一些,需要把这种高频的提示信息与游戏风格更贴合一些。

图片.png

图片.png

(标准toast功能上好用,但是效果审美疲劳,会来带h5特征感觉)

减少零碎的loading

有些h5会在请求发起时出现一个loading样式,结束之后再去掉这个loading,而游戏中需要尽可能避免这些零碎的loading。根本的解决方案是优化接口性能,但是大部分情况我们也同样需要加一些动画效果,在播动画效果时做数据情况并渲染,减少loading的出现情况。

图片.png

(局部loading较多)

3、做突破 h5 常规体验的点

音效

h5页面通常都没有做音乐音效。我们游戏加上音效除了增强体验之外,也跟“常规h5”拉开了一些辨识度

陀螺仪

大量端游都会使用陀螺仪在辅助增强操作手感,而h5获取陀螺仪数据其实很简单,而且兼容性很好。

震动

h5通常不太会有震动的效果,而震动能够显著增强操作手感,增加游戏的代入感。不过目前h5的震动API能力有限,要做出好的效果需要跟native进一步加强合作。


总结



我总是在想,我们的职业是个前端。前端是行业对这个岗位职责的需求的统一称呼,但是我们对工作产出的追求,真的应该完全在名为“前端”的圆圈中吗?

前端这个岗位是逐渐演化细分出来的,对前端的要求越来越明确、标准。但是这只是底线,不是上限,也不是唯一。在名为“前端”的圆圈中做到极致当然很厉害,能够把自己的职责之内的事情做好是可靠的,然而前端并不是实际问题的全集。

实际产生的问题不会天然的被定义到某个圈子中,甚至还有很多问题没有被看到,这并不意味着不存在。当专注于前端本身时,视野盲区会变得更大。也许是受各种规章制度的正面或者负面的潜在作用,鼓励人们去把某些点的问题钻研的更深,我理解这种制度是建立在成熟领域,团队分工成熟的情况下的。

然而现在基于前端的衡量标准在木舟上刻下的痕迹,当行驶到名为“h5游戏”的岛屿时,还能找到掉落的剑吗?在走进一个巨大未知的丛林时,我认为此时此刻抬起头承认我们无法看清但依然前进才是勇敢,我们只能谨慎而乐观的去解决一个个问题,无法在所有的点上都做到满分哪怕是及格,但现阶段也不应该止步不前,只着眼于某一个点。也许未来某一天终于绘制完成了这座岛屿的地图,此时的“前端”们可以在任何喜欢的、擅长的点上去努力,而这,正是我们如今背负的使命。


参考文档

游戏画面如何去减少廉价感:https://gameinstitute.qq.com/community/detail/133458

相关文章
|
6月前
|
移动开发 前端开发 Android开发
mPaaS 常见问题之移动开发平台 mpaas的H5 前端 Kylin 框架引入vant后包特别大如何解决
mPaaS(移动平台即服务,Mobile Platform as a Service)是阿里巴巴集团提供的一套移动开发解决方案,它包含了一系列移动开发、测试、监控和运营的工具和服务。以下是mPaaS常见问题的汇总,旨在帮助开发者和企业用户解决在使用mPaaS产品过程中遇到的各种挑战
242 0
|
6月前
|
前端开发
前端毕业设计|基于Vue+Nodejs实现游戏资讯平台(二)
前端毕业设计|基于Vue+Nodejs实现游戏资讯平台
|
存储 前端开发 JavaScript
前端实现俄罗斯方块游戏(内含源码)
前端实现俄罗斯方块游戏(内含源码)
197 2
|
6月前
|
人工智能 JavaScript 前端开发
【前端|JS实战第1篇】使用JS来实现属于自己的贪吃蛇游戏!
【前端|JS实战第1篇】使用JS来实现属于自己的贪吃蛇游戏!
136 0
|
移动开发 前端开发
前端(十八):移动端H5调用摄像头拍照旋转解决方案
移动端H5调用摄像头拍照旋转解决方案
342 0
|
13天前
|
移动开发 前端开发 JavaScript
前端实训,刚入门,我用原生技术(H5、C3、JS、JQ)手写【网易游戏】页面特效
于辰在大学期间带领团队参考网易游戏官网的部分游戏页面,开发了一系列前端实训作品。项目包括首页、2021校园招聘页面和明日之后游戏页面,涉及多种特效实现,如动态图片切换和人物聚合效果。作品源码已上传至CSDN,视频效果可在CSDN预览。
20 0
前端实训,刚入门,我用原生技术(H5、C3、JS、JQ)手写【网易游戏】页面特效
|
6月前
|
存储 移动开发 前端开发
【Web 前端】H5新特性有哪些?
【4月更文挑战第22天】【Web 前端】H5新特性有哪些?
|
6月前
|
移动开发 前端开发 Windows
前端H5怎么简单的实现复制text内容的操作
前端H5怎么简单的实现复制text内容的操作
51 0
前端H5怎么简单的实现复制text内容的操作
|
6月前
|
前端开发 JavaScript 关系型数据库
前端毕业设计|基于Vue+Nodejs实现游戏资讯平台
前端毕业设计|基于Vue+Nodejs实现游戏资讯平台
|
6月前
|
前端开发 JavaScript 关系型数据库
前端毕业设计|基于Vue+Nodejs实现游戏资讯平台(一)
前端毕业设计|基于Vue+Nodejs实现游戏资讯平台