一群大佬猛肝30天 最后就做出个13kb的游戏？

游戏里我们控制一只小蜘蛛，要从一个房间的入口一段走到出口，并进入到下一个房间。

这当中我们要躲避各种会旋转的陷阱，一旦不小心碰到陷阱，小蜘蛛就会没命。

随着关卡难度增加，各种奇怪的陷阱也层出不穷。

比如你走着走着会遇到突然出现的方块，要过关的话，只有记住方块出现和消失的规律，在一个完美的瞬间穿过去。

再比如这个全图都在变大变小的圆圈，因为看起来很容易让人眼花，所以你在移动的时候，一定要保持好距离。。

别的不说，就这赛博风格和各式各样的陷阱都不敢想，这个有 20 个关卡的游戏居然只有 13kb。

后来顺着游戏的名字在网上搜了一圈，才发现这个游戏原来是出自于一场叫 js13kGames 的大赛。

它的比赛规则很简单，用 JavaScript 开发一个 H5 游戏，时间期限为 1 个月。

不过有一个要求，你最终提供的游戏文件 zip 压缩包大小必须在 13kb 以内，而且你的游戏不可以使用任何挂载在服务器上的图片、文件等。

换句话说，这 13 kb 包含了游戏运行需要的全部文件。

尽管有了体积和时间的限制，但让人惊讶的是，不管是玩法和画面，这些网页游戏居然还挺丰富的。

比如 2020 年的冠军作品：Ninja vs.Evilcorp。

游戏里我们扮演一个忍者，需要从起点出发，通过跳跃、爬墙等方式来到电脑旁偷到资料。

每个关卡中，除了有监控，还有来回巡视的安保，一旦被他们视线扫到，我们就要重来。

光看看忍者屁股后面的幻影效果，还有跳跃时的白色尘土效果这些细节，你告诉我这只有 13kb？

还有这个叫 The Last Spartan（ 最后的斯巴达人 ），游戏里我们在一块草原上进行砍杀，随着时间不断增加，敌人的数量和种类也会随之增多。

游戏里攻击招式也比较齐全。

除了普通攻击，我们可以使用 J + K 来突刺别人，或者是 J + Space 肉弹冲击，造成范围性伤害。

再来看看这个小车过河的游戏，它采用了和纪念碑谷类似的视觉错位。

这个 3D 画面下，小车被断桥挡住了去路，但如果切换到了 2D 画面，两个桥梁就很巧妙地连接上了。

随着难度增加，游戏也逐渐复杂起来，到后面不仅需要切换 2D 和 3D 画面，还需要移动视角才能过关。

看到这里大家一定好奇，这些游戏是怎么把体积控制在 13kb 以内的。

说起来你可能不信，除了有过人的编程技术，这些开发者还精通了五花八门的抠门学。

因为他们为了把游戏体积控制在 13kb ，把能抠的地方都抠过了。。

往往一个游戏里，素材图片占据了很大的比重。

如果要单纯地减小这些图片体积，我们可以使用压图工具进行压缩。

比如一个原本 173kb 的图片，重复压缩四次后就只有 80kb ，如果再重复压缩下去，可能最后只有几 kb。

当然，这个方法未免有点效率太低。

有些开发者采用了另外一种方法：用光圈来代替原图。

比如大赛里有一个 3D 迷宫博物馆的游戏，场景里放满了各种世界名画，有梵高也有蒙娜丽莎。

要展示一张蒙娜丽莎的画像，我们可以利用算法，让几十个光圈的无限组合，最后得到一张最接近的图片。

如果你摘掉眼镜拿远了看下图（ 不近视的请尝试让眼睛失焦 ），就会发现右边的光圈看起来其实跟左边没啥区别了。

所以，在游戏里告诉玩家这是一张蒙娜丽莎的画像，我们不需要放上一张几百 kb 的图片。

利用这些光圈，只需要在代码中敲出每个光圈位置、半径和颜色数据就行了。

当然了，就算你把素材压缩足够小，但要是素材数量太多，还是会超过 13kb 的限制。

所以开发者们最要做的，就是把素材重复利用。

比如上面的忍者游戏，你仔细观察会发现看似丰富的场景下，其实有很多重复的素材，有的最多也只是换了一种颜色。

除了上面这些素材图片要处理，游戏里的文字也是让参赛者头大的一个问题。

要在游戏里显示文字，就需要调用字体库。

尽管一个通用字体库只有十几 kb，但这明显不适合用在 13kb 大小的游戏上。

所以有聪明的开发者想到做像素字体。

首先他创立一个对象，这个对象由 3x5 个空白格子组成，每个格子里可以填入 true（ 真 ）或者 false（ 假 ）。

当填入 true 的时候，格子就会被涂上一个黑色的像素。

那如果填入 false，这个格子就会被跳过，留下空白。

那么要把这个对象涂成一个字母 A，我们可以按照下面的方式填入 true 和 false。

这个填入方式对应的代码也就是：

多 1 个字母就会多占 1 个字节，为了把体积缩到最小，我们可以用 1 来代替 true，把 false 删掉。

所以优化后的代码如下。

