GMOアプリクラウドは、6月15日、GMOインターネットグループが運営するコミュニケーションスペース「GMO Yours」にて、「ゲーム開発と技術力」をテーマとしたイベントとして、「現場のエンジニアが語る『Fate/Grand Order』の開発技術からアップデートに関するノウハウまで一挙公開」を開催した。
本イベントでは、ゲーム運営や開発に関わっている方々を対象に、『Fate/Grand Order』の開発をリリース当初から支えるサーバーエンジニアと、ディライトワークスの技術力向上のために、日々課題に取り組んでいるテクニカルディレクターによる「面白いゲームの作り方」や「海外展開に向けた取組み」について技術的側面から講演を行った。
本稿では、ディライトワークスの田村祐樹氏が登壇した、第三部「なぜ技術がないと面白いゲームがつくれないのか？」についての内容をレポートしていく。
第三部では、コンソールゲームからソーシャルゲームまで、田村氏が色々な開発をしてきた経験をもとに、「なぜ技術がないと面白いゲームがつくれないのか？」について言及。特に、最近のスマホゲームは更新し続けられることが利点でもあるが、逆に更新し続けなければならないジレンマがあることを、ゲーム開発と運営の実体験からトークが展開された。
■田村 祐樹 氏（ディライトワークス株式会社）
コンシューマゲームのデベロッパーに入社後、メインプログラマなどを担当。印刷会社の基盤システム構築および、動画共有サイトの構築などを経て、再度コンシューマ開発を担当。その後、ソーシャルゲーム会社に参画し、執行役員を務める。2015年に独立し、ピアレス株式会社を設立。2016年ディライトワークス株式会社へ入社し、テクニカルディレクターを務める。
■”面白いゲーム”を創るために必要な能力とは
講演の冒頭で自己紹介を終えた田村氏は、本講演の趣旨について「面白いゲームの創り方」を紹介するのではないと念を押した。
続けて、田村氏はゲームの開発期間や予算、規模が大きくなったことからゲーム開発という業種が未曽有の危機に瀕していると指摘。実際、2年かけた完成間近のタイトルが様々な事情からプロジェクト中止になったり、発売はしたもののバグが多くユーザーからの評価が散々だったたりという話を耳にしているという。その原因として、下記の2点を挙げた。
1.ユーザー視点の欠如
2.試行錯誤の不足
上記の問題について、”技術でどう立ち向かっていくか”という点について本講演でトークを展開した。
冒頭にも述べられた通り、複雑な技術や高度な技術が面白さと直結するわけではないが、面白い企画が出た際にそれを実現できる技術力がなければアイデアごと捨てられてしまうので、技術力は必要だという。田村氏は、技術力がなければ作成できないものは多数あり、「失敗を恐れてリスクを取らない」という選択を続けるとゲームが死んでしまうと注意を促した。
▲ただし、無計画に増築してしまうとちぐはぐなゲームになってしまう。
そこで必要になる能力が”変化に対応していく力”だという。ゲーム開発では、日々新しい技術が生み出されており、やりたいことには限界がなく実現できることもどんどん増えている。そこで、開発中・リリース後も常に先を見据えて変化に強い設計をしておくことで多彩なケースへの対応が可能になるというのだ。さらに、これを実現するには試行錯誤を重ねるための技術力や、失敗を恐れずリスクを選択し、それをカバーできる力が必要になると話した。
では、「変化＝更新」とは何なのか。
過去のコンソールゲームには「完成させれば終わり」という考えがあったが、今はほとんどのゲームにアップデートという概念があるため、1年、2年と月日を経るほどそのゲームがどうなっているかは誰にも分からないものだと田村氏は語る。どういったものが良い設計かについては、ゲームを面白くしたいときに邪魔にならず、より面白くできる柔軟な構造であることが条件になるという。
▲そもそも「変化を前提とした設計」を前提としなければゲームとして成り立たないところまできているとのこと。
その後、ゲーム開発を行ううえで必ず通ることになるフィーチャー・クリープと仕様変更についての紹介を行った。
【フィーチャー・クリープとは】
▲機能を追加した結果、面白くなるかどうかは遊んでみないと分からないため、これが一概に悪であるとも言えないという。「最初に全部決めてください」という要望には応えられないため、どうしても変更を避けることができないのだと説明した。
また田村氏は、変更を行う際には下記で紹介する5つの原則が重要な指針になっていると紹介。ただし、これは問題が発生した際に適応する指針で、原則主義者になってはいけないと付け加えた。
●1.単一責任の原則
これは、役割（責任）＝変更理由、即ちクラスを変更する理由はひとつでなければならないという指針。ひとつのクラス／モジュールは、ひとつの責任しか持ってはならない。
この原則を破った悪い例として、下記の何でもやるプログラマークラスを紹介した。
【悪い例】
役割をきちんと分けることで下記のようにシンプルな構造になり、この問題を解消できる。
【良い例】
▲図で説明されたのがこちら。写真左が悪い例、右が良い例となっている。
●2.オープン・クローズドの原則
拡張に対して開かれている＝様々なアイデアに対応しやすく仕様変更に強い。修正に対して閉じている＝エンバグしにくい。一部直したら全体に影響するというのは絶対に避ける。この原則については、とある1日のスケジュールを例として紹介。
【良い例】
▲上記の例では順序の入れ替えや割り込みなど、融通が利きやすく個々が疎結合となっている。
【悪い例】
▲一方、こちらのケースは何かを前提に動いているため非常に融通が利きにくい。この中のひとつがリスケされることで他のMTGを開催できなくなるなど、個々が密結合になっている。
つまり、「開いている」とは振る舞いを拡張できること、「閉じている」とは他に影響を与えないことだと説明した。
●3.リスコフの置換原則
▲基本型にできることが派生型でできなくなってはいけないとのこと。
例えば、長方形を継承して正方形を作ることはできるか。答えはNoである。これは、正方形は常に「幅」と「高さ」を満たす必要があるので、長方形と置き換えることができない。こちらの原則では、置き換えることができないものを同一として扱うことで自身の意図しない現象が起きてしまう可能性があるため、禁止していると解説を行った。
●4.依存関係逆転の原則
ここでは、上位のモジュールが下位のモジュールに依存してはいけないこと、どちらも「抽象」に依存すべきである。また、「抽象」は実装の詳細に依存してはいけない。実装の詳細が「抽象」に依存すべきであるという原則を、下記の例に習って紹介した。
▲通路を塞ぐ役割の「ドア」と、鍵をかけたり開けたりできる役割の「ノブ」のふたつを依存させてはならないとのこと。
●5.インターフェイス分離の原則
関心の分離とも言われるこの原則については、可能な限り、重複がない複数の機構に分離することであると説明した。
例えば、「どんなカードでも入るカード入れ」を設計すると、下記のようなものになる。カードの仕様が決まっていないため、全てに対応させようとすると口が肥大化してしまう。また、新しい規格、サイズのカードが登場するたびに他の全てのカードを入れていた口が影響を受けることになるということだ。
これら、設計の原則は現実的な問題を解決することにも当てはまる。例えば、最初は1種類だと伝えられていた仕様も言われた通り作るのではなく、あらかじめ増えることを予測して作っておくことで後々の発展がかなり楽になる。ここで田村氏は、ゲーム開発の目的は「完成させることや終わらせること」ではなく、「プレイしてくださる方々に面白いと感じていただけるものを創ること」だということを忘れてはいけないとコメントした。無理なことはありつつも、そこで一歩立ち止まって何のために開発を行っているか考えることが重要であると説いた。
▲開発が進むと不確実性は下がっていくが、プログラマーが最初に携わる頃にはまだまだ不確定な要素も多いため、如何に予測しておくかがポイントとなる。
また、実際の現場では進捗に明確な境目がないことも多いため、変化に対応する技術が必要な能力となってくる。これがなければ面白いアイデアに対して向き合うことができず、面白いゲームを創ることができない。そうした理由が「技術がなければ面白いゲームが創れない」ことへの根拠となっているとまとめて講演の締めとした。
（取材・文 編集部：山岡広樹）
