整合营销服务商

电脑端+手机端+微信端=数据同步管理

免费咨询热线:

前沿穿越!聊聊HTML5小游戏的制作技巧及经验

者按:今天腾讯的同学从一款HTML5小游戏《植物大战僵尸》说起,分享一些动画实现的知识(动画可控性、如何兼容不同分辨率、如何识别平板手机等),附上众多实现小技巧,来收 >>>

hello~大家好,我是黑米! O(≧▽≦)O

今天我来跟大家分享一些动画实现的相关知识,希望大家能够支持(鞠躬……

我很喜欢很喜欢看动画片,一直有做出好看动画片的梦想……所以最近做了不少动画效果来玩儿,也为自己以后可以做出伟大的动画片打好基础!

Web端动画表现有不少办法,我列一些常见的,然后再说说在实现上的一些小技巧。

进入正题,我要开始认真了!(严肃脸…… ( ̄ー ̄〃)

嗯……首先大家先来跟我一起玩个游戏,请快速的掏出手机,打开微信,“扫一扫”下面的二维码,通关最多的前三名同学……什么奖品都没有!!

相信大家都认真的玩儿了游戏吧?我们这里有一位万技师一直玩到50多关,最后体力透支,主动“自杀”,否则相信他能玩出过百关,怎么做到的?有彩蛋,不知道你有没有发现,哈哈……

嗯……回归正题,这个小游戏当中用到了大量的动画效果,主要是逐帧动画,今天的第一部分,就先来讲讲动画这个事情。

我先来列一排动画效果给大家看……

图1

图2

图3

刚才上面列的动画效果分别是 GIF 动画、Canvas + CSS 动画、逐帧动画。其实说起常见的动画实现,除了 GIF(APNG)、Flash 和 Canvas 外,其他基本都是 CSS 动画,即使是通过 JS 实现,大部分情况下只是通过 JS 来修改 CSS 属性而已。

而 GIF 动画仅支持 8 位色,颜色偏少,虽然 APNG 解决了这个问题,但是存在兼容问题,同时它和 GIF 一样,没有可控性,所以它们一般很少用于动画制作流程中,仅用来展示。相对来说 CSS 动画和 Canvas 动画的可控性更易于制作页面效果动画以及页面游戏。

一、可控性

刚才说了“可控性”,那到底什么是可控性?我们先来看一个动画效果的大概示意图!

一段动画一般由“开始 – 过渡 – 结束”来组成,GIF 动画是无法通过代码来获取到这些状态的,但 CSS 动画可以!

我这里的做法是把每一组图片合成一张“雪碧图”,然后利用 CSS 的 animation 做逐帧动画,写好函数通过不同的参数来调用不同的角色。

Role(dirt)

Role(rises)

Role(cast)

Role(broken)

Role(death)

合成“雪碧图”的逐帧动画

像上面 图2 和 图3 的例子,都是由好几个动画衔接完成,那么它们之间如何衔接呢?有的同学可能会说用setTimeout/setInterval/requestAnimationFrame 一类的延迟功能来做衔接,但是这样会有个问题就是在性能不同的机器上,会有误差,而且维护繁琐。所以,我们需要一个触发形式的衔接方式,即上一个动画完成了,通知下一个动画开始。

CSS 动画实现一般使用 animation 和 transition 来搭配其他属性使元素产生不同变化,从而达到动画效果。

而这两个属性是可以通过 JS 中的事件来监听到“开始”和“结束”状态。具体事件如下:

animationstart:

  • animationstart 事件在 CSS animation 开始时被触发。如果有 animation-delay ,事件将在延迟时效过期之后立即触发。 如果延迟时效是负值,事件触发时将带有等于延迟时效绝对值的 elapsedTime 。

animationend:

  • animationstart 事件在 CSS animation 完成时被触发。

transionstart:

  • transionstart 事件在 CSS transition 过渡开始时被触发。

transitionend:

  • transitionend 事件会在 CSS transition 结束后触发。当 transition 完成前移除 transition 时,比如移除 CSS 的 transition-property 属性,事件将不会被触发。

这些事件在不同浏览器下需要加前缀什么的大家应该都懂得,至于 transionstart,目前仅在 IE10+ 上有效……

通过事件监听的方式衔接,并利用分层的形式叠加多重动画,最终实现效果:

现在,开始状态和结束状态获取到了,那中间的过渡状态要怎么办呢?比如说我要动画执行到 30% 的时候,执行一个回调,亲一口姐姐,肿么办??(?ε??)

虽然没有直接的事件可以监听到过渡状态,而且这个需求中也暂时用不到这个过渡状态监听,但是我们也可以稍微做点事情的。(不抛弃,不放弃!)

怎么做呢?比如一个动画的执行时间是10s,那么在动画开始的时候,跑一个 setInterval 来不断的记录过渡状态,然后用当前跑到的值和总时长就能算出具体的进度了。这里要稍微注意一下,因为动画播放控制(animation-play-state)属性的存在,在暂停和重新播放时,需要对计时器稍微进行一下处理,否则得出的进度值会有错误。

这不是一个很完美的办法,因为在不同的性能下,计时器的值可能会有微弱误差,但如果你要求并不是很精确,还是可以尝试这个办法的。

二、如何 Perfect 的兼容各分辨率?

兼容各式屏幕一般有这样的办法:

还有这样的办法:

最后,还有传说中的弹性自适应布局:∑(O_O;)

但是,在这个需求上,统统不适用!为什么?

viewport 和 media Query 在 iOS 和 Android 上识别的单位不同,在 iOS 上识别的是“设备像素”,而在 Android 上识别的是“CSS像素”,这两个词后面会讲到。

因为这个页面游戏上有大量的元素用到绝对定位,如果使用弹性自适应布局的话,会进行大量的布局计算,而且还不一定精准。

所以,这里的解决办法是通过 discrimina.appVersion 获取 UA 信息中的关键字来判断不同的系统,针对不同的系统做不同的解决方案,Android 对最外层 div 进行 zoom 缩放,而 iOS 使用 viewport 缩放:

三、如何 Perfect 的识别平板和手机?

各设备上的布局问题解决了,但是如果设备屏幕比较大,你的图片是糊的,怎么办?

也许有的同学会举手说去检测 CSS 分辨率,但是这里就有问题了……有的老旧平板可能屏幕尺寸大,但 CSS 分辨率小;而有的新手机屏幕尺寸不如平板,但是 CSS 分辨率挺高,咋办?

回归现实,我们分辨平板和手机是以什么来分辨的?屏幕尺寸,对吧?那么我们这里也同样,只要想办法计算出访问者的屏幕尺寸即可,就是平常我们说的几寸屏…几寸屏的那个尺寸。

怎么获取那个尺寸呢?我们这里先来学习一些专业术语……

标红的“屏幕尺寸”是我们的目标,绿色的元素是我们后续会用到的东西,其中我们可以直接通过 JS 获取到的只有最后两项,即“设备像素”和“设备像素比”。

然后我们来看看“屏幕尺寸”的计算公示:

屏幕尺寸 = 屏幕对角线的CSS像素值/(设备像素比*PPI) = (√长²+宽²)/(设备像素比*PPI)

屏幕是矩形,矩形对角线的计算公示就是上方右侧那个公示;现在我们来看一下这个公示中用到的元素如何获得……

现在,万事俱备,就差 PPI,这东西虽然没有直接获取方式,但是我查了一下资料,还是得到了一些数据。

注意,这里给的是基准值,我们常说的 iPhone 多少多少 PPI,那个值是用基准值乘以设备像素比得出来的。由于 Android 手机厂商众多,并没有统一的标准,这里的 160 只是约等值,所以 Android 屏幕尺寸结果会有误差,但是基本也够用了。

现在公式中的所有要素都已经齐备了,具体在代码中实现,就是下面这样子:

得出的值,单位是“英寸”,我们根据这个值就可以考虑针对平板和手机等不同屏幕尺寸做不同的事情了,比如最基本的,换一套高清图……

四、音频之殇 (T^T)

这个小游戏中一共用到3类音频,共6个音频,且存在同时播放问题,iOS 下没问题,但是 Android 下会出现后播放的音频打断之前播放音频的问题。

我测试了一些设备,发现无迹可寻,有的老设备支持,新设备反而不支持。我的解决办法是 Android 用户仅播放关键音频,比如这个游戏当中就是背景音乐,其他的就不放了。因为没办法判断设备到底是否支持多音频同时播放……

五、形变+位移+旋转=?

刚才讲了“活捉兵马俑”那个游戏的一些经验技巧,现在讲讲几个 CSS 小属性搭配起来可以做的东西。

不可否认,做动画 Flash 是走在前面的,它的很多表现形式都值得我们借鉴,比如说这位豌豆射手。

这个豌豆的需求是一个双屏互动需求,PC 端使用 Flash 实现,移动端没办法用 Flash,所以动态效果我就照着临摹了下来。

具体做法是把豌豆拆成不同的小组件,然后再利用 animation、translate、scale、rotate,拼合出一个完整的动态效果,并没有多少技术含量,但几种属性的搭配使用,让这颗豌豆看起来还是挺赞的!

等于

所以,很多属性稍微搭配一下,其实就可以做出很好玩的东西。哈哈……

六、其他一些小细节……

看了这么久的文章,你可能也累了,下面一些小细节快速过一下……

1)不要放弃 PC 访问的用户,如果没有很好的引导,他们会直接关闭网页的。

2)如果是横屏没法用的页面,给予良好的横屏提示。

