FC/NES 遊戲是怎麼製作的？

01-14

更新：

我接觸到的所謂「開發秘話」大多是小公司的視點，但是就我力所能及的範圍內補充一下吧。

添加了大公司的開發環境以及Debug方法。

---------------------------------------------------

我在日本就讀專門學校時，我的老師正是那個年代的程序員，前世嘉家用機部門部長，從SG-1000年代走過來的老人，本人有幸從老師口中得知了許多知識，結合我自己的知識，就讓我稍微講講吧。

這位 @平機王作者觀察能力相當了得，發現了遊戲中的素材復用等細節，但是很明顯對遊戲開發的技術細節並不了解，寫了很多但是其中謬誤卻不少。比如「卡機死機」……在那個年代，沒有操作系統，程序絕對不可能「耗盡資源」而死機，一個正常的程序無論經歷多長時間總會完成指定的操作，進入下一個循環。

這裡就簡單講一下遊戲編程和普通軟體編程的區別。普通軟體的業務流程通常是，啟動，處理業務，結束這麼一套流程。但是遊戲的本質則是無限循環，程序啟動之後就會進入所謂的「主循環」，除非玩家主動退出（在那個年代甚至都沒有退出這個功能），就會永遠的循環下去。當然，每個循環肯定要給玩家不同的反饋，不然一動不動不就是死機了么。

而死機的理由通常不外乎三種：CPU執行了一個它不認識的機器碼/執行了HCF指令（Halt and Catch fire），試圖讀取/寫入一個不存在的內存地址導致CPU匯流排掛掉，或者在某個子程序之中陷入無限循環無法跳出，導致永遠無法進入下一個循環。

@孟德爾書記的答案比較貼切的描述了當時的製作場景（要結合評論觀看），但是並沒有涉及細節。不免讓人有種「欲求不滿」之感，於是下面就是一些乾貨了。

最開始，請記住初代FC的發售日是1983年7月。

製作遊戲，首先需要有策劃，這個階段通常就是在紙面上進行一些設計，確定美術風格，固化設定，探討各方面的可行性。和今日的遊戲開發差不多，當然，那個時代的想像力也是受到了一定的限制的……

拍板之後，就會開始寫「仕樣書」（對應英語Specification），詳細確定具體細節，以便日後程序員實現。當然，也有跳過這一步直接開始製作的，那個年代條件有限，全才比較多，程序員懂美術懂音樂司空見慣，遊戲策劃師本人就是主程序員的事情也不少見。

理想狀態下，自然是完整的企劃書，仕樣書，美術素材，音樂素材一切就緒之後開始寫程序，不過這是不可能的……所以通常大家會並行推進工作。

程序方面，想耍高級語言那是不可能的，6502的性能實在捉雞，編譯出來的C代碼跑起來那速度，畫面太美不敢想像，只能手寫彙編。而同樣是彙編，和今日的彙編相比起來那就是地獄級難度。為什麼？最開始的時候，那幫苦逼程序員手裡是沒有宏彙編器的！

這意味著什麼？

舉個栗子，在今天非常常見的彙編代碼寫法（以x86為例）：

push teststr call _printf add esp, 4 xor eax, eax ret

teststr : db "Hello World!"

現代的彙編器會自動計算出teststr所在的內存地址，並轉換成16進位數替換掉push後面的teststr。但是在那個年代，這根本就是天方夜譚，你需要在那裡留空，代碼全部寫好之後檢查一下位元組數，然後自己計算地址，寫入留空的地方，這是一件非常蛋疼的事情，那個年代的程序員需要克服的「Human Error」比今天的程序員們要多得多。到80年代後期，宏編譯器普及之後程序員們可算從計算地獄之中解放了出來……

當然也不會有什麼隨時隨地Debug執行一下看看效果之類的說法，想要看效果，就必須把寫好的程序和臨時素材燒進EPROM裡面（那個年代EEPROM也是稀罕貨，可編程ROM基本都是一次性的，這都是成本，也直接阻止了程序員們的大部分「試試看」的想法），在實機上執行。

