探索坦克游戏中的平台差异:雅达利与频道F的对比分析

被遗忘的频道F

1975年,一个名叫“电视显示控制装置”的专利[1]US4026555A在美国注册。这宣告着仙童频道F历史的开始。这个专利听着不像什么跨时代的理念,其中主要描绘了基础的基于控制器和游戏机的电视娱乐系统,真正重要让其极为重要的的是接下来这句话:“这个微处理器在“软件”的控制下运行(即计算机类型的程序),该软件存储在ROM中。”

这是第一次在电子游戏界,“软件”与“硬件”的分别地位被提出。这个正在开发的主机也将会在三年后,成为全世界第一个使用可替换式卡带的游戏机 – 仙童频道F[2]。在此之前,玩家只能在家用游戏机上选择预设好的游戏,甚至看似使用替换式游戏卡的米华罗奥德赛,其卡也只是一些电路板而已,也非单独贩售。

这一创造对游戏业的重要意义无法估量。从此开始,在一个游戏机的生命周期里,新的游戏可以不断被开发,其也在某种意义上开始真正成为一个“平台”。

频道F的卡带阵容

频道F的卡带设计极为有趣。为了让卡带的使用轻松易懂,仙童的工程师们决定将卡带设计为类似八轨磁带的样子[3]。为了防止卡带的头被损坏,他们将其放进了黄色的保护性盖子中。类似的设计影响深远,之后的雅达利也采用了相似的设计

频道F卡带
一个八轨磁带

仙童频道F在游戏史中有着极为矛盾的地位,它不仅是卡带游戏与游戏暂停的先驱者,目前被发现最早的彩蛋[4]甚至也出现在其上。但是,仙童F并没有获得商业上的成功,其发售后的仅仅三年后,也是雅达利推出的同年,仙童就因仅350,000台的销量,直接放弃了频道F,并将其销售给外部。[5]

想到频道F,而不想到雅达利是一件很难的事。两个发售时间只隔不到两年的卡带游戏机,一个成为时代的尘埃,而一个几乎成为电子游戏的同名词。对于他们的商业成功或失败,原因很为复杂。在这篇文章中,我们将从两个极为相似,且同源的作品,一瞥两者平台的异同。

雅达利VCS

两个坦克大战

1974,Pong大获成功的两年后,雅达利高层觉得游戏业“太空了”,他们需要给自己创造出一个假竞争对手,来将市场推向繁荣。雅达利开始在”Kee Games‘’的名下开始发售自己街机长得不一样的复制品。直到一天,曾参与Computer Space(第一个街机游戏)开发的Steve Bristow想开始做一些Kee“自己的游戏”,于是Kee自主开发,并发行了坦克游戏Tank。

Tank街机Cabinet

两个玩家各操控红、蓝坦克,在迷宫中穿行,躲避地雷的同时发射炮弹干掉对手。游戏大获成功,且获得了多次街机续集和再版。中国玩家对小霸王最喜爱的游戏之一 – 坦克大战的雏形也来源于此。

Tank游戏画面

最有趣的是,Tank的成功加上其双人属性和简单直接的画面,让其成为了下一个十年多个主机平台的改编对象。最广为人知的莫过为雅达利2600的Combat。雅达利以其CX2600的代号广为人知,而Combat正是紧随其后的代号CX2601,我们可以说它是第一个被设计在雅达利上运行的游戏,也相当于是雅达利硬件设计用途的“官方演示”(博物馆中Combat上架啦!欢迎游玩)

Combat游戏画面

但Combat并不是第一个家用游戏平台上的Tank仿品。两年前,仙童频道F的三个首发游戏之一 – Desert Fox也是一个tank仿品。

Desert Fox游戏画面

那,这两个改编自同样游戏,作为首发阵容开发的作品各表现了两个平台的什么异同?

硬件妥协

在1970年代,家用游戏主机的工程被如下这些问题所限制。

1.在北美,你的机器必须使用CRT电视机和60帧每秒,每帧大概有240个扫描行,频率也就是约15kHz。你的机器不能比这个帧率和扫描频率跑得慢。

2.RAM(内存)与芯片极其高价,对于芯片,就连多一个针脚也很高价,面向大众消费的商品必须妥协。这代表使用的处理器速度不会超过2Mhz

3.FCC的规定对电子品的辐射量极其严苛,整个机器必须被金属包裹完全

4.电视不接收除了电视信号的其他信号,因此主机的输出必须与天线一致。

雅达利的妥协是较为著名的。对于处理器,雅达利将6502处理器的16个针脚减为13个,这也将RAM限制在了128个字节。雅达利抛弃了帧缓存,使用了”Racing the Beam”的策略[6],也就是开发者必须谨慎计时,一行一行地命令程序,为了进一步减少性能要求,雅达利也将不同画面元素做了清晰度区分,并将其数量固定。这些我们都会在后面详细说明。

