WEBVTT

00:00:03.860 --> 00:00:09.120
ゴリラがいない『Ape Out』は
ほとんど想像できない

00:00:09.160 --> 00:00:12.247
しかし最初はまさにそうだった

00:00:12.287 --> 00:00:17.709
開発者 Gabe Cuzzillo によると
最初は時間ループ系のステルスゲームになるはずだった

00:00:17.749 --> 00:00:21.282
押す・つかむ仕様で
壁沿いをコソコソ移動するのだ

00:00:21.322 --> 00:00:27.737
だがゲームに警備員がいるなら
当然同じ仕組みで彼らをつかめるはずで

00:00:27.777 --> 00:00:32.902
これが警備員を拘束して
壁にブン投げる遊びに発展した

00:00:32.942 --> 00:00:36.740
これが作中で一番面白い部分だと
判明したので

00:00:36.780 --> 00:00:43.286
Gabe は方針を大胆に変えて
この概念を中心にゲームを開発していった

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

00:00:47.985 --> 00:00:51.437
そしてこのアイデアを強調するためなら
何でもやった

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

00:00:58.990 --> 00:01:04.014
これは「楽しさを追う」と呼ばれる
ゲーム設計手法の一例だ

00:01:04.054 --> 00:01:10.196
これは一見単純な考え方で
開発者は計画や先入観を無視して

00:01:10.236 --> 00:01:15.036
代わりにゲーム自体に目を向けて
開発の方向性を見出そうという意味だ

00:01:15.076 --> 00:01:19.016
緻密な戦術ゲームの傑作
『Into the Breach』を見てみよう

00:01:19.056 --> 00:01:23.336
このゲームは標準的な
ファミコンウォーズ系の作品として始まった

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

00:01:28.066 --> 00:01:32.711
だがある敵は自分のターンで
何をするつもりなのか正確に示していた

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

00:01:35.662 --> 00:01:40.663
Subset の開発者はこれが
一番楽しい部分であると気づき

00:01:40.703 --> 00:01:46.306
ゲームの他の部分を
もっぱらこの予告攻撃に集中させることにした

00:01:46.346 --> 00:01:51.610
またこれはスタジオが行うべき
他の設計判断にも役立った

00:01:51.650 --> 00:01:57.758
敵が何をするつもりか分かっているなら
自分のユニットを攻撃ゾーンの外に移動できないのか？

00:01:57.798 --> 00:02:02.151
それなら、このゲームの目的は
動かない建物を守ることになるだろう

00:02:02.191 --> 00:02:06.810
だから敵を押し出して
攻撃を失敗させるというゲームにする

00:02:06.850 --> 00:02:11.031
だがこれを使えば
敵の同士討ちも可能になる

00:02:11.071 --> 00:02:14.472
この手法を使う開発者が——

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

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

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

00:02:28.587 --> 00:02:34.680
「設計作業ではなく反復作業として、私たちの仕事は
ただゲームを遊んで、聞いて、感じて」

00:02:34.720 --> 00:02:38.511
「このゲームがどうなりたいのか
探るようなものです」

00:02:38.551 --> 00:02:40.860
「何が楽しいのかを
ただ追いかけるのです」

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

00:02:46.196 --> 00:02:48.772
確かに刺激的な話だろう

00:02:48.812 --> 00:02:52.560
だが素晴らしいアイデアが
自然に生まれるわけではない

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

00:02:54.372 --> 00:02:59.860
リズム型のローグライク
『Crypt of the Necrodancer』の原点を見てみよう

00:02:59.900 --> 00:03:05.047
開発者の Ryan Clark は『Spelunky』の
目まぐるしい意思決定を

00:03:05.087 --> 00:03:08.160
伝統的なターン制のダンジョン探索ゲームに
組み込もうとした

00:03:08.200 --> 00:03:14.099
そこで彼は、次のターンまで１秒しかないという
ローグライクの簡単な試作品を作った

00:03:14.139 --> 00:03:18.717
それを遊んでみると
リズムゲームに近い性質があると気づき

00:03:18.757 --> 00:03:22.151
ゲームを音楽に合わせるべきだと
ハッキリしたのだ

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

00:03:29.722 --> 00:03:32.570
Psyonix がゲームの前身である——

