點選上方 Java後端，選擇 設為星标
優質文章，及時送達
來自 | 知乎
連結 | 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
-END-
如果看到這裡，說明你喜歡這篇文章，請轉發、點贊。同時标星（置頂）本公衆号可以第一時間接受到博文推送。
推薦閱讀
1. 看小姐姐用動圖展示10大Git指令
2. 很用心的為你寫了9道MySQL面試題
3. MyBatis 事務管了解析
4. 最從寫履歷，到面試、談薪酬