3)为用户添加桌面图标,方便用户启动页面。

好的,今天的分享基本就这样告一段落,欲知后事儿如何,请听下回分解!

原文地址:tgideas

优秀网页设计公众微信号:youshege碎片时间学习利器!

onstruct 2是一款能够帮助你制作HTML5电脑游戏的应用程序,它将为你带来一个清晰直观、支持“拖拽”操作的开发环境。程序中的大部分工具都可通过图形界面来使用,完全无需写下任何代码,即使你没有任何编程经验也能拥有自己的游戏哦。

Construct 2

Construct 2旨在创建2D游戏,内置的各种资源让游戏制作更加轻松:物理引擎使游戏中的物体支持地心引力,当然还有元件、背景、音效等各种游戏所需的图形与声音。另外,将媒体文件导入程序也很简单。

Construct 2

Construct 2

简单、直观的视觉环境是Construct 2所信奉的哲理之一。当你拖拽元件至某个位置时,程序会使该元件与其他物体互动。例如:我的人物->撞墙->停止。很容易理解吧!

Construct 2

Construct 2

免费版允许你将作品导出至HTML5,在任何平台的任何浏览器中运行,但这并不能帮你挣到一分钱。专业付费版则增加了一个导出工具,使用这个工具,你的游戏不仅能在安卓或iOS设备中运行,甚至,你还能创建一个可执行文件,在电脑中运行游戏。

Construct 2

毫无疑问,对于任何想要制作游戏,却不懂编程的用户来说,Construct 2都是一款不可多得的工具。简单好用的工具搭配大量素材,绝对是你创建游戏的好选择。

下载地址:http://www.itbang.top/forum.php?mod=viewthread&tid=1222&extra=

/ Luiu

最近跟的一款项目是HTML5手游,在这个项目中遇到并解决了诸多问题,也学习到了很多项目开发过程中需要注意的事情。这个项目自立项到现在已经过了5个多月,如今项目研发已经过了早期的忙乱阶段,于是借此机会梳理下思绪,为了能够更好的完成以后的工作。如果能给想进入HTML5这个领域的新团队一些参考,那也是一件极好的事情。

这款项目是我们团队接到的第一款HTML5类型的游戏合约,在此前团队一致在致力于传统回合制手游研发。因此团队可以说在这个领域几乎是从零开始(当然一开始的时候我们不这么觉得),所以在研发进行到中期的时候遇到了很多影响效率的问题。

其中影响最大的问题之一就是——界面适配

HTML5手游这个品类说白了就是把页游装进一个壳里,本质上他还是一个页游,拥有很多页游的特性。它是在页游框架的基础上,将UE对移动设备做了优化。因此该类游戏在后期将会根据渠道需求发行多个版本,包括直接在网页运行(电脑网页和手机网页)、在手机端运行、在平板电脑设备上运行。这样就会带来一个严重的问题——兼容性问题。由于HTML5跨平台的特性,很容易产生兼容问题。最明显的一个就是界面适配问题,最基本的要做到UI在不同长宽比的屏幕下均能完全展示,在这个基础上再考虑对主流长宽比的屏幕进行特殊处理,优化用户体验。

一、适配方案

界面适配的方案一:约束比例缩放(主流方案)

方案描述:该是保持界面中元素的相对位置不变,在不同长宽比的屏幕中进行整体缩放。

这种方案会将界面分为上中下3个区域,将中间的主要区域视作一个窗口根据屏幕比例进行缩放。在缩放的过程中保证窗口长宽比不变,保持长或者宽任意一个维度占满屏幕就可,不强求整体铺满屏幕。

方案优势:处理简单,且最终效果还可以。可以保证UI在不同长宽比的屏幕下均能完全展示,并且UI布局不变。

最终效果如图:

图中黑色部分为空白区域,虽然对界面的美观有一定影响,但是影响不大。如果把中间的区域设计为窗口的样式,会使界面看起来更自然。

界面适配方案二:全屏铺满

方案描述:该方案同样要将界面分为上中下3个区域,只是对中间那块主要区域采用了不同的处理方式。这种方案会要求中间区域底板铺满屏幕,所有处于该底板上的元素坐标需要根据界面的长宽比进行计算,并且界面中的列表,底框等元素的大小也要根据屏幕的长宽比进行计算。

方案优势:该方案可以解决方案一种空白区域的问题,在移动设备上显示更加美观。

该方案的最终效果如图:

这个方案实现较方案一来说更加复杂,并且最终效果不好把控。容易造成不同比例屏幕下UI出现重叠,超出边界等问题。如果处理不好,最终效果反而不如方案一。

从目前市面上的HTML5游戏来看,基本采用方案一就可满足当前用户需求。采用方案二会增加项目研发时长,并且增加人力成本。

二、元素布局方式

我们这个项目使用的是白鹭引擎,在该引擎的UI编辑器中有个约束坐标的功能。使用该功能,可以将元素的坐标相对屏幕四边或者中心进行约束,确保缩放后界面布局随之改变。建议界面中的元素更多的采用约束的形式,而不是绝对坐标。

白鹭引擎中的约束功能:

为什么建议使用约束的形式呢?这是因为约束的方案更有利于保证界面中元素的边距,居中,四边对齐等布局。这样当用户在两个相似界面之间切换时,相同的元素位置也相同。不会出现切换时由于相同元素坐标的微小差异造成的晃动感。并且该方案更方便约定团队成员在拼界面时的规范,只需要约定相同元素的边距,元素互相之间的间距等。再者,如果采用界面适配方案一时使用约束功能的话,后期若要改为方案二,也会更加方便一些。

三、UI标准

规定UI标准对于保证UI的最终效果十分重要。在项目开始之初,就需要设计好界面中的通用控件的样式和规格,包括通用按钮、列表、标签等。并且不同功能标签的字体大小、色值、样式(加粗、描边)等也要有统一的标准。除了以上这些控件的规格和样式,还需要规定游戏中各种弹窗的样式和规格,否则必然会出现弹框大小参差不齐,影响UI美观。

UI就是游戏的脸面,是给用户留下第一印象最直观的内容。因此UI中的各个细节必须保证统一美观,这样才能给用户留下好印象。