为什么有32个关卡的游戏《超级马里奥兄弟》只要40KB? 第1页

首先，为什么是40KB？

因为FC在硬件上，CPU允许一次性映射ROM中32KB的数据（感谢指正，并非是读入内存而是映射，即分配一个可访问的地址），而PPU则是一次能用8KB。如果超过这个容量，也不是不可以，只是无法一次性将整个ROM中的数据映射到地址空间，而是需要动态切换，在需要的时候，将ROM中的特定数据映射（这叫做切换bank）。超级马里奥兄弟1代没有使用这样的技术，所以最大可用的容量就是32+8=40KB。

其他回答主要讲到了FC对于图像的处理，这其实是所有FC游戏（以及很多传统游戏机上的2D游戏）的处理方法。也就是说，这种压缩是通用的，并非超级马里奥兄弟独有。至于广为人知的“树丛和云使用的相同的图像”这一点，其实很有趣，因为它们的tile虽然确实一样，但使用了两个不同的meta-tile。

什么是meta-tile呢？

把4个8x8的tile组合起来，就是一个meta-tile。meta-tile的大小显然是16x16。用meta-tile的好处是，原本一个（比方说）32x32的图像只需要用4个meta-tile来描述，而原本需要用16个tile来描述。虽然我们需要额外的空间来存储meta-tile，但是meta-tile是可以公用的，不会占据额外的空间。

已经有人反编译出了可读的马里奥1代源代码（注意是可读的。简单地将FC的二进制数据反汇编成6502汇编码很容易，但那是不可读的）。从中可以看出，云和树丛使用的meta-tile不同，尽管它们的tile一致：

       ...... Palette0_MTiles:   .db $24, $24, $24, $24 ;blank   .db $27, $27, $27, $27 ;black metatile   ;这里是树丛   .db $24, $24, $24, $35 ;bush left   .db $36, $25, $37, $25 ;bush middle   .db $24, $38, $24, $24 ;bush right   .db $24, $30, $30, $26 ;mountain left   .db $26, $26, $34, $26 ;mountain left bottom/middle center   .db $24, $31, $24, $32 ;mountain middle top ...... Palette2_MTiles:   ;这里是云，注意云有下半部分，树丛没有   .db $24, $24, $24, $35 ;cloud left   .db $36, $25, $37, $25 ;cloud middle   .db $24, $38, $24, $24 ;cloud right   .db $24, $24, $39, $24 ;cloud bottom left   .db $3a, $24, $3b, $24 ;cloud bottom middle   .db $3c, $24, $24, $24 ;cloud bottom right   .db $41, $26, $41, $26 ;water/lava top ......     

至于为什么要分两个meta-tile，可能是因为需要使用不同调色板的原因。

这个回答不打算涉及更多的关于图像的方面，毕竟图像只有8KB（实际上还有几十个字节空余），而前面的程序代码有32KB，而且是一个字节也没有空余了（尽管中间还是有几个字节的多余代码）。而且，问题中提到了“32个关卡”，所以我打算主要说一下32个关卡对空间的占用。

32KB的代码当中，32个关卡占用了4647字节，约占总代码量的1/7。可能有人会很意外：32个内容丰富的关卡的数据，比游戏运行代码的数据量更少吗？事实上，马里奥1代的代码不算简单，光马里奥，就需要处理走、跑、蹲、转身、跳跃、游泳、顶砖、爬藤、发射火球、进水管（纵向和横向都有），还有与物体的互动，如踩怪、弹簧跳、与各种移动平台交互等。现代的游戏的这些细节都可以交给引擎来做，但FC时代并没有游戏引擎，所有的这些都需要自行处理。并且除了代码，还有音乐和文本，以及前面提到的meta-tile数据，都算在这32KB里了（尽管这些加起来也没有关卡数据多）。

怎样用4647字节描述出全部32个关卡（包括各种奖励区域在内）呢？我们以1-1举例。

马里奥1代的关卡，分为敌人和地形两部分，分开存储。1-1的敌人占用30字节，地形占用101字节（不含地下奖励区域，这个后面会提到）。

