40KB大小的红白机游戏能做成什么样？这支独立团队在挑战这个极限
现在还有人为35年前发售的FC开发游戏吗？答案是“有”，并且还不少。这支名为Morphcat Games的二人独立团队也在开发一款全新的FC游戏，并且他们在挑战一个新的极限：将游戏的容量控制在40KB以内。
仅有40KB的FC游戏存在吗？存在，初代《超级马力欧兄弟》就是。但如果将它的画面和Morphcat Games正在开发的《Micro Mages》相比，或许你会发现Morphcat Games到底是在挑战什么样的极限。
《超级马力欧兄弟》固然是经典中的经典，画面也达到了当时的最高水准。虽然《超级马力欧兄弟》的画面和《Micro Mages》比起来有点不那么生动，但是它同样也在压缩上付出了艰辛的努力。
和现在的游戏不同，FC游戏的画面由背景和活动块构成，背景是固定的，顶多能以卷轴形式活动，活动块的位置可以变化，但如果想让它们做出“动作”，就要像动画片一样，轮流播放不同的图案。游戏中用到的所有图案，包括角色动作的每一帧形象，都保存在ROM里。
但这就是马力欧在游戏里保存的活动块吗？其实并不是
FC前期的卡带上有2个记忆晶片，其中一个是跟CPU关联的PRG，它储存了游戏程序和声效，另一个是CHR，它跟FC的图形处理器（Picture Processing Unit）关联，里面保存着游戏用到的所有图形素材。在一张40KB的卡带上，CHR的大小只有8KB，并且其中一部分只能用于活动块，另一部分只能用于背景——这么做的目的是让开发者尽可能多地利用这些空间。
背景和活动块的每个单位，都是8x8像素大小的图案。FC呈现的画面本质上是一个32x28的网格，因此分辨率是256×224。每个活动块只能包含三种颜色，所以想用单个活动块去表现角色是非常难的。在《超级马力欧兄弟》里，吃了红蘑菇的长大马力欧就包含8个活动块。
那么，在一个8KB大的CHR里，留给活动块的空间是多少呢？答案是只能摆256个。栗子小子的走路动作，其实是一副形象不停地镜像切换，这也是为了节省空间。
而由于角色的形象都是活动块拼接而成的，所以保存在CHR里的数据，其实长这样：
而在这么多的限制下，《Micro Mages》还要做到以下几点：
主角除了移动和攻击之外，还有踩墙跳、攀爬等等动作
支持1-4人同屏游戏
8个大关，26个小关
隐藏要素和高难度模式
最后，这款游戏要被制作成卡带，并能够真实地在FC上运行。
Morphcat Games准备制作的实体版游戏
你可能会问，不管是日版的FC还是欧美的NES，不都只能插两个手柄吗？其实在1990年，任天堂为NES发售了一款名为“NES Four Score”的手柄分插器，当时有20多款游戏支持四人对战，日本市场则是由外设大厂HORI推出了同等功能的设备。
当然，可能大部分玩家都不曾知道FC/NES有四人对战的游戏，因此《Micro Mages》支持这个玩法，算是强行提高难度。FC游戏的另一项限制，是画面每行只能显示8个活动块。你可能会发现一些FC游戏有时候会出现角色身体的某块部位消失的情况，这就是同一行超过8个活动块导致的。
而四人对战，毫无疑问地增加了出现这种bug的可能。
Morphcat Games原本设计的主角是一个戴着帽子的小男孩，但这个形象需要占用4个活动块，如果4个玩家一起玩，那么同一行的活动块数量就会达到8个，这时候再出现一个敌人，角色们就会出现角色闪烁、消失的问题。
如果主角形象需要占用4个活动块，同一行的活动块数量就很可能超过8个
主角的形象也因此被改成了戴着帽子、黑着脸的1.5头身小法师，这个形象只占用1个活动块，因此在游戏画面上，它看起来比我们熟知的任何FC游戏主角个头都要小，而这也可能是开发组把游戏名定为“Micro Mages”的原因。
开发组为小法师设计了多达23种动作状态，这使得它看起来比其他任何FC游戏主角都要活泼，而这些动作也只占用了23个活动块，因此CHR里还可以放下很多敌人和NPC。
游戏中还存在着一些体型较大的敌人，开发组也想为它们设计出不同的动作和表情，这时候的压缩大法，自然是将对称的地方整合复用了。
这是第一关BOSS的所有表情，每个的大小为4x4个活动块
把BOSS切开，将一些可以复用的部位整合成一个
在场景上，FC运作的方式，就像是从背景CHR里选出指定的方块图案，放到指定的位置上，因此每个场景都需要花费一定的容量去记录方块的摆放方法。如果按照32x28的规格去记录，那么一屏场景的数据就要占用960字节的空间，很奢侈。
Morphcat Games的做法，是在原有的背景库之外，额外设置两个库，将4个方块组合在一起，称之为“大方块（meta-tile）”，并且把组合而成的各种大方块放在“大方块库”里。
这是最基础的素材库
这是大方块库，其中的每一个方块都有4个基础方块构成
这还没完。他们又把4个大方块组合在一起，称之为“大大方块（meta-meta-tile）”，然后再把它们放在“大大方块库”里。
这是大大方块库，每一个方块都由4个大方块构成。另一个需要注意的是这个库里格子的数量
这样做的话，在记录场景数据时，画面的密度就相当于从32x28变成了8x7，只占用60字节的空间。但Morphcat Games发现，这样做还是没法把游戏压缩到40KB大小。
《Micro Mages》是一款竖卷轴、玩家需要不断向上爬的平台动作游戏，这也给开发组提供了缩减容量的思路：如果把一幅场景对半劈开只保留一半，再把留下的这一半镜像对称填充到另一边，就能将容量缩减一半。
但是，如果很多场景都是这种对称式的结构，游戏就太无聊了。Morphcat Games当然还有其他的魔术，不过在揭晓之前，我们先来做一个小算术。
首先，一个大大方块占用的大小是1字节，即8比特，8比特代表的是一堆由8个数字构成的二进制数，即从“00000000”到“11111111”，共256个，也代表着大大方块可以有256种形态。
但是，开发组只设计了96种大大方块，计数通常从0开始，因此这96个大方块编号分别为0到95，而95换算成二进制是1100000，只有7位。这意味着开发组可以把没有用到的一位拿出来，去耍一些别的花样。
在经过对称处理之后，场景的一行相当于有4个8比特，每个比特的空余位拿出来，就成了一个4比特，即“0000”到“1111”，共16个。开发组将对称的图案进行平移，并将平移的结果记录在这4比特中，创造出了不对称的场景。
而在高难度模式下，场景则只需要改变色盘和挑选一些不同的大大方块，就能创造出游戏体验截然不同的关卡。
下面这些，都是Morphcat Games在极力压缩容量之后创造出来的惊人画面：
就像一开始我们说的，现在还在为FC开发游戏的人还有不少，而比《Micro Mages》画面好的FC游戏也是有的。去年有一款全新的FC游戏，叫《闪亮星星之夜DX》，画面是这样的：
但这款游戏的容量高达512KB，内容也很少。FC上单游戏容量最大的记录保持者是《大航海时代》和民间自制游戏《9人街霸》，它们的容量都是640KB。
看到这里，或许你可以理解，为什么直到现在都有人热衷于为FC开发游戏了。这台诞生于35年前的玩具依然有着不小的可能性。以前游戏开发者所面临的局限性不仅仅是性能，开发环境、美术制作环境以及测试环境都能成为掣肘，对于一些资金压力较大的小公司来说更是如此。
《Magic Mages》在9月初上线Kickstarter开始众筹，可点击这里前去支持。他们在一天之内就达到了17676美元的目标金额，并且筹款额依然在持续上升，目前已经接近10万。这个结果也代表了众多复古游戏爱好者们对他们的肯定。
与游戏的玩法创意相比，开发者在程序层面上的设计并不能被大多数人看到，但程序的设计、挤海绵的过程，往往也有创意之美。对于普通玩家来说，游戏如何去压缩容量并不重要，他们甚至可能觉得容量小的游戏缺乏诚意。而愿意关心游戏设计和程序里的各种细节，也算是真正爱游戏的人们独有的特质了吧。