1
00:00:03,860 --> 00:00:09,200
主人公がゴリラじゃない『Ape Out』を
想像することは不可能に近い

2
00:00:09,200 --> 00:00:12,260
だが正に、世に出る前はそうだった

3
00:00:12,260 --> 00:00:17,740
設計の Gabe Cuzzillo によると、最初は時間ループ系の
ステルスゲームを作ろうとしていたらしい

4
00:00:17,740 --> 00:00:21,300
「掴み動作」を使って
壁沿いをコソコソ移動するという内容だ

5
00:00:21,300 --> 00:00:27,680
だがゲーム内に警備員が居るのなら、当然
同じ仕組みで警備員を掴むことが可能なはずで

6
00:00:27,680 --> 00:00:30,580
これが警備員を人質にして

7
00:00:30,580 --> 00:00:32,860
壁にぶん投げる遊びに繋がった

8
00:00:32,860 --> 00:00:39,880
これが作中で一番面白い部分だと判明したので
Gabe は方針を大胆に変更することを決め

9
00:00:39,880 --> 00:00:43,280
この構想を中心にして
実際にゲームを開発していった

10
00:00:43,280 --> 00:00:48,040
彼はステルスや時間ループなどの
不要な要素を全て削除した

11
00:00:48,040 --> 00:00:51,560
そしてこの面白さを増幅する為なら
なんだってした

12
00:00:51,560 --> 00:00:57,680
最も顕著なのは、主人公のハゲ男を
300 ポンドの怒れるゴリラに替えたことだ

13
00:00:58,960 --> 00:01:04,100
これは「面白さを追う」と呼ばれる
ゲーム設計の方法論の模範例だ

14
00:01:04,100 --> 00:01:10,220
開発者が最初に掲げた企画や
先入観に囚われてしまうのではなく

15
00:01:10,220 --> 00:01:15,080
ゲーム自体に目を向け、開発をどこへ導くべきか
見いだすという一見単純な方法論だ

16
00:01:15,080 --> 00:01:19,040
緻密な戦術ゲームの傑作とも言える
『Into the Breach』の例を見てみよう

17
00:01:19,040 --> 00:01:23,460
このゲームは一般的な
ファミコンウォーズ系の作品として始まった

18
00:01:23,460 --> 00:01:28,060
敵はランダムに攻撃を選び
ターンが来るまで次の行動を隠していた

19
00:01:28,060 --> 00:01:32,800
だがある敵は自分のターンで
どこを攻撃するのか正確に示していた

20
00:01:32,800 --> 00:01:35,560
攻撃する予定のマスを
強調していたのだ

21
00:01:35,560 --> 00:01:40,720
Subset の開発者はこれが
一番楽しい部分であることに気付き

22
00:01:40,720 --> 00:01:46,360
ゲームの他の部分を、専らこの予告攻撃に
集中させることに決めたのだった

23
00:01:46,360 --> 00:01:51,640
またこれはスタジオが行うべき
その他の意思決定を決めることに役立った

24
00:01:51,640 --> 00:01:54,720
敵がどこを攻撃する予定なのか
事前に把握しているなら―

25
00:01:54,720 --> 00:01:57,820
自分のユニットを攻撃ゾーンの外に
移動させることはできないだろうか？

26
00:01:57,820 --> 00:02:02,160
なるほど　このゲームは恐らく
動かない建物を防衛する内容になる

27
00:02:02,160 --> 00:02:06,800
だからすぐに、攻撃が外れるように
敵を押し出さなければならない

28
00:02:06,800 --> 00:02:11,080
だが実は、これを悪用することで
敵に同士討ちをさせることもできる

29
00:02:11,080 --> 00:02:14,460
この手法を使う開発者が、頻繁に―

30
00:02:14,460 --> 00:02:18,940
「ゲームがある程度は、自らを設計した」と
言っている理由がよく分かるだろう

31
00:02:18,940 --> 00:02:23,420
『Crashlands』を開発した Butterscotch Shenanigans
の Sam Coster は次のように述べる

32
00:02:23,880 --> 00:02:28,220
「私たちはこれをゲームが時間をかけて
自らを発見する過程だと考えています」

33
00:02:28,220 --> 00:02:34,840
「設計作業ではなく反復作業として
ひたすらゲームを遊んで、聞いて、感じることで」

