H5游戏开发:贪吃蛇

H5游戏开发:一笔画

2017/11/07 · HTML5 ·
游戏

原文出处: 凹凸实验室   

图片 1

炉石开发历程探索:2个人用纸笔画出来的游戏!

2014/05/09 10:19:34| 来源:互联网 | 小编:犀利哥 |
已有[0]人评论我要评论

H5游戏开发:贪吃蛇

2017/09/28 · HTML5 · 1
评论 ·
游戏

原文出处:
凹凸实验室   

图片 2
贪吃蛇的经典玩法有两种:

  1. 积分闯关
  2. 一吃到底

第一种是笔者小时候在掌上游戏机最先体验到的(不小心暴露了年龄),具体玩法是蛇吃完一定数量的食物后就通关,通关后速度会加快;第二种是诺基亚在1997年在其自家手机上安装的游戏,它的玩法是吃到没食物为止。笔者要实现的就是第二种玩法。

贪吃蛇的经典玩法有两种:

H5游戏开发:套圈圈

2018/01/25 · HTML5 ·
游戏

原文出处: 凹凸实验室   

 

H5游戏开发:一笔画

by leeenx on 2017-11-02

一笔画是图论[科普](https://zh.wikipedia.org/wiki/%E5%9B%BE%E8%AE%BA)中一个著名的问题,它起源于柯尼斯堡七桥问题[科普](https://zh.wikipedia.org/wiki/%E6%9F%AF%E5%B0%BC%E6%96%AF%E5%A0%A1%E4%B8%83%E6%A1%A5%E9%97%AE%E9%A2%98)。数学家欧拉在他1736年发表的论文《柯尼斯堡的七桥》中不仅解决了七桥问题,也提出了一笔画定理,顺带解决了一笔画问题。用图论的术语来说,对于一个给定的连通图[科普](https://zh.wikipedia.org/wiki/%E8%BF%9E%E9%80%9A%E5%9B%BE)存在一条恰好包含所有线段并且没有重复的路径,这条路径就是「一笔画」。

寻找连通图这条路径的过程就是「一笔画」的游戏过程,如下:

图片 3

相关资源:

当Eric
Dodds首次提交《炉石传说》的概念时,公司很多人表示:“哦,你要做的东西可真是古怪,你到底在做什么?”没人真的抵制这个主意,但人们纷纷对此表示怀疑。这款暴雪的首款卡牌对战网游的开发历程是怎样的?在这篇文章中能找到答案,也许你还能找到更多——比如暴雪人的可贵品质。

在Eric
Dodds成为《炉石传说》的首席设计师之前,他向暴雪提出自己打算做一款数字卡牌游戏,而不是一款大型多人在线网游。最初,一些同事对这个念头表现出了困惑,但在他通过纸、笔和挂在自己办公室墙上的一沓信封向他们展示出游戏内容之后,他成功地改变了人们的态度。

图片 4

Eric Dodds将这个开端描述为“低沉的轰鸣”,而游戏的执行制作人Hamilton
Chu则认为 “喃喃低语”更为恰当。

之后,暴雪于2013年PAX
East展会中人满为患的发布会现场公布了这部作品,首次亮相的《炉石传说》迎来了一阵礼节性的掌声,以及全体观众的困惑–此前业内曾传言暴雪将要在波士顿公布一款新作,很多人都猜测是一款全新的大型多人在线网游,或是《魔兽世界》等暴雪主力品牌的DLC,但没人猜到会是一款数字卡牌游戏。

也没人真的需要一款卡牌游戏。

Eric和Hamilton对于这种回应再熟悉不过了,眼前的一切正是他们当初在暴雪内部经历过的。早在一年多之前,暴雪将一群志趣相投的开发者凑成了一支团队,并将其命名为“Team
5”,这支团队唯一的使命就是灵活、轻盈地对其他体积笨重的大型团队无暇顾及的机遇展开探索,并为其注入自己的热情。

当Eric Dodds首次向他的上司提交《炉石传说》的概念时,上司的反应与PAX
East展会现场的气氛并无不同。他没有遭到拒斥,但所得到的回应更类似担忧。

还有一点点困惑。

图片 5

Eric Dodds,《炉石传说》首席游戏设计师

Eric如此回顾这段经历:“当我们最初公布这款游戏的时候,很多人都表示‘哦,你要做的东西可真是古怪,你到底在做什么?这东西可一点都不寻常,而且有点不可思议。’当时整个公司上下都做出了同样的回应。”

“没人真的抵制这个主意,但人们纷纷对此表示怀疑。”

这就是暴雪的工作原理:团队成员倾向于为他们感兴趣的项目效力。按照Hamilton的说法,暴雪的开发者只创作他们自己想玩的游戏。依照这一标准,《炉石传说》显得合情合理。在新成立的Team
5中,绝大部分成员都曾长期沉迷于各种卡牌游戏,平均卡牌游龄超过十年之久。但他们也明白自己玩过的很多卡牌游戏都会显得高不可攀——这些卡牌游戏的规则可能令人费解。

“我们的感觉往往是‘伙计,这个真是超有趣的点子’,但现实是这些游戏中有相当一部分都非常复杂,”Hamilton解释道:“于是我们想:做出一款能够让大众找到那种乐趣的卡牌游戏,岂不是绝妙的主意?”

接下来,Team
5立即着手设计这款他们自己想玩的游戏:基于《魔兽争霸》世界观塑造出的,简单易懂的卡牌游戏。

当时,无论是Eric Dodds,还是Hamilton
Chu,都无法预见到这款游戏会流行到何种程度。

纸、笔与信封

图片 6

但项目刚开始没过多久,它就迎来了一次近乎“灭顶之灾”的遭遇:早在塑造雏形的艰难工作展开之前,Team
5就遭到了临时的解散。

当时,更重要的项目发售日正向暴雪步步紧逼,另一款大作需要在发售前集中更多人力。为此,Team
5的绝大部分成员都被抽调到了该项目中,只有Eric Dodds和资深设计师Ben
Brode留守原本的岗位。

但事后回忆起来,这段经历反而令《炉石传说》因祸得福。

“那种感觉颇有几分酷意。”Eric Dodds如此描述那段回忆。

他说‘酷’是因为仅存的两人一瞬间就变得孤立无援,需要独自钻研。但这并没有构成问题,Team
5最终受益于此。两人在这种状态下天马行空地为《炉石传说》绘制出了大量原型,并通过简单粗暴、直接有效的方式识别出哪些值得进一步挖掘,哪些有必要被抛在脑后。

在这段最漫长的开发过程中,Eric与Ben几乎只通过纸与笔来进行工作。

Eric Dodds
分享了他的回忆:“我们基本上陷在这样的问题之中:‘我们觉得这游戏的设计应该是什么样的?’面对这样的问题,设计师不应把太多时间浪费在传统之中。对我们而言,这意味着需要做出大量不同的构想。我们把大量时间用在通过纸笔勾画原型上,并探讨游戏应呈现出怎样的面貌,这是一段美妙的经历。”

他们在一张张白纸上画出一些有趣的图案,然后在图案上标记出各种数字,在Hamilton的记忆中:“他们把这些有趣的图案剪切成卡片,然后在探索出那些好主意的过程中提出了大量馊主意。”

这是一段令人振奋的经历,“纸上谈兵”正是游戏设计的最纯粹的形态。

电子游戏开发传统中的重重瓶颈并不存在于这个过程之中:《炉石传说》尚未进入流水线作业,它不需要经营管理,也不会产出无用功。这个项目的全部内容就是一间屋子,两个人,他们的纸与笔,以及一些可能派得上用场的疯狂念头。就算念头派不上用场也无关紧要,他们只要把纸团成一团,径直扔进最近的垃圾桶里,然后再想出新的念头就行。

游戏完工

这当然不是暴雪内部司空见惯的工作场景,但《炉石传说》也不是人们所熟悉的那种暴雪游戏:两人办公室的墙上挂满了信封和卡片,在布置出这样一幕惨状之后,他们完成了《炉石传说》中竞技场的异步轮抽流程设计,藉此,玩家可以通过特殊途径构建一套牌组并藉此展开对抗。

图片 7

当Team
5的其他团队成员完成抽调任务,回到自己的工作岗位之时,迎接他们的就是铺天盖地袭来的信封和卡片。

从某种程度上来说,这支团队已经对此做好了心理准备,Hamilton表示暴雪内部向来弥漫着这种“分享交流的文化氛围”。人们看到Eric和Ben留下的这些信封和碎纸片后,他们对于两人探索的结果也就有了模糊的认识。

但令这些新回归的团队成员感到措手不及的是:他们没料到Eric和Ben会在摸索中行进多远的距离。在他们不在的这段时间里,两人已经颠覆了众人所熟知的关于游戏设计流程的一切规矩。

当时,Eric指向了摆放在房间角落的一台电脑,电脑上正运行着《炉石传说》的Flash版本:在众人忙于其他项目的这段时期,Eric和Ben没有享受分秒空闲,他们已经大致上完成了游戏的原型,并且通过Flash做出了《炉石传说》的大体形态。

简而言之:这款游戏已经完成了。

“我们当时就指着那台电脑,跟他们说——‘游戏完工了’,”Eric笑道:“你们去把那游戏再做一遍就行了。”

这就是两人简单粗暴、直接有效的迭代过程的产物。

Hamilton
对此的评述是:“毫不夸张地说,他们迭代的效率要比我参与过的其他游戏项目高出了一个数量级。游戏最终的核心内容与最初的原型所保持的一致程度简直令人难以置信。”

将Eric与Ben完成的原型加以精制和包装之后,我们今日玩到的那一款《炉石传说》就此诞生。

12下一页尾页在本页阅读全文

MVC设计模式

基于贪吃蛇的经典,笔者在实现它时也使用一种经典的设计模型:MVC(即:Model
– View – Control)。游戏的各种状态与数据结构由 Model 来管理;View
用于显示 Model 的变化;用户与游戏的交互由 Control 完成(Control
提供各种游戏API接口)。

Model 是游戏的核心也是本文的主要内容;View 会涉及到部分性能问题;Control
负责业务逻辑。 这样设计的好处是: Model完全独立,View 是 Model
的状态机,Model 与 View 都由 Control 来驱动。

  1. 积分闯关
  2. 一吃到底

前言

虽然本文标题为介绍一个水压套圈h5游戏,但是窃以为仅仅如此对读者是没什么帮助的,毕竟读者们的工作生活很少会再写一个类似的游戏,更多的是面对需求的挑战。我更希望能举一反三,给大家在编写h5游戏上带来一些启发,无论是从整体流程的把控,对游戏框架、物理引擎的熟悉程度还是在某一个小难点上的思路突破等。因此本文将很少详细列举实现代码,取而代之的是以伪代码展现思路为主。

游戏 demo 地址:

游戏的实现

「一笔画」的实现不复杂,笔者把实现过程分成两步:

  1. 底图绘制
  2. 交互绘制

「底图绘制」把连通图以「点线」的形式显示在画布上,是游戏最容易实现的部分;「交互绘制」是用户绘制解题路径的过程,这个过程会主要是处理点与点动态成线的逻辑。

Model

看一张贪吃蛇的经典图片。

图片 8

贪吃蛇有四个关键的参与对象:

  1. 蛇(snake)
  2. 食物(food)
  3. 墙(bounds)
  4. 舞台(zone)

舞台是一个 m * n
的矩阵(二维数组),矩阵的索引边界是舞台的墙,矩阵上的成员用于标记食物和蛇的位置。

空舞台如下:

[ [0,0,0,0,0,0,0,0,0,0], [0,0,0,0,0,0,0,0,0,0],
[0,0,0,0,0,0,0,0,0,0], [0,0,0,0,0,0,0,0,0,0],
[0,0,0,0,0,0,0,0,0,0], [0,0,0,0,0,0,0,0,0,0],
[0,0,0,0,0,0,0,0,0,0], [0,0,0,0,0,0,0,0,0,0],
[0,0,0,0,0,0,0,0,0,0], [0,0,0,0,0,0,0,0,0,0], ]

1
2
3
4
5
6
7
8
9
10
11
12
[
[0,0,0,0,0,0,0,0,0,0],
[0,0,0,0,0,0,0,0,0,0],
[0,0,0,0,0,0,0,0,0,0],
[0,0,0,0,0,0,0,0,0,0],
[0,0,0,0,0,0,0,0,0,0],
[0,0,0,0,0,0,0,0,0,0],
[0,0,0,0,0,0,0,0,0,0],
[0,0,0,0,0,0,0,0,0,0],
[0,0,0,0,0,0,0,0,0,0],
[0,0,0,0,0,0,0,0,0,0],
]

食物(F)和蛇(S)出现在舞台上:

[ [0,0,0,0,0,0,0,0,0,0], [0,0,0,0,0,0,0,0,0,0],
[0,0,F,0,0,0,0,0,0,0], [0,0,0,S,S,S,S,0,0,0],
[0,0,0,0,0,0,S,0,0,0], [0,0,0,0,S,S,S,0,0,0],
[0,0,0,0,S,0,0,0,0,0], [0,0,0,0,S,0,0,0,0,0],
[0,0,0,0,0,0,0,0,0,0], [0,0,0,0,0,0,0,0,0,0], ]

1
2
3
4
5
6
7
8
9
10
11
12
[
[0,0,0,0,0,0,0,0,0,0],
[0,0,0,0,0,0,0,0,0,0],
[0,0,F,0,0,0,0,0,0,0],
[0,0,0,S,S,S,S,0,0,0],
[0,0,0,0,0,0,S,0,0,0],
[0,0,0,0,S,S,S,0,0,0],
[0,0,0,0,S,0,0,0,0,0],
[0,0,0,0,S,0,0,0,0,0],
[0,0,0,0,0,0,0,0,0,0],
[0,0,0,0,0,0,0,0,0,0],
]

由于操作二维数组不如一维数组方便,所以笔者使用的是一维数组, 如下:

JavaScript

[ 0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0, 0,0,F,0,0,0,0,0,0,0,
0,0,0,S,S,S,S,0,0,0, 0,0,0,0,0,0,S,0,0,0, 0,0,0,0,S,S,S,0,0,0,
0,0,0,0,S,0,0,0,0,0, 0,0,0,0,S,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0, ]

1
2
3
4
5
6
7
8
9
10
11
12
[
0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,
0,0,F,0,0,0,0,0,0,0,
0,0,0,S,S,S,S,0,0,0,
0,0,0,0,0,0,S,0,0,0,
0,0,0,0,S,S,S,0,0,0,
0,0,0,0,S,0,0,0,0,0,
0,0,0,0,S,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,
]

舞台矩阵上蛇与食物只是舞台对二者的映射,它们彼此都有独立的数据结构:

  • 蛇是一串坐标索引链表;
  • 食物是一个指向舞台坐标的索引值。

第一种是笔者小时候在掌上游戏机最先体验到的(不小心暴露了年龄),具体玩法是蛇吃完一定数量的食物后就通关,通关后速度会加快;第二种是诺基亚在1997年在其自家手机上安装的游戏,它的玩法是吃到没食物为止。笔者要实现的就是第二种玩法。

希望能给诸位读者带来的启发

  1. 技术选型
  2. 整体代码布局
  3. 难点及解决思路
  4. 优化点

底图绘制

「一笔画」是多关卡的游戏模式,笔者决定把关卡(连通图)的定制以一个配置接口的形式对外暴露。对外暴露关卡接口需要有一套描述连通图形状的规范,而在笔者面前有两个选项:

  • 点记法
  • 线记法

举个连通图 —— 五角星为例来说一下这两个选项。

图片 9

点记法如下:

JavaScript

levels: [ // 当前关卡 { name: “五角星”, coords: [ {x: Ax, y: Ay}, {x:
Bx, y: By}, {x: Cx, y: Cy}, {x: Dx, y: Dy}, {x: Ex, y: Ey}, {x: Ax, y:
Ay} ] } … ]

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
levels: [
// 当前关卡
{
name: "五角星",
coords: [
{x: Ax, y: Ay},
{x: Bx, y: By},
{x: Cx, y: Cy},
{x: Dx, y: Dy},
{x: Ex, y: Ey},
{x: Ax, y: Ay}
]
}
]