在项目被仙童接手后,频道F使用了自家的仙童F8处理器,一个比雅达利所用6507更为强大的8位处理器。为频道F打造的F8使用了一个3850 CPU+两个3851 PSU[7]。两个PSU则分别用来储存系统的BIOS和自带的曲棍球&网球游戏。另外,频道F拥有64个字节的RAM(运行内存),和2KB的帧缓冲(Frame Buffer)。处理器的一大缺陷在于,其并没有地址总线。地址总线的功能可以简单解释为沟通电脑内存元件的实体地址,可以说是内存的“黄页”。在一个常规的处理器中,指令的地址管理用堆栈结构实现(后进后出),当一个子例程被调用,子例程的地址会被推进堆栈,而在子例程运行结束后,返回地址会被推出堆栈,并被设为程序计数器的地址。

但是在频道F中,为了代偿地址总线的缺失,每个总线上的芯片都必须有两个程序计数器,包括ROM。在主程序调用子例程的时候,主程序下一个指令的地址会被存进一个程序计数器,而子例程中下一个指令的地址会用另一个计数器保存。[8]

子例程嵌套示意图

堆栈结构在频道F无法实现,这导致子例程的嵌套也无法实现(简单来说,无法在一个子例程里调用另一个子例程)[9],这对ROM大小拮据的程序影响重大,对于功能的实现也不是利好。

绘图差异

频道F 2kb的帧缓冲给了频道F 102×58像素的显示。(注:当时CRT电视机的显示像素均有不同,此数字不绝对)但是,这样的分辨率也带来了色彩上的妥协,因为每个像素只剩下2个比特负责色彩,频道F只拥有四种颜色,这与雅达利(NTSC制式)的128色是极大的差别。

让仙童频道F与雅达利相差最大的地方即是帧缓冲。帧缓冲是一个专门用来储存屏幕上所有像素(最小显示单位)的色彩的储存器。这对于开发者来说是极大的利好,开发者的命令只用指定特定的位置坐标显示特定的色彩即可。以下是在频道F上显示一些像素颜色的代码,虽然看着有些复杂,但我们可以得出的结论是对于频道F的游戏创作者,显示任何画面只用告诉系统其每个像素点的x坐标,y坐标,颜色就够了。

; r1(暂存器1)已储存色彩值
; r2储存横坐标x(0-127)
; r3储存纵坐标y(0-63)

plot: ;绘制一个像素点的子例程
	  ; 下面两行将接口1(管理色彩)的值设置为r1
	lr	       A, 1 ;将累加器(Accumulator)的值设为r1
outs	1     ;将累加器的值传入接口1

	; 下面三行将接口4(管理横坐标)的值设置为r2(经翻转)
	lr	      A, 2
com	       ; COM命令将x坐标翻转(例:0101翻转为1010)
outs	4     ;传入接口4

	; 下面三行将接口5(管理纵坐标)的值设置为r3(经翻转)
	lr	      A,3
com		 ; COM命令将y坐标翻转
outs	5	 ;传入接口5

	;将数据传输到屏幕内存,此处略
       ;......

	;此处应有延迟的代码(以等待画面更新),此处略
	;......

	pop		; 结束子例程

一个像素如此,一个精灵图(sprite,图案)也如此,游戏也无需限制其同屏的任何画面元素的数量。

雅达利则是一个截然不同的物种。雅达利并不存在帧缓存,也不存在xy坐标的概念。可以说,开发者在对着一行一行扫描的电子枪进行画面绘制,而一个元素的位置仅能由精确到微秒的时间控制才能做到。

CRT电视的电子枪动作

也就是说,对于雅达利的开发者,一个图案的纵坐标可以由电子枪扫的行数决定,而横坐标就只能计数,看处理器运行了多少个工作周期,来计算在横向电子枪跑了多远。让我来看看在一个平面上显示一个精灵(图案)在雅达利里如何完成吧。

;以下代码已被简化  批注中的(i)意思为本行运行需要几个运行周期

lda     #$9A                ; (2) 将十六进制9A的值存入寄存器A
sta	    COLUBK		  ; (3) 将背景颜色设为寄存器A(9A即蓝色)
lda	    #$0E		  ; (2) 将十六进制0E的值存入寄存器A
sta	    COLUP0		  ; (3) 将精灵0号颜色设为寄存器A(0E即白色)
lda	    #%10101010; (2) 一个虚线的二进制表示
sta	    GRP0		  ; (3) 将10101010存为精灵0的图形
nop                             ; (2) 什么都不做
nop                             ; (2) 什么都不做
nop                             ; (2) 什么都不做
sta 	    RESP0		  ; (3) 显示精灵0(需要经过5个像素的延迟处理)

精灵显示画面(编译后,用Stella模拟器运行)

在编译后,这是我们得到的游戏画面。通过画面分析,我们可以数出来我们的图案离屏幕左侧的距离是9个像素。原因如下:

CRT电视的电子枪动作

让我们回到CRT电视的动作,在电子枪从一行转向下一行(即图中紫色的过程),这行的代码就开始运行了。这段从一行末尾转下一行的时间,相当于电子枪在平动中划过68个像素的时间。代码中,每一个运行周期需要的是划过3个像素的时间。代码片段中一共有24个运行周期(把括号中标注的加起来),也就是需要耗费72个像素的时间,再加上显示精灵需要的5个像素,减去转向下一行(这个期间叫做Horizontal Blank)的68个像素,恰好是9个像素。