如果你玩《马里奥制造》，你可能会误以为马里奥1代的地图是一格一格存储的。但对于马里奥1代来说，连图像都要用tile、meta-tile、实际显示这样三级压缩，一格一格存储地图实在太过奢侈。

首先，我们发现整个地面都是2格高的，这意味着不需要把整个地形存储下来，只要存储“整个关卡都是2格高的地面”，就行了。马里奥1代设置了16种地形，这种2格高的地面就是其中一种，其他的还包括：没有地面（如1-3使用），下面2格高地面+天花板1格封死（如1-2、1-4使用）等等。16种地形，只占用半个字节：也就是说我们用半个字节就存储了整个1-1的地面。只是我们需要在地面上挖3个坑而已。

然后，我们关卡中的一个物体，其实只要2个字节：位置以及类型。

一个关卡这么长，怎么只用一个字节就能描述位置呢？我们注意到1代所有关卡都是1屏幕高的，而一个物体的大小是16x16，所以纵坐标只要16格就足够了（屏幕是240像素高，我们凑个整，用256像素）。而横向上，我们把每16格划分为一“页”。这样每一页都只有256个格子，刚好用1个字节就够了。

那么不同的页怎么办呢？我们可以在某个物体上标记一个“换页”。游戏读取到这个标记后，就表示在这以后的物体都是在下一页（或者下一页以后），不用在这一页加载这些物体了。这个标记只要1个bit就行了（只有“换页”和“不换页”两种），可以从物体类型的那个字节挤出来：毕竟马里奥1代不需要256种物体类型，去掉1比特后，剩下128种也足够了。

我们发现物体不会埋在地下，所以纵坐标有些位置是用不到的。这可以用来设置一些特殊物体：比如坑，它不需要纵坐标，我们就不需要浪费描述纵坐标的那半个字节，而那半个字节完全可以描述“坑的大小”。又比如，如果有一整页都没有物体，要怎么描述呢？我们也可以用一个特殊的“跳页”物体来描述。这个物体显然也不需要横坐标和纵坐标。特殊物体还有个好处：它可以不占用那128种物体的数量，因为它和普通物体是分开处理的。

而物体的类型，则还包括了物体的大小。比如关卡的中间部分一长排的横向砖，其实并不是很多个物体并排，而是一个“长度为8的横向砖块”。这样一来，128种物体还够用吗？不够。但没事，马里奥1代做了很多特殊处理，强行压缩到了128种不同的物体，比如：

• 炮台和蘑菇平台，其实是同一种物体，只是在不同风格的关卡中显示不同而已。
• 地面和地下场景可以顶碎的砖块，在水下会变成不可顶碎的紫色珊瑚，它们也是同一种物体。
• 有些地方有一长排的？砖块，但这种砖块是特殊物体，不能设定它的纵坐标。它只能在2种特定的纵坐标出现。作为特殊物体，它不占用128种物体的数量。

• 水管只有“可进入”和“不可进入”两种，最高高度是8，所以水管物体只有16种。至于水管会通向哪里，则不是和物体存储在一起，而是和敌人的数据存储在一起的：游戏读取了目标位置后，所有水管和藤蔓都会把你传送到那个目标位置，直到游戏读取下一个目标位置或者进入下一关为止。（这也是马里奥1代速通当中，4-2进水管却到了爬藤蔓到达的跳关区域的原理。）
• 很多不需要纵坐标的物体也是特殊物体。如库巴的桥、斧头、旗杆、城堡等等。

还有各种各样节省关卡容量的特殊手段：

• 1-1后半段出现了2个4格高的台阶，这种台阶也是特殊物体，不是用4个物体拼起来的。旗杆前的8格台阶+右侧多一列的组合也是一整个特殊物体。
• 1-2有大量复杂的砖块，但是他们并非是很多砖块物体拼接而成的，而是不停地在16个地形之间切换。
• 1-1一开头有个“砖-蘑菇砖-砖-金币砖-砖”的设计，这里不是5个物体，而是一个5格长的横向砖，叠上2个？砖，总共3个物体。