34
00:02:34,840 --> 00:02:38,580
「このゲームがどうなりたいのか
探ることが私たちの仕事です」

35
00:02:38,580 --> 00:02:40,580
「何が面白いのかをただ
追いかけていくのです」

36
00:02:41,200 --> 00:02:46,220
さて、ゲームが自分自身を設計するという発想は
次の大ヒットを狙っている人間にとって

37
00:02:46,220 --> 00:02:48,860
かなり刺激的な話だろう

38
00:02:48,860 --> 00:02:52,560
だがそんな素晴らしいアイデアが
天から降ってくる訳ではない

39
00:02:52,560 --> 00:02:54,430
ではどこから生まれるのか？

40
00:02:54,430 --> 00:02:59,880
では、リズムに基づいたローグライク
『Crypt of the Necrodancer』の起源を見てみよう

41
00:02:59,880 --> 00:03:04,980
設計の Ryan Clark は『Spelunky』の
目まぐるしい意思決定を

42
00:03:04,980 --> 00:03:08,180
伝統的なターン制のダンジョン探索ゲームに
組み込みたいと考えていた

43
00:03:08,180 --> 00:03:10,820
そこで彼はローグライクの
簡単な試作品を作ることにした

44
00:03:10,820 --> 00:03:14,120
次のターンまで
1秒しかないという内容だ

45
00:03:14,120 --> 00:03:18,720
それを遊んでみると
音ゲーに近い性質があることに気付き

46
00:03:18,720 --> 00:03:21,920
音楽を主軸にすべきであることが
明らかになった

47
00:03:24,920 --> 00:03:29,720
または『Rocket League』を象徴する
空中技を見てみよう

48
00:03:29,720 --> 00:03:32,640
Psyonix がゲームの前身である―

49
00:03:32,640 --> 00:03:35,400
『Supersonic Acrobatic Rocket-Powered Battle-Cars』
に取り組んでいたとき

50
00:03:35,400 --> 00:03:37,900
彼らはそれ以来
販売戦略について多くの教訓を得た

51
00:03:37,900 --> 00:03:42,640
彼らは車同士が戦うゲームを作ったが
車が加速する仕組みを追加したいと思っていた

52
00:03:42,640 --> 00:03:46,640
そこで開発者は単純に、車両後部に
物理的な力を加えることにした

53
00:03:46,640 --> 00:03:52,980
試遊では、空中でその力を使うことで
競技場をロケットのように飛べることが判明した

54
00:03:52,980 --> 00:04:00,780
意図していなかったが、開発者たちはこの要素が
莫大な深みと新たな側面を付与していることに気付き

55
00:04:00,780 --> 00:04:02,360
そのまま維持した

56
00:04:02,360 --> 00:04:07,360
スタジオは「この仕組みを、ほぼ偶然によって
開発しました」と言っている

57
00:04:07,360 --> 00:04:11,600
実際、開発過程で発生した
バグ、不具合、事故が

58
00:04:11,600 --> 00:04:15,060
機能に転じた事例は
ゲーム史の中では珍しくない

59
00:04:15,060 --> 00:04:21,920
例えば神谷英樹は『鬼武者』で、敵を空中で
何度も斬りつけられるバグを発見した

60
00:04:21,920 --> 00:04:28,380
修正されてしまったが、神谷はこれを
『Devil May Cry』の主役級の仕組みに発展させた

61
00:04:28,380 --> 00:04:33,100
重要なのは、この過程には
初めのアイデアが必要になるという点だ

62
00:04:33,100 --> 00:04:39,140
それがズボラで、不鮮明で、独創性を欠いていても
実際に動く試作品を作ることが大切なのだ

63
00:04:39,140 --> 00:04:44,640
そして試作と試遊の過程で
新しいアイデアが生まれることになる

64
00:04:44,640 --> 00:04:49,460
またゲームの声に耳を傾け
注意深くなれるかどうかは開発者次第だ

65
00:04:49,460 --> 00:04:53,920
何が面白いのかを悟り
その側面を探求することを いとわないこと

66
00:04:53,920 --> 00:04:57,540
たとえそれが当初考えていた企画と
完全に一致していなくてもだ

67
00:04:57,540 --> 00:05:02,900
『Gunpoint』は人に目掛けて
冷蔵庫を落とす宇宙ロボが主人公から

68
00:05:02,900 --> 00:05:07,160
建物をハッキングするスパイの
パズルゲームに変容した