这已经是一个很简化的案例,精灵的每一行长得一模一样(所以像几条竖线),我们也忽略了纵位置的问题。但从中我们大致能看出雅达利缺少帧缓存对其开发者的影响。在频道F上,如果时间慢了,可能游戏只会运行得更慢,但在雅达利上,会直接影响画面和运行逻辑。从以上部分,我们已经可以看出,仙童频道F在很多层面上,是比起雅达利2600对开发者更友好的平台。

雅达利的这个特性反映了其背后一个重要的设计哲学,即在不可升级的硬件上能省尽省,且减少具体功能,但给予可替换,可升级的软件很高的权限和可能性,以至于连游戏重置,电子枪控制都是软件以决定其功能。这个设计模式给了开发者很高的难度,但也换来了平台的长寿。David Crane(动视创始人之一,雅达利前员工)在一次采访回忆到,“我记得我在屏幕上实现了什么,然后一个硬件工程师路过,他会盯着屏幕震惊好几秒,想不明白这都是怎么可能在他设计的硬件上运行”[10]当然, 我们也可以认为硬件的特性来源于纯粹的成本考虑, 但无论如何, 雅达利最终成为众多优秀作品的摇篮, 且在其寿命的十年里不断有技术革新。

精灵与否

当我们放大去看两个坦克游戏中的坦克图案,很明显地,雅达利版本的坦克更为清晰,而这是如何在一个看似硬件更弱的机器上实现的呢?这一切,都得从精灵,和区别化渲染的概念谈起。

Desert fox坦克

Combat坦克

精灵概念在软件上最早的出现之一,是雅达利的创始人Nolan Bushnell在开发历史上第一个街机游戏-Computer Space的时候产生的。

Computer space游戏画面

游戏中,在密麻的星海上,由光点组成的飞船在上面浮游。因为背景不需要移动,但移动的飞船计算比较复杂,所以相比背景,飞船受单独的晶体管控制[11]。在最后的成像中,两者的图像才被叠加在一起。这被视为精灵(sprite)在电子游戏中最早的雏形之一。

雅达利屏幕上显示的元素分为四种:底色(铺满整个屏幕的颜色),背景(用来绘制粗略的场景,例如combat的迷宫)两个多功能精灵(sprite),两个导弹精灵,和一个球精灵。(扯一点题外话,专门的导弹和球精灵的出现与雅达利2600最初的构想密切相关。在一次采访中,David Crane表示,雅达利高层对2600的设想只是一个又能玩Pong,又能玩tank的机器罢了[10],他们也没有意想到如此长的寿命和如此多的创新性作品。导弹和球精灵好在,每个特殊精灵只需要一个比特,就能提供在tank和pong里重要的元素。)雅达利的运行内存(RAM)拥有128个字节,即1024个比特。而这其中,在每一刻只有32个比特用作图案显示。这是雅达利设计之初就确定的极大硬件妥协的结果。

用四像素条带标注的pitfall画面

雅达利的屏幕是160×192的长宽像素。160的宽意味着,为了在每行电子枪留下画面的时候,需要有160个比特管理整个背景,但是在妥协中,雅达利将横向的四个像素合并为一个,这留下了40个比特。但这还是太多了,雅达利决定让屏幕的右半边只能镜像或者重复左半边的画面,于是背景的RAM被硬生生压到了20个比特。

雅达利pf寄存器及其负责区域示意图

上图是雅达利背景显示逻辑的视觉化。共有三个寄存器负责背景的显示,分别是PF0,PF1,和PF2. PF0的宽度是1与2的一半,只占四个比特(四个背景最小横向显示单位),而PF1和PF2各占8个。下方的代码中,我们让PF0全显示,PF1全不显示,PF2全显示。

;以下代码经过简化
       		ldx 	#0                     ;x寄存器归零(x寄存器来数行数)
drawfield:	lda		#%11111111  ;将a寄存器设为二进制的11111111,即背景全满
sta 	       PF0                   ;将PF0显示区域设为全满
lda		#0                     ;将a寄存器设为0,即空白
sta		PF1                   ;将PF1显示区域设为空白
lda		#%11111111  ;将a寄存器设为二进制的11111111,即背景全满
sta		PF2		      ;将PF2显示区域设为全满
sta 	      WSYNC              ;电子枪换行
inx                                  ;x寄存器+=1
cpx 	#192                ;将x寄存器与十进制的192比较
bne 	drawfield         ;如果还没有画192行,就重复代码段

编译成果(用Stella模拟器运行)

用这种方式,我们清晰地看到了实心的PF0,空心的PF1,和实心的PF2.

经过在背景上的大幅妥协,雅达利为每个普通精灵赢来了8个像素的宽(即每个精灵8个比特)这代表精灵的横向分辨率是背景的四倍之多(下图)

Combat的坦克与墙体

Desert fox的坦克与墙体