需要Debug的信息么，就自己輸出到畫面上，於是就會產生遊戲完成的時候程序員忘了把Debug模式刪掉導致一些奇怪的秘籍的誕生……

而硬體Debugger是SFC才有的，彼時已經1990年，是FC發售的7年之後了……

真正財大氣粗的公司，對，我說的就是那些街機大佬出身的，比如說NAMCO。

他們在開發的時候一是硬體資源充足，他們可以用小型機寫代碼！他們能用VAX！那個年代這根本就是大殺器，都可以用軟體或者一些外圍硬體做各種模擬器（Emulation Probe）。那個年代硬體結構也相對簡單，任天堂並沒有做任何硬體保護，這幫人完全可以徹底分析硬體，然後用比如HP 64000之類的硬體開發平台，配上自己做的一些硬體模擬器，那開發效率自然是剛剛的。這些公司對FC硬體架構吃透之後，甚至可以自己開發第三方的MMC（內存映射控制器，可以讓FC通過切換BANK的方式定址多於64K的地址空間），並添加一系列音頻增強功能！

二是人力資源充足。我是說那種站在那個年代的角度的「上古程序員」。他們莫說彙編了，70年代做開發的時候都是直接手寫二進位代碼！你都能手寫二進位代碼了，在什麼平台上寫代碼還重要麼……我的老師就講過這方面的趣事，他是1981年進入了世嘉公司，那個時候幸運的是已經普及了彙編工具，他在寫代碼的時候遇到了一個BUG，盯著彙編好的二進位代碼發獃，旁邊的前輩過來看了看他的屏幕，指著一串數字說「你這裡寫錯了，應該寫成abcd....」，聽的我老師一愣一愣的。

那個年代程序員在現代角度來說一個個都是開掛神人……

還有一些中大型公司，他們可以買一些當年被稱作ROM模擬器玩意，通過串口把數據傳輸到板子上運行。比那些小型機，硬體開發平台之類的便宜很多，但是依然不是小型公司能買得起的……

美術方面，正如闞唐君所說，由於遊戲畫面的特殊性（通常是一個固定的背景，上面有一些能夠活動的物體），所以FC的畫面是背景+活動快構成的。而這些背景和活動快則是由一個個8x8像素的Tile構成的。而且由於屏幕解析度的低下（256x224）、以及固定調色板的彩色模式（只有固定的54種顏色可以使用），所以藝術家們只能通過像素藝術（Pixel Art）來表達自己的想法。

而畫畫這種事情並不需要在目標機器上進行，財大氣粗的公司可以選擇一些圖形工作站，比如施樂的一些高檔貨色，那個年代的程序員們也比較熱衷於造輪子，弄台蘋果2，接個彩電，寫個畫點陣圖的程序也未嘗不可。無論如何，只要圖畫出來，並且能夠轉換為FC的PPU（圖像處理器）能夠識別的數據就可以了。

當年KID公司的作曲家鹽田信之（如果我沒記錯的話）在博客上講述過在接SFC外包的時候，看到發行商公司裡面有三台NeXT來做圖形製作，看的直流口水，要借還不給，只能自己搞一些簡陋的工具湊合的趣事。

正由於這些苦難，好不容易做好的一些漂亮的效果通常就都會復用了，無論是圖像還是音頻。反正都是公司財產，還能增加開發效率，何樂而不為。

聲音上，那個聲音「生成」晶元（也就是憑空生成波形的，並不是通過合成PCM採樣來播放音樂的）作為主流的年代，MML似乎成為了一種既定標準，當然，它易於被程序處理，簡潔易記等特點也決定了程序員們不會在這方面造一些不必要的輪子。MML是一種音樂記述語言，是一種文本化的樂譜。當年諾基亞的鈴聲編輯也是MML的一個變種。

作曲家用MML寫好音樂之後，程序員就會把它轉換成自己的音頻引擎能夠識別的二進位格式，合併到遊戲數據之中。當然，也有作曲家本人負責音頻引擎編寫的猛者，比如Tim Follin大神……

當然，FC有一個DPCM通道，不過在那個ROM容量捉襟見肘的年代，一是不會太奢侈，二是那解析度只有1bit，效果也不會太好，適合一些簡單的音頻，比如軍鼓什麼的。