线记法如下:

JavaScript

levels: [ // 当前关卡 { name: “五角星”, lines: [ {x1: Ax, y1: Ay, x2:
Bx, y2: By}, {x1: Bx, y1: By, x2: Cx, y2: Cy}, {x1: Cx, y1: Cy, x2: Dx,
y2: Dy}, {x1: Dx, y1: Dy, x2: Ex, y2: Ey}, {x1: Ex, y1: Ey, x2: Ax, y2:
Ay} ] } ]

1
2
3
4
5
6
7
8
9
10
11
12
13
levels: [
// 当前关卡
{
name: "五角星",
lines: [
{x1: Ax, y1: Ay, x2: Bx, y2: By},
{x1: Bx, y1: By, x2: Cx, y2: Cy},
{x1: Cx, y1: Cy, x2: Dx, y2: Dy},
{x1: Dx, y1: Dy, x2: Ex, y2: Ey},
{x1: Ex, y1: Ey, x2: Ax, y2: Ay}
]
}
]

「点记法」记录关卡通关的一个答案,即端点要按一定的顺序存放到数组
coords中,它是有序性的记录。「线记法」通过两点描述连通图的线段,它是无序的记录。「点记法」最大的优势是表现更简洁,但它必须记录一个通关答案,笔者只是关卡的搬运工不是关卡创造者,所以笔者最终选择了「线记法」。:)

蛇的活动

蛇的活动有三种,如下:

  • 移动(move)
  • 吃食(eat)
  • 碰撞(collision)

MVC设计模式

基于贪吃蛇的经典,笔者在实现它时也使用一种经典的设计模型:MVC(即:Model

  • View – Control)。游戏的各种状态与数据结构由 Model 来管理;View
    用于显示 Model 的变化;用户与游戏的交互由 Control 完成(Control
    提供各种游戏API接口)。

Model 是游戏的核心也是本文的主要内容;View 会涉及到部分性能问题;Control
负责业务逻辑。 这样设计的好处是: Model完全独立,View 是 Model
的状态机,Model 与 View 都由 Control 来驱动。

技术选型

一个项目用什么技术来实现,权衡的因素有许多。其中时间是必须优先考虑的,毕竟效果可以减,但上线时间是死的。

本项目预研时间一周,真正排期时间只有两周。虽然由项目特点来看比较适合走
3D 方案,但时间明显是不够的。最后保守起见,决定采用 2D
方案尽量逼近真实立体的游戏效果。

从游戏复杂度来考虑,无须用到 Egret 或 Cocos
这些“牛刀”,而轻量、易上手、团队内部也有深厚沉淀的
CreateJS 则成为了渲染框架的首选。