69
00:05:07,160 --> 00:05:12,220
当初のハッキングの仕組みは横スクロールの
『Deus Ex』に触発されたような

70
00:05:12,220 --> 00:05:15,020
ミニゲームの一つに過ぎなかった

71
00:05:15,020 --> 00:05:18,600
だが開発者の Tom Francis が
試作を始めてみるとすぐに

72
00:05:18,600 --> 00:05:22,640
最終的に『Gunpoint』となる
ゲームが現れたのだ

73
00:05:22,640 --> 00:05:23,500
Tom 曰く―

74
00:05:24,060 --> 00:05:27,360
「これをパズルゲームにするべきだと
すぐに分かりました」

75
00:05:27,360 --> 00:05:28,720
「パズルの仕組みでした」

76
00:05:28,720 --> 00:05:31,060
「そして『Gunpoint』は何になりたいのか
私に教えてくれたのです」

77
00:05:31,060 --> 00:05:33,560
「パズルになりたがっていたのは
明らかでした」

78
00:05:33,560 --> 00:05:37,860
「そして私は方針を転換して
ハッキングの遊びをより拡張したのです」

79
00:05:37,860 --> 00:05:40,440
「それを中心にゲーム全体を設計しました」

80
00:05:40,960 --> 00:05:47,460
この方法論は、ゲーム開発の序盤に
最も重要な変化を起こす

81
00:05:47,460 --> 00:05:53,400
これこそが Sam Coster がゲームのことを
「可鍛性の白いマグマ玉」であると表現している点だ

82
00:05:53,400 --> 00:05:59,220
開発が進むにつれてそれは使えるものになり
形成されることで、決まった形に落ち着き始める

83
00:05:59,220 --> 00:06:04,380
例えば中身の制作について、Jonathan Blow は
『Braid』のパズルは

84
00:06:04,380 --> 00:06:09,520
時間操作エンジンが生んだ予期せぬ結果を
単に展示しただけだと述べている

85
00:06:09,520 --> 00:06:12,240
Blow 曰く―
「私は学芸員の役割でした」

86
00:06:12,240 --> 00:06:17,240
「答えを整理して、プレイヤーが楽しめるように
提示しただけです」

87
00:06:17,249 --> 00:06:19,249
詳細はこの動画を参照してほしい

88
00:06:19,249 --> 00:06:22,349
あるいはプレイヤーの反響を
聞くという方法もある

89
00:06:22,349 --> 00:06:27,000
Chris Hecker が『Spy Party』を作った時
プレイヤーはあらゆる種類の抜け穴や

90
00:06:27,000 --> 00:06:29,200
予想外の遊び方を発見した

91
00:06:29,200 --> 00:06:31,120
だがこうした「バグ」を
修正する代わりに―

92
00:06:31,120 --> 00:06:35,100
Chris は身を乗り出し
そのバグをゲームの公式要素にした

93
00:06:35,100 --> 00:06:40,380
ゲーム体験を、心理戦や心理的トリックとして
推し進めたのだった

94
00:06:40,380 --> 00:06:44,640
そしてこの方法はゲーム開発の
全般的な方針として役立てることもできる

95
00:06:44,640 --> 00:06:47,440
『Subnautica』の開発者である
Charlie Cleveland は次のように述べる

96
00:06:47,980 --> 00:06:49,840
「自分の行き先が分かっていると
思うでしょう」

97
00:06:49,840 --> 00:06:51,540
「そこは地平線上の
どこかにあります」

98
00:06:51,540 --> 00:06:54,060
「そして道が多くてどう行けばいいのか
分からない」

99
00:06:54,060 --> 00:06:57,100
「でもゲームの声を聴けば、作品が向かいたい方向が
分かるでしょう」

100
00:06:57,580 --> 00:07:00,480
それこそが彼のスタジオが
ホラーゲームを生み出した方法だ

101
00:07:00,480 --> 00:07:03,300
企画の初めには
ホラーを作る意図は無かったのだ

102
00:07:05,200 --> 00:07:08,800
さて、明らかなことは
このような設計過程を経ると

103
00:07:08,800 --> 00:07:12,600
ゲームが完成するまでにかかる時間の予測が
非常に困難になってしまう

104
00:07:12,600 --> 00:07:17,000
この方法論が独立系ゲームの業界で
よく使われている一方で