而在频道F,工程师选择用同样的逻辑渲染背景和精灵。这给了开发者便利,但也极大地牺牲了游戏中图案的保真度。雅达利选择对面积大,不移动,且重要性低的背景进行妥协,这为面积小,移动,且至关重要的精灵赢得了宝贵的清晰度,这种妥协在游戏画面的视角下无疑是聪明的。

除了画面,这个机制也对游戏的机制产生了影响。对于两个系统,在坦克旋转之时,他们都得全部使用多套预定义的精灵进行替换。

二者坦克旋转对比图

在频道F的Desert Fox中,在坦克的正常大小下,精灵只有5×5,这导致在旋转过程中,坦克的最小旋转角度是45度,而在雅达利的Combat中,受益于坦克精灵8个像素的宽度,这个数字是22.5度。这无疑给了Combat的玩家更大的操控精确度,这在一个竞技游戏中是无比重要的。

频道F的画面处理方式也有其好处。因为没有严格分开的硬件精灵,精灵限制在频道F上并不存在,这代表游戏中物体的数量不成问题。因为这一好处,街机游戏中间的地雷被频道F完全复现,坦克只要与地雷接触就会输掉这一局。

Tank游戏地雷局部

Desert fox地雷局部

但在雅达利的Combat中,这一功能因为两个多功能精灵已经耗尽,无法使用精灵来绘制地雷。

Combat游戏画面

但这并无法合理化地雷从游戏中的缺失。当背景以最小横纵单位渲染的时候,虽然长得不像地雷,但也总可以合理化画面的不同。下左图是雅达利移植版的centipede,在那里,最小横纵单位的背景用来代表蘑菇[12],这说明在雅达利上画面的简化一般是可接受的。再如右图,雅达利版吃豆人的樱桃等道具被替换成了画面中央的奇怪方块,雅达利还在官方说明书里将其解释为“维他命”。[13]

Centipede游戏画面

Pacman游戏画面

至于为什么地雷没有被实现,我们会很快在讨论碰撞时讲到。

碰撞难题

碰撞,可以说在绝大多数游戏中至关重要,甚至说在以画面为核心的电子游戏里都难找出反例。当今游戏处理碰撞的方式即是广为人知的“碰撞箱”。

Unity引擎中的2d碰撞箱编辑界面

我们可以将碰撞箱定义为,不可见的游戏中物体在物理互动中所占的二位或三维空间。它当然不总是一个2d或3d箱子,但是因为箱子是对性能最为经济,最为简化的碰撞箱,所以它得以得名。

Minecraft中的碰撞箱

在雅达利和频道F中,碰撞肯定在机子的开发之初便会成为重心之一,工程师们会尝试让开发者在调用碰撞检测的时候尽可能简单。在雅达利,工程师团队决定将碰撞检测的功能与TIA(自研显示芯片)整合。这也就是说,如果两个画面元素有了像素上的重叠,TIA便会判断为碰撞。

Adventure游戏中碰撞示意图

举个例子,在上图中,我们看到Adventure中玩家拿着剑打龙。在如图所示的位置,如果游戏使用的是标准的碰撞箱,那龙应该已经受到攻击了(左图),但因为是显示芯片在负责碰撞检测,只要像素没有重叠,系统仍检测没有碰撞。

理论上,雅达利的开发者确实可以想办法找到每个物体的具体x,y坐标,并以简单的减法以完成2d碰撞箱的计算,但在这个内存与处理器性能如此拮据的系统上是很不明智的。

这与当今游戏的碰撞检测逻辑并不相同,但的确简单且精确地获得了碰撞信息。在雅达利中,仅有6个相互可能发生碰撞的个体:精灵1;精灵2;导弹1;导弹2;球;背景。雅达利决定让开发者可以直接获取是哪两个物体发生碰撞的信息,因为C(6,2)等于15,所以恰好有15个比特的碰撞寄存器[14]

地址名称 D7字节 D6字节
CXM0P 导弹0;精灵1 导弹0;精灵0
CXM1P 导弹1;精灵0 导弹1;精灵1
CXP0FB 精灵0;背景 精灵0;球
CXP1FB 精灵1;背景 精灵1;球
CXM0FB 导弹0;背景 导弹0;球
CXM1FB 导弹1;背景 导弹1;球
CXBLPF 球;背景 无功能
CXPPMM 精灵0;精灵1 导弹0;导弹1

值得一提的是,这个碰撞检测法也使得开发者除了知道碰撞发生的两物体外不知道任何别的信息,所以任何复杂碰撞逻辑只得用绕弯的方式实现。

Combat碰撞游戏画面

上图是坦克在墙壁上碰撞的演示。我们可以看到,当坦克的炮管从侧面蹭过墙壁的时候,碰撞并没有被触发,这印证了雅达利并没有使用碰撞箱。实际负责碰撞的代码比较复杂(因为要保证其尽多场景的通用性),但我们可以大概了解这个功能发生的逻辑。

每一帧,程序会检查一次CXP0FB地址以查看坦克是否与墙有触碰,如果CXP0FB的值大于0,程序则会读取上一个时刻的坦克位置,并将其传送回去(针对正在旋转的坦克有不同的处理逻辑),在同帧程序会运行CXCLR,这会将所有碰撞寄存器归零。