另外需要考虑的是是否需要引入物理引擎,这点需要从游戏的特点去考虑。本游戏涉及重力、碰撞、施力等因素,引入物理引擎对开发效率的提高要大于学习使用物理引擎的成本。因此权衡再三,我引入了同事们已经玩得挺溜的
Matter.js。( Matter.js
文档清晰、案例丰富,是切入学习 web 游戏引擎的一个不错的框架)

交互绘制

在画布上绘制路径,从视觉上说是「选择或连接连通图端点」的过程,这个过程需要解决2个问题:

  • 手指下是否有端点
  • 选中点到待选中点之间能否成线

收集连通图端点的坐标,再监听手指滑过的坐标可以知道「手指下是否有点」。以下伪代码是收集端点坐标:

JavaScript

// 端点坐标信息 let coords = []; lines.forEach(({x1, y1, x2, y2})
=> { // (x1, y1) 在 coords 数组不存在 if(!isExist(x1, y1))
coords.push([x1, y1]); // (x2, y2) 在 coords 数组不存在
if(!isExist(x2, y2)) coords.push([x2, y2]); });

1
2
3
4
5
6
7
8
// 端点坐标信息
let coords = [];
lines.forEach(({x1, y1, x2, y2}) => {
// (x1, y1) 在 coords 数组不存在
if(!isExist(x1, y1)) coords.push([x1, y1]);
// (x2, y2) 在 coords 数组不存在
if(!isExist(x2, y2)) coords.push([x2, y2]);
});

以下伪代码是监听手指滑动:

JavaScript

