2024年2月5日、Unity Japanの代表取締役であった大前広樹氏の退任、及び顧問への就任が発表された。
2023年2月にUnity Japanの代表に就任した大前氏は、2010年ごろから「Unity」が日本で浸透するために尽力してきた人物で、Unity Japanの立ち上げにも関わってきた。かつてはゲームプログラマーとしてフロム・ソフトウェアで『デモンズソウル』などの開発に取り組み、またUnityでは『COGEN』の開発などに携わっていた経歴も持つ。
そんな大前氏がゲーム開発者との連帯を深めるべく、電ファミニコゲーマーを通じ、彼が聞き手を担う連載企画が進行していた。上述したような経歴を持つ大前氏の視点から、現在のゲーム開発についてや、ゲームを作っていく生き方などについて、いろいろな話ができれば面白いのではないか──と考えていたのだ。
しかし準備を進めていた最中の2023年9月、Unity本社が発表した新料金ポリシー「Unity Runtime Fee」がゲーム開発者を中心に大きな混乱を招いた。
今でこそその問題点は修正され、ポリシーは正式に変更となったわけだが、当時は「できあがった原稿もふくめ、連載自体をお蔵入りにするべきではないか」というところまで議論は発展し、そうこうしているうちに大前氏の退任まで決定してしまった……という次第である。
こうした流れを踏まえ、正直なところ「出さない方が無難ではある」とは思いつつも、Unity＆大前氏側に相談をさせていただいたところ、
「記事自体は、自分たちだけで完結しているものではなく、取材に対応してくれた先方あってのものでもある。Unityの都合で掲載が見送られてしまうのも、それはそれで違うのではないか」
「Unityとしても、信頼回復に向けていろいろな取り組みを行っていくつもり。さまざまなご意見があるとは思いつつも、とにかくまずは踏み出してやっていくしかない」
「大前氏が代表から顧問になった後も、Unity Japanとして引き続きゲーム業界にコミットしていく姿勢は変わらない」
という見解を頂いた。
そうであるならば──「編集部としても、記事はぜひ掲載させてほしい」とお願いをし、大前氏が退任を発表したこのタイミングでの公開に相成った。
本件、ぶっちゃけUnityと大前氏としてもリスクのある決断だったとは思うので、記事公開の許可をいただいたことに対して、まずはお礼を言わせていただきたい。ありがとうございます。
というわけで。
今回大前氏を聞き手として話を伺ったのは、『Papers, Please』や『Return of the Obra Dinn』などの傑作インディーゲームの開発者として知られるルーカス・ポープ（Lucas Pope）氏だ。
直近では、「手回しクランク付き」というユニークな携帯型ゲーム機「Playdate」向けの新作ゲーム『Mars After Midnight』がリリースされたばかり。
ルーカス氏といえば、その極めてユニークな作風によってインディー界を風靡した、まさに天才的とも言えるゲーム開発者。それだけに、あんなことやこんなことも聞いてみたい！
そして実際、今回の取材では氏の独創的なゲーム制作の手法について、かなり詳細にお話を伺うことができた。
加えて、ルーカス氏はあまり表に出ることの少ない人物でもあるため、本稿の内容は大変貴重なものとなっている。そのため、電ファミ編集部としてもこれをお蔵入りにしてしまうのはあまりに忍びないと感じていたのである。
インディーゲーム開発のみならず、ゲーム開発を生業にしている人なら必読の内容になっていると思うので、ぜひ記事を読んでみて貰えればと思う次第。独創性に富む、ルーカス氏の裏側にある考え方とは──？
※この記事はユニティ・テクノロジーズ・ジャパンと電ファミ編集部のタイアップ企画です。
Unityのいいところは、ゲーム開発で「何に時間を費やすか」を素早く判断できるところ
大前広樹氏（以下、大前氏）：
本日はよろしくお願いいたします。私はルーカスさんの大ファンなので、お聞きしたいことが山ほどあります。ですから正直なところ、今日はUnityに関する質問はしないかもしれません（笑）。
ルーカス・ポープ氏（以下、ルーカス氏）：
もし必要であれば、Unityに関してはいくらでもお話しできますよ（笑）。
大前氏：
ありがとうございます。であれば、せっかくUnityを活用してもらっていますし、いくつか聞いてみてもいいかもしれないですね。
さて、ルーカスさんは日本にお住まいで、完全な個人制作でゲームを作って生計を立てていらっしゃいますよね。たしか、ご家族も一緒でしたよね？
ルーカス氏：
ええ。私の妻は日本人で、ロサンゼルスで出会ったんです。結婚した後もロサンゼルスの「Realtime Associates」というゲーム会社で一緒に働いていました。その後、私はノーティードッグ【※】に転職することになります。
ただ、私のキャリア自体は実験的なゲームの制作から始まっているんです。なので、その頃に戻りたくなってしまって、それで日本で同じことをやってみようと思ったんです。
※ノーティードッグ
カリフォルニア州サンタモニカに拠点を置くゲーム開発会社。『クラッシュ・バンディクー』、『アンチャーテッド』、『The Last of Us』など人気ゲームシリーズを多数手掛ける。
大前氏：
ロサンゼルスのどのあたりでお仕事をされていたんでしょうか？
ルーカス氏：
サンタモニカですね。悪くはなかったんですが、交通量がすさまじいところで……。その点、日本は車なしで移動ができて最高です。
大前氏：
私も3年半くらいロサンゼルスに住んでいたのでわかります（笑）。
実は、南カリフォルニア大学に通っていたんです。卒業はしませんでしたが。
ルーカス氏：
そうなんですね。どのくらいの期間、アメリカにいらっしゃったんですか？
大前氏：
高校の時からなので、おおよそ6年くらいでしょうか。
14歳のころからゲームプログラマーになりたいと思っていたんですが、そのためには英語の能力が必要だと思って。
大学をやめたあとは、日本でITのスタートアップからはじめて、2年くらいしてからゲーム会社に転職しました。
ルーカス氏：
それは大変でしたね。
大前氏：
実際のところは楽しかったですよ。母から買ってもらったMacで自分のゲームを作っていましたから。といっても、当時のMacはあまりゲーム開発には向いていませんでしたけどね。
当時はゲームエンジンも何もなかった時代だったので、「ゲームを作る」というのは「ほとんどすべてを自分でやる」に近いものでした。
ルーカス氏：
私も、じつはゲームを作り始めたときはMacからでした。当時のゲーム開発は、大変だったけど面白かったですよね。何が起きて、何をすればいいのか、本当にわからなくて。
いまはUnityを使ってMacからPC向けに公開できますから、自分はMacで開発していますよ。いい時代になったと思います。
大前氏：
その後、フロム・ソフトウェアで5年半働いていて、『アーマード・コア4』やいくつかのPS2のゲームで音楽まわりのライブラリ開発などを担当していました。
それからフロムはマルチプラットフォームに進出することになるのですが、当時フロムの中で、マルチプラットフォームでのゲーム開発について話しているのが私だけだったんです。そうしたら、その機会が来た時に「じゃあやってよ」と。それで、マルチプラットフォームで動くシステムを作ったんです。
ルーカス氏：
すごいですね、マルチプラットフォーム向けですか。
大前氏：
そのシステムは『デモンズソウル』や『アーマード・コア4』あたりで使っていたんですが……最近一緒に飲みにいった『アーマード・コア6』のスタッフいわく、まだ私が作ったシステムがけっこうそのまま残っているらしくて。
ルーカス氏：
自分が書いたコードがどれくらい変わったのか、気になりませんか？
私は『アンチャーテッド』シリーズのメニューやセーブデータ周りを担当していたんですけど、そのコードはほとんど私ひとりで書いた、めちゃくちゃなものだったんです（笑）。最終的にはちゃんと動いたんですけど、あのコードがいまどうなったか確認するのはちょっと恥ずかしいですね。
大前氏：
でもこの手のものって、けっこうそのまま残っちゃいがちなんじゃないかと思います。コードが汚かろうが、ちゃんと動いてはいますからね（笑）。
ルーカス氏：
そうですよね。実際にはコードの見た目や構造の美しさって、そこまで重要ではなくて。プロダクションコードは、乱雑でも動けばいい。
私も若いころはけっこう完璧主義者だったので、そこに気づくのにだいぶ時間がかかりましたけどね。美しいAPIの仕様を考えることよりも、QA（品質管理）テストを通過することのほうがずっと価値があると思います。
大前氏：
おっしゃる通りだと思います。実際、ゲームエンジンやシステム関連のコードの多くは生産的でも創造的でもないですからね。
プロジェクトとしてマルチプラットフォーム対応に向けた作業は必要な仕事であって、誰がやるかは関係ないし、結局誰がやっても80%はほぼ同じになります。
だから、それにあまり気を使う必要はないんですよね。
もし改善が本当に必要なら、その改善が実際に必要なのか、それともその時間をゲームをもっと面白くすることに使うのかを判断する方が大事なはずです。
ルーカス氏：
おっしゃるとおりです。
というのも、ひとりですべてを開発していると、「何に時間を使うか」というだけでも、たくさんの取捨選択が必要になるからです。
Unityのいいところは、その取捨選択の判断を素早く行えるところだと思います。何かにつまずいても、その問題をちょっと後回しにして、先にグラフィックや音楽など別の作業を進められるんです。
大前氏：
その点で、『Papers, Please』の開発はどうだったのでしょう？
ルーカス氏：
『Papers, Please』のオリジナル版は、OpenGLをベースとしたOpenFLというエンジンで作業していました。でも、いくらベースが20年物の大御所級エンジンとはいえ、PCの相性問題には勝てません。
そして、そのゲームが20万本、20万台の異なるコンピュータで実行されると思うと……。
大前氏：
怖ろしいですね……。
ルーカス氏：
ゲーム開発において、ハードウェアの互換性やエンジンの選択に関する課題は重要なんです。ハードウェアはいつどこで不具合が起こってもおかしくないですからね。
実際、ハードウェア起因の不具合については、私のせいでもなければ、エンジンのせいでもプログラミング言語のせいでもない。デバイスドライバを作っている人たちが、ちょっと仕様を変えるだけで特定のユーザーの環境でゲームが動かなくなるんです。
でもユーザーはお金を払っているから、私にはそれをなんとかする責任が生じる。そのユーザーの環境で直接試せるわけではないので、何度もやりとりを重ねて解決を目指すしかないんです。
大前氏：
実は私がUnityに参加した理由も、いまルーカスさんがおっしゃられたことと同じような経験があったからなんです。
特に小規模な開発者さんの場合、そうしたアフターサポートまでやらなければいけないのはあまりに荷が重すぎる。それよりも、コンテンツや体験の提供に貴重な時間を割いてほしいわけです。
ルーカス氏は、とにかく開発ツールをたくさん作る。ゲーム開発よりもツール開発の方が好きなくらい
ルーカス氏：
Unityを使って驚いたのは、エディターの使いやすさやその一貫性、そしてやってみたいことが何でも実現できることでした。
私は大のツール好きで、いつも開発ツールを作っているんです。一度作ってしまえば仕事の効率が倍増するので、ゲーム開発よりもツール開発の方が好きなくらいです（笑）。
Unityではツールの変更や新しいインスペクター・パネルの追加、プロセスの実行、自動化などが非常に簡単に行えますから、ツール好きとしてもありがたいところです。
たとえば『Return of the Obra Dinn』（以下、Obra Dinn）ではマップのレイアウトにUnityを使用していたのですが、ゲームを実際に実行することなく、何か物を動かしたりボタンを押すだけで、アセットを再設置できるのも便利でしたね。
大前氏：
そんなにツールを作っていらっしゃるんですか。ツールづくりにかける時間と、そうでない時間はどれくらいの比率でしょうか？
ルーカス氏：
ツール作りは私の仕事の約40%くらいで、残りの60%はゲームのプログラミングに費やしていると思います。
私にとって、ツールは何か問題が起こったときに役立つ、ある種の解決策なんです。
何か問題があって開発の手が止まったとき、その問題部分を切り離して解決策を考えます。ある程度案が固まったら実際に手を動かして、適宜PythonやHaxe、C#などを用いてツールを作り始めるんです。
もうひとつ、ツールのいいところはそれが「完成品である必要はない」ということです。
正直なところ、私も開発中は多くの仕事を投げ出していました。そんなときに、ツール作りを進めることで、ちょっとでもアウトプットを稼ぐようにしていたんです。そのアウトプットがのちのち効いてくる場面もたくさんありました。
──ルーカスさんのようにツールをたくさん作るのは普通のことなんでしょうか？
ルーカス氏：
そんなことはないと思いますよ。
私がノーティードッグで働いていたときは、たくさんのツールがありました。でも、基本的に大企業だとツールを作る人間とツールを使う人間が別なんです。 生産能力もそもそも段違いだと思いますし。
大前氏：
日本には、「永遠に開発する」ことを意味する「エターナる」という面白い言葉があります。
この言葉には、ゲーム開発が未完に終わることを指すほか、個人でプロジェクトを進めていると、いつのまにかゲームの完成よりもツールの開発に没頭してしまうことが多いので、「ツールだけ作っていても前進とは言えないから、気を付けよう」という教訓的な意味合いもあるようです。
実際のところ、一般的なインディーゲーム開発者はツールをシンプルに保つように意識しないといけないのかもしれませんね。一方で、ルーカスさんはツール作りにそれだけ時間を割いてもきちんとゲームをリリースできているのですから、すごいですよね。
ルーカス氏：
その点については、ノーティードッグで学んだことが大きいと思います。実際、私も以前は技術面やツール開発などに今よりももっと時間を割いていましたから。
ノーティードッグのようなゲーム会社では、個人開発と違って「ゲームがいつリリースされるか」を決めるのは私ではなく、会社の判断です。だからこそ、ゲームは未完に終わらずリリースされるわけだし、何よりゲームが実際にリリースされてみないと、結局何がいちばん大事だったのかもわからないわけです。
たとえば、ユーザーに遊ばれることで、気づきもしなかったバグが見つかったり、逆に自分が重大なバグだと思っていたものが誰にも見つからないといったことが起きます。こういった経験を経て初めて、次のゲーム開発をもっと良くすることができるようになるんじゃないかと思います。
ですから、大前さんのおっしゃった「エターナる」開発者の方々には、「実際にゲームをリリースして得られるフィードバック」が欠けているのではないかと感じます。
やはり、そのフィードバックがなければ、開発において「重要なもの」と「そうでないもの」を判別するのは難しいのではないかと。
「制約」を事前に設定することにより、「どう上手くやるか」という工夫が生まれる
大前氏：
他メディアでのインタビューだったと思うのですが、ルーカスさんはおひとりでゲーム制作を続ける理由として、“他の人の人生を左右したくない”とおっしゃっていましたよね。
音楽やグラフィックに関していえば、マーケットプレイスで購入することなども含めて比較的簡単に共同作業が実現できると思うのですが、おひとりで制作することにこだわる理由はなにかあるのでしょうか？
ルーカス氏：
結局「自分ひとりでやる」のが好きだからなんだと思います。
結果として多くの作品を作れなかったとしても、『Obra Dinn』のように私自身で納得のいく出来まで作り込むことができれば、問題ないと思っているんです。
たとえば『Obra Dinn』では「すべてのテクスチャを作る必要はない」と判断しました。もちろん、テクスチャはすべてちゃんと作ったほうがゲームはリッチになるでしょう。でも、それでは私ひとりで作りきるには作業が膨大になりすぎますし、「グラフィックのリッチさ」は『Obra Dinn』というゲームにとって必ずしも必要ではないのです。
ですから、私ができる範囲でうまくこなせる手段が見つかれば、より優れたテクスチャアーティストが居たとしても関係ないのです。
大前氏：
たしかに『Obra Dinn』の独特なアートスタイルは、さまざまな面でゲーム全体の雰囲気を醸し出していると思います。3Dにもかかわらず、キャラクターの顔はぼんやりとしていて明確には描かれていない。
でも、これが“記憶をたどる”という『Obra Dinn』のコンセプトとピッタリ合っているわけですよね。制約やスタイルがゲームのプレイ体験を向上させているいい例だと思います。
ルーカス氏：
言うなれば、『Obra Dinn』は「アートスタイルとゲームシステムをいかに上手く組み合わせるか」を試行錯誤する、魅力的なパズルでした。
「Maya【※】上での作業をなるべく減らして、どこまでアートを魅力的に見せられるか」という制約の中で“どう上手くやるか”を模索するのが非常に楽しかったんです。
※Maya
3Dアニメーション作成ソフト。UnityにはMayaとの連携機能がデフォルトで存在する。
大前氏：
技術や才能があるかどうかよりも、制約を設定したうえで「上手くこなせるか」「どう上手くやるか」という観点が重要なんですね。
ルーカス氏：
そうなんです。上手くこなすことさえできれば、ゲーム制作はパズルのように面白くなってくるんです。
これは私の一例ではありますが、「自分のできる範囲で楽しんで取り組めて、しかも最終的に面白いゲームになる」というような作業フローが構築できるのが理想だと思います。
大前氏：
先ほどおっしゃっていた「制約」はどのタイミングで生まれるのでしょうか。プロジェクトの開始前に設定するのか、それともある程度進んだ段階で自然に生まれるものなのでしょうか？
ルーカス氏：
良い質問ですね。私の場合、たいていは事前に設定しています。
重要なのは「大手スタジオがやらないような制約」を選ぶ必要があることです。もしそこで競合してしまったら、とても太刀打ちできませんからね。
そこで私が設定した制約は、『Papers, Please』では「入国審査官になって書類をチェックするだけでゲームができるのか？」、『Obra Dinn』では「1bitのグラフィックで、モダンな3Dゲームが作れるのか？」というものでした。この制約の中でどれだけ楽しいものを作れるのかを考えたのです。
大前氏：
私もMacintoshで育った人間のひとりなので、あの『HyperCard』や『Samurai Mech』のようなゲームを彷彿とさせる『Obra Dinn』のグラフィックを見た瞬間に「買わなきゃ！」と思いました（笑）。
実際、その「制約」による『Obra Dinn』のアートスタイルはマーケティングの観点からしても大きな成功だと思いますね。ゲームのスタイルや方向性に集中できるだけでなく、やはり他のゲームに比べて際立ったインパクトを与える結果になっているかと思います。
ルーカス氏：
広報担当がいないので、マーケティングに関しては「やらない」か「ほとんどできない」の2択になってしまうんです（笑）。
ですから、ゲームを魅力的に見せる手段も限られてきます。数枚でゲーム内容を理解できるスクリーンショットやコンセプトなど、ひとつかふたつの要素に絞られますね。
大前氏：
なるほど。ゲームになりそうなアイディアを選ぶ際には、そうしたマーケティングの観点から勝てるのか、という点も考慮に入れる必要があると。
そう考えると、勝つために考えたアイディアが自分自身が作りたいモノにどれだけ貢献しているか、という点も重要ですね。
ルーカス氏：
おっしゃるとおりです。
私は普段、やりたいことのリストを作っているのですが、その中で頭から離れないモノや「イケそう」と感じたモノを整理しながら、どれが実現可能で、かつ長期的に取り組むことができるのかを考えています。
大前氏：
そうしたアイディアをもとにゲームを作り始めて、途中まで作って投げ出したりすることもあるのでしょうか？
ルーカス氏：
たまにですが、ありますね（笑）。でもかなり稀な例です。普段は「良いゲームになりそうなアイデア」を思いついてから手をつけることが多いです。
たとえば『Obra Dinn』での「現場の記憶を遡るシステム」がいい例ですね。それを実現するために必要な作業量は未知数でしたが、このアイディアで良いゲームが作れそうだ、とピンときていたのです。
もっとも、その時点で実際の作業量が見えていたら作るのをやめていたかもしれませんが……（笑）。
大前氏：
大変な作業量だったのですね……（笑）。ここまでお話を聞いていると、本当にたくさんのアイディアがあるようですが、複数のゲームの開発を同時に進行することはあるのでしょうか？
ルーカス氏：
少なくとも今はそこまで手が回っていませんね。『Papers, Please』と『Obra Dinn』のメンテナンスも並行して実施しなければいけないので、ひとつのゲームを作ることで精いっぱいなんです。
「メンテナンスのしやすさ」という観点で言えば、Unityはとても優れていて、大変助かっていますよ。