最后，这个关卡的最前面，还有两个字节，表示关卡的整体属性，比如：

• 关卡一开始，是16种地形中的哪一种？（就是上面提到的半个字节）
• 关卡是什么类型的？（地面，地下，水下，城堡）
• 关卡有多少时间？（400、300、200）
• 关卡的背景是什么？（1-1是山丘和树丛，1-3是天空，而1-2的地下部分则什么都没有）
• 关卡是什么风格的？（比如第5世界其实是下雪的世界，第3世界是黑夜等等。还有上面提到的，关卡中到底是炮台还是蘑菇平台？）

关卡最后则是1个字节的结束标志。

敌人的设计也是类似的，这里就不详细讲了。除了固定放置的敌人，还有一种不停产生的敌人，比如2-3的飞鱼，5-3的炮弹等等。另外，水管里的食人花不需要专门设置：除了1-1，其他关卡每个水管里都有食人花。有时候没有食人花，是因为马里奥1代最多同时出现5个敌人（严格地说是除了马里奥以外的sprite），超出部分会被丢掉。

最后的最后，还有一点，就是关卡重用。比如奖励区域，很多关卡都会到相同的奖励区域（上述的1-1就有一个），这些区域其实也是重用的。还有一个更绝的关卡重用：1-2、2-2、4-2、7-2从地下或水下出来到地上，直到拉旗子的那一段，其实都是1-1的结尾。

有些关则是完全相同的，比如1-4和6-4，1-3和5-3等等，但是其中的敌人有所不同。但是没必要设置两套敌人，只要让一部分敌人在前面的那关不出现，在后面的那关出现就行了。马里奥1代有个分界线：5-3，所有这种相同的关卡中的敌人，都是区分在5-3之前出现，和在5-3之前不出现的。

总之，通过各种压缩手段，使马里奥1代的32个关卡的数据只占用了4647个字节。事实上游戏代码才是40KB中的大头。

首先，超级马里奥兄弟1（以下略做SMB1）的尺寸是40KB而不是64KB，32K的PRG（程序）和8K的CHR（图像）。

图像素材只有固定的几种“块”（Tile），地图可以进一步简化成表示了特定块组合（2x2）的二维数组，一格16x16像素。

1-1的尺寸只有212*13格，一格一个字节来算，也就是2756字节。但如果按照3k左右来算32个关卡容量肯定不够（光地图数据都有96KB了）。所以SMB1首先把对象做了抽象化，定义了一些“对象”，比如“砖块”、“管道”、“城堡”之类的，然后关卡数据仅保存这些“对象”的出现位置，一个对象占据2字节。连背景加敌人以及金币等数据，1-1的尺寸在131个字节，其他关卡基本也没有超过200个字节，这样一来32个关卡合计容量也就在7KB以内，外加几百个字节的字符和其他信息，剩下至少24KB可以用来存储程序代码。6502作为一个8位CPU，指令都不长，24KB可以作为代码来说是一个相当大的容量。

而FC的一个Tile（8x8像素）最多只能显示4种颜色，至于哪4种则可以自由选择（称作调色板），所以一个像素可以用2比特来表示，每8x8的图形占用16个字节。这个数据是不包含调色板信息的，调色板是程序动态指定的。虽说8KB的尺寸限制之下可以用的块只有512个，但是SMB1通过活用调色板也达到了多彩多样的图像。而且如上文所说，程序上把最基础的8x8像素的“块”抽象定义成了16x16像素的“块组合”，在每一关（也有可能是整个游戏）不超过128种块组合，并且每一关固定10种颜色组合成4种调色板，这样一个字节就可以代表一个块组合（2比特调色板+6比特块组合id），再进一步抽象定义“物件”，一个物件可以有多个块组合来构成。这样多层抽象的顶一下就可以大幅度节约内存，因为你的一个对象并不记录所有的块信息和他们的颜色。

于是，在这样的手法加持下，SMB1做到了40KB的限制下达到了极高的可玩性，提供了32个多彩多样的关卡。