开发者（KaiFaX）

面向全栈工程师的开发者
专注于前端、Java/Python/Go/PHP的技术社区

来自 | 知乎

来源丨https://www.zhihu.com/question/50076174

仅作学术交流，如有侵权，请联系删文。

   提问

为什么魂斗罗只有128KB却可以实现那么长的剧情？

   高质量回答

皮皮关

划重点：这里是游戏开发小班培训 http://www.levelpp.com

https://www.zhihu.com/question/50076174/answer/1101330430

现代程序员A和1980年代游戏程序员B的对话：

A：为什么你用128KB能实现这么多画面、音乐、动画？

B：128KB还不够么？其实为了表现力已经相当奢侈了，加了很多不重要的细节。

A：就说你们的音乐，这个音乐，我压到最低码率的mp3，也得至少1MB吧。

B：你怎么压的？一首背景音乐怎么可能超过1KB。

A：那你实现全屏卷轴，用了多少显存？

B：一共就只有2KB显存，多了也放不下啊。

A：……

我们对“数据量”无法直观认识

除非是专家，一般人根本无法估算到底多大算大，多小算小。

一般人对“数据量”并没什么概念。一篇800字的作文有多少数据量？按照GBK编码，约1.6KB，按照UTF-8编码，则是2.4KB。

只写了1个字的作文，按理来说1字节~3字节就够了。但只写1个字的word文档，有10956字节【汗】。而由于硬盘格式化要求，再多占用1332字节【再汗】。

我就写了一个字，真的什么都没干

现实中常见的产品、流行的技术，实际上和时代背景密切相关。

当你抱着15寸笔记本还嫌小的时候，1990年代初的家庭，可是一家人围着14~18寸的球面电视看的。把雪碧拿给古代人喝一口，估计他会齁得要死，必须喝点水压压惊。

当物质基础变得十分丰富的时候，一定会产生无法避免的“浪费”，这种“浪费”会进一步改变人感受的阈值，对度量的估计都变得紊乱了。

FC时代的图形技术

由于早期的记忆芯片（ROM）非常贵，而且大容量磁盘的技术也不成熟，所以暂且不论硬件计算能力，仅仅是想增加游戏的总容量也非常困难。所以自然会使用符合当时水平的数据结构。

以红白机FC为例，它的分辨率为256x240。分辨率不算低，但却只有2KB显存，而且还要实现全屏卷轴效果。所以在FC设计之初，从硬件上就提供了充分利用显存的方法——使用Tile（瓦片）。

对每一个场景来说，使用若干数量的瓦片，场景用有限的瓦片拼接即可。这种“二级”表示方法能极大节约存储量。具体一些原理讲解可以看一些科普，比如这个：

【萌新图形学】TileMap瓦片地图简介，以及它的优化原理

https://www.bilibili.com/video/BV19J411e763

音频容量和代码容量

现代音乐格式往往直接保存声道的波形，这种做法保真度高、通用性强，但很显然占用空间多，一首曲子的容量以千字节、兆字节计算。

而八位芯片时代的音频解决方案，关键是一颗专用芯片，例如FC用的理光2A03：

下：理光2A03

音频芯片可以产生合成音效，能提供的音色可以在一定程度上配置，但非常有限。听听FC游戏的音乐可以体会到常用的音色几乎一样。我觉得这个音频芯片最厉害的地方是可以同时播放几个音轨（但不能是和弦那种“同时”），《魂斗罗》、《沙罗曼蛇》、《忍者龙剑传》的殿堂级音乐，主要是靠多个音轨的交替配合实现的。

每个音符只要记录音色、频率和音高就足够了，音频芯片自然会识别出来。把音符按时间排列好就是“乐谱”了，可以简单理解为“简谱”。这种简谱需要的数据量十分有限，而且大部分游戏音乐都是循环播放，数据量更是小的可怜。

代码也是类似的。

FC时代的游戏，没有所谓的“引擎层”，或者说引擎层就是“硬件层”。任天堂的主机完全是为游戏而设计的，瓦片、调色板、音乐、音效等基本功能已经预先考虑到了，这样一来就节约了大量底层代码。

程序员要仔细研究文档，在硬件框架下思考问题，比如如何显示图片、如何卷动屏幕等等；而且还要非常熟悉硬件底层和汇编，不要浪费代码空间。

一来二去，代码也能写的非常小。

总的来说，128KB的游戏大作，在30年前稀松平常，放到现在简直就是黑科技。科技的剧烈变革带来技术指标非线性的变化，让我们的记忆和直觉彻底落伍 ：）

知乎用户

索尼互动娱乐（上海）有限公司 开发技术支持经理

https://www.zhihu.com/question/50076174/answer/1102335113