105
00:07:17,000 --> 00:07:21,280
超大作ゲームのような厳しく組織化された世界では
忌避されている理由がこれだ

106
00:07:21,280 --> 00:07:29,040
Tom Francis が二作目に『Heat Signature』を作った時
彼は「宇宙船に潜入する」という曖昧なアイデアが

107
00:07:29,040 --> 00:07:33,440
『Gunpoint』と同じく魔法のように
良くなることを期待していた

108
00:07:33,440 --> 00:07:35,260
しかし……そうはならなかった

109
00:07:35,260 --> 00:07:37,580
少なくとも、かなり長い間
良くならなかった

110
00:07:37,580 --> 00:07:40,280
実際、Tom は何がゲームを
面白くするのかを見つける為には―

111
00:07:40,280 --> 00:07:46,020
膨大な要素を制作する必要があることに気付き
これが開発の長期化に繋がってしまった

112
00:07:46,020 --> 00:07:50,560
彼は宇宙船生成システム
人工知能、戦闘システムや

113
00:07:50,560 --> 00:07:53,580
経済を含む銀河の全体地図などを
作ることになった

114
00:07:53,580 --> 00:07:59,560
船内の戦闘が一番面白い要素だと理解するまでに
Tom は何年もかかってしまった

115
00:07:59,560 --> 00:08:05,540
だから本当の慣用句は、ただの「面白さを追う」より
もう少し長いことは覚えておく価値がある

116
00:08:05,540 --> 00:08:09,820
僕はこの慣用句の出自をこの男まで遡った
Marc LeBlanc だ

117
00:08:09,820 --> 00:08:13,080
彼は『Thief』と『System Shock』に
取り組んだ開発者であり

118
00:08:13,080 --> 00:08:17,260
「MDA フレームワーク」のような概念の考案を
助けた教育者でもある

119
00:08:17,260 --> 00:08:23,860
この言葉を生み出した時、彼は
起業家の世界でよく知られた慣用句から始めた

120
00:08:23,860 --> 00:08:25,920
「まずは失敗してみる」という言葉だ

121
00:08:25,920 --> 00:08:29,560
この制作過程は、ゲームを
可能な限り早くまとめ上げて

122
00:08:29,560 --> 00:08:32,020
何が上手くいき、何がそうでないかを
見るためのものである

123
00:08:32,020 --> 00:08:36,000
失敗しても、それほど時間を無駄に
しなかったのだから問題ではない

124
00:08:36,000 --> 00:08:40,980
だが所謂「失敗」は、次の試作でどの方向へ
進むべきかについて多くのことを教えてくれる

125
00:08:40,980 --> 00:08:45,940
では、反復作業を高速化するための
具体的な手法はあるのだろうか？

126
00:08:45,940 --> 00:08:51,260
まぁ、GMTK の視聴者であればご存知だろうが
その 1つが「Game Jam」だ

127
00:08:51,260 --> 00:08:57,360
これは狂気のゲーム開発マラソンであり
週末の 2日以内でゲームを作らねばならない

128
00:08:57,360 --> 00:08:57,860


129
00:08:57,860 --> 00:09:02,400
Arvi Teikari は Game Jam で賞を獲得したパズルゲーム
『Baba is You』を考え出した人物で

130
00:09:02,400 --> 00:09:04,580
Game Jam ついて
こう述べている

131
00:09:04,860 --> 00:09:08,100
「全体の意図は、頭に浮かんだ
試作品を使って」

132
00:09:08,100 --> 00:09:10,040
「それを中心に何かを
作ろうというものです」

133
00:09:10,040 --> 00:09:11,900
「もし上手くいかなくても大丈夫」

134
00:09:11,900 --> 00:09:13,860
「Game Jam の後で捨てても構いません」

135
00:09:13,860 --> 00:09:18,140
「Game Jam にかけた時間より長く
そのアイデアに注力する訳ではないのです」

136
00:09:18,500 --> 00:09:24,480
別の手法は、Game Maker や Godot Engine などの
手早く試作できるソフトを活用することだ

137
00:09:24,480 --> 00:09:30,420
あるいは紙で試作したり、LEGO や
PS4 の制作系ソフト『Dreams』を使う

138
00:09:30,420 --> 00:09:34,280
既にゲームの大部分が出来ていて
ただ中身を増やしたいだけの場合は

