制做2048游戏

下载 :: Game 2048 with Animation

今天的任务是给2048加上动画。别看用js的transition就搞定的事情，用GDI来实现是有难度的。

2048的游戏实现机制

虽然代码抄自gabrielecirulli/2048: A small clone of 1024 (https://play.google.com/store/apps/details?id=com.veewo.a1024) ，可是将js代码用lua去实现仍是多费了点工夫。固然二者都是动态语言，坑比较少。

如今来说下2048是怎样实现的。

首先，咱们看界面，它就是个4x4的方块，显而易见，用4x4数组或1x16数组就能搞定。那么数组里面存什么呢？咱们分析2048中的数值：空方格、2的幂次数值方块，就两种。解决方案是只要存int——空方格对应0；2的幂就对应它的幂。因此：空=0，2=1，以此类推，2048=11。所以数据结构很是简单，随便用伪代码表示：[2048-Table] = array<int>(4x4)。

知道了数据结构，那么接下来就是算法，这是难的部分。

算法须要解决一些问题：

• 处理每次的上下左右动做。这个是核心功能，有几个方面。1、判断是否要合并；2、不合并的话就将方块向前推到边上，直到推不动为止；3、随机位置增长新方块。
• 肯定当前是否为死局。这个简单，只要遍历4x4数组，看是否存在相邻的连续数值的方块。

下面解决主要问题。

1、判断是否要合并

假如当前按下Left键，方块向左移动，假如某行是“2-2-4-4”，那么结果是“4-8-0-0”，由于只须要合并相邻的方块；如果“2-2-2-2”，结果是“4-4-0-0”，不会是“8-0-0-0”，这是由算法决定的。

那么问题变简单了，正如memcpy所作的，若是memcpy(src,dst)，其中src和dst有交界部分。若src在dst前面，那么应该从后向前复制，反之是从前向后。

同理，方向为Left时，对于“2-2-4-4”，是从左向右遍历，先肯定“2-2”，将其换为4，变成“4-0-4-4”，而后处理右边两个4。此时，左起第一个4其实已经合并过了，将其排除，因此当前只要处理“0-4-4”，那么再将当中的4移至最左，成为“4-0-4”，再处理第二个4，因为第一个4还没有合并过，所以两个4再进行合并，成为8。最后结果“4-8-0-0”。

整理一个过程：Left，2-2-4-4，加[]表示已合并过，无需再次合并。2-2-4-4 => [4]-0-4-4 => [4]-4-0-4 => [4]-[8]-0-0。

2、对不能合并的方块进行移动

如“2-4-6-0”，方向Right，从右向左遍历。过程为：2-4-6-0 => 2-4-0-6 => 2-0-4-6 => 0-2-4-6。解释略。

3、随机增长新方块

增长新方块，添加2和4的几率比为9比1，用随机数实现。

而后须要寻找空位添加，这简单，遍历4x4数组，找到数值为0的将其位置记录，接着随机抽位子。

---------------------------------------

2048的动画实现机制

花了一天实现了方块的移动，也有难度。

项目相关：布局只支持新增GUI对象，不支持删除，所以须要一开始就建立好。

思路：原4x4中每一个方块对应一个GUI对象（记做origin），另外再新建4x4的GUI对象（记做anime），用于实现动画。

例：当前2-2-4-4，方向Right，结果为0-0-4-8。设计动画，假设[n]表明从左起第n个位置。

方块移动：[1,2,3,4] => [3,3,4,4]。那么当第一个2（位置为[1]）进行移动时，这时应该将origin方块隐藏，将替身anime方块代替origin位置并显现，随后播放动画，将anime的位置从[1]逐渐移动到[3]，移动完毕后，主角origin上场，替身anime下场。

总结一下：当origin须要移动时，召唤替身anime到指定位置，替身移动，最后替身消失，origin在替身消失的地方出现。替身移动其实就是插值思想。

另外，为防止动画没有播放完程序仍接受游戏指令致使逻辑乱套，所以在动画播放期间用户输入无效，否则动画就会出问题。

======我是分割线======

02/23更新

写在前面

通过坚持不懈的努力，第一个游戏已经制做完成。

游戏逻辑所有用Lua实现，发挥Lua的特长。

前期的辛苦，到第一个游戏完成时，已经烟消云散了，想必制做游戏的人们都是这个心情吧。

游戏简介

2048这个游戏很经典，当前它的游戏算法我是抄的:)，由于没足够时间去思考，可是它的算法难度不算过高，我以为没有Popstar implementation(MFC)难写（固然Popstar我也写过才敢这么说）。

不过，因为游戏框架功能有限，2048中的动态滑动效果还没有实现，下降了美观度。

那么搭建这个游戏的框架所具有的最小功能有哪些呢？

1. 交互层(Win32)：拦截Win32消息，处理好程序与系统的交互。
2. 逻辑层(Lua)：根据交互层传来的消息，实现界面或游戏逻辑，保证程序正常运行。
3. 渲染层(Direct2D)：遵从逻辑层命令，进行窗口的渲染。

从上面能够看出：Lua将交互层与渲染层相解耦，是十分重要的胶水语言。

这样作的好处有哪些？

1. 脚本语言的优点，如lambda函数、动态类型、yield等
2. 只需修改脚本，无需再次编译程序
3. 有出错提示，便于debug
4. 垃圾回收
5. 模块化

初次使用Lua就体会到它强大之处，在乎料之中。

实现思路

总结一下编写简单的游戏框架并用其实现2048整个过程当中的问题。

• Lua的坑。因为对它不熟悉，走了些弯路。Lua中统一用double保存整型与浮点，因此输出整数就要进行转换。再者就是类的问题，目前的问题是切换场景后，文本框的内容没有重置。
• D2D的坑。D2D的文档比较少，学着费劲。要注意RenderTarget无效问题，无效后必须立刻从新建立，连带以前的画刷、图片、文字等对象要所有重建。
• Win32的坑。这已经见怪不怪了，一个字，略。

那么总体的思路是：

1. 交互层，将Win32消息进行封装，对每一个消息调用Lua进行处理。这里比较重要的是窗口改变大小问题，将大小改变时，UI也要跟着改变、跟着放缩，不过UI的问题我所有用Lua脚本去作，省去很多麻烦。
2. 逻辑层，主要是Lua脚本的模块化构建。个人思路：根为场景（Scene），场景下有GDI对象（GdiObject），每一个GDI对象能够包含其余GDI对象，组成树结构。场景切换时，GDI树销毁并建立新的。还有一个就是布局（Layout），这里的思路比较经典，掌握基本的递归方法就能够写成。布局里有绝对布局、线性布局、表格布局，都比较简单，这些布局会自动调整成员的大小。
3. 渲染层，很少说，能用现成的就用。像画纯色矩形算简单，涉及富文本就复杂了，所以我暂时不考虑富文本状况，画画基本的几何图形就足够。这方面不算重要的内容。

由http://zhuanlan.zhihu.com/p/25401920备份。