嗯,我想写一个2048已经好久好久了……
人蠢是一种怎样的体验?
连个2048都不会写。
当然啦,我说的2048一定是指带动画的版本,静态的我早就写过了。“写个动画有什么难的?”我在动手写之前也是这么想的,后来发现这背后的问题大了……不过在此之前,我们先明确一下2048的规则。
一群2们究竟是怎么合成一个2048的
一个简单的问题:一行四个2,为什么合成的是两个4,不是一个8或者一个4+两个2?
在2048中,一次滑动之后,要经过以下的步骤:
- 按照滑动的方向把数字分为四列,每列之间互不干涉。
- 按照滑动的方向把各数字标号,手指轨迹指向的方向为“大端”,从大端开始分别标号为1,2,3,4。
- 从2号数字开始,称为当前数字,执行以下的步骤
- 查看当前数字前面的一个位置;
- 若该位置被标记为“已合并”,则当前数字停在该位置之后的一个位置上;
- 若该位置上有数字,则若该数字与当前数字一样,就将当前数字合并到该位置上,并将该位置标记为“已合并”;否则,将当前数字移动到该位置之后的一个位置上;
- 若该位置没有数字,则继续看该位置之前的一个位置,并重复以上步骤;若一直看到1号位置都没有数字,则将当前数字移动到1号位置上。
以上的步骤对每列的数字顺次执行,即前一个数字操作完了后一个数字再开始,当所有数字都操作完时这次滑动的效果全部完成。如果在整个过程中没有任何一个数字的位置或大小发生变化,则认为这是一个无效操作;否则在空格区域随机添加一个数字,位置完全随机,数字有十分之一的概率是4,其余是2。开局的两个数字与此一致。
经过上面的一番长篇大论,大致可以看出,操作的基本单位是数字,而基本操作有三种:移动,合并和新增。其中合并是指一个数字不动,另一个数字移动到其位置与之合并,该操作又可以分为两步:先移动,然后目的地的数字替换为加倍的数字。为什么要把合并拆开看?仔细观察2048游戏界面就会发现,每次滑动过后的动画,是按照移动、合并和新增的顺序进行的,只有所有的移动动画全部结束以后(无论是单纯的移动还是合并的前半部分),才会开始合并的动画。到这里,为什么动画难实现的回答也有了一半:所有的操作不能按照算法的顺序直接作用在局面上,要先存起来,整理好顺序才能执行。
而另一半原因则是这三种操作本身的区别:移动和替换都是针对一个数字,而新增则是从无到有;移动时,两个数字可能会移动到同一个位置上。按照一般的思路……算了我已经把一般的思路忘得差不多了。接下来就是Try2048登场的时间了。
相比起2048的“官方”实现,这应该算是一个超级短小的程序,目前还没有500行,因此没有分散在多个文件里,预期就是让读者可以一口气看到低——记得当初实在写不出去看官方版本的时候,还没有看懂那些现在看来连设计模式都算不上的封装就已经被吓跑了,真是怀念啊。写代码的思路基本是分层,然后由下至上的实现,因此本文也采取这样的顺序。
最底层并不是画界面,我认为这个层面可以慢慢写,所以首先抽象了三个基本操作:
|
|
这样做之后给自己带来了一些小小的麻烦,下文中会详细讲到。可以看到,函数体原本只有一行log,后来写好了底层才对接了上来。接受的参数中finished
是一个不带参数的回调函数,调用它即意味着当前基本操作完成了。是的,这些接口都会在动画执行之前就返回,因此需要这个参数确定确切的完成时间。原本只打印log的时候finished
就直接就地调用了,现在则需要传下去。
有了基本操作的表示以后,进入到最复杂也是最重要的一个抽象层次:Turn
。它代表着一次滑动所触发的所有基本操作的集合,对上层提供的接口除了向集合中添加基本操作外,还有一个Trigger
函数,在执行时会按照上文所述的顺序执行所有的基本操作,并且等待一类基本操作都执行完了再执行下一类,它还可以携带一些钩子函数,在合适的时机触发它们。首先是内部数据结构:
|
|
其中_actions
存了每种基本操作的每一个操作的调用参数,比如advent
中的元素形式为{x, y, number}
,与上面的接口相对应,而_remain
中则是每种基本操作的剩余个数。
接下来是向Turn
中添加操作的接口:
|
|
其中,Merge
在该层被抽象出来,上层将可以使用真正需要的三个接口进行调用。接下来的Trigger
函数……做好心理准备:
|
|
以上是该函数的第一部分。由于对于三种基本操作的处理方法基本一致,因此抽象出一个pattern。整个思路还算清晰,有点别扭的大概就是上面的decrease
了,这是因为原本调用是用的self._remain.advent
之类,后来发现不行,因此基本类型是传值调用的,于是改成{value: self._remain.advent}
,结果还是不行,因为保留更改的只是这个匿名对象里的值,而从self._remain.advent
到这个匿名对象还是复制了……所以接下来如果看到这种东西:
|
|
希望你能体会我的无奈。
哦你说为啥参数里没有afterMerge
?这不是赤裸裸的歧视吗?一方面我还没想好怎么把它对接到替换上去,另一方面……其实这俩也是因为用上了才慢慢加上的,afterMerge
?没有这种需求,当然就没有啦。
看完第一部分我想你已经猜到了接下来怎么调用它,不过也许你发现了一些不得了的东西:为什么这个函数要返回一个匿名函数?这不是多此一举吗?如果我告诉你这是为了保持和after
参数形式的一致性,我想你大概能预感到一些可怕的事情了。没错,我遵循那个著名的信条:
嵌套回调函数是丑陋的。
原话大概还包含了对其的一个形象的比喻,不过被我忘记了。总之,作为嵌套回调转化为链式的准备步骤,就有了接下来的第二部分:
|
|
可惜我当时脑子不太好使,不然应该可以写出一个不需要缓存参数的版本。现在……脑子更不好使了,就当没看见吧。从嵌套到平铺的一个关键问题就是没有after
,因此首先对各个函数调用进行科里化,延缓其对after
的需求。最后,第三部分包含了套参数和组装的过程:
|
|
使用reduceRight
就可以按照自然顺序进行链式调用了(“在CurryList
里不能处理吗?”“听不见听不见……”),顺便你会发现在接口层当中预留的finished
函数其实就是上面第一部分中定义的,基本逻辑是给计数器减一,到0就调用after
开始下一阶段。afterXXX
也都被安排到了合理的位置上。
顺便一说写到reduceRight
的时候我突然想起对IE的兼容性问题,于是万念俱灰的用IE11打开这个页面,没想到在去掉了默认参数和Array.fill
以后居然正确的运行了!这一刻我的喜悦和程序刚刚跑通时相比有增无减。
下一个抽象层次是Grid
,它代表一张棋盘。在这里,我们终于要迎来喜闻乐见的游戏逻辑,而在此之前,问自己一个问题:如何避免把同样的代码写四遍?官方实现用的方法非常精巧,而我就笨拙得多了。进入主题前先看看内部数据结构:
|
|
一个简单的二维数组,因为去掉了Array.fill
所以显得有些啰嗦,不过倒是有点像我上一篇文章里说的,有点C程序的感觉了,只是现在……我谢天谢地它不是用C写的。跳过生成随机数字的函数,首先来看Slide
的第一部分:
|
|
这个子函数的功能是把一列数向着它的首元素方向“滑动”,逻辑基本就是上文的复述。这里主要注意的是移动数字以后对于“是否改变”的判定,要把“原地移动”的情况排除掉。想来这个函数功能的简单出乎各位看官的预料,那么更多的功能显然交给调用方了。大家等不及看四遍重复的代码了吧?然而,还真没有……
|
|
在对不同的情况把numbers
当中的数排好顺序的同时,填好iX
和iY
两个数组,作为两个平行数组分别储存numbers
中各元素的x和y坐标。在SlideVector
中使用的move
和merge
也在此处被包装好,提供足够的信息去调用下层的接口。在此之后,Grid
当中还有一个判断游戏是否结束的函数,主要检查两件事:还有没有空位,以及有没有相邻的相同元素,符合任何一个条件都还是活局,否则就死了。
以上两个层次作为这篇代码的精华,也是最华而不实的部分……如果把其中为了形式美观做的抽象(科里化、SlideVector
子函数等)都去掉,再把所有的左大括号拿到上一行去(做梦吧),这篇代码也许就只剩300多行了。
接下来是组装前的最后一个步骤:画界面层。在这里我就遇到了之前给自己挖的坑:接口层留的三个基本接口实在是太“纯粹”了,它们都是无状态的接口,不能在两次调用之间留存任何信息。而偏偏图形层就需要一些信息:比如说前一个调用创建了一个数字,后一个调用去移动它的时候,得先在DOM树上把它找回来。之前采用id来标识,就会遇到两个数字移动到同一个位置的尴尬局面。最后先妥协了一下,用了全局变量,之后尽量把它改过来,先凑合着看吧。
|
|
其中还有大量的常数,之后会抽到配置当中去。这里的三个全局(列)表都是为DisplayMove
服务的,在一个Turn
的周期内,所有的数字以如下的方式在这三个表中流窜:
- 最初,所有数字都在
searchTable
里; - 移动阶段,每个数字移动的同时,把自己注册到
registryTable
的对应位置上,如果遇到两个数字都移动且终点相同的情况则后来者会覆盖先到者,并把它转移到deadQueue
里面去。(这里谁去谁留没有区别,因为这种情况之后一定会对应一个替换步骤,所以……谁都活不了) - 移动结束阶段,首先
deadQueue
里的数字被清除掉,然后registryTable
里的数字转移回searchTable
里,如果转移回来的时候发现对应的格子里已经有数字了,说明这是一个数字移动到另一个静止数字位置上的情况,则静止数字被清除,由新来的数字填补。 - 接下来的时间里,大家都一直呆在
searchTable
里,直到下一个移动阶段到来。
这里的一个要点就是一定要到移动结束阶段(对应于DisplayAfterMove
函数)才可以开始清理重叠的数字,对于静止的数字,这是为了防止格子上的数字突然消失吓到小朋友;对于两个数字都移动的情况,别忘了它们身上还有一个finished
呢,这个函数的调用时机是transitionend
事件(比手动setTimeout
高端多了),如果提前清掉了移动阶段就再也结束不了了。这几个方法的结尾都有一个OnceListener
函数的调用,这个函数会给元素添加一个绑定在transitionend
事件上的一次性回调函数,触发了就被移除,避免与下一个finished
弄混。
此外,DisplayAdvent
要实现的动画效果是从中心一个点开始扩大,要把设置其样式为正常值的部分放在setTimeout(..., 0)
的里面,这样可以避免与前面的DOM操作合并,动画没了是小事,触发不了transitionend
可就坏了。
最后,DisplaySubstitute
(感谢这个程序终于让我记熟了这个词的拼写)的效果是先变大一圈再变小。你问我为什么不写成链式的了?懒啊!
好了,最后终于来到了主函数部分:
|
|
大部分逻辑都一目了然了。其中animating
是为了在动画过程中屏蔽按键(虽然除非你是故意瞎滑也不可能那么快做出判断),而“Game Over”的界面不仅仅是没有加入到真正的页面上,甚至没有完成其正确性测试……每一局都因为各种奇奇怪怪的原因流产了……最后一次是在IE11上,我把它的console调出来看看输出,然后键盘操作就不好使了……什么龟。
感觉就像讲了一生的故事一样,这份代码经过几次推倒重来,虽然最终版只用了小半天时间,但算是近很长一段时间以来唯一一个算是完整的作品。当然啦,只能叫“算是”,毕竟这份代码的最终目的——帮我玩出4096,还一点都没开始呢。
项目地址:try-2048,欢迎丢星星。