easel.addEventListener(“touchmove”, e => { let x0 =
e.targetTouches[0].pageX, y0 = e.targetTouches[0].pageY; // 端点半径
—— 取连通图端点半径的2倍,提升移动端体验 let r = radius * 2;
for(let [x, y] of coords){ if(Math.sqrt(Math.pow(x – x0, 2) +
Math.pow(y – y0), 2) <= r){ // 手指下有端点,判断能否连线
if(canConnect(x, y)) { // todo } break; } } })

1
2
3
4
5
6
7
8
9
10
11
12
13
14
easel.addEventListener("touchmove", e => {
let x0 = e.targetTouches[0].pageX, y0 = e.targetTouches[0].pageY;
// 端点半径 —— 取连通图端点半径的2倍,提升移动端体验
let r = radius * 2;
for(let [x, y] of coords){
if(Math.sqrt(Math.pow(x – x0, 2) + Math.pow(y – y0), 2) <= r){
// 手指下有端点,判断能否连线
if(canConnect(x, y)) {
// todo
}
break;
}
}
})

在未绘制任何线段或端点之前,手指滑过的任意端点都会被视作「一笔画」的起始点;在绘制了线段(或有选中点)后,手指滑过的端点能否与选中点串连成线段需要依据现有条件进行判断。

图片 10

上图,点A与点B可连接成线段,而点A与点C不能连接。笔者把「可以与指定端点连接成线段的端点称作有效连接点」。连通图端点的有效连接点从连通图的线段中提取:

JavaScript

coords.forEach(coord => { // 有效连接点(坐标)挂载在端点坐标下
coord.validCoords = []; lines.forEach(({x1, y1, x2, y2}) => { //
坐标是当前线段的起点 if(coord.x === x1 && coord.y === y1) {
coord.validCoords.push([x2, y2]); } // 坐标是当前线段的终点 else
if(coord.x === x2 && coord.y === y2) { coord.validCoords.push([x1,
y1]); } }) })

1
2
3
4
5
6
7
8
9
10
11
12
13
14
coords.forEach(coord => {
// 有效连接点(坐标)挂载在端点坐标下
coord.validCoords = [];
lines.forEach(({x1, y1, x2, y2}) => {
// 坐标是当前线段的起点
if(coord.x === x1 && coord.y === y1) {
coord.validCoords.push([x2, y2]);
}
// 坐标是当前线段的终点
else if(coord.x === x2 && coord.y === y2) {
coord.validCoords.push([x1, y1]);
}
})
})

But…有效连接点只能判断两个点是否为底图的线段,这只是一个静态的参考,在实际的「交互绘制」中,会遇到以下情况:

图片 11
如上图,AB已串连成线段,当前选中点B的有效连接点是 A 与 C。AB
已经连接成线,如果 BA 也串连成线段,那么线段就重复了,所以此时 BA
不能成线,只有 AC 才能成线。

对选中点而言,它的有效连接点有两种:

  • 与选中点「成线的有效连接点」
  • 与选中点「未成线的有效连接点」

其中「未成线的有效连接点」才能参与「交互绘制」,并且它是动态的。

图片 12

回头本节内容开头提的两个问题「手指下是否有端点」 与
「选中点到待选中点之间能否成线」,其实可合并为一个问题:手指下是否存在「未成线的有效连接点」。只须把监听手指滑动遍历的数组由连通图所有的端点坐标
coords 替换为当前选中点的「未成线的有效连接点」即可。

至此「一笔画」的主要功能已经实现。可以抢先体验一下:

图片 13

移动

蛇在移动时,内部发生了什么变化?

图片 14

蛇链表在一次移动过程中做了两件事:向表头插入一个新节点,同时剔除表尾一个旧节点。用一个数组来代表蛇链表,那么蛇的移动就是以下的伪代码:

JavaScript

function move(next) { snake.pop() & snake.unshift(next); }

1
2
3
function move(next) {
snake.pop() & snake.unshift(next);
}

数组作为蛇链表合适吗?
这是笔者最开始思考的问题,毕竟数组的 unshift & pop
可以无缝表示蛇的移动。不过,方便不代表性能好,unshift
向数组插入元素的时间复杂度是 O(n), pop 剔除数组尾元素的时间复杂度是
O(1)。

蛇的移动是一个高频率的动作,如果一次动作的算法复杂度为 O(n)
并且蛇的长度比较大,那么游戏的性能会有问题。笔者想实现的贪吃蛇理论上讲是一条长蛇,所以笔者在本文章的回复是
—— 数组不适合作为蛇链表

蛇链表必须是真正的链表结构。
链表删除或插入一个节点的时间复杂度为O(1),用链表作为蛇链表的数据结构能提高游戏的性能。javascript
没有现成的链表结构,笔者写了一个叫
Chain 的链表类,Chain
提供了 unshfit & pop。以下伪代码是创建一条蛇链表:

JavaScript

let snake = new Chain();

1
let snake = new Chain();

由于篇幅问题这里就不介绍 Chain 是如何实现的,有兴趣的同学可以移步到:

Model

看一张贪吃蛇的经典图片。

图片 15

web前端/H5/javascript学习群:250777811

欢迎关注此公众号→【web前端EDU】跟大佬一起学前端!欢迎大家留言讨论一起转发

贪吃蛇有四个关键的参与对象:

  1. 蛇(snake)
  2. 食物(food)
  3. 墙(bounds)
  4. 舞台(zone)

舞台是一个 m * n 的矩阵(二维数组),矩阵的索引边界是舞台的墙,矩阵上的成员用于标记食物和蛇的位置。

空舞台如下:

[
 [0,0,0,0,0,0,0,0,0,0],
 [0,0,0,0,0,0,0,0,0,0],
 [0,0,0,0,0,0,0,0,0,0],
 [0,0,0,0,0,0,0,0,0,0],
 [0,0,0,0,0,0,0,0,0,0],
 [0,0,0,0,0,0,0,0,0,0],
 [0,0,0,0,0,0,0,0,0,0],
 [0,0,0,0,0,0,0,0,0,0],
 [0,0,0,0,0,0,0,0,0,0],
 [0,0,0,0,0,0,0,0,0,0],
]

食物(F)和蛇(S)出现在舞台上:

[
 [0,0,0,0,0,0,0,0,0,0],
 [0,0,0,0,0,0,0,0,0,0],
 [0,0,F,0,0,0,0,0,0,0],
 [0,0,0,S,S,S,S,0,0,0],
 [0,0,0,0,0,0,S,0,0,0],
 [0,0,0,0,S,S,S,0,0,0],
 [0,0,0,0,S,0,0,0,0,0],
 [0,0,0,0,S,0,0,0,0,0],
 [0,0,0,0,0,0,0,0,0,0],
 [0,0,0,0,0,0,0,0,0,0],
]

由于操作二维数组不如一维数组方便,所以笔者使用的是一维数组, 如下:

[
 0,0,0,0,0,0,0,0,0,0,
 0,0,0,0,0,0,0,0,0,0,
 0,0,F,0,0,0,0,0,0,0,
 0,0,0,S,S,S,S,0,0,0,
 0,0,0,0,0,0,S,0,0,0,
 0,0,0,0,S,S,S,0,0,0,
 0,0,0,0,S,0,0,0,0,0,
 0,0,0,0,S,0,0,0,0,0,
 0,0,0,0,0,0,0,0,0,0,
 0,0,0,0,0,0,0,0,0,0,
]

舞台矩阵上蛇与食物只是舞台对二者的映射,它们彼此都有独立的数据结构:

  • 蛇是一串坐标索引链表;
  • 食物是一个指向舞台坐标的索引值。

整体代码布局

在代码组织上,我选择了面向对象的手法,对整个游戏做一个封装,抛出一些控制接口给其他逻辑层调用。

伪代码:

<!– index.html –> <!– 游戏入口 canvas –> <canvas
id=”waterfulGameCanvas” width=”660″ height=”570″></canvas>

1
2
3
<!– index.html –>
<!– 游戏入口 canvas –>
<canvas id="waterfulGameCanvas" width="660" height="570"></canvas>

// game.js /** * 游戏对象 */ class Waterful { // 初始化函数 init ()
{} // CreateJS Tick,游戏操作等事件的绑定放到游戏对象内 eventBinding ()
{} // 暴露的一些方法 score () {} restart () {} pause () {} resume () {}
// 技能 skillX () {} } /** * 环对象 */ class Ring { // 于每一个
CreateJS Tick 都调用环自身的 update 函数 update () {} // 进针后的逻辑
afterCollision () {} }

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
// game.js
/**
* 游戏对象
*/
class Waterful {
  // 初始化函数
  init () {}
  
  // CreateJS Tick,游戏操作等事件的绑定放到游戏对象内
  eventBinding () {}
  
  // 暴露的一些方法
  score () {}
  
  restart () {}
  
  pause () {}
  
  resume () {}
  
  // 技能
  skillX () {}
}
/**
* 环对象
*/
class Ring {
  // 于每一个 CreateJS Tick 都调用环自身的 update 函数
  update () {}
  
  // 进针后的逻辑
  afterCollision () {}
}

JavaScript

// main.js // 根据业务逻辑初始化游戏,调用游戏的各种接口 const waterful
= new Waterful() waterful.init({…})

1
2
3
4
// main.js
// 根据业务逻辑初始化游戏,调用游戏的各种接口
const waterful = new Waterful()
waterful.init({…})

自动识图

笔者在录入关卡配置时,发现一个7条边以上的连通图很容易录错或录重线段。笔者在思考能否开发一个自动识别图形的插件,毕竟「一笔画」的图形是有规则的几何图形。

图片 16

上面的关卡「底图」,一眼就可以识出三个颜色:

  • 白底
  • 端点颜色
  • 线段颜色

并且这三种颜色在「底图」的面积大小顺序是:白底 > 线段颜色 >
端点颜色。底图的「采集色值表算法」很简单,如下伪代码:

JavaScript

let imageData = ctx.getImageData(); let data = imageData.data; // 色值表
let clrs = new Map(); for(let i = 0, len = data.length; i < len; i +=
4) { let [r, g, b, a] = [data[i], data[i + 1], data[i + 2],
data[i + 3]]; let key = `rgba(${r}, ${g}, ${b}, ${a})`; let value =
clrs.get(key) || {r, g, b, a, count: 0}; clrs.has(key) ? ++value.count :
clrs.set(rgba, {r, g, b, a, count}); }

1
2
3
4
5
6
7
8
9
10
let imageData = ctx.getImageData();
let data = imageData.data;
// 色值表
let clrs = new Map();
for(let i = 0, len = data.length; i < len; i += 4) {
let [r, g, b, a] = [data[i], data[i + 1], data[i + 2], data[i + 3]];
let key = `rgba(${r}, ${g}, ${b}, ${a})`;
let value = clrs.get(key) || {r, g, b, a, count: 0};
clrs.has(key) ? ++value.count : clrs.set(rgba, {r, g, b, a, count});
}

对于连通图来说,只要把端点识别出来,连通图的轮廓也就出来了。

吃食 & 碰撞

「吃食」与「碰撞」区别在于吃食撞上了「食物」,碰撞撞上了「墙」。笔者认为「吃食」与「碰撞」属于蛇一次「移动」的三个可能结果的两个分支。蛇移动的三个可能结果是:「前进」、「吃食」和「碰撞」。

回头看一下蛇移动的伪代码:

JavaScript

function move(next) { snake.pop() & snake.unshift(next); }

1
2
3
function move(next) {
snake.pop() & snake.unshift(next);
}

代码中的 next
表示蛇头即将进入的格子的索引值,只有当这个格子是0时蛇才能「前进」,当这个格子是
S 表示「碰撞」自己,当这个格子是 F表示吃食。

好像少了撞墙?
笔者在设计过程中,并没有把墙设计在舞台的矩阵中,而是通过索引出界的方式来表示撞墙。简单地说就是
next === -1 时表示出界和撞墙。

以下伪代码表示蛇的整上活动过程:

JavaScript

// B 表示撞墙 let cell = -1 === next ? B : zone[next]; switch(cell) {
// 吃食 case F: eat(); break; // 撞到自己 case S: collision(S); break;
// 撞墙 case B: collision(B): break; // 前进 default: move; }

1
2
3
4
5
6
7
8
9
10
11
12
// B 表示撞墙
let cell = -1 === next ? B : zone[next];
switch(cell) {
// 吃食
case F: eat(); break;
// 撞到自己
case S: collision(S); break;
// 撞墙
case B: collision(B): break;
// 前进
default: move;
}

蛇的活动

蛇的活动有三种,如下:

  • 移动(move)
  • 吃食(eat)
  • 碰撞(collision)

初始化

游戏的初始化接口主要做了4件事情:

  1. 参数初始化
  2. CreateJS 显示元素(display object)的布局
  3. Matter.js 刚体(rigid body)的布局
  4. 事件的绑定

下面主要聊聊游戏场景里各种元素的创建与布局,即第二、第三点。

端点识别

理论上,通过采集的「色值表」可以直接把端点的坐标识别出来。笔者设计的「端点识别算法」分以下2步:

  1. 按像素扫描底图直到遇到「端点颜色」的像素,进入第二步
  2. 从底图上清除端点并记录它的坐标,返回继续第一步

伪代码如下:

JavaScript

for(let i = 0, len = data.length; i < len; i += 4) { let [r, g, b,
a] = [data[i], data[i + 1], data[i + 2], data[i + 3]]; //
当前像素颜色属于端点 if(isBelongVertex(r, g, b, a)) { // 在 data
中清空端点 vertex = clearVertex(i); // 记录端点信息
vertexes.push(vertext); } }

1
2
3
4
5
6
7
8
9
10
for(let i = 0, len = data.length; i < len; i += 4) {
let [r, g, b, a] = [data[i], data[i + 1], data[i + 2], data[i + 3]];
// 当前像素颜色属于端点
if(isBelongVertex(r, g, b, a)) {
// 在 data 中清空端点
vertex = clearVertex(i);
// 记录端点信息
vertexes.push(vertext);
}
}

But…
上面的算法只能跑无损图。笔者在使用了一张手机截屏做测试的时候发现,收集到的「色值表」长度为
5000+ !这直接导致端点和线段的色值无法直接获得。

经过分析,可以发现「色值表」里绝大多数色值都是相近的,也就是在原来的「采集色值表算法」的基础上添加一个近似颜色过滤即可以找出端点和线段的主色。伪代码实现如下:

JavaScript

let lineColor = vertexColor = {count: 0}; for(let clr of clrs) { //
与底色相近,跳过 if(isBelongBackground(clr)) continue; //
线段是数量第二多的颜色,端点是第三多的颜色 if(clr.count >
lineColor.count) { [vertexColor, lineColor] = [lineColor, clr] } }

1
2
3
4
5
6
7
8
9
let lineColor = vertexColor = {count: 0};
for(let clr of clrs) {
// 与底色相近,跳过
if(isBelongBackground(clr)) continue;
// 线段是数量第二多的颜色,端点是第三多的颜色
if(clr.count > lineColor.count) {
[vertexColor, lineColor] = [lineColor, clr]
}
}

取到端点的主色后,再跑一次「端点识别算法」后居识别出 203
个端点!这是为什么呢?

图片 17

上图是放大5倍后的底图局部,蓝色端点的周围和内部充斥着大量噪点(杂色块)。事实上在「端点识别」过程中,由于噪点的存在,把原本的端点被分解成十几个或数十个小端点了,以下是跑过「端点识别算法」后的底图:

图片 18

通过上图,可以直观地得出一个结论:识别出来的小端点只在目标(大)端点上集中分布,并且大端点范围内的小端点叠加交错。

如果把叠加交错的小端点归并成一个大端点,那么这个大端点将十分接近目标端点。小端点的归并伪代码如下:

JavaScript

for(let i = 0, len = vertexes.length; i < len – 1; ++i) { let vertexA
= vertexes[i]; if(vertextA === undefined) continue; // 注意这里 j = 0
而不是 j = i +1 for(let j = 0; j < len; ++j) { let vertexB =
vertexes[j]; if(vertextB === undefined) continue; //
点A与点B有叠加,点B合并到点A并删除点B if(isCross(vertexA, vertexB)) {
vertexA = merge(vertexA, vertexB); delete vertexA; } } }

1
2
3
4
5
6
7
8
9
10
11
12
13
14
for(let i = 0, len = vertexes.length; i < len – 1; ++i) {
let vertexA = vertexes[i];
if(vertextA === undefined) continue;
// 注意这里 j = 0 而不是 j = i +1
for(let j = 0; j < len; ++j) {
let vertexB = vertexes[j];
if(vertextB === undefined) continue;
// 点A与点B有叠加,点B合并到点A并删除点B
if(isCross(vertexA, vertexB)) {
vertexA = merge(vertexA, vertexB);
delete vertexA;
}
}
}

加了小端点归并算法后,「端点识别」的准确度就上去了。经笔者本地测试已经可以
100% 识别有损的连通图了。

随机投食

随机投食是指随机挑选舞台的一个索引值用于映射食物的位置。这似乎很简单,可以直接这样写:

JavaScript

// 伪代码 food = Math.random(zone.length) >> 0;

1
2
// 伪代码
food = Math.random(zone.length) >> 0;

如果考虑到投食的前提 ——
不与蛇身重叠,你会发现上面的随机代码并不能保证投食位置不与蛇身重叠。由于这个算法的安全性带有赌博性质,且把它称作「赌博算法」。为了保证投食的安全性,笔者把算法扩展了一下:

JavaScript

// 伪代码 function feed() { let index = Math.random(zone.length)
>> 0; // 当前位置是否被占用 return zone[index] === S ? feed() :
index; } food = feed();

1
2
3
4
5
6
7
// 伪代码
function feed() {
let index = Math.random(zone.length) >> 0;
// 当前位置是否被占用
return zone[index] === S ? feed() : index;
}
food = feed();

上面的代码虽然在理论上可以保证投食的绝对安全,不过笔者把这个算法称作「不要命的赌徒算法」,因为上面的算法有致命的BUG
—— 超长递归 or 死循环。

为了解决上面的致命问题,笔者设计了下面的算法来做随机投食:

JavaScript

// 伪代码 function feed() { // 未被占用的空格数 let len = zone.length –
snake.length; // 无法投食 if(len === 0) return ; // zone的索引 let index
= 0, // 空格计数器 count = 0, // 第 rnd 个空格子是最终要投食的位置 rnd =
Math.random() * count >> 0 + 1; // 累计空格数 while(count !==
rnd) { // 当前格子为空,count总数增一 zone[index++] === 0 && ++count;
} return index – 1; } food = feed();

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// 伪代码
function feed() {
// 未被占用的空格数
let len = zone.length – snake.length;
// 无法投食
if(len === 0) return ;
// zone的索引
let index = 0,
// 空格计数器
count = 0,
// 第 rnd 个空格子是最终要投食的位置
rnd = Math.random() * count >> 0 + 1;
// 累计空格数
while(count !== rnd) {
// 当前格子为空,count总数增一
zone[index++] === 0 && ++count;
}
return index – 1;
}
food = feed();

这个算法的平均复杂度为 O(n/2)。由于投食是一个低频操作,所以
O(n/2)的复杂度并不会带来任何性能问题。不过,笔者觉得这个算法的复杂度还是有点高了。回头看一下最开始的「赌博算法」,虽然「赌博算法」很不靠谱,但是它有一个优势
—— 时间复杂度为 O(1)。

「赌博算法」的靠谱概率 = (zone.length – snake.length) /
zone.length。snake.length
是一个动态值,它的变化范围是:0 ~ zone.length。推导出「赌博算法」的平均靠谱概率是:

「赌博算法」平均靠谱概率 = 50%

看来「赌博算法」还是可以利用一下的。于是笔者重新设计了一个算法:

新算法的平均复杂度可以有效地降低到 O(n/4),人生有时候需要点运气 : )。

移动

蛇在移动时,内部发生了什么变化?

图片 19

蛇链表在一次移动过程中做了两件事:向表头插入一个新节点,同时剔除表尾一个旧节点。用一个数组来代表蛇链表,那么蛇的移动就是以下的伪代码:

function move(next) {
 snake.pop() & snake.unshift(next); 
} 

数组作为蛇链表合适吗? 这是笔者最开始思考的问题,毕竟数组的 unshift & pop 可以无缝表示蛇的移动。不过,方便不代表性能好,unshift 向数组插入元素的时间复杂度是
O(n), pop 剔除数组尾元素的时间复杂度是 O(1)。

蛇的移动是一个高频率的动作,如果一次动作的算法复杂度为 O(n)
并且蛇的长度比较大,那么游戏的性能会有问题。笔者想实现的贪吃蛇理论上讲是一条长蛇,所以笔者在本文章的回复是
—— 数组不适合作为蛇链表。

蛇链表必须是真正的链表结构。 链表删除或插入一个节点的时间复杂度为O(1),用链表作为蛇链表的数据结构能提高游戏的性能。javascript
没有现成的链表结构,笔者写了一个叫 Chain 的链表类,Chain 提供了 unshfit & pop。以下伪代码是创建一条蛇链表:

let snake = new Chain(); 

吃食 & 碰撞

「吃食」与「碰撞」区别在于吃食撞上了「食物」,碰撞撞上了「墙」。笔者认为「吃食」与「碰撞」属于蛇一次「移动」的三个可能结果的两个分支。蛇移动的三个可能结果是:「前进」、「吃食」和「碰撞」。

回头看一下蛇移动的伪代码:

function move(next) {
 snake.pop() & snake.unshift(next); 
} 

代码中的 next 表示蛇头即将进入的格子的索引值,只有当这个格子是0时蛇才能「前进」,当这个格子是 S 表示「碰撞」自己,当这个格子是 F表示吃食。

好像少了撞墙? 笔者在设计过程中,并没有把墙设计在舞台的矩阵中,而是通过索引出界的方式来表示撞墙。简单地说就是 next === -1 时表示出界和撞墙。

以下伪代码表示蛇的整上活动过程:

// B 表示撞墙
let cell = -1 === next ? B : zone[next]; 
switch(cell) {
    // 吃食
    case F: eat(); break; 
    // 撞到自己
    case S: collision(S); break; 
    // 撞墙
    case B: collision(B): break; 
    // 前进
    default: move; 
}

 

一、CreateJS 结合 Matter.js

阅读 Matter.js 的 demo 案例,都是用其自带的渲染引擎
Matter.Render。但是由于某些原因(后面会说到),我们需要使用 CreateJS
去渲染每个环的贴图。

不像 Laya 配有和 Matter.js 自身用法一致的 Render,CreateJS
需要单独创建一个贴图层,然后在每个 Tick 里把贴图层的坐标同步为 Matter.js
刚体的当前坐标。

伪代码:

JavaScript

createjs.Ticker.addEventListener(‘tick’, e => { 环贴图的坐标 =
环刚体的坐标 })

1
2
3
createjs.Ticker.addEventListener(‘tick’, e => {
  环贴图的坐标 = 环刚体的坐标
})

使用 CreateJS 去渲染后,要单独调试 Matter.js
的刚体是非常不便的。建议写一个调试模式专门使用 Matter.js 的 Render
去渲染,以便跟踪刚体的运动轨迹。

线段识别

笔者分两个步骤完成「线段识别」:

  1. 给定的两个端点连接成线,并采集连线上N个「样本点」;
  2. 遍历样本点像素,如果像素色值不等于线段色值则表示这两个端点之间不存在线段

如何采集「样式点」是个问题,太密集会影响性能;太疏松精准度不能保证。

在笔者面前有两个选择:N 是常量;N 是变量。
假设 N === 5。局部提取「样式点」如下:

图片 20

上图,会识别出三条线段:AB, BC 和 AC。而事实上,AC不能成线,它只是因为
AB 和 BC 视觉上共一线的结果。当然把 N 值向上提高可以解决这个问题,不过 N
作为常量的话,这个常量的取量需要靠经验来判断,果然放弃。

为了避免 AB 与 BC 同处一直线时 AC 被识别成线段,其实很简单 ——
两个「样本点」的间隔小于或等于端点直径
假设 N = S / (2 * R),S 表示两点的距离,R
表示端点半径。局部提取「样式点」如下:

图片 21

如上图,成功地绕过了 AC。「线段识别算法」的伪代码实现如下:

JavaScript

for(let i = 0, len = vertexes.length; i < len – 1; ++i) { let {x: x1,
y: y1} = vertexes[i]; for(let j = i + 1; j < len; ++j) { let {x:
x2, y: y2} = vertexes[j]; let S = Math.sqrt(Math.pow(x1 – x2, 2) +
Math.pow(y1 – y2, 2)); let N = S / (R * 2); let stepX = (x1 – x2) / N,
stepY = (y1 – y2) / n; while(–N) { // 样本点不是线段色
if(!isBelongLine(x1 + N * stepX, y1 + N * stepY)) break; } //
样本点都合格 —- 表示两点成线,保存 if(0 === N) lines.push({x1, y1, x2,
y2}) } }

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
for(let i = 0, len = vertexes.length; i < len – 1; ++i) {
let {x: x1, y: y1} = vertexes[i];
for(let j = i + 1; j < len; ++j) {
let {x: x2, y: y2} = vertexes[j];
let S = Math.sqrt(Math.pow(x1 – x2, 2) + Math.pow(y1 – y2, 2));
let N = S / (R * 2);
let stepX = (x1 – x2) / N, stepY = (y1 – y2) / n;
while(–N) {
// 样本点不是线段色
if(!isBelongLine(x1 + N * stepX, y1 + N * stepY)) break;
}
// 样本点都合格 —- 表示两点成线,保存
if(0 === N) lines.push({x1, y1, x2, y2})
}
}

View

在 View 可以根据喜好选择一款游戏渲染引擎,笔者在 View 层选择了 PIXI
作为游戏游戏渲染引擎。

View 的任务主要有两个:

  1. 绘制游戏的界面;
  2. 渲染 Model 里的各种数据结构

也就是说 View
是使用渲染引擎还原设计稿的过程。本文的目的是介绍「贪吃蛇」的实现思路,如何使用一个渲染引擎不是本文讨论的范畴,笔者想介绍的是:「如何提高渲染的效率」。

在 View 中显示 Model 的蛇可以简单地如以下伪代码:

上面代码的时间复杂度是
O(n)。上面介绍过蛇的移动是一个高频的活动,我们要尽量避免高频率地运行
O(n) 的代码。来分析蛇的三种活动:「移动」,「吃食」,「碰撞」。
首先,Model 发生了「碰撞」,View 应该是直接暂停渲染 Model
里的状态,游戏处在死亡状态,接下来的事由 Control 处理。
Model
中的蛇(链表)在一次「移动」过程中做了两件事:向表头插入一个新节点,同时剔除表尾一个旧节点;蛇(链表)在一次「吃食」过程中只做一件事:向表头插入一个新节点