FC嘛，只有那麼些個通道（2方波，1三角波，1噪音），想要達到一些好的效果就需要一些創意了。比如如果作曲家本人對合成器的知識比較深，可以玩出一些花樣，比如Tim Follin大神把三角波和噪音硬生生玩成了TB303的感覺……

於是，現在程序，圖像，聲音都有了，剩下來的就是燒進ROM里，接到機器上，Debug！

而Death March什麼的那個年代也很常見，這個跟現代沒什麼區別，基本上都是臨近發布的那段時間沒日沒夜加班加點趕工。

好了，Bug沒了，到了截止日期了，Master掉，提著軟盤去任天堂，點頭哈腰三鞠躬，畢恭畢敬的把數據雙手呈上交給老任，忍受著任天堂人員的傲慢無禮，順便被狠宰一刀（要掏一大筆錢作為「生產費」，老任絕對不會幫你墊付），為了遊戲大賣時的收入，忍氣吞聲熬過這一切，再點頭哈腰「阿里加多撒有哪啦」，180轉身，走出任天堂大門，多走幾步，吐出一口濁氣，往地上「呸」的吐一口痰，罵一句「八格牙路」，就一切搞定了！

當然，那些接外包的小公司不用去受這窩囊氣，把數據丟給發行商，讓他們去折騰就完事了。

於是，一個遊戲從企划到發售應該是寫全了吧……我也沒想到會寫這麼多，或許有一些漏掉的地方，可以在評論中指出來，我會補充進答案之中。

感謝你能耐心的讀完這麼長的回答，謝謝！

謝謝大家的贊！我第一次有這麼多贊我太感動了TwT

百贊了！！！OwO

這得召喚南晶科技的程序員。。。

國內還有這個程序人員的阿，能開發個LINUX控制終端控制大型電腦雲系統吧

應該有通用性的編譯程序，以及圖形界面製作工具的。

遊戲從其本質上來說，是以美工師製作的畫面來撐起來視覺效果的一種娛樂產品。音樂其次，程序，只要不讓玩家看出來明顯的BUG，影響遊戲進程就可以了。

外星，南晶等公司製作的一些山寨FC遊戲，許多程序，以及背景用到的圖形元素等，都是類同或近似的。

再看一些外國遊戲公司製作的遊戲，同一個公司製作的遊戲，有時甚至會借用一些美工元素，相關貼圖等。如FC遊戲《赤影戰士》（俗稱《水上魂斗羅》）和《最後的使命》（俗稱《空中魂斗羅》），其中獨特的粒子狀爆破效果，看起來很科幻，但卻可能是同一元素（美工資源）的復用。

現時代，我們並未從網上看到這些遊戲公司公開他們的FC等早期主機遊戲的編輯製作軟體，否則以網友的想像力和智慧，早製作出無數部不輸給原作的新遊戲來了。

編過程序的人都知道，目標程序和源程序不同的，而有圖形界面的編譯器，和沒圖形界面的編譯器，效率又是不能相比的。

然而FC遊戲許多高效率執行的彙編語言代碼，估計仍然需要程序員在圖形界面製作完成以後，拚命鑽研地將其優化，否則以FC的微弱機能，隨時耗盡機器資源而卡機死機，該遊戲就搞笑嚴重了。這種事件在當年只要出現一次，其後果肯定比雅達利公司1983年粗製濫造的《ET外星人》遊戲事件更嚴重。該遊戲公司說不定會因此從地球上消失，遊戲行業說不定會崩潰，而該公司的遺作會成為無數人的笑柄。

FC遊戲工作還是那些，人員縮減到10人以下。

不會作曲的美工，很難擔任FC遊戲的導演。

ATARI上的遊戲，一個人干兩個月就算得上是大製作了。

fc遊戲的寫法個現代程序有很大區別，本身機器是專用晶元，支持固定的幾種圖像顯示，以活動塊和色板支撐的。所謂的機能也只是支持一個背景捲動，同屏多少個活動塊，活動塊最大多大，同屏最多多少顏色。甚至連旋轉都做不到，很多效果都是美工硬畫出來的。