这样一来，原本在游戏里显示一个字母 A 需要调用十几 kb 字库，现在只需要十几个字节了。

解决了文字和图片的问题，开发者还需要把代码压缩得尽可能小。

通常做一个游戏都需要借助游戏引擎或者框架，来减少一些工作量。

但常见的游戏框架肯定不适合做 13kb 的游戏。

好在这游戏已经举办了不少年，有一些早期参赛选手自己做了一些游戏微框架，并提供给后来的参赛者。

比如有人做出了一个非常轻量级的游戏框架 Kontra.js。

如果要在游戏中做出一个不断循环的元素，原本可能需要敲下几十行的代码，但通过Kontra.js 只需要几行代码就能实现。

光是这种方式缩减代码还不够。

在编程中有一类工具叫混淆器，它在保证不破坏原功能的前提上，把源代码混淆成让人难以理解的格式，来保护源代码。

怎么混淆呢？

比如把变量和函数用单字母代替、删除代码之间的空格、将多行代码挤到一行等等。

大家有没有注意到它的混淆方式中包含了 “ 缩减中间变量和函数 ”，“ 去掉空格 ” 。。

巧了。。

这就意外地让混淆后的代码相比之前缩小了 25% 左右。

所以，这个主要用来保护源代码的工具也被大家用来缩减代码体积。。

除此之外，还有人建议编写代码时尽量少用一些层级目录（ 少用一些分类文件夹 ）。

虽然这样编写时会比较乱，但至少在游戏文件最终打包的时候，压缩率会高一点。

特意还做了测试验证了一下：

把 3 个文件直接放在一个文件夹内，压缩得到 A.zip。

把同样的 3 个文件分别放到 3 个小文件夹内，然后把这 3 个小文件夹放到一个大文件夹内，再压缩得到 B.zip。

经过对比发现，虽然文件一模一样，但是 A.zip 确实小了几百个字节。。

不仅是压缩上抠细节，这些选手还会对压缩包再压缩。

用什么软件都有讲究，比如有人就建议使用 advzip，因为它相对其他的压缩软件能多缩小 1kb 。。

看到这些开发者个个跟抠门学大师一样的操作，其实也能理解他们。

毕竟你要把一个游戏做得既有趣，又得控制在 13kb 以内，真就好比用电锯剪鼻毛，每一步都得小心翼翼。。

但恰恰在这些压力下，开发者会绞尽脑汁去优化自己的代码，去挖掘自己的脑洞。。

所以反而意外的让他们做出了这些比较好玩的，有创意的游戏。

这也让我想到了另外一个例子：《 超级马里奥 》。

你可能从未想过，这个多达 32 个关卡的过关游戏，它只有 40kb。

我们曾经出过一期视频告诉大家是怎么做到的，这里再稍微讲讲。

和上面讲到 13kb 游戏素材重复利用一样，马里奥也是有一套素材包。

我们只需要在需要用到素材的时候，把他拖放过去。

当然了，这些素材包也要能省就省。

比如游戏里的草垛，其实就是白云的上半部分换个颜色罢了。

再比如马里奥一整套的动作，是由 21 张图像（ 准确说法为 Sprite ）组成的。

但 21 张图片占用空间太多，所以开发者把每张马里奥图片都切成了 4 份，去掉相同的部分。

这样剩下的素材依然可以通过组合，来完整马里奥所有的动作。

如果你仔细观察，就会发现花朵和星星都是对称的。

其实游戏开发者只存储了半只花和星星，只是在显示它们的时候，把它们复制了一下再放出来罢了。

你看，虽然限制非常严苛，但这并不妨碍开发者们做出影响了几代人的《 超级马里奥 》。

这样的例子还不少。

比如早期因为机器性能问题，根本做不出 3D 游戏，那怎么表现出 3D 效果呢。

在上世纪 80 年代就有开发者想出利用平行投影，通过倾斜视角来展示游戏画面，从而产生立体效果。

1982 年世嘉出品的《 Zaxxon 》▼??

这类游戏也被称为等距游戏，这种方式也被各种 RPG 和战略类游戏所采用。

还有开发者想到利用视差滚动的效果，让 2D 画面更有立体感。

什么是视差滚动？

我们坐车的时候向窗外看，会感觉远处的山脉移动速度慢，近处的稻田和建筑物移动速度快。

那游戏里也可以把远处的背景速度拉慢，距离镜头较近的物品速度拉快，模仿人类视觉效果，营造立体感。

1981 年推出的《 Jump Bug 》就采用了视差滚动效果，仔细看近处的大楼要比远处的白云移动速度快很多。

这个方式后来经常被用在横版闯关游戏里，甚至还有一些网站为了提高逼格，也用上了这种视觉效果。

所以尽管当时各项硬性条件不足，但是开发者还是发挥了他们最大的能力，给我们做出了一代又一代经典的游戏。

虽说现在随着科技高速发展，开发者们做游戏很少有这样那样的条件限制。

但是通过这样一个 13kb 的比赛，我们发现如今依然有人可以在这种严苛的限制下，做出优质的游戏。可以看到只要尽力了，困难永远都不能限制到他们，办法也总比困难多嘛。当然在某种层面上，这个道理也适用于所有人。