快到年终的时候做了一个以游戏形式展示的h5活动页,第一次尝试使用js写小游戏,很有趣的过程,很宝贵的经验。
效果图
直接上个效果的gif图,游戏的一小部分效果,录出来有点卡
结果页:
起因
产品妹子突然给我拉进来一个群,跟我们讲做了这么久的制作平台(用户制作手机主题的平台),我们是不是应该反馈给用户点什么东西,就像之前特别火的微信年终总结那样。总之就是要打动用户,要特别酷。说特别酷的时候她回头朝我微微一笑,微笑中带着一点点,嗯,杀意。
活动形式,展现方式,什么数据反正就是统统都没想好,整个过程中大家讨论的热火朝天。当时不知道我为啥脑子一热,跟她说了一句:“没事儿,搞吧,你能想出来我就给你做出来。”而我也因为这句话把自己置身于水深火热之中。。
讨论的结果就是大家的idea感觉都不是特别酷,又不好玩儿,干脆就做个游戏形式的吧!所有人都转头看向我,我想了想之前说的话,只吐出来一个字,“搞”。而内心中五味杂陈,“游戏?有意思啊?搞!没搞过啊?能搞定吗?搞!”。最终敲定,两周时间,游戏方式,展现用户在魔秀的点点滴滴。
准备工作
游戏的形式大概类似一个滑雪大冒险和赛车的结合,以赛车的形式进行伪3d效果的展现,滑雪大冒险的样式作为我们的主题,同时大家还给我们的游戏起了个酷炫的名字—-魔秀时光道。
游戏引擎
游戏的展现形式确定后,直觉告诉我,想要将游戏快速稳定的呈现,免去图片加载控制,动画控制之类的复杂处理,我需要一个JS游戏引擎。最终在Egret\Phaser\PixiJS中选定了PixiJS,虽然不像Egret一样有完善的中文文档,但是它提供了清晰易懂的examples可快速上手,没有复杂的生态,简单的几行代码就可以用js实现我想要以下几点功能:
容器渲染及背景描绘
我需要定制整个画布的大小和背景,我需要使用不同的容器来承接不同的内容,并且灵活控制每个容器的属性:
|
|
图片加载及动画处理
大家都知道,使用canvas进行图片绘制的时候,需要确定图片已经成功加载,而游戏中有着大量的图片资源需要去维护,PixiJS已经为我们提供此项服务:
|
|
同时,我们需要一个动画控制器,来控制各Sprite的运动和重绘,而不是生硬的对各项属性进行重新修改:
|
|
需要注意的是,我们会发现,此处的Sprite动画控制,相当于添加了运动的动画队列,并且实现了类似transformjs的效果,可直接对实例的属性进行操作。而我在写项目的时候官方的例子是通过统一animate函数进行操作,通过requestAnimationFrame进行帧动画控制,更推荐新的方式而不是如下:
|
|
事件处理
游戏最重要的部分相当于用户的交互了,也就是所谓的事件处理,为Sprite添加事件监听,很简单,如下所示:
|
|
设计图
设计图当然也是很重要的,决定了我们如何去实现这个游戏,当我拿到设计图的时候,他是长成这样的,我的内心是崩溃的。我能怎么样,我也很无奈呀~ 开搞吧!
实现思路
根据以上,PixiJS已经基本满足我们的需求,也就是说,工具准备和素材准备已经都完成了。在动手书写之前,我们需要把实现思路想好,才能保证书写过程的清晰,避免不必要的麻烦。
背景滑动效果实现
就像我们平时玩儿赛车游戏一样,我们感觉赛车在跑道上进行比赛,实际上赛车只进行左右移动而已,而运动的则是背景,如何规划好路线,让背景按照既定的场景去运动,并展现不同的视角,特意向央美的同胞咨询了下,他们是用一个叫“摄像机”的东西实现的。对于我们来说,不需要那么复杂的场景,只需让背景像前规律的“平移”,造成“树动我不动”的视觉效果,同时我们利用“透视”的原理,让背景以“近大远小”的方式进行变化,就会产生一种low low的立体效果。
关键词:透视 近大远小(偏移,大小,速度)
偏移路线
对于背景及物体的运动,大概路线规划如下:
确定视觉焦点后,我们只需随机生成物体出现的位置,计算出a,b相对固定,使其y进行相应速度的增加,x根据运动轨迹进行对应偏移,则可实现往近跑的效果。针对运动轨迹, 假设物体向下偏移距离为N,则对应水平针对中轴线的偏移为:
大小
同时,我们还需对物体进行近大远小的显示,这个比较简单,以焦点为0,页面最底端为1,进行对应比例放大即可:
|
|
而针对物体,则需要随机生成它的初始x坐标,并计算出其对于的路线进行运动,在运动过程中,进行碰撞检测,检测是否与人物进行相撞。
人物滑动实现
人物滑动的操作,用了最简单的实现方式:按钮。当用户点击不同方向时,让人物向对应方向进行偏移。同时,为了让人物滑动不僵硬,在左右滑动过程中,人也应该随着运动有对应角度的倾斜,就像我们平时玩儿滑雪拐弯时,会改变中心一样。思路如下:
- 点击按钮时,改变方向
- 运动时检测方向,若向左,则x减小,向右,则增加
- 向右(左)运动时,人物对应rotation也进行增加(减小)
- 松开手时,人物对应rotation慢慢恢复成0;
碰撞检测
由于人物有吃东西的环节(不然这还叫什么游戏呢),因此碰撞检测肯定是必须的啦。我们可以通过两种方式进行碰撞检测
- 人物检测碰撞物体,需实时遍历物体坐标列表,进行检测
- 每个物体自身进行碰撞检测,检测自身与人物位置的对应差
我很机智的选择了第二个,毕竟每个物体的位置都是实时变动的,而每次碰撞检测都进行一次循环的方法,太笨重啦。在这里我们设置碰撞检测的区域(宽高),在物体运动时,针对人物的x,y坐标,与自身的x,y坐标加减形成的四条边界进行比较即可,若进行碰撞,则进行对应的操作即可,如播放音频,得分+1等。
架构设计
思路理清楚之后,后面的路就很明朗啦。接下来我们就可以着手设计下如何实现这个东西了,很显然,游戏中我们拥有许许多多的“角色”,使用“面向对象”的方式再好不过了。大概的划分如下
- stage //舞台,进行基本场景渲染,游戏整体控制(开始,停止)等
- player //玩儿家,也就是对应的人物
- sprite //出现的物体,如蛋糕等,提供玩儿家吃。 包含碰撞检测等,会自己运动
- tree //因为tree自身会运动,所以每个tree为一个类
- score //进行分数控制及显示
- cfg.js //包含整体游戏配置
对象内部划分
每个对象包含以下几点属性及功能:
1. 对象配置
每个对象包含其内部自身基本配置,包括位置,边界,图片等。直观,便于调试
|
|
2. 其他方法
每个对象都包含其自身方法,如下所示:
- render //进行图片等渲染
- animate //动画function
- init //一些初始化配置
实现
通过以上思路的设计和结构的设计,我很快的将这个游戏实现了。。。没错,理清思路和结构的重要性就是这样。当然,在实现过程中,也有一些小的点可以记录下:
资源加载器(图片)
为了游戏的进行效果,还是决定在加载完所有资源(尤其是图片资源)后,才停止loading页面。如何判断所有内容都加载完毕了呢?写了个小loader
|
|
强制横屏
游戏是横屏展示的,那就强制横屏好啦。这个当时还纠结挺久,还是自己功底不扎实脑子走私了,还在想是监听resize事件还是旋转屏幕事件,都没有这些事儿啊好吗!直接让它旋转就好。
|
|
timer控制
理清思路后,最乱的还是各种定时器啦。 为了实现物体随机出现的效果,让每个物体随机多少秒后开始出现;最后一个物体出现完,多少秒后出现结束画面等等,需要理清楚各个定时器的关系,并对其添加语义化良好的标记,及时对未完结的定时器进行清除,防止定时器带来的意想不到的问题。
写在最后
最终游戏的效果基本让大家满意啦,也是第一次尝试这方面的开发,周围也完全没有做过这东西的人。从开始的忐忑和一无所措,到过程中理清思路和结构,到书写中的各种未知的坑,自己在这两周感觉经历了很充实的一件事情。同时也对后续进行一些未知事物的探索和学习有了更丰富的经验,找对路子才是王道呀!