图片 22

如果在 View 中对 Model 的蛇链表做差异化检查,View
只增量更新差异部分的话,算法的时间复杂度即可降低至 O(1) ~ O(2)
。以下是优化后的伪代码:

随机投食

随机投食是指随机挑选舞台的一个索引值用于映射食物的位置。这似乎很简单,可以直接这样写:

// 伪代码
food = Math.random(zone.length) >> 0; 

如果考虑到投食的前提 ——
不与蛇身重叠,你会发现上面的随机代码并不能保证投食位置不与蛇身重叠。由于这个算法的安全性带有赌博性质,且把它称作「赌博算法」。为了保证投食的安全性,笔者把算法扩展了一下:

// 伪代码
function feed() {
    let index = Math.random(zone.length) >> 0; 
    // 当前位置是否被占用
    return zone[index] === S ? feed() : index; 
}
food = feed(); 

 

上面的代码虽然在理论上可以保证投食的绝对安全,不过笔者把这个算法称作「不要命的赌徒算法」,因为上面的算法有致命的BUG
—— 超长递归 or 死循环。

为了解决上面的致命问题,笔者设计了下面的算法来做随机投食:

// 伪代码
function feed() {
    // 未被占用的空格数
    let len = zone.length - snake.length; 
    // 无法投食
    if(len === 0) return ; 
    // zone的索引
    let index = 0, 
    // 空格计数器
    count = 0, 
    // 第 rnd 个空格子是最终要投食的位置
    rnd = Math.random() * count >> 0 + 1; 
    // 累计空格数
    while(count !== rnd) {
        // 当前格子为空,count总数增一
        zone[index++] === 0 && ++count; 
    }
    return index - 1; 
}
food = feed(); 

 

这个算法的平均复杂度为 O(n/2)。由于投食是一个低频操作,所以
O(n/2)的复杂度并不会带来任何性能问题。不过,笔者觉得这个算法的复杂度还是有点高了。回头看一下最开始的「赌博算法」,虽然「赌博算法」很不靠谱,但是它有一个优势
—— 时间复杂度为 O(1)。

「赌博算法」的靠谱概率 = (zone.length – snake.length) /
zone.length。snake.length 是一个动态值,它的变化范围是:0 ~ zone.length。推导出「赌博算法」的平均靠谱概率是:

「赌博算法」平均靠谱概率 = 50%

看来「赌博算法」还是可以利用一下的。于是笔者重新设计了一个算法:

// 伪代码
function bet() {
    let rnd = Math.random() * zone.length >> 0; 
    return zone[rnd] === 0 ? rnd : -1; 
}
function feed() {
    ...
}
food = bet(); 
if(food === -1) food = feed(); 

 

新算法的平均复杂度可以有效地降低到 O(n/4),人生有时候需要点运气 : )。

二、环

本游戏的难点是要以 2D 去模拟 3D,环是一点,进针的效果是一点,先说环。

环由一个圆形的刚体,和半径稍大一些的贴图层所组成。如下图,蓝色部分为刚体:

图片 23

伪代码:

JavaScript

class Ring { constructor () { // 贴图 this.texture = new
createjs.Sprite(…) // 刚体 this.body = Matter.Bodies.circle(…) } }

1
2
3
4
5
6
7
8
class Ring {
  constructor () {
    // 贴图
    this.texture = new createjs.Sprite(…)
    // 刚体
    this.body = Matter.Bodies.circle(…)
  }
}

性能优化

由于「自动识图」需要对图像的的像素点进行扫描,那么性能确实是个需要关注的问题。笔者设计的「自动识图算法」,在识别图像的过程中需要对图像的像素做两次扫描:「采集色值表」
与 「采集端点」。在扫描次数上其实很难降低了,但是对于一张 750 * 1334
的底图来说,「自动识图算法」需要遍历两次长度为
750 * 1334 * 4 = 4,002,000
的数组,压力还是会有的。笔者是从压缩被扫描数组的尺寸来提升性能的。

被扫描数组的尺寸怎么压缩?
笔者直接通过缩小画布的尺寸来达到缩小被扫描数组尺寸的。伪代码如下:

JavaScript

// 要压缩的倍数 let resolution = 4; let [width, height] = [img.width
/ resolution >> 0, img.height / resolution >> 0];
ctx.drawImage(img, 0, 0, width, height); let imageData =
ctx.getImageData(), data = imageData;

1
2
3
4
5
// 要压缩的倍数
let resolution = 4;
let [width, height] = [img.width / resolution >> 0, img.height / resolution >> 0];
ctx.drawImage(img, 0, 0, width, height);
let imageData = ctx.getImageData(), data = imageData;

把源图片缩小4倍后,得到的图片像素数组只有原来的
4^2 = 16倍。这在性能上是很大的提升。

Control

Control 主要做 3 件事:

  1. 游戏与用户的互动
  2. 驱动 Model
  3. 同步 View 与 Model

「游戏与用户的互动」是指向外提供游戏过程需要使用到的 APIs 与
各类事件。笔者规划的 APIs 如下:

name type deltail
init method 初始化游戏
start method 开始游戏
restart method 重新开始游戏
pause method 暂停
resume method 恢复
turn method 控制蛇的转向。如:turn(“left”)
destroy method 销毁游戏
speed property 蛇的移动速度

事件如下:

name detail
countdown 倒时计
eat 吃到食物
before-eat 吃到食物前触发
gameover 游戏结束

事件统一挂载在游戏实例下的 event 对象下。

「驱动 Model 」只做一件事 —— 将 Model
的蛇的方向更新为用户指定的方向

「同步 View 与 Model 」也比较简单,检查 Model 是否有更新,如果有更新通知
View 更新游戏界面。

View

在 View 可以根据喜好选择一款游戏渲染引擎,笔者在 View
层选择了 PIXI 作为游戏游戏渲染引擎。

View 的任务主要有两个:

  1. 绘制游戏的界面;
  2. 渲染 Model 里的各种数据结构

也就是说 View
是使用渲染引擎还原设计稿的过程。本文的目的是介绍「贪吃蛇」的实现思路,如何使用一个渲染引擎不是本文讨论的范畴,笔者想介绍的是:「如何提高渲染的效率」。

在 View 中显示 Model 的蛇可以简单地如以下伪代码:

// 清空 View 上的蛇
view.snake.clean(); 
model.snake.forEach(
    (node) => {
        // 创建 View 上的蛇节点
        let viewNode = createViewNode(node); 
        // 并合一条新蛇
        view.snake.push(viewNode); 
    }
); 

 

上面代码的时间复杂度是
O(n)。上面介绍过蛇的移动是一个高频的活动,我们要尽量避免高频率地运行
O(n) 的代码。来分析蛇的三种活动:「移动」,「吃食」,「碰撞」。

首先,Model 发生了「碰撞」,View 应该是直接暂停渲染 Model
里的状态,游戏处在死亡状态,接下来的事由 Control 处理。

Model
中的蛇(链表)在一次「移动」过程中做了两件事:向表头插入一个新节点,同时剔除表尾一个旧节点;蛇(链表)在一次「吃食」过程中只做一件事:向表头插入一个新节点。

图片 24

如果在 View 中对 Model 的蛇链表做差异化检查,View
只增量更新差异部分的话,算法的时间复杂度即可降低至 O(1) ~ O(2)
。以下是优化后的伪代码:

let snakeA = model.snake, snakeB = view.snake; 
// 增量更新尾部
while(snakeB.length <= snakeA.length) { 
    headA = snakeA.next(); 
    // 头节点匹配
    if(headA.data === headB.data) break; 
    // 不匹配
    else { 
        // 向snakeB插入头节点
        if(snakeA.HEAD === headA.index) {
            snakeB.unshift(headA.data); 
        }
        // 向snakeB插入第二个节点
        else snakeB.insertAfter(0, headA.data); 
    }
}
// 增量更新头部 
let tailA = snakeA.last(), tailB; 
while(snakeB.length !== 0) { 
    tailB = snakeB.last(); 
    // 尾节点匹配
    if(tailA.data === tailB.data) break; 
    // 不匹配
    else snakeB.pop(); 
}

 

三、刚体

为什么把刚体半径做得稍小呢,这也是受这篇文章
推金币
里金币的做法所启发。推金币游戏中,为了达到金币间的堆叠效果,作者很聪明地把刚体做得比贴图小,这样当刚体挤在一起时,贴图间就会层叠起来。所以这样做是为了使环之间稍微有点重叠效果,更重要的也是当两个紧贴的环不会因翻转角度太接近而显得留白太多。如图:

图片 25

为了模拟环在水中运动的效果,可以选择给环加一些空气摩擦力。另外在实物游戏里,环是塑料做成的,碰撞后动能消耗较大,因此可以把环的
restitution 值调得稍微小一些。

需要注意 Matter.js
中因为各种物理参数都是没有单位的,一些物理公式很可能用不上,只能基于其默认值慢慢进行微调。下面的
frictionAir 和 restitution 值就是我慢慢凭感觉调整出来的:

JavaScript

this.body = Matter.Bodies.circle(x, y, r, { frictionAir: 0.02,
restitution: 0.15 })

1
2
3
4
this.body = Matter.Bodies.circle(x, y, r, {
  frictionAir: 0.02,
  restitution: 0.15
})

使用「自动识图」的建议

尽管笔者在本地测试的时候可以把所有的「底图」识别出来,但是并不能保证其它开发者上传的图片能否被很好的识别出来。笔者建议,可以把「自动识图」做为一个单独的工具使用。

笔者写了一个「自动识图」的单独工具页面:
可以在这个页面生成对应的关卡配置。

结语

下面是本文介绍的贪吃蛇的线上
DEMO 的二维码:

图片 26

游戏的源码托管在:

1 赞 5 收藏 1
评论

图片 27

Control

Control 主要做 3 件事:

  1. 游戏与用户的互动
  2. 驱动 Model
  3. 同步 View 与 Model

「游戏与用户的互动」是指向外提供游戏过程需要使用到的 APIs 与
各类事件。笔者规划的 APIs 如下:

name type deltail
init method 初始化游戏
start method 开始游戏
restart method 重新开始游戏
pause method 暂停
resume method 恢复
turn method 控制蛇的转向。如:turn("left")
destroy method 销毁游戏
speed property 蛇的移动速度

事件如下:

name detail
countdown 倒时计
eat 吃到食物
before-eat 吃到食物前触发
gameover 游戏结束

事件统一挂载在游戏实例下的 event 对象下。

snake.event.on("countdown", (time) => console.log("剩余时间:", time)); 

「驱动 Model 」只做一件事 —— 将 Model
的蛇的方向更新为用户指定的方向。 「同步 View 与 Model 」也比较简单,检查
Model 是否有更新,如果有更新通知 View 更新游戏界面。

四、贴图

环在现实世界中的旋转是三维的,而 CreateJS
只能控制元素在二维平面上的旋转。对于一个环来说,二维平面的旋转是没有任何意义的,无论如何旋转,都只会是同一个样子。

想要达到环绕 x 轴旋转的效果,一开始想到的是使用 rotation +
scaleY。虽然这样能在视觉上达到目的,但是 scaleY
会导致环有被压扁的感觉,图片会失真:

图片 28

显然这样的效果是不能接受的,最后我采取了逐帧图的方式,最接近地还原了环的旋转姿态:

图片 29

图片 30

注意在每个 Tick 里需要去判断环是否静止,若非静止则继续播放,并将贴图的
rotation 值赋值为刚体的旋转角度。如果是停止状态,则暂停逐帧图的播放:

JavaScript

// 贴图与刚体位置的小数点后几位有点不一样,需要降低精度 const x1 =
Math.round(texture.x) const x2 = Math.round(body.position.x) const y1 =
Math.round(texture.y) const y2 = Math.round(body.position.y) if (x1 !==
x2 || y1 !== y2) { texture.paused && texture.play() texture.rotation =
body.angle * 180 / Math.PI } else { !texture.paused && texture.stop() }
texture.x = body.position.x texture.y = body.position.y

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// 贴图与刚体位置的小数点后几位有点不一样,需要降低精度
const x1 = Math.round(texture.x)
const x2 = Math.round(body.position.x)
const y1 = Math.round(texture.y)
const y2 = Math.round(body.position.y)
if (x1 !== x2 || y1 !== y2) {
  texture.paused && texture.play()
  texture.rotation = body.angle * 180 / Math.PI
} else {
  !texture.paused && texture.stop()
}
  
texture.x = body.position.x
texture.y = body.position.y

结语

下面是本文介绍的「一笔画」的线上
DEMO 的二维码:

图片 13

游戏的源码托管在:
其中游戏实现的主体代码在:
自动识图的代码在:

感谢耐心阅读完本文章的读者。本文仅代表笔者的个人观点,如有不妥之处请不吝赐教。

感谢您的阅读,本文由 凹凸实验室
版权所有。如若转载,请注明出处:凹凸实验室()

1 赞 1 收藏
评论

图片 27

结语

想要贪吃蛇项目源码的加→

web前端/H5/javascript学习群:250777811

欢迎关注此公众号→【web前端EDU】跟大佬一起学前端!欢迎大家留言讨论一起转发

五、舞台

舞台需要主要由物理世界、背景图,墙壁,针所组成。

1. 物理世界

为了模拟真实世界环在水中的向下加速度,可以把 y 方向的 g 值调小:

JavaScript

engine.world.gravity.y = 0.2

1
engine.world.gravity.y = 0.2

左右重力感应对环的加速度影响同样可以通过改变 x 方向的 g 值达到:

JavaScript

// 最大倾斜角度为 70 度,让用户不需要过分倾斜手机 // 0.4
为灵敏度值,根据具体情况调整
window.addEventListener(‘deviceorientation’, e => { let gamma =
e.gamma if (gamma < -70) gamma = -70 if (gamma > 70) gamma = 70
this.engine.world.gravity.x = (e.gamma / 70) * 0.4 })

1
2
3
4
5
6
7
8
// 最大倾斜角度为 70 度,让用户不需要过分倾斜手机
// 0.4 为灵敏度值,根据具体情况调整
window.addEventListener(‘deviceorientation’, e => {
  let gamma = e.gamma
  if (gamma < -70) gamma = -70
  if (gamma > 70) gamma = 70
  this.engine.world.gravity.x = (e.gamma / 70) * 0.4
})

2. 背景图

本游戏布景为游戏机及海底世界,两者可以作为父容器的背景图,把 canvas
的位置定位到游戏机内即可。canvas 覆盖范围为下图的蓝色蒙层:

图片 33

3. 墙壁

因为环的刚体半径比贴图半径小,因此墙壁刚体需要有一些提前位移,环贴图才不会溢出,位移量为
R – r(下图红线为墙壁刚体的一部分):

图片 34

4. 针

为了模拟针的边缘轮廓,针的刚体由一个矩形与一个圆形所组成。下图红线描绘了针的刚体:

图片 35

为什么针边缘没有像墙壁一样有一些提前量呢?这是因为进针效果要求针顶的平台区域尽量地窄。作为补偿,可以把环刚体的半径尽可能地调得更大,这样在视觉上环与针的重叠也就不那么明显了。

进针

进针是整个游戏的核心部分,也是最难模拟的地方。

进针后

两个二维平面的物体交错是不能产生“穿过”效果的:

图片 36

除非把环分成前后两部分,这样层级关系才能得到解决。但是由于环贴图是逐帧图,分两部分的做法并不合适。

最后找到的解决办法是利用视觉错位来达到“穿过”效果:

图片 37

具体做法是,当环被判定成功进针时,把环刚体去掉,环的逐帧图逐渐播放到平放的那一帧,rotation
值也逐渐变为 0。同时利用 CreateJS 的 Tween 动画把环平移到针底。

进针后需要去掉环刚体,平移环贴图,这就是上文为什么环的贴图必须由
CreateJS 负责渲染的答案。

伪代码:

JavaScript

/ Object Ring afterCollision (waterful) { // 平移到针底部
createjs.Tween.get(this.texture) .to({y: y}, duration) // 消去刚体
Matter.World.remove(waterful.engine.world, this.body) this.body = null
// 接下来每一 Tick 的更新逻辑改变如下 this.update = function () { const
texture = this.texture if 当前环贴图就是第 0 帧(环平放的那一帧){
texture.gotoAndStop(0) } else { 每 5 个 Tick 往前播放一帧(相隔多少 Tick
切换一帧可以凭感觉调整,主要是为了使切换到平放状态的过程不显得太突兀) }
// 使针大概在环中央位置穿过 if (texture.x < 200) ++texture.x if
(texture.x > 213 && texture.x < 300) –texture.x if (texture.x
> 462) –texture.x if (texture.x > 400 && texture.x < 448)
++texture.x // 把环贴图尽快旋转到水平状态 let rotation =
Math.round(texture.rotation) % 180 if (rotation < 0) rotation += 180
if (rotation > 0 && rotation <= 90) { texture.rotation = rotation

  • 1 } else if (rotation > 90 && rotation < 180) { texture.rotation
    = rotation + 1 } else if (frame === 0) { this.update = function () {} }
    } // 调用得分回调函数 waterful.score() }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
/ Object Ring
afterCollision (waterful) {
  // 平移到针底部
  createjs.Tween.get(this.texture)
    .to({y: y}, duration)
  // 消去刚体
  Matter.World.remove(waterful.engine.world, this.body)
  this.body = null
  // 接下来每一 Tick 的更新逻辑改变如下
  this.update = function () {
    const texture = this.texture
    if 当前环贴图就是第 0 帧(环平放的那一帧){
      texture.gotoAndStop(0)
    } else {
      每 5 个 Tick 往前播放一帧(相隔多少 Tick 切换一帧可以凭感觉调整,主要是为了使切换到平放状态的过程不显得太突兀)
    }
    // 使针大概在环中央位置穿过
    if (texture.x < 200) ++texture.x
    if (texture.x > 213 && texture.x < 300) –texture.x
    if (texture.x > 462) –texture.x
    if (texture.x > 400 && texture.x < 448) ++texture.x
    // 把环贴图尽快旋转到水平状态
    let rotation = Math.round(texture.rotation) % 180
    if (rotation < 0) rotation += 180
    if (rotation > 0 && rotation <= 90) {
      texture.rotation = rotation – 1
    } else if (rotation > 90 && rotation < 180) {
      texture.rotation = rotation + 1
    } else if (frame === 0) {
      this.update = function () {}
    }
  }
  // 调用得分回调函数
  waterful.score()
}

进针判断

进针条件

1. 到达针顶

到达针顶是环进针成功的必要条件。

2. 动画帧

环必须垂直于针才能被顺利穿过,水平于针时应该是与针相碰后弹开。

当然条件可以相对放宽一些,不需要完全垂直,下图红框内的6帧都被规定为符合条件:

图片 38

为了降低游戏难度,我规定超过针一半高度时,只循环播放前6帧:

JavaScript

this.texture.on(‘animationend’, e => { if (e.target.y < 400) {
e.target.gotoAndPlay(‘short’) } else { e.target.gotoAndPlay(‘normal’) }
})

1
2
3
4
5
6
7
this.texture.on(‘animationend’, e => {
  if (e.target.y < 400) {
    e.target.gotoAndPlay(‘short’)
  } else {
    e.target.gotoAndPlay(‘normal’)
  }
})
3. rotation 值

同理,为了使得环与针相垂直,rotation 值不能太接近 90 度。经试验后规定 0

下图这种过大的倾角逻辑上是不能进针成功的:

图片 39

初探

一开始我想的是把三维的进针做成二维的“圆球进桶”,进针的判断也就归到物理事件上面去,不需要再去考虑。

具体做法如下图,红线为针壁,当环刚体(蓝球)掉入桶内且与 Sensor
(绿线)相碰,则判断进针成功。为了使游戏难度不至于太大,环刚体必须设置得较小,而且针壁间距离要比环刚体直径稍大。

图片 40

这种模拟其实已经能达到不错的效果了,但是一个技能打破了这种思路的可能性。

产品那边想做一个放大技能,当用户使用此技能时环会放大,更容易套中。但是在桶口直径不变的情况下,只是环贴图变大并不能降低游戏难度。如果把环刚体变小,的确容易进了,但相近的环之间的贴图重叠范围会很大,这就显得很不合理了。

改进

“进桶”的思路走不通是因为不兼容放大技能,而放大技能改变的是环的直径。因此需要找到一种进针判断方法在环直径小时,进针难度大,直径大时,进针难度小。

下面两图分别为普通环和放大环,其中红色虚线表示水平方向的内环直径:

图片 41

图片 42

在针顶设置一小段探测线(下图红色虚线),当内环的水平直径与探测线相交时,证明进针成功,然后走进针后的逻辑。在环放大时,内环的水平直径变长,也就更容易与探测线相交。

图片 43

伪代码:

JavaScript

// Object Ring // 每一 Tick 都去判断每个运动中的环是否与探测线相交
update (waterful) { const texture = this.texture // 环当前中心点坐标
const x0 = texture.x const y0 = texture.y // 环的旋转弧度 const angle =
texture.rotation // 内环半径 const r = waterful.enlarging ? 16 * 1.5 :
16 // 根据旋转角度算出内环水平直径的开始和结束坐标 // 注意 Matter.js
拿到的是 rotation 值是弧度,需要转成角度 const startPoint = { x: x0 – r
* Math.cos(angle * (Math.PI / 180)), y: y0 – r * Math.sin(angle *
(Math.PI / 180)) } const endPoint = { x: x0 + r * Math.cos(-angle *
(Math.PI / 180)), y: y0 + r * Math.sin(angle * (Math.PI / 180)) } //
mn 为左侧探测线段的两点,uv 为右侧探测线段的两点 const m = {x: 206, y:
216}, n = {x: 206, y: 400}, u = {x: 455, y: 216}, v = {x: 455, y: 400}
if (segmentsIntr(startPoint, endPoint, m, n) || segmentsIntr(startPoint,
endPoint, u, v)) { // 内环直径与 mn 或 uv 相交,证明进针成功
this.afterCollision(waterful) } … }

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
// Object Ring
// 每一 Tick 都去判断每个运动中的环是否与探测线相交
update (waterful) {
  const texture = this.texture
  // 环当前中心点坐标
  const x0 = texture.x
  const y0 = texture.y
  // 环的旋转弧度
  const angle = texture.rotation
  // 内环半径
  const r = waterful.enlarging ? 16 * 1.5 : 16
  // 根据旋转角度算出内环水平直径的开始和结束坐标
  // 注意 Matter.js 拿到的是 rotation 值是弧度,需要转成角度
  const startPoint = {
    x: x0 – r * Math.cos(angle * (Math.PI / 180)),
    y: y0 – r * Math.sin(angle * (Math.PI / 180))
  }
  const endPoint = {
    x: x0 + r * Math.cos(-angle * (Math.PI / 180)),
    y: y0 + r * Math.sin(angle * (Math.PI / 180))
  }
  // mn 为左侧探测线段的两点,uv 为右侧探测线段的两点
  const m = {x: 206, y: 216}, n = {x: 206, y: 400},
        u = {x: 455, y: 216}, v = {x: 455, y: 400}
        
  if (segmentsIntr(startPoint, endPoint, m, n) || segmentsIntr(startPoint, endPoint, u, v)) {
    // 内环直径与 mn 或 uv 相交,证明进针成功
    this.afterCollision(waterful)
  }
  
  …
}

判断线段是否相交的算法可以参考这篇文章:谈谈”求线段交点”的几种算法

这种思路有两个不合常理的点:

1.当环在针顶平台直到静止时,内环水平直径都没有和探测线相交,或者相交了但是
rotation 值不符合进针要求,视觉上给人的感受就是环在针顶上静止了:

图片 44

解决思路一是通过重力感应,因为设置了重力感应,只要用户稍微动一下手机环就会动起来。二是判断环刚体在针顶平台完全静止了,则给它施加一个力,让它往下掉。

2.有可能环的运动轨迹是在针顶划过,但与探测线相交了,此时会给玩家一种环被吸下来的感觉。可以通过适当设置探测线的长度来减少这种情况发生的几率。

优化

资源池

资源回收复用,是游戏常用的优化手法,接下来通过讲解气泡动画的实现来简单介绍一下。

气泡动画是逐帧图,用户点击按钮时,即创建一个 createjs.Sprite。在
animationend 时,把该 sprite 对象从 createjs.Stage 中 remove 掉。

可想而知,当用户不停点击时,会不断的创建 createjs.Sprite
对象,非常耗费资源。如果能复用之前播放完被 remove 掉的 sprite
对象,就能解决此问题。

具体做法是每当用户按下按钮时,先去资源池数组找有没有 sprite
对象。如果没有则创建,animationend 时把 sprite 对象从 stage 里 remove
掉,然后 push 进资源池。如果有,则从资源池取出并直接使用该对象。

当然用户的点击操作事件需要节流处理,例如至少 300ms
后才能播放下一个气泡动画。

伪代码:

JavaScript

// Object Waterful getBubble = throttle(function () { //
存在空闲泡泡即返回 if (this._idleBubbles.length) return
this._idleBubbles.shift() // 不存在则创建 const bubble = new
createjs.Sprite(…) bubble.on(‘animationend’, () => {
this._stage.removeChild(bubble) this._idleBubbles.push(bubble) })
return bubble }, 300)