139
00:09:34,280 --> 00:09:38,800
特注のレベル制作ツールを開発すれば
製作作業を高速化できる

140
00:09:38,800 --> 00:09:41,240
そして一緒に手伝ってくれる人を
増やす

141
00:09:41,240 --> 00:09:45,780
それで『マリオギャラクシー2』で、任天堂は
簡素なレベル設計ツールを開発し

142
00:09:45,780 --> 00:09:49,600
チーム全員が独創的な仕掛けを
考案できるよう促した

143
00:09:49,600 --> 00:09:55,620
また設計や仕組みに早く集中するために
仮仕様の絵素材や、音楽、物語を使うこともできる

144
00:09:55,620 --> 00:10:00,140
Klei が『Don't Starve』の最初期の
Game Jam 試作を制作していたとき

145
00:10:00,140 --> 00:10:03,120
主人公の実際の見た目は……

146
00:10:03,120 --> 00:10:04,960
『ゼルダの伝説』のリンクだった

147
00:10:04,960 --> 00:10:07,860
そして最後に
絶対に変更できない要素が

148
00:10:07,860 --> 00:10:10,860
実際に役立つことがある

149
00:10:10,860 --> 00:10:13,120
thatgamecompany の Sunni Pavolic によると

150
00:10:13,120 --> 00:10:17,680
『風ノ旅ビト』の制作時
スタジオは非常に反復的な方法論を用いたが

151
00:10:17,680 --> 00:10:22,860
このゲームは「愛」を探求する作品であるという
アイデアを常に念頭に置いていたらしい

152
00:10:22,860 --> 00:10:26,500
これによってチーム全員が従うべき
方向性が明確になり

153
00:10:26,500 --> 00:10:31,540
発見・開発できるアイデアの範囲を
狭めることに役立った

154
00:10:34,460 --> 00:10:38,380
だからこの動画から持ち帰ってもらいたいことが
1つだけある

155
00:10:38,380 --> 00:10:42,260
完璧なアイデアが現れるのを待つのは
止めることだ

156
00:10:42,260 --> 00:10:47,300
『Ape Out』『Crypt of the Necrodancer』
『Crashlands』のようなゲームを見て

157
00:10:47,300 --> 00:10:50,800
こうした作品は直感的な閃きによって
設計されたのだと思い込むのは簡単だ

158
00:10:50,800 --> 00:10:53,400
一度も停滞せずに完成したのだという
思い込みだ

159
00:10:53,400 --> 00:10:57,560
そして同じくらい優れたアイデアが思いつかないなら
わざわざ作ってみる必要など無いだろ？

160
00:10:57,560 --> 00:11:02,140
だが僕がこの動画で示したように
そうした思い込みは、誤解にもほどがある

161
00:11:02,140 --> 00:11:06,140
実際、これらの開発者全員を
結びつけるのは

162
00:11:06,140 --> 00:11:08,800
彼らは始めて
そして何かを作ったという点だ

163
00:11:08,800 --> 00:11:15,080
そしてその時―　開発者が新たなアイデアを試し
試作品を遊び、バグさえ生み出した時にようやく

164
00:11:15,080 --> 00:11:17,820
そのゲームが形作られ始めたのだ

165
00:11:17,820 --> 00:11:22,420
彼らが偉大な開発者である理由は
素晴らしいアイデアを考案したからではなく

166
00:11:22,420 --> 00:11:27,060
ゲームの声を聞くことを知っていたからであり
辿るべき道を知っていたからであり

167
00:11:27,060 --> 00:11:29,660
早く頻繁に失敗する方法を
知っていたからであり

168
00:11:29,660 --> 00:11:33,900
異なるアイデアを融合させて
一貫性を生み出す方法を知っていたからなのだ

169
00:11:34,600 --> 00:11:38,620
だから Game Maker’s Toolkit を視聴して
ゲームを作りたいと思っているのなら

170
00:11:38,620 --> 00:11:40,960
完璧なアイデアを待っていてはダメだ

171
00:11:40,960 --> 00:11:42,380
何かを作ってみよう

172
00:11:42,380 --> 00:11:46,360
そして、ゲームの声を聞き
その面白さを追うといいだろう

173
00:11:46,360 --> 00:11:53,220
そうすれば、ゲームそれ自体が、多少なりとも
自らを設計していることを発見するかもしれない