為什麼魂鬥羅只有128KB卻可以實現那麼長的劇情?

閆孫


你好兄弟,我是正在認證遊戲領域的老玩家強仔,希望我的回答能夠幫助到你

關於你的問題,我一共整理了4點要素

1.遊戲大量複用圖塊,圖塊還使用調色板索引,好像每個像素才佔用2bit。

2.程序員精心優化各種數據結構,每一bit存儲都不浪費。

3.聲音只存儲發聲通道的調製參數序列,能複用就複用。

4.代碼全是彙編寫成,直接操作硬件,基本不存在浪費的指令。


老玩家強仔


說起《魂鬥羅》容量問題,其實美版和日版還不同,我們小時候玩的黃卡基本都是美版(盜版),卡帶容量比較小,而日版其實要比美版大一倍。

玩過日版的《魂鬥羅》會發現,這個版本中每關之後都是有過場動畫的,通關動畫也比美版多一個坐直升飛機的過程。

關於容量的問題,當時FC紅白機實現圖像的原理的核心就是“重複利用”,開發者製作一個個小方塊作為基本元素,放在一個庫中(CHR圖形庫),遊戲中所有的圖像都是由圖形庫中的基本元素拼接成的。

像現在一張照片就要幾M,放在當時是不可能做到的,所以不得不採取重複利用的方式。


AGamer


魂鬥羅有劇情嗎?題主可能說的是關卡的長度吧,這樣說的話,魂鬥羅遊戲的長度確實不算短的,可容量卻如此之小,其實原因大概如下幾點。

一款遊戲中最佔用容量的地方在哪

首先,玩法肯定是最不佔容量的部分,這些都是通過代碼實現的,一款遊戲中最佔用容量的地方在於畫面,音樂,還有過場動畫,早期的FC遊戲自然是沒有什麼過場動畫的,音樂都是一種類似於MIDI的電子音樂,幾乎不佔用什麼容量,畫面則是由一個個的基礎像素點配上顏色來構成的,遊戲的分辨率也是非常的低,所以以這些元素來構成的遊戲,容量自然大不到哪裡去,128KB,還沒有如今的手機隨便拍一張照片大。

建模重複與鏡像

這在當年的FC遊戲中是各個遊戲廠家非常慣用的手段,一方面是省事,另一方面就是節省容量了,在很多遊戲中我們都會見到各種重複的建模,RPG遊戲中的一些NPC,樹林,山脈,很明顯的重複,超級瑪麗,重複的怪物和地形,魂鬥羅也是一樣。鏡像是什麼意思呢,比如我們要構建一個左右對稱的角色或者道具吧,我們只要做一半就好了,剩下的一半以鏡像複製的方式來實現就完整了,很簡單吧。

總結

當然了,這些都是當年由於科技發展,沒有辦法才採取的一些技巧,或者是偷懶吧,現在的遊戲其實也會使用一些,但不會那麼明顯的被玩家們看出來了,因為現在的遊戲容量方面可以說沒有什麼問題的,技術方面也是,最大的問題是,好看是越來越好看了,可有多少玩家還能找回當年玩魂鬥羅時候的樂趣呢?


8090遊戲迷


超級瑪麗才64K,劇情比魂鬥羅還長。

當年電腦技術的限制和成本限制導致FC硬件性能不行,FC上魂鬥羅、超級瑪麗這種優秀的遊戲,在設計階段就考慮怎麼實現“人看上去內容豐富,實際技術層面單調”,遊戲策劃人員和程序員密切合作,實現了效果好、容量小、對性能要求還低。

例如魂鬥羅這種遊戲中,由於主機內存空間有限,任何一幀畫面的顏色其實只有16種,但通過美工巧妙的設計,人家16色的畫面達到了256色的效果。

今天的很多2D遊戲基本都是65536甚至更高的色彩,除了少數優秀作品,大部分遊戲顏色搭配上感覺也沒有超越魂鬥羅。

你看看今天XBox上贈送的"大戰喵星人\

煙花煙柳煙燻裝


您好,我是小哪吒,很高興回答你的問題。現代程序員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寸的球面電視看的。把雪碧拿給古代人喝一口,估計他會齁得要死,必須喝點水壓壓驚。

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

2、FC時代的圖形技術

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

以紅白機FC為例,它的分辨率為256x240。分辨率不算低,但卻只有2KB顯存,而且還要實現全屏卷軸效果。所以在FC設計之初,從硬件上就提供了充分利用顯存的方法——使用Tile(瓦片)。

對每一個場景來說,使用若干數量的瓦片,場景用有限的瓦片拼接即可。這種“二級”表示方法能極大節約存儲量。具體一些原理講解可以看一些科普,比如這個:

【萌新圖形學】TileMap瓦片地圖簡介,以及它的優化原理_嗶哩嗶哩 (゜-゜)つロ 乾杯~-bilibili​

3、音頻容量和代碼容量

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

而八位芯片時代的音頻解決方案,關鍵是一顆專用芯片






遊戲呆雞小哪吒


1.遊戲大量複用圖塊,圖塊還使用調色板索引,好像每個像素才佔用2bit。

2.程序員精心優化各種數據結構,每一bit存儲都不浪費。

3.聲音只存儲發聲通道的調製參數序列,能複用就複用。

4.代碼全是彙編寫成,直接操作硬件,基本不存在浪費的指令。



王者小記者


7z


隨波而流85456481


FC和小霸王主機自帶SDK庫吧,這些128KB遊戲主要是調用庫,所以風格類似~


分享到:


相關文章: