< Return to Video

It Takes Two

  • 0:00 - 0:02
    欢迎观看《关卡之上》
  • 0:02 - 0:08
    这是一个我与关卡的创造者,共同游玩他们手中优秀关卡的系列
  • 0:08 - 0:12
    这次我选择的是 2021 年度我最喜爱的游戏之一:
  • 0:12 - 0:16
    拥有无穷创意的合作冒险之旅,《双人成行》
  • 0:16 - 0:19
    游戏的主角是一对感情破裂的夫妻,科迪和梅
  • 0:19 - 0:25
    他们被变成了玩具,不得不合作无间,穿越疯狂的微缩世界
  • 0:25 - 0:30
    今天我们的关卡,也是疯狂世界的一员:科迪和梅的花园里的一棵树
  • 0:30 - 0:35
    这棵树里藏了一群松鼠士兵、黄蜂杀手、以及一个巨型的蜜蜂高达
  • 0:35 - 0:39
    为了能有一战之力,这对情侣获得了两把好用的武器:
  • 0:39 - 0:42
    科迪获得了一把可以射出大团黄色树液的枪
  • 0:42 - 0:45
    ——而梅则是一把发射燃烧火柴的十字弩
  • 0:45 - 0:47
    一旦二者合作使用——
  • 0:48 - 0:50
    为了了解这一关卡的制作过程
  • 0:50 - 0:54
    我采访了Hazelight的设计师,奥利弗·格兰伦德
  • 0:54 - 0:58
    ——他是负责这一关布局和游戏机制的设计师之一
  • 0:58 - 1:01
    一般来说,这个系列的传统是我玩游戏
  • 1:01 - 1:04
    然后通过Zoom向设计师直播我的屏幕画面
  • 1:04 - 1:09
    但这次我们玩的是一个合作游戏,所以我会和奥利弗一起玩
  • 1:09 - 1:12
    ——我玩科迪,而他玩梅
  • 1:12 - 1:14
    那么,闲话不多说
  • 1:14 - 1:18
    以下就是我们的对话,有关于《双人成行》第二章:
  • 1:18 - 1:19
    "大树之章"
  • 1:21 - 1:25
    哈,这边!
  • 1:28 - 1:30
    什么?! 你不可能跳过去的!
  • 1:30 - 1:34
    是吗?看我的,嘿!
  • 1:34 - 1:39
    那么,一个常见的开场白:你们是如何开始这一关的开发的?
  • 1:39 - 1:43
    首先,美术人员会在设定方面进行一系列探索
  • 1:43 - 1:45
    在玩家都会变小的前提下,什么地方最有趣?
  • 1:45 - 1:51
    而树是一个在最初就被确信为 "有趣" 的地点
  • 1:51 - 1:54
    而在这个阶段的设计则会做大量的原型
  • 1:54 - 1:57
    尽可能在各种不同的机制上,做天马行空的尝试
  • 1:57 - 2:00
    ——然后我们就想到了树液和火柴枪的设定
  • 2:00 - 2:03
    在早期阶段,这些只是松散的原型
  • 2:03 - 2:06
    而从某个时间点开始,大家就将它们和 "树" 联系到了一起
  • 2:06 - 2:08
    工作室的大家会遍历每一个机制
  • 2:08 - 2:11
    然后挑选出最适合与美术原型联系起来的那个
  • 2:11 - 2:15
    接下来,我们会给每个、或者每组设计师
  • 2:15 - 2:18
    分配一个关卡,然后让他们着手制作
  • 2:18 - 2:21
    为二者之间,设计出各种机制和元素
  • 2:21 - 2:23
    就我所知,你和设计师罗伯特·约翰逊
  • 2:23 - 2:27
    负责了大树和雪景球之章的设计,是这样吗?
  • 2:27 - 2:28
    是的,没错
  • 2:28 - 2:30
    我特意挑选了这一章来放到今天聊
  • 2:30 - 2:32
    是因为很多人共同合作创造了它
  • 2:32 - 2:36
    例如这一部分,它的设计师是亨利克·桑丁
  • 2:36 - 2:38
    其实这段在很后期才被做出来
  • 2:38 - 2:42
    从玩家视角,这是一章的最开头
  • 2:42 - 2:43
    但它完成的时间其实很后期
  • 2:43 - 2:48
    当我们完成整个大树之章后,才发现摆荡机制被遗忘了
  • 2:48 - 2:51
    所以我们回到开头,专门加了这样一段
  • 2:51 - 2:52
    而这部分最后的效果相当不错
  • 2:52 - 2:56
    也算是两段风暴之间的宁静
  • 2:56 - 2:59
    而且也是对大树主题的一个很好的开场白
  • 2:59 - 3:02
    在开发这部分时,有不少聪明的小花絮
  • 3:02 - 3:05
    例如蚂蚁会向着玩家的目标方向前进
  • 3:05 - 3:06
    比如这里
  • 3:06 - 3:08
    而这其实源自于一个意外:
  • 3:08 - 3:12
    美术加入了到处乱爬的蚂蚁,然后发现玩家喜欢跟着蚂蚁走
  • 3:12 - 3:16
    然后,当蚂蚁爬下悬崖时,不少人想都没想就跳下去了
  • 3:16 - 3:19
    亨利克利用这种玩家的思路做出了游戏引导
  • 3:20 - 3:23
    我们没有时间搞这个,这到底是不是条近路?
  • 3:35 - 3:41
    黄蜂入侵了我们的大树,然后屠杀了我们大多数的族人
  • 3:41 - 3:44
    你们两个必须把他们杀了
  • 3:44 - 3:46
    那么,树液和火柴枪
  • 3:46 - 3:48
    是怎么从原型被一步步,开发成游戏中的样子的呢?
  • 3:48 - 3:53
    在原版的设定中,你只能用树液粘住物体,用火柴引爆
  • 3:54 - 3:57
    这个设定在战斗中是很炫酷的
  • 3:57 - 4:00
    但到了解谜环境就显得没什么用
  • 4:00 - 4:05
    所以我们将这个机制从原型中拿出来后,做的第一件事
  • 4:05 - 4:10
    就是探索其 "发射-引爆" 之外的其他可能性
  • 4:10 - 4:11
    而从这个出发点开始
  • 4:11 - 4:15
    我们就做出了 "树液重量机制" 和 "火柴推力机制"
  • 4:15 - 4:18
    有趣的是,这是整个游戏中非常少见的
  • 4:18 - 4:21
    在新手教学阶段把玩家分开的一章
  • 4:21 - 4:25
    因为如果玩家看到一个瞄准标志,比如梅这边的这种
  • 4:25 - 4:26
    两个玩家都会对其射击
  • 4:26 - 4:28
    而如果你看到了黄色……
  • 4:28 - 4:32
    你懂的,就是游戏常用的 "这里能互动" 的设计语言,
  • 4:32 - 4:35
    两个玩家也会射击同一个东西——这让机制变得很难理解
  • 4:35 - 4:38
    你是说,你们要确保玩家能够,分别理解自己承担的责任?
  • 4:38 - 4:39
    完全正确
  • 4:39 - 4:40
    我们注意到的一点是
  • 4:40 - 4:43
    当我们为游戏加入一个新元素,比如树液枪后
  • 4:43 - 4:48
    需要非常小心的确保玩家能理解我们的意思
  • 4:48 - 4:51
    比如,用重量把一个东西压下去的同时,另一个物体升起来
  • 4:51 - 4:52
    那么这两个物体就需要是连在一起的
  • 4:52 - 4:54
    如果你去看我们的其他关卡的话
  • 4:54 - 4:57
    会发现它们有很多 "马里奥风格" 的悬浮平台
  • 4:57 - 5:03
    所以我们做的就是,每个关卡都有自己的独立的规则和内在逻辑
  • 5:03 - 5:06
    有点像是每隔一个小时就教玩家学习一部新游戏
  • 5:06 - 5:08
    在这个过程中你们遇到过什么挑战吗
  • 5:08 - 5:13
    有趣的是,因为树液枪是一种非常 "系统性" 的武器
  • 5:13 - 5:14
    它的自由度很高
  • 5:14 - 5:16
    你想射在哪里都可以
  • 5:16 - 5:18
    而这是一个我们在很早期就做出的决定
  • 5:18 - 5:20
    机制设计有两条路线:
  • 5:20 - 5:23
    你可以选择那条处处有限制的路线
  • 5:23 - 5:28
    玩家只能射击一个屋子里指定的那么几个点
  • 5:28 - 5:31
    亦或者玩家想射哪就射哪,也就是我们最终选择的路线
  • 5:31 - 5:34
    而这种设计会导致不少问题,比如这个笼子
  • 5:34 - 5:36
    给你看看我们的开发过程视频吧
  • 5:36 - 5:39
    这个过程非常有趣
  • 5:39 - 5:42
    首先,这是这个原型一开始的样子
  • 5:42 - 5:48
    这蜂巢乍看起来可能完全不一样,但它的玩法思路是完全一致的
  • 5:48 - 5:52
    但问题出现了:如果你可以把树液黏在平台外面
  • 5:52 - 5:53
    那么梅就引爆不了
  • 5:53 - 5:59
    而这是我们的第二版设计:依然是伤了我的心
  • 5:59 - 6:04
    科迪很自然的把树液射在了屋顶,而梅则不得不抬头……
  • 6:04 - 6:08
    噢,不,这样绝对不行
  • 6:08 - 6:11
    我们围绕着这些机制做的很多努力
  • 6:11 - 6:16
    都在于限制那些,会让玩家玩起来不舒服的选择
  • 6:16 - 6:19
    在确保谜题依然完整的前提下
  • 6:19 - 6:22
    做出大量的迭代和简化
  • 6:22 - 6:23
    "减法设计" 嘛
  • 6:23 - 6:25
    我觉得牢记这一点很有用
  • 6:25 - 6:27
    尽管有个别设计是一出来就完美的
  • 6:27 - 6:31
    但大多数的设计,总归是需要一、二次迭代的
  • 6:31 - 6:34
    那么,鉴于这是你第一次设计合作游戏
  • 6:34 - 6:37
    同时为两个玩家设计的体验如何?
  • 6:37 - 6:40
    我认为游戏中的合作可以分为三种形式
  • 6:40 - 6:42
    首先是 "平行合作"
  • 6:42 - 6:47
    基本上就是你和另一个玩家一起玩,但游戏依然基于单人设计
  • 6:47 - 6:49
    然后,还有 "步骤合作"
  • 6:49 - 6:53
    也就是你先做某件事,我才能做某件事
  • 6:53 - 6:55
    如此循环往复
  • 6:55 - 6:58
    第三种则是 "同步合作"
  • 6:58 - 7:01
    也就是两个玩家必须同时行动
  • 7:01 - 7:03
    我们希望能够囊括所有这三种形式
  • 7:03 - 7:09
    而做好这几种合作之间的节奏控制,是最难的任务
  • 7:09 - 7:11
    也是我们花了很多时间调试的东西
  • 7:11 - 7:14
    这段实验室环节非常不错,能和我聊聊吗?
  • 7:14 - 7:17
    这是我们早期的一个版本
  • 7:17 - 7:20
    而这一版,幸亏我们有提前测试了
  • 7:20 - 7:23
    这玩起来可太困难了
  • 7:23 - 7:24
    而现在看似普通的形式
  • 7:24 - 7:27
    也就是这个让一切玩起来轻松多了的侧轴视角
  • 7:27 - 7:28
    当时还不在这里
  • 7:28 - 7:29
    那么你们是什么时候引入这个机制的?
  • 7:29 - 7:35
    在游戏开发比较早期时,我们开始测试后
  • 7:35 - 7:38
    但我想说的是,就如同这个视角
  • 7:38 - 7:42
    很多明显的修改都出自于,我们先做出来,发现效果不佳
  • 7:42 - 7:44
    那么……要怎么样将它改的更好呢?
  • 7:44 - 7:47
    很多迭代都设这样产生的
  • 7:47 - 7:50
    初期想法,"噢我们应该有几个转盘"
  • 7:50 - 7:54
    然后发现,比如说,有明显的视角问题
  • 7:54 - 7:59
    然后你就会知道,噢我们可以再加一个侧轴视角机制
  • 8:03 - 8:06
    嘿,放我出去!
  • 8:06 - 8:08
    噢对,你之前玩过这个吗
  • 8:08 - 8:12
    没,第一次玩的时候我错过了这个,刚才吓我一跳
  • 8:12 - 8:14
    吓一跳就对啦
  • 8:17 - 8:18
    这些支线互动是如何产生的?
  • 8:18 - 8:22
    在每个游戏的大进度后,我们都会先玩一遍
  • 8:22 - 8:24
    也会找一些玩家来帮忙测试
  • 8:24 - 8:26
    从而确保没有什么被忽略的问题
  • 8:26 - 8:29
    而其中一个问题就是,玩家能做的事太少了
  • 8:29 - 8:35
    所以我们开始大量创造小游戏和支线互动
  • 8:35 - 8:37
    最后真的做了不少
  • 8:37 - 8:39
    而这一项的灵感来自于
  • 8:39 - 8:42
    最开始,我们的想法是
  • 8:42 - 8:45
    "困住你的朋友然后嘲笑他们,一定会很有趣吧"
  • 8:45 - 8:50
    然后 "嘲笑" 变成了 "折磨",大家的坏念头都冒出来了
  • 8:50 - 8:53
    而这些支线某种意义上也成了游戏的收集品
  • 8:53 - 8:56
    在最开始我们有一个讨论,鉴于这部游戏是平台跳跃
  • 8:56 - 8:59
    收集品显然是传统艺能了,对吧?
  • 8:59 - 9:00
    比如地图上的问号?
  • 9:00 - 9:04
    但我们发现,游戏不能让玩家的收集毫无意义
  • 9:04 - 9:09
    我们想要走另一条路,为玩家的收集赋予意义或者动机
  • 9:09 - 9:13
    而这种思路一直走下去,就是我们创造的一大堆小游戏
  • 9:13 - 9:17
    因为这些小游戏有点破坏注意力,我们将它们稍稍藏了起来
  • 9:17 - 9:20
    而这些东西在最后就成了变相的收集品
  • 9:22 - 9:23
    有东西过来!
  • 9:23 - 9:25
    黄蜂杀手!
  • 9:25 - 9:30
    这是我们的第一场遭遇战,它有什么特别的吗?
  • 9:30 - 9:32
    合作战斗中很有趣的一点是
  • 9:32 - 9:37
    你需要以一种和普通战斗完全不同的视角去思考
  • 9:37 - 9:41
    尤其是我们还打算采用同步合作,也就是两个玩家都要操作的战斗
  • 9:41 - 9:45
    比如说,在这里,两个玩家的工作是不同的
  • 9:45 - 9:48
    你是炸弹安装者,我是炸弹引爆者
  • 9:48 - 9:52
    也就是说,直到你粘住敌人之前,我基本是无事可做的
  • 9:52 - 9:56
    所以我们调高了AI对于梅的攻击性
  • 9:56 - 9:59
    在我不需要引爆炸弹时,不至于无所事事
  • 9:59 - 10:03
    另外一个问题是,如果你的同伴
  • 10:03 - 10:07
    比你要菜的多,或者你比他菜的多怎么办?
  • 10:07 - 10:10
    而这,我认为是一个更难着手解决的问题
  • 10:10 - 10:15
    对于新玩家来说,我想大树之章恰恰是全游戏最难的
  • 10:15 - 10:19
    这是唯一你需要同时进行 "瞄准" 和 "战斗" 的一关
  • 10:19 - 10:21
    但当你玩的时候就会发现
  • 10:21 - 10:24
    其自动瞄准机制其实是非常宽松的
  • 10:24 - 10:28
    我们尽量让玩法核心脱离 "我能不能射中目标"
  • 10:28 - 10:30
    而更关注于 "我能不能躲开黄蜂的攻击"
  • 10:30 - 10:32
    以及 "我能不能选择正确的射击目标"
  • 10:32 - 10:35
    以及其他类似的东西
  • 10:35 - 10:39
    对于用不好摇杆的人群来说,这依然是最难的机制之一
  • 10:39 - 10:46
    但我们仍然确保它操作起来,比大多数第一/第三人称射击游戏更简单
  • 10:47 - 10:50
    有趣的玩意儿,看起来是某种拔河比赛
  • 10:51 - 10:53
    惊了,你手速好快,哦不!
  • 10:54 - 10:57
    好耶!这也太简单了,来再试一次!
  • 10:57 - 11:03
    来来来,再试一次,刚才那段给我剪掉
  • 11:05 - 11:09
    啊这,你在用键盘玩吗?
  • 11:09 - 11:11
    没啊,用的Xbox手柄
  • 11:11 - 11:12
    行吧,那就是我丢人了……
  • 11:12 - 11:15
    那么,你们为什么会决定要做 "竞技类" 的小游戏呢?
  • 11:15 - 11:18
    整部游戏的主题就是合作
  • 11:18 - 11:21
    这种节奏不会被轻易打破
  • 11:21 - 11:27
    而我们之所以做这样的小游戏,一个重要原因就是
  • 11:27 - 11:29
    为情侣创造一个,更多样的时刻
  • 11:29 - 11:32
    当然,也是一种对于故事中夫妻争吵的影射
  • 11:32 - 11:35
    当故事中,夫妻在争吵时
  • 11:35 - 11:37
    我们希望玩家也有这样 "争执" 的时刻
  • 11:37 - 11:40
    当你看到这种情况发生时,有点有趣和好笑
  • 11:40 - 11:44
    我们也尽可能的在扩展小游戏的多样性
  • 11:44 - 11:46
    确保各种类型的玩家都有机会获胜
  • 11:46 - 11:48
    我们甚至做了一个国际象棋
  • 11:48 - 11:52
    所以,核心思路在于,不要让所有小游戏提供同一类挑战
  • 11:52 - 11:55
    否则同一个玩家就会一直一直赢下去
  • 11:55 - 11:59
    我很喜欢这个大保险门,是个很惊艳的设计
  • 11:59 - 12:04
    这个门最初的设计,其实是要玩家先射一圈再引爆
  • 12:04 - 12:08
    但这样的话门就不能太大,否则玩家视角里就装不下了
  • 12:08 - 12:11
    所以我们最后使用了这个简单的旋转门
  • 12:11 - 12:15
    然后把那个思路用在了这个盖子上
  • 12:15 - 12:18
    基本上,我们的关卡就是把原型搬来搬去
  • 12:18 - 12:20
    这个迭代的过程有多重要?
  • 12:20 - 12:23
    这个迭代过程可太重要了
  • 12:23 - 12:27
    我们并没有时间去把每一个设计做到完美
  • 12:27 - 12:31
    我们不是3A游戏,没有那么多时间
  • 12:31 - 12:34
    但我们需要它对玩家来说足够好
  • 12:34 - 12:37
    而迭代是这个目标不可缺少的一部分
  • 12:37 - 12:39
    尽管很多点子本身没有什么大变化
  • 12:39 - 12:42
    但它们最终的实现非常不同
  • 12:42 - 12:45
    ——从头到尾,完全不同
  • 12:45 - 12:48
    尤其是当你有这么多需要交给玩家的机制时
  • 12:48 - 12:51
    有一半的时间,我们都在打磨这些机制自身
  • 12:51 - 12:53
    也许这里不够明确,也许那里不够好
  • 12:53 - 12:55
    我们能传达的更完善一些吗?
  • 12:55 - 12:58
    而另外一半时间我们则在迭代谜题自身
  • 12:58 - 13:01
    让它们更流畅,更有趣,更直观
  • 13:01 - 13:05
    很多现在很有趣的东西,在一开始其实并非如此
  • 13:05 - 13:08
    将 "点子" 转化为 "有趣的玩法"
  • 13:08 - 13:10
    ——花费了我们远超你想象的时间精力
  • 13:10 - 13:15
    我们的工作方式,与重生的"动作块"设计流程很相似
  • 13:15 - 13:18
    在一周内做出一些东西,然后放在一边等着后续用
  • 13:18 - 13:19
    不过,要注意的一点是
  • 13:19 - 13:23
    即便一个原型也许只需一周就能做到"能玩"的程度
  • 13:23 - 13:25
    你可能会花费长得多的时间去打磨它
  • 13:25 - 13:29
    而这件事,发现的太晚了,就会让人痛苦万分
  • 13:31 - 13:33
    别担心,只是个机器人里的松鼠罢了
  • 13:33 - 13:38
    没错,不过是个巨大的,想要杀死我们的机器人
  • 13:38 - 13:40
    要不我们回去吧……
  • 13:40 - 13:44
    当我们在游戏后期加上这一幕的时候,我们发现……
  • 13:44 - 13:46
    艹,这关的内容好像还多着呢
  • 13:46 - 13:48
    对于大树之章,我们在最开始有准备一个故事板
  • 13:48 - 13:52
    根据故事版,我们估计这一关的长度应该差不多是一个小时
  • 13:52 - 13:56
    而做出来后,我们才发现已经远不止一个小时了
  • 13:56 - 13:58
    这一关的流程差不多两个小时
  • 13:58 - 14:03
    这其实是有问题的——过多的玩法冲淡了游戏的故事
  • 14:03 - 14:05
    大概是因为我们在最开始做了太多原型了
  • 14:05 - 14:08
    我们在最后才开始着手故事的部分
  • 14:08 - 14:11
    在游戏的各个地方加上过场动画
  • 14:11 - 14:14
    在一个游戏玩法不停变化的游戏中,控制故事的节奏一定很不容易吧
  • 14:14 - 14:19
    确实,确实,尤其是这类游戏
  • 14:19 - 14:22
    我们需要知道,玩家可以忍受多少没有故事进展的玩法
  • 14:22 - 14:25
    以及忍受多少没有玩法的过场动画
  • 14:25 - 14:28
    你需要非常精妙的平衡两者,才能既不让玩家感到无聊
  • 14:28 - 14:32
    又不让玩家在故事方面,失去继续玩的动力
  • 14:32 - 14:37
    有趣的是,直到游戏做完为止,你都很难测试这方面的平衡
  • 14:37 - 14:41
    这也是为什么,很多游戏都没能做好这点
  • 14:41 - 14:44
    因为直到游戏的非常后期,你都测试不到这方面
  • 14:44 - 14:47
    你不知道某一段是否会被延长或这缩短
  • 14:47 - 14:51
    而离了游戏的前后上下文,你很难做出任何判断
  • 14:51 - 14:54
    所以你不得不时刻想象着游戏完成后的样子
  • 14:54 - 14:58
    当你们在平衡游戏的故事和玩法时,有没有一方压倒了另一方?
  • 14:58 - 15:00
    我们做的上一部游戏是《逃出生天》
  • 15:00 - 15:02
    那是一部专注于故事的游戏
  • 15:02 - 15:05
    而这部游戏中,我想玩法部分可能胜出了
  • 15:05 - 15:07
    但我们在尽可能的平衡两者
  • 15:07 - 15:11
    我们的座右铭就是尽量让玩法和故事结合——让它们融为一体
  • 15:11 - 15:14
    我们希望这些机制最好能,不仅仅是玩法
  • 15:14 - 15:16
    而是可以让故事也更加丰满
  • 15:16 - 15:19
    例如,磁铁机制是有关情侣之间的吸引力的
  • 15:19 - 15:21
    而钟表则有关于时间
  • 15:21 - 15:23
    我们将这些关卡称为 "情感关卡"
  • 15:24 - 15:29
    我喜欢这个游戏的原因之一,就是它在玩法上的多样性
  • 15:29 - 15:31
    你们为何会这么做呢?
  • 15:31 - 15:33
    这一点是我们游戏开发流程中的 "支柱" 之一
  • 15:33 - 15:34
    我们拒绝重复的事物
  • 15:34 - 15:40
    我们重新审视了经典的任天堂游戏设计
  • 15:40 - 15:42
    也就是关卡的四步设计
  • 15:42 - 15:46
    这确实是一种很好的设计,我们也有用到
  • 15:46 - 15:50
    但我们更感兴趣的是,尽可能的塞进去各种各样的东西
  • 15:50 - 15:54
    在其他游戏中,开船的这一幕可能是一整部游戏
  • 15:54 - 15:56
    但在这里,只是一个5分钟长度的部分
  • 15:56 - 16:01
    我们当然有能力,将它延长为一个更丰富的30分钟的关卡
  • 16:01 - 16:04
    但我们认为那样只会让游戏变得更差
  • 16:04 - 16:06
    你们通常会给一个机制创造多少深度
  • 16:06 - 16:07
    如果它只会出现5分钟的话?
  • 16:07 - 16:09
    对于这点,我要说
  • 16:09 - 16:13
    如果你没有足够的展示机会的话,有深度的机制并不代表着好的质量
  • 16:13 - 16:15
    而这就是我们一直说的
  • 16:15 - 16:16
    "点到为止"
  • 16:16 - 16:19
    也是我们游戏开发的 "支柱" 之一
  • 16:19 - 16:21
    "多样性" 和 "点到为止"
  • 16:21 - 16:22
    二者互相结合
  • 16:22 - 16:24
    一个机制需要有多少深度?
  • 16:24 - 16:27
    如果你只打算做一个5分钟的流程的话
  • 16:27 - 16:29
    它就没必要是一个20小时深度的机制
  • 16:29 - 16:32
    这点非常重要:你要知道止步于何处
  • 16:32 - 16:36
    因为玩家可能不会接受任何超出这个范围的东西
  • 16:36 - 16:42
    我们所做的是,试图把所有发现的 "最好" 的东西,放在关卡中
  • 16:42 - 16:45
    而不是把所有东西一股脑的拖进游戏里
  • 16:45 - 16:49
    哇啊,看来它们现在要来真的了!
  • 16:49 - 16:53
    做出了这部分其实花了我们不少的时间:
  • 16:53 - 16:56
    蜂群技术,比如让它们变成锤子,这整套系统都不好做
  • 16:56 - 17:01
    才能让它完成从战斗到滑梯的无缝衔接
  • 17:01 - 17:06
    这花了我们很多精力,但我想最后的成果是值得的
  • 17:06 - 17:08
    嘿……嘿!别那样做!
  • 17:13 - 17:16
    又是,作为一个设计师,我在设计某个东西时
  • 17:16 - 17:18
    心里很清楚这玩意儿要实现很花精力
  • 17:18 - 17:23
    我会祈祷这做出来是好玩的,否则就是对其他员工时间的浪费
  • 17:23 - 17:26
    确实,作为设计师,你总要丢一大堆工作给程序和艺术
  • 17:26 - 17:29
    你们是如何运作这段关系的?
  • 17:29 - 17:31
    重要的一点是,你需要在正式开始之前
  • 17:31 - 17:35
    对最终成品的效果有所预期
  • 17:35 - 17:38
    我们将一段抽象的游戏玩法讲给美术
  • 17:38 - 17:39
    还要畅谈 "这东西最后会是什么样"
  • 17:39 - 17:42
    然后你懂的,美术就坐在那里,看着你
  • 17:42 - 17:44
    然后和你说,这听起来一点也不好玩
  • 17:45 - 17:48
    有没有哪次,美术的成果是让你感到惊艳的?
  • 17:48 - 17:50
    太多,太多次了
  • 17:50 - 17:53
    比如这整个实验室流程
  • 17:53 - 17:55
    比如这个大轮子,看起来好像
  • 17:55 - 17:58
    怎么说呢,是一个和整个故事毫无关联可言的设计
  • 17:58 - 18:00
    为什么松鼠的巢穴会有这种转动的大轮子?
  • 18:00 - 18:04
    美术们却把它变成了这个非常精致的实验室,成为了故事重要的一部分。
  • 18:04 - 18:09
    很多时候,美术和程序人员
  • 18:09 - 18:11
    都能拿出一些让我们惊艳的成果
  • 18:11 - 18:17
    而那一刻会让我确信,游戏开发确实是一项团队运动啊
  • 18:18 - 18:20
    噢……现在怎么办!
  • 18:21 - 18:22
    我觉得要往那边走
  • 18:23 - 18:25
    哇,拜托,小梅!我们没法游过去!
  • 18:26 - 18:29
    我们坐船过去!帮我一把!
  • 18:29 - 18:32
    我得给你看看这艘船的迭代
  • 18:32 - 18:37
    你之前问了我一些关于如何做原型的问题,我这里还保留着早期原型
  • 18:37 - 18:41
    最开始我们的想法是,对着空气射击,然后船会往反方向移动
  • 18:41 - 18:44
    这点子太糟了:你没法看到自己再往哪个方向移动
  • 18:44 - 18:47
    糟糕透顶
  • 18:47 - 18:52
    但是没关系——做这个我们没花多少时间
  • 18:52 - 18:54
    然后我们就开始想:
  • 18:54 - 18:58
    能不能让船变得操作起来更轻松,更有趣呢?
  • 18:58 - 19:03
    我们做出了这个版本,基本就是发动机前进,你来掌舵
  • 19:03 - 19:09
    这玩起来很有趣,但并不符合我们一开始设定的规则
  • 19:09 - 19:13
    就像我说的,每个设计师都会为自己的关卡设定规则
  • 19:13 - 19:18
    罗伯特和我的规则是,这一关将围绕 "力学" 展开
  • 19:18 - 19:20
    我们会尽可能的少使用UI
  • 19:20 - 19:22
    然后尽量多让玩家使用武器
  • 19:22 - 19:26
    玩家不应该按Y键开门,而是应该把门炸开
  • 19:26 - 19:29
    而这,就引出了我们最后的方案
  • 19:29 - 19:34
    将同样的开船功能与游戏的实际机制相结合
  • 19:34 - 19:37
    这里你需要射击来推动自己前进
  • 19:37 - 19:40
    我们的工作室很擅长随即应变:
  • 19:40 - 19:43
    我们先把东西做出来,测试一下,讨论一下,然后再改
  • 19:43 - 19:46
    而这也是我们的强项
  • 19:46 - 19:50
    从长远来看,这绝对是让我们游戏变得优秀的原因之一
  • 19:52 - 19:56
    哇,好美啊!
  • 19:56 - 20:01
    是的……致命的美。水母有剧毒,我们最好赶快走
  • 20:01 - 20:04
    从这开始,关卡就变得越来越怪了
  • 20:04 - 20:08
    你们对 "游戏可以变得多奇怪" 有做出什么限制吗?
  • 20:08 - 20:12
    没有,绝对——没有
  • 20:12 - 20:17
    我们的游戏总监倒是曾经反馈过,这游戏还可以 "再怪一点"
  • 20:17 - 20:20
    他是想让我们把《双人成行》做成哈草游戏的
  • 20:20 - 20:21
    所以我们就照做了
  • 20:21 - 20:24
    我敢打包票,玩家们玩到这里的时候
  • 20:24 - 20:27
    一定会不由得想 "我们真的还在树里吗?"
  • 20:29 - 20:32
    我真是受够了跌落的感觉
  • 20:32 - 20:34
    想点好的吧,至少你看起来还不错
  • 20:34 - 20:36
    噢,真的吗?谢了,小梅
  • 20:36 - 20:38
    我是说你这个泥土身体还没摔坏
  • 20:38 - 20:39
  • 20:39 - 20:42
    在这一关的节奏上,你们有做什么努力吗?
  • 20:42 - 20:43
    我觉得对于这一点
  • 20:43 - 20:45
    我们其实应该付出比现在更多的注意力
  • 20:45 - 20:48
    但我们当时全都专注于多样化和炫酷玩意儿了
  • 20:48 - 20:51
    大部分游戏对于 "节奏" 的想法其实与我们不同
  • 20:51 - 20:54
    他们的节奏更有关于内容的重复性
  • 20:54 - 20:57
    这里是平台环节,这里是战斗环节
  • 20:57 - 21:00
    然后这里又是平台环节,这里又是战斗环节
  • 21:00 - 21:01
    为了不让这种重复显的无聊
  • 21:01 - 21:05
    你必须确保游戏的节奏是正确的、多样的
  • 21:05 - 21:10
    我们完全没有这种担忧,因为我们的游戏自身就已经足够多样了
  • 21:10 - 21:12
    毕竟我们一直在做出新机制来
  • 21:12 - 21:14
    但我们仍然需要注意关卡节奏的激烈度
  • 21:14 - 21:17
    不能让玩家太累,也不能让他们太无聊
  • 21:17 - 21:22
    仍然需要确保那条心流曲线是一直上下游动的
  • 21:25 - 21:27
    噢……哇
  • 21:27 - 21:29
    这是什么地方?
  • 21:29 - 21:34
    呃……不知道,但是它们看起来很生气啊
  • 21:34 - 21:36
    是,没错
  • 21:42 - 21:45
    这几乎是整部游戏中最激烈的一场战斗了
  • 21:45 - 21:47
    关于设计它,你有什么想说的吗?
  • 21:47 - 21:51
    最开始,我们其实想把独角仙作为普通的小怪
  • 21:51 - 21:54
    但从某一刻开始,我们开始想 "也许我们不需要那么多小怪"
  • 21:54 - 21:56
    要不干脆把它做成BOSS得了?
  • 21:56 - 22:00
    其实我们不该这么干的,毕竟这段后面紧接着就是一场大型BOSS战
  • 22:00 - 22:04
    但在请求通过后,我们就——
  • 22:04 - 22:05
    啊,打偏了,我的我的……
  • 22:05 - 22:06
    没事!
  • 22:06 - 22:11
    我们在这场战斗上迭代了超多次,来确保它
  • 22:11 - 22:17
    能集中于玩家移动的能力,而非瞄准技术或者对机制的掌握
  • 22:17 - 22:20
    例如这些地上的炉子
  • 22:20 - 22:25
    既能让你提前一步做好准备,也能减少你瞄准的压力
  • 22:25 - 22:29
    在早期的版本,我们的设计是让玩家射击它的屁股
  • 22:29 - 22:34
    但这对机制的掌控、玩家的交流要求都太高了
  • 22:34 - 22:38
    跑到它身后,瞄准……这太难了
  • 22:38 - 22:42
    那个……你知道女王吗?她有喝不完的花蜜
  • 22:42 - 22:48
    如果你帮我们解决她,你想要多少花蜜就有多少!
  • 22:48 - 22:55
    真好吃呀,吼吼!那还等什么?快点,跳上来!
  • 22:58 - 22:59
    快跳!
  • 23:07 - 23:09
    入侵者们!
  • 23:09 - 23:12
    现在我们终于遇上这一关的最终BOSS了
  • 23:12 - 23:16
    我很好奇你们对于游戏中血量系统的设计
  • 23:16 - 23:19
    在原型阶段,我们实际上有着另一种血量系统
  • 23:19 - 23:22
    我们最开始做了类《战争机器》的血量系统
  • 23:22 - 23:25
    一个玩家死了,另一个玩家需要去救他
  • 23:25 - 23:27
    但是我们的玩法实在是太过丰富了
  • 23:27 - 23:31
    你永远没法预料玩家会在什么地方,或者两人分开的时候死掉
  • 23:31 - 23:33
    所以这套系统没法用
  • 23:33 - 23:38
    我们又尝试了一种,将血条放在中间共享的方案,这点子看起来不错:
  • 23:38 - 23:40
    玩家共享生命值,这才是合作嘛
  • 23:40 - 23:44
    但如果两个玩家之间的水平差异非常大的话
  • 23:44 - 23:48
    比较菜的那位会一直狂死,然后让两个人都失败
  • 23:48 - 23:51
    而不是让厉害的玩家带队友起飞
  • 23:51 - 23:56
    所以我们最终的成果是这个倒计时,只要其中一人活着就不会失败
  • 23:56 - 23:59
    这在游玩中很能炒热气氛,玩家会喊
  • 23:59 - 24:01
    "小心!别死了!我马上就复活了!"
  • 24:01 - 24:04
    而这让我们的最终方案相当不错
  • 24:04 - 24:07
    我们会尽量避免让玩家不得不重玩某个部分
  • 24:07 - 24:09
    因为这与我们 "多样性" 的座右铭不符
  • 24:09 - 24:11
    我们之所以把血量系统做成这样
  • 24:11 - 24:13
    就是因为,这样其中一个玩家的死亡就无伤大雅
  • 24:13 - 24:15
    毕竟他们会在随后复活
  • 24:15 - 24:17
    有点像是变相的多给了你一条命
  • 24:17 - 24:21
    死亡是很有意思的,因为它让你感到了压力和挑战
  • 24:21 - 24:24
    但 "不得不重来" 一点也不好玩
  • 24:32 - 24:36
    有意思的是,很多人对独角仙的死亡有点伤心
  • 24:36 - 24:39
    但它对我们来说其实啥都不是
  • 24:39 - 24:41
    做出它的原型只花了一周,然后我们就把它丢进游戏里了
  • 24:41 - 24:45
    玩家会说 "噢,不,独角仙兄!",而我们会说 "哈哈,臭独角仙"
  • 24:45 - 24:50
    我们完全没想到这一点,这还挺好玩的
  • 24:50 - 24:54
    快点,科迪,这边!你来开!
  • 24:54 - 24:59
    什么?! 小梅,这是架飞机——不是旅行车!
  • 24:59 - 25:00
    飞就完事了!!!
  • 25:01 - 25:04
    飞机这段让人印象深刻,你有什么想说的吗?
  • 25:04 - 25:07
    这部分的设计者是佩尔·斯坦贝克
  • 25:07 - 25:09
    我们已经有了故事板
  • 25:09 - 25:14
    在原型之前,故事就已经指出了我们需要一个飞机环节
  • 25:14 - 25:18
    我原本以为这部分可能就是一个普通的飞行片段
  • 25:18 - 25:24
    那很不错,但几经周转,它才变成了现在这样
  • 25:24 - 25:30
    大家想出大概的想法,让松鼠追着你飞
  • 25:30 - 25:33
    然后它们会降落在你的飞机上,你需要把它们射下去
  • 25:33 - 25:34
    ——啊这
  • 25:34 - 25:34
    抱歉!
  • 25:36 - 25:39
    然后我们在聊这个时,谈到了
  • 25:39 - 25:43
    "也许可以让松鼠跳到飞机上,然后再把它们踢下去"
  • 25:43 - 25:46
    这时有一个声音问道:"像《街头霸王》那样?"
  • 25:47 - 25:52
    是时候说再见了小娃娃。等不及要打爆你的木头脸了!
  • 25:52 - 25:54
    我等不及要踹飞你的福瑞屁股了!
  • 25:58 - 26:00
    这种事其实很常见
  • 26:00 - 26:05
    很多公司都会畅想 "如果……的话?",但这些畅想都不会成真
  • 26:05 - 26:09
    但在这里它实现了,这也是我喜欢我们公司Hazelight的原因之一
  • 26:09 - 26:15
    我要为制作这段的每个人点赞,是他们把一个点子变成了游戏的高光时刻
  • 26:18 - 26:20
    KO!!!
  • 26:21 - 26:22
    我来了!
  • 26:26 - 26:30
    这一部分有点像是在致敬《兄弟:双子传说》
  • 26:30 - 26:35
    有一个类似的场景,不过当时是单玩家控制两个人,而现在则是双人合作
  • 26:35 - 26:38
    没错,这部分最后效果相当不错
  • 26:38 - 26:42
    整个飞机环节都很赞,玩法丰富多样
  • 26:42 - 26:47
    玩家会经历总共三个环节,每个环节都截然不同
  • 26:47 - 26:50
    而我想这都要归功于
  • 26:50 - 26:56
    我们多元化的工作方式,不管是美术、程序、还是设计
  • 26:56 - 27:01
    每个人都有极大的自由,可以在游戏中添加很多自己的想法
  • 27:01 - 27:03
    这自然的让我们的游戏与众不同
  • 27:09 - 27:11
    哇!……吼!
  • 27:12 - 27:16
    这是我最后一次坐你的内裤飞机!
  • 27:16 - 27:19
    噢,哈哈,你可真会开玩笑,你知道吗?
  • 27:19 - 27:20
    谢谢你
  • 27:20 - 27:22
    而这,就是全部了
  • 27:22 - 27:26
    这是一场很棒的经历,我们了解到两把枪是如何被创造出来的
  • 27:26 - 27:29
    也了解到了它们从专注于战斗的机制,如何演化成了一个解谜用的工具
  • 27:29 - 27:35
    很高兴能够看到这部游戏从原型到打磨,一步步完成的全过程
  • 27:35 - 27:40
    在这之上,这场采访也体现出来关卡设计天生需要的 "交流重要性"
  • 27:40 - 27:44
    就此,奥利弗想要感谢几位同事——
  • 27:44 - 27:48
    我想要感谢罗伯特、亚历山大、汤姆,他们帮我准备了这期视频
  • 27:48 - 27:51
    我还要感谢罗伯特、佩尔、亨利、和菲利普
  • 27:51 - 27:53
    他们与我共同设计了大树之章,多亏了他们
  • 27:53 - 27:59
    不用我说,完整的游玩流程和采访在Patreon中独占
  • 27:59 - 28:01
    如果你想要支持《游戏制作工具箱》的话
  • 28:01 - 28:06
    在我们进入独立游戏推荐之前,请看看这个短暂的YouTube广告吧
  • 28:08 - 28:10
    别等了,哪有什么广告啊
  • 28:11 - 28:15
    本次推荐的独立游戏是《摄追赤红末世代》
  • 28:15 - 28:18
    一个具有颠覆性幽默感的,低模风格的游戏
  • 28:18 - 28:21
    在每关中,你都会被扔进一个3D环境
  • 28:21 - 28:23
    有一个摄像头和一个需要拍摄的东西清单
  • 28:23 - 28:28
    你需要找到每个目标,并使用正确的镜头和站位
  • 28:28 - 28:33
    如果你也同意 "摄影" 是一个绝妙的游戏机制
  • 28:33 - 28:35
    那就玩玩《摄追赤红末世代》吧
  • 28:35 - 28:38
    它在 PC 和 Switch 上均有发售
Title:
It Takes Two
Description:

more » « less
Video Language:
English
Duration:
28:43

Chinese, Simplified subtitles

Revisions