00:03:32.610 --> 00:03:35.390
『Supersonic Acrobatic Rocket-Powered Battle-Cars』
を作っていたとき

00:03:35.430 --> 00:03:37.922
彼らはそれ以来
マーケティングをたくさん学んだ

00:03:37.962 --> 00:03:42.607
彼らは車同士が戦うゲームを作ったが
加速する仕様を追加したかった

00:03:42.647 --> 00:03:46.554
そこで開発者は単純に
車両後部に物理的な力を加えた

00:03:46.594 --> 00:03:52.942
テストでは、空中でその力を使って
競技場を飛び回れることが分かった

00:03:52.982 --> 00:03:56.093
これは計画していなかったが
開発者たちは気づいた

00:03:56.133 --> 00:04:02.276
これがゲームに巨大な深みと高さの次元を加えていたのだ
だからそのまま残した

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

00:04:07.321 --> 00:04:09.763
実際、ゲームの歴史では——

00:04:09.803 --> 00:04:15.019
開発過程で生じたバグ、不具合、偶然が
機能に変わったことがある

00:04:15.059 --> 00:04:22.010
例えば神谷英樹は『鬼武者』で、敵を空中で
何度も斬って手玉にとれるバグを発見した

00:04:22.050 --> 00:04:28.017
修正されてしまったが、神谷はこれを
『Devil May Cry』で一番重要な仕様に発展させた

00:04:28.447 --> 00:04:32.950
重要なのは、この工程には
最初のアイデアが必要だということだ

00:04:32.990 --> 00:04:39.016
それがどんなに散漫で、不明瞭で、独創性がなくても
実際に動く試作品を作るのだ

00:04:39.056 --> 00:04:44.584
そして試作と試遊の過程で
新しいアイデアが生まれることがある

00:04:44.624 --> 00:04:49.440
そのためゲームの声を素直に聞くかどうかは
開発者次第だ

00:04:49.480 --> 00:04:53.802
何が面白いのかを認識し
その側面を積極的に探求すること

00:04:53.842 --> 00:04:57.525
たとえそれが最初に考えていたものと
完全に一致していなくてもだ

00:04:57.565 --> 00:05:02.754
こうして『Gunpoint』は宇宙ロボが
人に向けて冷蔵庫を落とすという内容から

00:05:02.794 --> 00:05:07.017
建物の配線を変えるスパイの
パズルゲームに変わったのだ

00:05:07.057 --> 00:05:12.131
この配線の仕組みは
『Deus Ex』に触発された横スクロールの

00:05:12.171 --> 00:05:14.936
ミニゲームの１つに過ぎなかった

00:05:14.976 --> 00:05:18.527
だが開発者の Tom Francis が
試作を始めるとすぐに

00:05:18.567 --> 00:05:22.729
最終的に『Gunpoint』となる
ゲームが現れた

00:05:22.769 --> 00:05:24.013
Tom は述べる

00:05:24.053 --> 00:05:28.664
「これをパズルゲームにすべきだとすぐに分かりました
パズルの仕組みでした」

00:05:28.704 --> 00:05:33.306
「Gunpoint が何になりたいのか教えてくれたのです
パズルになりたがっていたのは明らかでした」

00:05:33.346 --> 00:05:37.451
「そして私は方針を転換して
ハッキングの仕様を拡張し」

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

00:05:40.960 --> 00:05:47.446
そのためこの手法は一般的に
ゲーム開発の序盤に最も重要な変化を起こす

00:05:47.486 --> 00:05:53.353
そのため Sam Coster はゲームのことを
「柔軟なマグマの白熱球」と表現している

00:05:53.393 --> 00:05:59.214
だが開発が進んでゲームの形が決まり始めても
この手法はまだ使うことができる

00:05:59.254 --> 00:06:04.323
例えばコンテンツの制作だ
Jonathan Blow は『Braid』のパズルは

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

00:06:09.524 --> 00:06:12.105
彼が言うには
「私は学芸員の役割でした」

00:06:12.145 --> 00:06:17.162
「正解を整理して、プレイヤーが楽しめるように
提示したのです」

00:06:17.202 --> 00:06:19.279
詳細はこの動画を見てほしい

00:06:19.319 --> 00:06:24.559
またプレイヤーの感想を聞くときにも使える
Chris Hecker が『Spy Party』を作ったとき

00:06:24.599 --> 00:06:29.003
プレイヤーは色々な裏技や
予想外の遊び方を発見した

00:06:29.043 --> 00:06:35.149
これらの「バグ」を修正するのではなく
Chris はバグをゲームの公式要素にした

00:06:35.189 --> 00:06:40.352
ゲーム体験を心理戦や心理トリックの方向へ
変えたのだ

00:06:40.392 --> 00:06:44.637
または単にゲーム開発の
全体的な指針にも使える

00:06:44.677 --> 00:06:47.646
『Subnautica』の開発者
Charlie Cleveland はこう述べる

00:06:47.877 --> 00:06:51.508
「遠くにある目的地を
分かってる気になってますが」

00:06:51.548 --> 00:06:53.943
「道が多すぎて選べません」

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

00:06:57.491 --> 00:07:03.054
それで彼のスタジオはホラーゲームを作ったのだが
企画の開始時にそんなつもりは無かったのだ

00:07:05.281 --> 00:07:12.281
さて、明らかにこのような設計工程では
ゲーム制作にかかる時間が非常に予測しづらくなる

00:07:12.453 --> 00:07:17.015
そのため、この方法論は
独立系ゲームの世界では人気だが

00:07:17.055 --> 00:07:21.200
超大作ゲームを作る厳しい統制の世界では
あまり使われていない

00:07:21.240 --> 00:07:25.021
Tom Francis が２作目の
『Heat Signature』を作ったとき

00:07:25.061 --> 00:07:31.100
彼は「宇宙船に入る」という曖昧なアイデアが
魔法のように良作を生むと期待していた

00:07:31.140 --> 00:07:35.226
『Gunpoint』で起きたことの再現だ
だが…そうはならなかった

00:07:35.266 --> 00:07:37.525
少なくとも長い間はダメだった

00:07:37.565 --> 00:07:43.954
実際、彼はゲームを面白くする要素を見つけるためには
大量の要素を作る必要があると気づき

00:07:43.994 --> 00:07:49.403
これが開発の長期化に繋がり
彼は船の生成システムや、人工知能

00:07:49.443 --> 00:07:53.628
格闘システム、経済を含む銀河全体マップなどを
作ることになった

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

00:07:59.519 --> 00:08:05.514
だから本当の文言は、ただの「楽しさを追う」よりも
少し長いことは覚えておく価値がある

00:08:05.554 --> 00:08:09.811
僕はこの言葉の起源をこの男まで遡った
Marc LeBlanc だ

00:08:09.851 --> 00:08:13.110
彼は『Thief』や『System Shock』を
手がけた開発者で

00:08:13.150 --> 00:08:17.144
MDA フレームワークなどを考案した
教育者でもある

00:08:17.184 --> 00:08:23.931
彼がこの言葉を作ったとき
実は起業家精神の世界で有名な慣用句が発端だった

00:08:24.147 --> 00:08:25.949
「早く失敗する」だ

00:08:25.989 --> 00:08:31.778
これはゲームをできるだけ早くまとめ上げて
上手くいくものとそうでないものを見極める作業だ

00:08:31.818 --> 00:08:35.012
時間を無駄にしていないので
失敗しても問題ではない

00:08:35.052 --> 00:08:41.015
だがいわゆる「失敗」は、次の試作がどの方向へ
行くべきかたくさん教えてくれる

00:08:41.055 --> 00:08:45.950
では、試行錯誤を高速化するための
具体的な手法はあるのか？

00:08:45.990 --> 00:08:51.240
GMTK の視聴者は知っているだろうが
その１つが「ゲームジャム」だ

00:08:51.280 --> 00:08:57.552
これは大慌てのゲーム開発マラソンであり
たぶん１回の週末でゲームを作らないといけない

00:08:57.592 --> 00:09:02.423
Arvi Teikari はゲームジャムで受賞したパズルゲーム
『Baba is You』を考案した人物で

00:09:02.463 --> 00:09:04.687
このイベントの威力について
語っている

00:09:04.727 --> 00:09:09.751
「要は、頭の中にある試作品を元に
何かを作ろうということです」

00:09:09.791 --> 00:09:13.408
「上手くいかなくても大丈夫
ゲームジャムの後で捨ててもいい」

00:09:13.448 --> 00:09:18.258
「ゲームジャムより長くそのアイデアに
専念することはありません」

00:09:18.445 --> 00:09:24.462
別の方法は、Game Maker や Godot などの
手早く試作できるツールを使うことだ

00:09:24.502 --> 00:09:30.383
あるいは紙での試作や、LEGO や
PS4 のゲーム制作ソフト『Dreams』を使う

00:09:30.423 --> 00:09:34.181
既にゲームの大部分を作っていて
コンテンツを増やしたいだけなら

00:09:34.221 --> 00:09:38.668
独自のステージ制作ツールを開発すれば
制作作業を高速化して

00:09:38.708 --> 00:09:41.201
たくさんの人に手伝ってもらえる

00:09:41.241 --> 00:09:45.706
任天堂は『マリオギャラクシー２』で
簡単なステージ設計ツールを作り

00:09:45.746 --> 00:09:49.534
チーム全員が独創的な仕様を
考案できるようにした

00:09:49.574 --> 00:09:55.536
また設計や仕様に素早く集中するために
仮のアート、音楽、筋書きを利用できる

00:09:55.576 --> 00:09:59.945
Klei が『Don't Starve』の
最初のゲームジャム試作品を作ったとき

00:09:59.985 --> 00:10:02.946
主人公の実際の見た目は……

00:10:02.986 --> 00:10:04.689
ゼルダの伝説のリンクだった

00:10:04.729 --> 00:10:10.692
そして最後に、絶対に変更できない要素が
実際に役立つこともある

00:10:10.732 --> 00:10:13.075
thatgamecompany の
Sunni Pavolic によると

00:10:13.115 --> 00:10:17.662
『風ノ旅ビト』の制作時
スタジオは試行錯誤をかなり繰り返したが

00:10:17.702 --> 00:10:22.831
このゲームは「愛」を探求する作品であるという
考えを常に持っていたらしい

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

00:10:26.490 --> 00:10:31.569
発見、開発できるアイデアの範囲を
狭めることができた

00:10:34.347 --> 00:10:38.353
だからこの動画から１つだけ
持ち帰ってほしいことがあるとすれば

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

00:10:42.325 --> 00:10:47.235
『Ape Out』『Crypt of the Necrodancer』
『Crashlands』などのゲームを見て

00:10:47.275 --> 00:10:50.311
これらのゲームは
直感の閃きで設計されており

00:10:50.351 --> 00:10:53.290
停滞せずに完成したと
思い込むのは簡単だ

00:10:53.330 --> 00:10:57.552
そういう良いアイデアが思いつかないなら
なぜ作らないといけないのか？

00:10:57.592 --> 00:11:02.140
だが僕がこの動画で示したように
それは誤解にもほどがある

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

00:11:06.146 --> 00:11:08.772
彼らは始めて
何かを作ったという点だ

00:11:08.812 --> 00:11:15.021
そして開発者が新しいアイデアを試し
試作品を遊び、バグさえ作ったときに初めて

00:11:15.061 --> 00:11:17.809
今のゲームが形作られたのだ

00:11:17.849 --> 00:11:21.723
彼らが偉大なのは
素晴らしいアイデアを考えたからじゃなく

00:11:21.763 --> 00:11:27.018
ゲームを聞く方法や
辿るべき道を知っていたからであり

00:11:27.058 --> 00:11:29.717
早く頻繁に失敗する方法や

00:11:29.757 --> 00:11:34.300
異なるアイデアを融合させて
一貫性を作る方法を知っていたからなのだ

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

00:11:38.601 --> 00:11:42.258
完璧なアイデアを待つのはダメだ
何かを作ってみよう

00:11:42.298 --> 00:11:47.203
そしてゲームを聞いて楽しさを追うといい
運が良ければ——

00:11:47.243 --> 00:11:53.220
ゲームがささやかながら自らを設計していることに
気づくかもしれない

00:11:53.870 --> 00:11:54.620
（字幕翻訳：Nekofloor）