有一个很魔性的网页过关游戏，正如你猜的那样，它的体积只有13kb。游戏里我们控制一只小蜘蛛，要从一个房间的入口一段走到出口，并进入到下一个房间。这当中我们要躲避各种会旋转的陷阱，一旦不小心碰到陷阱，小蜘蛛就会没命。随着关卡难度增加，各种奇怪的陷阱也层出不穷。比如你走着走着会遇到突然出现的方块，要过关的话，只有记住方块出现和消失的规律，在一个完美的瞬间穿过去。
再比如这个全图都在变大变小的圆圈，因为看起来很容易让人眼花，所以你在移动的时候，一定要保持好距离。
别的不说，就这赛博风格和各式各样的陷阱，咱都不敢想，这个有20个关卡的游戏居然只有13kb。后来我们顺着游戏的名字在网上搜了一圈，才发现这个游戏原来是出自于一场叫js13kGames的大赛。它的比赛规则很简单，用JavaScript开发一个H5游戏，时间期限为1个月。
不过有一个要求，你最终提供的游戏文件zip压缩包大小必须在13kb以内，而且你的游戏不可以使用任何挂载在服务器上的图片、文件等。换句话说，这13kb包含了游戏运行需要的全部文件。
尽管有了体积和时间的限制，但让人惊讶的是，不管是玩法和画面，这些网页游戏居然还挺丰富的。比如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的比赛，我们发现如今依然有人可以在这种严苛的限制下，做出优质的游戏。
可以看到只要尽力了，困难永远都不能限制到他们，办法也总比困难多嘛。当然在某种层面上，这个道理也适用于所有人。