FC/NES 游戏是怎么制作的？ 第1页

更新：

我接触到的所谓“开发秘话”大多是小公司的视点，但是就我力所能及的范围内补充一下吧。

添加了大公司的开发环境以及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