WEBVTT

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

00:00:09.200 --> 00:00:12.260
だが正に、世に出る前はそうだった

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

00:00:17.740 --> 00:00:21.300
「掴み動作」を使って
壁沿いをコソコソ移動するという内容だ

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

00:00:27.680 --> 00:00:30.580
これが警備員を人質にして

00:00:30.580 --> 00:00:32.860
壁にぶん投げる遊びに繋がった

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

00:00:39.880 --> 00:00:43.280
この構想を中心にして
実際にゲームを開発していった

00:00:43.280 --> 00:00:48.040
彼はステルスや時間ループなどの
不要な要素を全て削除した

00:00:48.040 --> 00:00:51.560
そしてこの面白さを増幅する為なら
なんだってした

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

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

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

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

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

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

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

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

00:01:32.800 --> 00:01:35.560
攻撃する予定のマスを
強調していたのだ

00:01:35.560 --> 00:01:40.720
Subset の開発者はこれが
一番楽しい部分であることに気付き

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

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

00:01:51.640 --> 00:01:54.720
敵がどこを攻撃する予定なのか
事前に把握しているなら―

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

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

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

00:02:06.800 --> 00:02:11.080
だが実は、これを悪用することで
敵に同士討ちをさせることもできる

00:02:11.080 --> 00:02:14.460
この手法を使う開発者が、頻繁に―

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

00:02:18.940 --> 00:02:23.420
『Crashlands』を開発した Butterscotch Shenanigans
の Sam Coster は次のように述べる

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

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

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

00:02:38.580 --> 00:02:40.580
「何が面白いのかをただ
追いかけていくのです」

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

00:02:46.220 --> 00:02:48.860
かなり刺激的な話だろう

00:02:48.860 --> 00:02:52.560
だがそんな素晴らしいアイデアが
天から降ってくる訳ではない

00:02:52.560 --> 00:02:54.430
ではどこから生まれるのか？

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

00:02:59.880 --> 00:03:04.980
設計の Ryan Clark は『Spelunky』の
目まぐるしい意思決定を

00:03:04.980 --> 00:03:08.180
伝統的なターン制のダンジョン探索ゲームに
組み込みたいと考えていた

00:03:08.180 --> 00:03:10.820
そこで彼はローグライクの
簡単な試作品を作ることにした

00:03:10.820 --> 00:03:14.120
次のターンまで
1秒しかないという内容だ

00:03:14.120 --> 00:03:18.720
それを遊んでみると
音ゲーに近い性質があることに気付き

00:03:18.720 --> 00:03:21.920
音楽を主軸にすべきであることが
明らかになった

00:03:24.920 --> 00:03:29.720
または『Rocket League』を象徴する
空中技を見てみよう

00:03:29.720 --> 00:03:32.640
Psyonix がゲームの前身である―

00:03:32.640 --> 00:03:35.400
『Supersonic Acrobatic Rocket-Powered Battle-Cars』
に取り組んでいたとき

00:03:35.400 --> 00:03:37.900
彼らはそれ以来
販売戦略について多くの教訓を得た

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

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

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

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

00:04:00.780 --> 00:04:02.360
そのまま維持した

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

00:04:07.360 --> 00:04:11.600
実際、開発過程で発生した
バグ、不具合、事故が

00:04:11.600 --> 00:04:15.060
機能に転じた事例は
ゲーム史の中では珍しくない

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

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

00:04:28.380 --> 00:04:33.100
重要なのは、この過程には
初めのアイデアが必要になるという点だ

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

00:04:39.140 --> 00:04:44.640
そして試作と試遊の過程で
新しいアイデアが生まれることになる

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

00:04:49.460 --> 00:04:53.920
何が面白いのかを悟り
その側面を探求することを いとわないこと

00:04:53.920 --> 00:04:57.540
たとえそれが当初考えていた企画と
完全に一致していなくてもだ

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

00:05:02.900 --> 00:05:07.160
建物をハッキングするスパイの
パズルゲームに変容した

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

00:05:12.220 --> 00:05:15.020
ミニゲームの一つに過ぎなかった

00:05:15.020 --> 00:05:18.600
だが開発者の Tom Francis が
試作を始めてみるとすぐに

00:05:18.600 --> 00:05:22.640
最終的に『Gunpoint』となる
ゲームが現れたのだ

00:05:22.640 --> 00:05:23.500
Tom 曰く―

00:05:24.060 --> 00:05:27.360
「これをパズルゲームにするべきだと
すぐに分かりました」

00:05:27.360 --> 00:05:28.720
「パズルの仕組みでした」

00:05:28.720 --> 00:05:31.060
「そして『Gunpoint』は何になりたいのか
私に教えてくれたのです」

00:05:31.060 --> 00:05:33.560
「パズルになりたがっていたのは
明らかでした」

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

00:05:37.860 --> 00:05:40.440
「それを中心にゲーム全体を設計しました」

00:05:40.960 --> 00:05:47.460
この方法論は、ゲーム開発の序盤に
最も重要な変化を起こす

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

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

00:05:59.220 --> 00:06:04.380
例えば中身の制作について、Jonathan Blow は
『Braid』のパズルは

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

00:06:09.520 --> 00:06:12.240
Blow 曰く―
「私は学芸員の役割でした」

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

00:06:17.249 --> 00:06:19.249
詳細はこの動画を参照してほしい

00:06:19.249 --> 00:06:22.349
あるいはプレイヤーの反響を
聞くという方法もある

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

00:06:27.000 --> 00:06:29.200
予想外の遊び方を発見した

00:06:29.200 --> 00:06:31.120
だがこうした「バグ」を
修正する代わりに―

00:06:31.120 --> 00:06:35.100
Chris は身を乗り出し
そのバグをゲームの公式要素にした

00:06:35.100 --> 00:06:40.380
ゲーム体験を、心理戦や心理的トリックとして
推し進めたのだった

00:06:40.380 --> 00:06:44.640
そしてこの方法はゲーム開発の
全般的な方針として役立てることもできる

00:06:44.640 --> 00:06:47.440
『Subnautica』の開発者である
Charlie Cleveland は次のように述べる

00:06:47.980 --> 00:06:49.840
「自分の行き先が分かっていると
思うでしょう」

00:06:49.840 --> 00:06:51.540
「そこは地平線上の
どこかにあります」

00:06:51.540 --> 00:06:54.060
「そして道が多くてどう行けばいいのか
分からない」

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

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

00:07:00.480 --> 00:07:03.300
企画の初めには
ホラーを作る意図は無かったのだ

00:07:05.200 --> 00:07:08.800
さて、明らかなことは
このような設計過程を経ると

00:07:08.800 --> 00:07:12.600
ゲームが完成するまでにかかる時間の予測が
非常に困難になってしまう

00:07:12.600 --> 00:07:17.000
この方法論が独立系ゲームの業界で
よく使われている一方で

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

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

00:07:29.040 --> 00:07:33.440
『Gunpoint』と同じく魔法のように
良くなることを期待していた

00:07:33.440 --> 00:07:35.260
しかし……そうはならなかった

00:07:35.260 --> 00:07:37.580
少なくとも、かなり長い間
良くならなかった

00:07:37.580 --> 00:07:40.280
実際、Tom は何がゲームを
面白くするのかを見つける為には―

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

00:07:46.020 --> 00:07:50.560
彼は宇宙船生成システム
人工知能、戦闘システムや

00:07:50.560 --> 00:07:53.580
経済を含む銀河の全体地図などを
作ることになった

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

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

00:08:05.540 --> 00:08:09.820
僕はこの慣用句の出自をこの男まで遡った
Marc LeBlanc だ

00:08:09.820 --> 00:08:13.080
彼は『Thief』と『System Shock』に
取り組んだ開発者であり

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

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

00:08:23.860 --> 00:08:25.920
「まずは失敗してみる」という言葉だ

00:08:25.920 --> 00:08:29.560
この制作過程は、ゲームを
可能な限り早くまとめ上げて

00:08:29.560 --> 00:08:32.020
何が上手くいき、何がそうでないかを
見るためのものである

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

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

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

00:08:45.940 --> 00:08:51.260
まぁ、GMTK の視聴者であればご存知だろうが
その 1つが「Game Jam」だ

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

00:08:57.360 --> 00:08:57.860


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

00:09:02.400 --> 00:09:04.580
Game Jam ついて
こう述べている

00:09:04.860 --> 00:09:08.100
「全体の意図は、頭に浮かんだ
試作品を使って」

00:09:08.100 --> 00:09:10.040
「それを中心に何かを
作ろうというものです」

00:09:10.040 --> 00:09:11.900
「もし上手くいかなくても大丈夫」

00:09:11.900 --> 00:09:13.860
「Game Jam の後で捨てても構いません」

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

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

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

00:09:30.420 --> 00:09:34.280
既にゲームの大部分が出来ていて
ただ中身を増やしたいだけの場合は

00:09:34.280 --> 00:09:38.800
特注のレベル制作ツールを開発すれば
製作作業を高速化できる

00:09:38.800 --> 00:09:41.240
そして一緒に手伝ってくれる人を
増やす

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

00:09:45.780 --> 00:09:49.600
チーム全員が独創的な仕掛けを
考案できるよう促した

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

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

00:10:00.140 --> 00:10:03.120
主人公の実際の見た目は……

00:10:03.120 --> 00:10:04.960
『ゼルダの伝説』のリンクだった

00:10:04.960 --> 00:10:07.860
そして最後に
絶対に変更できない要素が

00:10:07.860 --> 00:10:10.860
実際に役立つことがある

00:10:10.860 --> 00:10:13.120
thatgamecompany の Sunni Pavolic によると

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

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

00:10:22.860 --> 00:10:26.500
これによってチーム全員が従うべき
方向性が明確になり

00:10:26.500 --> 00:10:31.540
発見・開発できるアイデアの範囲を
狭めることに役立った

00:10:34.460 --> 00:10:38.380
だからこの動画から持ち帰ってもらいたいことが
1つだけある

00:10:38.380 --> 00:10:42.260
完璧なアイデアが現れるのを待つのは
止めることだ

00:10:42.260 --> 00:10:47.300
『Ape Out』『Crypt of the Necrodancer』
『Crashlands』のようなゲームを見て

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

00:10:50.800 --> 00:10:53.400
一度も停滞せずに完成したのだという
思い込みだ

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

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

00:11:02.140 --> 00:11:06.140
実際、これらの開発者全員を
結びつけるのは

00:11:06.140 --> 00:11:08.800
彼らは始めて
そして何かを作ったという点だ

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

00:11:15.080 --> 00:11:17.820
そのゲームが形作られ始めたのだ

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

00:11:22.420 --> 00:11:27.060
ゲームの声を聞くことを知っていたからであり
辿るべき道を知っていたからであり

00:11:27.060 --> 00:11:29.660
早く頻繁に失敗する方法を
知っていたからであり

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

00:11:34.600 --> 00:11:38.620
だから Game Maker’s Toolkit を視聴して
ゲームを作りたいと思っているのなら

00:11:38.620 --> 00:11:40.960
完璧なアイデアを待っていてはダメだ

00:11:40.960 --> 00:11:42.380
何かを作ってみよう

00:11:42.380 --> 00:11:46.360
そして、ゲームの声を聞き
その面白さを追うといいだろう

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