从上表,我们可以知道,在雅达利的预先设计中,碰撞仅能检测什么物体间发生了碰撞,这也就代表,在初期的雅达利游戏中,两种物体之间仅能有一种互动。这就解释了地雷的缺失,因为当玩家触碰背景,程序很难判别是哪个地点得到了碰撞,也就是说地雷和墙体无法区分。虽然在随后的游戏中,开发者们利用更多信息来让“背景”承担更加复杂的工作,但这确不是此功能最初的设计。

接下来是频道F。因为没有人对频道F的游戏卡的源代码做过人工解编批注,解编码的可读性非常低,我们也很难精确管理碰撞的代码段。但是市面上有一些爱好者写的频道F游戏,那些代码大多都有批注和正确的标签。以下是一段爱好者的吃豆人游戏中的碰撞检测代码。

powerPellets.checkCollision.x1:
;保证x坐标在范围内(管理左半屏幕)
lr	A, 4 ; 加载x坐标至暂存器A
ci    2
bp	powerPellets.checkCollision.x2 
;比较x坐标是否大于2,如果不是,则分支到检测在不在右半屏幕
ci	9
bm	powerPellets.checkCollision.x2 
;比较x坐标是否小于9,如果不是,则分支到检测在不在右半屏幕
; 把目标的坐标加载
lis   7
lr    2, A
br	powerPellets.checkCollision.y1 
;如果x坐标在2-9。则再去检测y坐标

powerPellets.checkCollision.y1: 
; 检测y坐标,此部分略
;.......

我们可以看到,频道F并没有独立,可直接调用的碰撞检测,反之,一切碰撞检测都又x,y坐标减法与比较来确定。这其实与现代游戏的基础2d碰撞箱逻辑是一致的。

Desert fox碰撞游戏画面

上图中,我们可以看到Desert Fox中使用了类似的碰撞箱逻辑。我们操控的坦克拥有一个5×5的碰撞箱,这恰好能把它旋转过程中的所有像素包含在内。

在DesertFox中,可以说整个游戏最为迷惑的机制是坦克穿墙。

Desert fox游戏画面

不管在原版的街机游戏,还是雅达利的Combat上,墙都既能阻隔子弹,又能阻隔玩家的活动,而为什么这个看似不复杂的机制不存在与Desert Fox?

最简单的解释往往是正确的,在对游戏细节的一些观察后,我的结论是这块墙壁实际上拥有的也是5×5的简单方形碰撞箱,而并非表面上的L形,这让碰撞功能的设置成为不可能。至于其对球的阻拦效果,我的最好的猜测是,也只是结合坦克和墙碰撞箱的接触;球和墙碰撞箱的接触,还有接触x,y坐标方向的计算。

Desert fox游戏画面

举个例子,在此位置,玩家碰撞箱与墙壁碰撞箱没有接触,导弹在此情境下会直接“穿墙”。这印证了真正L形碰撞箱的不存在,也复杂化了坦克与墙的碰撞。Desert Fox的开发者为了优先保留导弹与墙的大部分阻拦效果,牺牲了玩家与墙的碰撞。而这归根结底也与频道F碰撞系统缺少平台层面上的功能有关。

操控差异

频道F与雅达利在控制器上也有极大的不同。这在操控的角度上对两个游戏的成品有了很大的影响。

频道f hand controller

频道F的控制器被称为”Hand Controller”。玩家需要一手握持控制器,另一手于上方的三角状钮进行互动。这对于家用主机无疑是一大创造(在此之前,家用主机几乎全是单轴的仿Pong控制器)。

Hand controller专利图表

控制器的输入种类出奇多。钮不仅可以被拔出和按下,还可以类似摇杆地完成前后左右的动作,与此同时,三角形钮可以被旋转,侧边还有一个单独的红色按钮。[15]比较独特的是,设计者Jerry Lawson(频道F背后的主要先驱者)在采访中说,频道F的控制器采用了数位而非模拟的架构,不像使用电阻器或电位计的一般控制器,它的摇杆会在释放后回到原位。[16]在当今的视角下,频道F的设计无疑是古怪的,但因为当今我们对游戏控制器已经有思维惯性,我们很难评价它的直觉性。对于这点,最好的方法是查阅当时的出版物。在1982年的一本游戏机选购指南[17]中,作者将频道F的控制器形容为“拥有普通的摇杆功能”,这显示出它的设计在当时未必是令人费解的。

雅达利摇杆

雅达利的控制器相比就简洁。它只包含一个八个方向的摇杆,和一个大红按钮。

雅达利摇杆专利图表

雅达利摇杆的设计一直被人津津乐道。杆子下面采用半球设计,当一边下压的时候,下方的针脚将那个方向的控制激活,同时,机械的力反馈机制会把杆子往反方向推。[18]

虽然在1977年,街机游戏中已经开始利用摇杆,但雅达利第一次在家用游戏中让摇杆坐上了王座。其CX-40版本继续在VIC-20, C64等80年代经典计算机上适配,这让其成了第一个广多平台适配的游戏控制器。[19]至于频道F,控制器在设计之初就是死连接在主机上的。在或许雅达利的影响下,摇杆在现代的控制器中虽然以被缩小到了手指大小,但继续发挥着不可或缺的作用。