一个古老的问题，因为某些机构号挖坟，被我看到了。作为那个时代的亲历者，来给新生代程序员讲讲这里面的奥秘吧 。

其实，玩过小霸王学习机的话（不是打游戏，而是编程），应该多少都知道。没玩过的话，那种用文字拼的图，见过吧。网上有很多。那种图，显然比一张图片，容量要小多了吧。

FC时代的游戏，画面就是这个原理。整个画面是由一块一块“马赛克”拼出来的。就好像《我的世界》里面用块块拼各种造型那样。

因为是8bit CPU，int类型（准确来说，是可以直接操作的整数）是8bit。所以，索引范围是0-255。也就是这样的砖块最多能有256种。也就是说，你所看到的任何一关，都是由这最多256种砖块拼出来的。（当然，不同关卡可以使用不同的砖块，就好像《我的世界》里面的皮肤那样）

这个砖块的大小是8x8像素。FC的画面分辨率为256x240，容易计算得出就是32x30个砖块（tile）。

此外，砖块本身也并非是按照今天的图片那样，按照RGB三通道直接存储颜色，而是使用调色板。8bit的调色板虽然理论上最多可以支持256种颜色，但是实际上FC整体上只能输出64色（其中还有重复色）：

而且即便是这64色还不能直接使用，而是要从中挑选出要用的颜色，放入到总共4个调色板当中，才可以使用。每个调色板只能有4色，其中0号颜色强制为透明。也就是说，每个调色板其实只能放入3个自选色（还必须从上面64个里面选），4个调色板共12色，+透明，共计13色。

每个砖块可以最多绑定一个调色板。因为一个调色板是4色，所以每个像素只需要2bit就可以索引这4种颜色。这样存储一个砖块的内存容量其实是8x8x2bit=16byte。256个砖块就是4KB。

然后其实画面分两层：背景、前景。背景可以使用单独的256个砖块，4个调色板；前景也有自己的256个砖块，4个调色板。所以这样的话一关最多是512个砖块，8个调色板。调色板数量很少存储大小忽略不计，512个砖块存储需要8KB。

然后就是实际记录游戏场景（背景）以及人物武器装备子弹等的开销。背景前面计算了，一屏幕需要32x30个砖块，砖块之间不能重叠。因为是从256个砖块里面选，所以需要8bit的索引。那么一屏幕（背景）就是32x30x8bit=960字节。

各个关卡的长度不一。下面是所有关卡的背景图：

https://www.nesmaps.com/maps/Contra/ContraBG.html

以最长的第五关为例，该关背景图为5616x240，那么也就是横轴差不多22屏。这样的话存储这个背景所需的索引值的总容量就是960x22=21KB的样子。

前景。前景就是那些人物啊，子弹啊，炮台什么的。FC最多支持64个前景“精灵”（之所以叫这个名字是因为和背景的块块不同，前景的块块可以放在画面任何位置且可以相互重叠，像精灵一样漂浮）。每个8x8（或者8x16）像素。保守起见按全部都是8x16（2个tile）计算（事实上不是），那么总共就是8bit/tile * 2tile/sprit * 64 sprits = 128B。（注意游戏当中的角色等很多是由多个精灵组成的，特别是boss，所以精灵并不是和角色一对一的）

https://www.nesmaps.com/maps/Contra/sprites/ContraSprites.html

所以，满打满算，前景背景都用足256个砖块，且所有砖块都不同，8KB的砖块存储+前景索引128B+背景索引21KB/关 * 8关，大约176KB的样子。当然此外还有程序（逻辑）的部分，音频的部分（音频的部分其实是MIDI而且音符很少，大概CDEFGAB+cdefgab，也就是2个八度音阶的样子（音高。音色是通过三角波方波等波形控制，也有的游戏卡里加入了额外的波形生成芯片），容量很小），但是显然背景部分是最耗的。其它场景都没有第五关那么长，甚至部分关卡短得多，而且有些关卡之间雷同很高，砖块可以大量复用（比如如果仔细看第五关的背景图，显然不同的砖块远远少于256个）。所以这样看下来大致上128KB是没有问题的。

http://www.vgmpf.com/Wiki/images/5/55/06_-_Contra_-_NES_-_Snow_Field.ogg

1. 回复“m”可以查看历史记录；
2. 回复“h”或者“帮助”，查看帮助；开发者已开通多个技术群交流学习，请加若飞微信：1321113940  (暗号k）进开发群学习交流说明：我们都是开发者。视频或文章来源于网络，如涉及版权或有误，请您与若飞（1321113940）联系，将在第一时间删除或者修改，谢谢！开发者：KaiFaX面向全栈工程师的开发者
专注于前端、Java/Python/Go/PHP的技术社区