為什么魂斗羅只有 128KB 卻可以實現那么長的劇情?下面來給新生代程序員講講這里面的奧秘吧。

現代程序員 A 和 1980 年代游戲程序員 B 的對話：

A：為什么你用 128KB 能實現這么多畫面、音樂、動畫?

B：128KB 還不夠么?其實為了表現力已經相當奢侈了，加了很多不重要的細節。

A：就說你們的音樂，這個音樂，我壓到最低碼率的 MP3，也得至少 1MB 吧。

B：你怎么壓的?一首背景音樂怎么可能超過 1KB。

A：那你實現全屏卷軸，用了多少顯存?

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

A：……

1我們對“數據量”無法直觀認識

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

一般人對“數據量”并沒什么概念。一篇 800 字的作文有多少數據量?按照 GBK 編碼，約 1.6KB，按照 UTF-8 編碼，則是 2.4KB。

只寫了 1 個字的作文，按理來說 1 字節~3 字節就夠了。但只寫 1 個字的 word 文檔，有 10956 字節。而由于硬盤格式化要求，再多占用 1332 字節。 

我就寫了一個字，真的什么都沒干

現實中常見的產品、流行的技術，實際上和時代背景密切相關。

當你抱著 15 寸筆記本還嫌小的時候，1990 年代初的家庭，可是一家人圍著 14~18 寸的球面電視看的。把雪碧拿給古代人喝一口，估計他會齁得要死，必須喝點水壓壓驚。 

當物質基礎變得十分豐富的時候，一定會產生無法避免的“浪費”，這種“浪費”會進一步改變人感受的閾值，對度量的估計都變得紊亂了。

2FC 時代的圖形技術

由于早期的記憶芯片(ROM)非常貴，而且大容量磁盤的技術也不成熟，所以暫且不論硬件計算能力，僅僅是想增加游戲的總容量也非常困難。所以自然會使用符合當時水平的數據結構。

以紅白機 FC 為例，它的分辨率為 256x240。分辨率不算低，但卻只有 2KB 顯存，而且還要實現全屏卷軸效果。

所以在 FC 設計之初，從硬件上就提供了充分利用顯存的方法——使用 Tile(瓦片)。

對每一個場景來說，使用若干數量的瓦片，場景用有限的瓦片拼接即可。這種“二級”表示方法能極大節約存儲量。

具體一些原理講解可以看一些科普，比如這個：

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

3,音頻容量和代碼容量

現代音樂格式往往直接保存聲道的波形，這種做法保真度高、通用性強，但很顯然占用空間多，一首曲子的容量以千字節、兆字節計算。

而八位芯片時代的音頻解決方案，關鍵是一顆專用芯片，例如 FC 用的理光 2A03： 

下：理光 2A03

音頻芯片可以產生合成音效，能提供的音色可以在一定程度上配置，但非常有限。聽聽 FC 游戲的音樂可以體會到常用的音色幾乎一樣。

我覺得這個音頻芯片最厲害的地方是可以同時播放幾個音軌(但不能是和弦那種“同時”)，《魂斗羅》、《沙羅曼蛇》、《忍者龍劍傳》的殿堂級音樂，主要是靠多個音軌的交替配合實現的。

每個音符只要記錄音色、頻率和音高就足夠了，音頻芯片自然會識別出來。把音符按時間排列好就是“樂譜”了，可以簡單理解為“簡譜”。 

這種簡譜需要的數據量十分有限，而且大部分游戲音樂都是循環播放，數據量更是小的可憐。

代碼也是類似的。

FC 時代的游戲，沒有所謂的“引擎層”，或者說引擎層就是“硬件層”。任天堂的主機完全是為游戲而設計的，瓦片、調色板、音樂、音效等基本功能已經預先考慮到了，這樣一來就節約了大量底層代碼。

程序員要仔細研究文檔，在硬件框架下思考問題，比如如何顯示圖片、如何卷動屏幕等等;而且還要非常熟悉硬件底層和匯編，不要浪費代碼空間。

一來二去，代碼也能寫的非常小。

總的來說，128KB 的游戲大作，在 30 年前稀松平常，放到現在簡直就是黑科技。 

科技的劇烈變革帶來技術指標非線性的變化，讓我們的記憶和直覺徹底落伍!