在讨论操控前,我们必须回去看看街机“Tank”的控制是如何设计的。通过Tank检修手册的扫描件,我们得知街机上对每个玩家各有两个单轴(前后)摇杆,分别控制两个履带的动力。

Tank街机局部

具体来说,全向前推是前进,反则是不动;转完则是一前一后地完成。很明显,两个主机都不存在每个玩家两个摇杆的设计,于是他们需要各自想出自己的坦克操控方法。

雅达利这边,选择将动力及转向功能全部交给一个四方向摇杆。

Combat游戏画面

(相邻两个控制可以被同时激活,例如右上,左下)。[20]向前是动力,而同时向左向右充当转弯工作。

Combat手册控制部分

雅达利的控制器,不同于频道F,采用的是可替换设计。但在雅达利的整个生命周期里,也只推出了Joystick和Paddle(可旋转的扭)两种控制器。在那个“专用型”家用游戏主机仍占绝对主导地位的年代,这显示出了雅达利采用“通用”控制的设计思路。

频道F的Desert Fox则采用了三个游戏中最为独特的设计。

频道f hand controller

我们先前谈了频道F控制器的构造。Desert Fox的设计师决定将坦克转向与移动的绑定完全解除。玩家可以将三角形摇杆往上下左右推以控制坦克的移动,同时,旋转上方的三角形旋钮以旋转坦克的炮台方向。这代表,你可以在向屏幕上方移动的同时,向左侧发射导弹。[21]

Desert fox游戏画面

我们可以合理猜测,这一改变有两个原因:频道F有限的分辨率导致其移动及转向不够顺滑,且最小转动角度只有45度,这会让移动+转向的过程十分奇怪其缺乏驾驶感;第二,频道F独特的控制器设计给了其一个四方向摇杆式操控,和一个二方向旋转式操控,这才让转向和移动的分开成为可能。很明显,这在只有一个四方向摇杆式操控的雅达利上是无法实现的

这无疑对游戏的机制有很大的影响,Combat的战斗可以被形容为“有障碍的狗斗”,坦克在关键时刻是在被做转向且精准地发射挑战。在Desert Fox中,移动方向与射击方向的特点下,我们可以说玩家是在完成将对方的位置优化到自身的横竖或对角线向,同时躲避地雷,先于对方射中。在和朋友的几局游戏中,很明显这一硬件引发的机制对于游戏的gameplay有了重大的影响。

滴滴答答

雅达利与频道F在声音的输出上也有很大区别。

频道F在其寿命的初期,音频能力十分受限。它只能发出“Beep” “Beep” 的短音效,而且还只在三个确定的频率[22]。声音由处理器的端口5的前两个比特控制(即前两位0/1)。

LI        %01000000    ; 1000赫兹的哔声
OUTS 5

LI       %10000000    ; 500赫兹的哔声
OUTS 5

LI       %11000000    ; 120赫兹的哔声
OUTS 5

LI       %00000000    ; 没有声音
OUTS 5

在Desert Fox的实际游戏中,它们被分别这样利用:

在移动的过程中,程序会持续播放500赫兹的短音效。

Desert fox坦克移动

在地雷爆炸的时候,程序会重复播放120赫兹的音效。

Desert fox地雷爆炸

而当一个坦克被导弹击中,程序会播放1000赫兹的音效。

Desert fox敌人击中

这里最大的限制是,频道F无法播放连续性的音效,这也导致“驾驶感”在坦克行进的时候较弱。(这一定程度上与Desert Fox炮筒与行进无关的操纵方式相符合)

在雅达利,声音功能是与负责显示的芯片TIA集成的。TIA本身支持双通道声音效果,但最终的机子将两个通道的输出合并,导致其只有单通道输出。雅达利上有三个控制声音输出的寄存器[14]

寄存器名 功能 大小
AUDCX 音色控制 4比特(0-15)
AUDFX 频率控制 5比特(0-31)
AUDVX 音量控制 4比特(0-15)

在几种可能音色中,有的声音类似单簧管,适合作为音乐使用;也有的声音类似于引擎,适合应用于交通工具。对比频道F,这种自定义程度肯定是更高的,并且支持长音。

作为例子,以下是Combat中管理引擎声音的代码:

DOMOTOR	
             LDY  GAMSHP   ;将游戏模式的数据载入Y寄存器
LDA  SNDV,Y   ;根据Y寄存器的游戏模式,在SNDV中找到正确的音量数据
AND  GameOn   ;检查游戏是否开始,如果没开始,音量设为0
STA  AUDV0,X  ;将音量数据载入AUDV0,同时储存进X寄存器
LDA  SNDC,Y   ;根据Y寄存器的游戏模式,在SNDC中找到正确的音色
STA  AUDC0,X  ;将音色数据载入AUDC0,同时储存进X寄存器
CLC                    ;清除carry flag(可忽略)
LDA  #$00        ;(可忽略,与此功能无关)
                   ;此处的频率数据默认,没有手动指定