1
2
3
4
5
6
7
8
9
10
11
12
// Object Waterful
getBubble = throttle(function () {
  // 存在空闲泡泡即返回
  if (this._idleBubbles.length) return this._idleBubbles.shift()
  // 不存在则创建
  const bubble = new createjs.Sprite(…)
  bubble.on(‘animationend’, () => {
    this._stage.removeChild(bubble)
    this._idleBubbles.push(bubble)
  })
  return bubble
}, 300)

环速度过快导致飞出边界

Matter.js
里由于没有实现持续碰撞检测算法(CCD),所以在物体速度过快的情况下,和其他物体的碰撞不会被检测出来。当环速度很快时,也就会出现飞出墙壁的
bug。

正常情况下,每次按键给环施加的力都是很小的。当用户快速连续点击时,y
方向累积的力也不至于过大。但还是有玩家反应游戏过程中环不见了的问题。最后发现当手机卡顿时,Matter.js
的 Tick
没有及时触发,导致卡顿完后把卡顿时累积起来的力一次性应用到环刚体上,环瞬间获得很大的速度,也就飞出了游戏场景。

解决方法有两个:

  1. 给按钮节流,300ms才能施加一次力。
  2. 每次按下按钮,只是把一个标志位设为 true。在每个 Matter.js 的 Tick
    里判断该标志位是否为 true,是则施力。保证每个 Matter.js 的 Tick
    里只对环施加一次力。

伪代码:

JavaScript

btn.addEventListener(‘touchstart’, e => { this.addForce = true })
Events.on(this._engine, ‘beforeUpdate’, e => { if (!this.addForce)
return this.addForceLeft = false // 施力 this._rings.forEach(ring =>
{ Matter.Body.applyForce(ring.body, {x: x, y: y}, {x: 0.02, y: -0.03})
Matter.Body.setAngularVelocity(ring.body, Math.PI/24) }) })

1
2
3
4
5
6
7
8
9
10
11
12
btn.addEventListener(‘touchstart’, e => {
  this.addForce = true
})
Events.on(this._engine, ‘beforeUpdate’, e => {
  if (!this.addForce) return
  this.addForceLeft = false
  // 施力
  this._rings.forEach(ring => {
    Matter.Body.applyForce(ring.body, {x: x, y: y}, {x: 0.02, y: -0.03})
    Matter.Body.setAngularVelocity(ring.body, Math.PI/24)
  })
})

结语

如果对「H5游戏开发」感兴趣,欢迎关注我们的专栏

1 赞 收藏
评论

图片 27

发表评论

电子邮件地址不会被公开。 必填项已用*标注