对音色,频率,和音量的三重控制,无疑给了游戏更多的音效可能性,也在其他游戏中让音乐的存在成了可能。

下面是坦克行驶时的“引擎”音效

下面是坦克发射导弹和击中的音效

文字显示

频道F对文字的使用毫不吝啬,在开始前,当游戏询问是否开始时,屏幕上会直接显示S?,以表示询问是否要start。

Desert fox游戏启动画面

这在雅达利上必然是不可能的,虽然可以通过背景或精灵显示粗略文字 但这么做会过于消耗本就不多的游戏文件(ROM)大小限制。前面我们提过一嘴,频道F较为有趣的设计是,它具有简单的BIOS(basic input/output system). 简单来说, 它的作用是给软件一些可以直接调用的功能。这其中就包括字母显示。

dci	text_hw; 调取Hello World文字数据
li	87		; x坐标
lr	3, A
text_hw_get_char:
li	32		; y坐标
lr	4, A
lis	8		; 宽度
lr	5, A	
lis	5		; 高度
pi	blit		; 显示字母
;..........此处省略
text_right_end:
;..........此处省略
text_hw:
	.byte "HELLO WORLD" ;Hello World文字数据

上方是频道F上绘制“你好世界”使用的代码,我们可以看到,仅用x坐标,y坐标,宽度,高度,和文字数据,字母就能便捷地被绘制。

频道f blackjack画面

文字使用的简便给了频道F在许多桌面游戏的电子化上优势。举个例子,上图的是频道F的“Black Jack”黑杰克游戏,文字不仅用来显示牌,还用来询问玩家”HIT?” “BET?” 等命令。

频道F不使用专用精灵的方式,也对其上面电子桌游的质量有所贡献,例如在blackjack中,雅达利,不仅不能显示这么多数量的画面元素,也无法足够精细的显示文字。仙童的主工程师Jerry Lawson在一次采访中说:“雅达利尝试与我们竞争的游戏之一就是blackjack,但是他们输的很惨”。[16]

Jerry lawson与频道f 2代合影

多模式游戏

雅达利在设计之初就鼓励多模式游戏。

雅达利vcs“Heavy sixer”

上图是最早版本的雅达利VCS,被称为”Heavy Sixer”,因为它是有六个手柄的型号,且比后面的版本更重。

Heavy sixer局部

仔细看雅达利上面的6个手柄,我们可以看到从右往左数,第一个写着“Game Reset”,负责重置游戏,而紧挨着它的就是”Game Select”,即”选择游戏模式”。从雅达利硬件的设计之初,每个游戏卡带就被设计拥有多个游戏模式,甚至对于最初期的游戏,一般是至少10个以上。这与雅达利“想做一个能玩高级版Pong和Combat的机器”是符合的,为了能具有比街机还多功能的体验。以下是Combat各游戏模式对应的二进制数据。

在游戏程序的各处,程序通过获取特定比特的信息以确定执行什么指令,这允许在同一套代码框架下塞下这么多游戏模式。举个例子,以下是只有反弹能造成伤害的”Tank Pong”

tank pong游戏画面

如下是Combat的双翼飞机模式

Bi plane模式游戏画面

我们可以看到,这实际上是比坦克更为简单的游戏模式。不需要一切碰撞的背景逻辑和子弹逻辑,只需要作为遮盖的背景云,这通过改变一些画面元素和禁用一些部分即可实现。

频道f Videocart 1

而在频道F中,对于游戏卡的预期有所不同。在其整个生命周期里,频道F上一共发售过26个Videocart[23],其中最初的Videocart-1拥有四个电子桌游:“Tic Tac Toe, Shooting Gallery, Doodle, Quadradoodle”。

频道f初代主机

这些游戏统统通过频道F上面的方形按钮选择。但是在后期的Videocarts里,其几乎全变成了单一游戏,其一般的游戏模式选择比较有限,一般通过机器上的”Time”键选择游戏持续时间。

不论成败

我们可以看到,雅达利最主要的妥协在于帧缓存的缺失,这直接指数级增大了游戏开发的难度,也可能在一定程度上造成了开发者的外流,动视的创立,和第三方游戏的市场竞争(这可能更多是开发者缺少署名权和福利的后果)。同时,雅达利并没有bios,也将电子枪,控制等的权限全给了软件,以节省硬件成本。我们只能在结果上说,雅达利给软件更为底层权限的做法在长期的游戏革新上是更为有利的。除此之外,雅达利在画面元素上大大限制,并且根据重要程度对其进行不同精细度的处理,这也给了游戏画面更大的保真度。。

对于频道F,其嵌套子例程的缺失使同样ROM大小下的游戏功能受限,在画面和碰撞处理上,它有意思地与现代的电脑处理逻辑相似。他并没有对不同画面元素的差异化处理,也存在完整的帧缓存系统。但是因为硬件受限,这些更为“通用”的方法并非十分讨巧。其设计的好处也是明显的,在画面,文字,和没有计时需求的优点下,其游戏开发工作更加简便。

当当今的我们在谈论到频道F,论调通常是惋惜的。但频道F从未真正被遗忘过,可编程可替换的游戏发行方式成为了家用游戏平台的新标杆。频道F背后的开发人员同样如此,说服仙童继续发售的Gene Landrum未来会帮助Bushnell想出Chuck E Cheese的街机+披萨商业模式;帮助仙童做市场调研的Trip Hawkins会在未来创办EA;频道F卡带的两个工程师会在未来帮助动视生产出适配雅达利的卡带;频道f的总工程师Jerry Lawson也会以黑人游戏先驱的身份被永远铭记。

至于雅达利呢,会接着成为电子游戏的同名词,以至于大约两个美国家庭里,就会有一个拥有一台雅达利。

参考资料

[1] Kirschner, W., & Haskel, L. M. (1975). Television display control apparatus. ALPEX COMPUTER CORP. US4026555A. Retrieved from https://patents.google.com/patent/US4026555A/en 
[2] Smith, R. A., & Talesfore, N. F. (1976). Cartridge programmable video game apparatus. Fairchild Semiconductor Corp. US4095791A. Retrieved from https://patents.google.com/patent/US4095791A/en 
[3] Zell-Breier, Sam (June 11, 2021). "The Untold Truth Of Jerry Lawson, The Father Of The Video Game Cartridge". Retried from https://www.svg.com/434774/the-untold-truth-of-jerry-lawson-the-father-of-the-video-game-cartridge/ 
[4] Wolf, Mark J. P. (2012). Encyclopedia of Video Games: The Culture, Technology, and Art of Gaming. Santa Barbara, California, USA: Greenwood. p. 177. ISBN 9780313379369. 
[5] Edwards, Benj (January 22, 2015). "The Untold Story Of The Invention Of The Game Cartridge". Fast Company. 
[6] Bogost, I., & Montfort, N. (2009). Racing the Beam. MIT Press 
[7] "The Untold Story Of The Invention Of The Game Cartridge": https://www.fastcompany.com/3040889/the-untold-story-of-the-invention-of-the-game-cartridge 
[8] Branagan, N. (2021). The Fairchild Channel F: First and Finest? Retrieved from https://nicole.express/2021/the-most-unfair-child.html 
[9] GeeksforGeeks. (n.d.). Subroutine, Subroutine nesting and Stack memory. Retrieved from https://www.geeksforgeeks.org/subroutine-subroutine-nesting-and-stack-memory/ 
[10] Saunders, G. (1997). Stella at 20 - An Atari 2600 Retrospective. Retrieved from https://archive.org/details/StellaAt20/Stella+at+20+-+tape+07+-+David+Crane%2C+Al+Miller.mp4 
[11] Bushnell, N. K. (1971). Computer Space Operations and Service Manual. Nutting Associates, Inc. Retrieved from https://www.arcade-museum.com/manuals-videogames/C/ComputerSpace.pdf 
[12] Atari, Inc. (1982). Centipede Game Program Instructions, Retried from https://www.gamesdatabase.org/Media/SYSTEM/Atari_2600/manual/Formated/Centipede_-_1982_-_Atari.pdf
[13] Atari, Inc. (1981). Pac Man Atari Game Program Instructions. Retried from https://archive.org/details/Pac-Man_1981_Atari 
[14] Steve Wright(1988). Stella’s Programmer’s Guide. Retrieved from https://cdn.hackaday.io/files/1646277043401568/stella.pdf 
[15] Talesfore, N. F. (1976). Hand-held controller for a video game or the like. Fairchild Semiconductor Corp. USD247754S. Retrieved from https://patents.google.com/patent/USD247754S 
[16] Edwards, B. (2009, February 24). Vintage Computing and Gaming. VC&G Interview: Jerry Lawson, Black Video Game Pioneer. Retrieved from https://www.vintagecomputing.com/index.php/archives/545/vcg-interview-jerry-lawson-black-video-game-pioneer 
[17] Uston, K. (1982). Ken Uston’s Guide to Buying and Beating the Home Video Games. 
[18] Asher, J. C. (1980). Joystick control. Nevada: ATARI Corp. US4349708A. Retrieved from https://patents.google.com/patent/US4349708A/en 
[19] "Atari CX40 Joystick." Wikipedia, Wikimedia Foundation, 8 June 2021, en.wikipedia.org/wiki/Atari_CX40_joystick. 
[20] Atari, Inc. (1977). Combat Game Program Instructions. Retrieved from AtariAge: https://atariage.com/manual_thumbs.php?SoftwareID=935 
[21] Fairchild Semiconductor International, Inc. (1976). Instructions for Cartridge 2 console games. Retrieved from https://www.gamesdatabase.org/game/fairchild-channel-f/desert-fox-and-shooting-gallery 
[22] “Outputting Sound.” VES Wiki. Retried from https://channelf.se/veswiki/index.php?title=Outputting_Sound 
[23] "Fairchild Channel F Videocarts." Wikipedia, Wikimedia Foundation, https://en.wikipedia.org/wiki/Fairchild_Channel_F_Videocarts 

 

发表评论

您的电子邮箱地址不会被公开。 必填项已用 * 标注