MGS4の開発ドキュメンタリーを見てAPEXに同情した話② (完結編)
待たせたな
※本記事はコチラの後編となっております。
この記事を書いている人
pokopan_black
MGS4のオンライン対戦モードであるMGO2に入り浸り、世界ランキングトップ100入りを記録した過去を持つ。
ただし、若さ故の言動や立ち回りが痛すぎたため現在は黒歴史として封印している。
・・・
なぜゲームからバグが無くならないのか
では改めて、ゲーム開発の現場が何故これ程までにバグまみれなのかを考えて行くのですが、それはひとえにゲーム開発が一般的なシステム開発よりも遥かに高度なプログラミングであることに他ならないと私は断言します。
過去に学んだ数少ないゲーム開発の知識を元に、これからその深淵の一旦を感じていただければと思います。
ゲームには複雑な処理がいっぱい
今回ゲーム開発の難しさを語るに当たり、実際にアクションゲームを作る過程を妄想してみましょう。
ジャンルは初代スーパーマリオブラザーズのような2D横スクロールアクションゲームにします。
まずは主人公となるプレイヤーキャラが必要なのですが、キャラクターをそのまま拝借するのは色々な法律に引っかかりそうなのでオリジナルのキャラクターを用意してきました。
単純な図形を組み合わせて作ったのですが、どうみてもカービィに似ているので名前は「モドキ」とします。
次は敵キャラです。
当たるとゲームオーバーになってしまうトゲトゲした奴がいいですね。
こちらは星に似ているのですが、星を目指す者達の通う学校である"スターライトロード学院"の元生徒であり、星になるための最終試験である"超新星爆発<ギャラクシーエクスプロード>"にて事故により親友を失ってしまったことから立ち直れず、星にもなれず何者にもなれないまま亡霊のように毎日を生きる存在であるため「成れの果て」とします。
今回はこの2キャラを使ってゲーム開発を進めていきます。
まずは画面上にキャラクターを表示します。
これはゲーム画面をキャンバスに見立て、どの位置に表示するかを一次関数のごとくX,Y座標を用いて指定します。そこにキャラクターの画像を張り付ければ完了です。
次に、このキャラクターを動かすことを考えてみます。
先ほどXY座標を用いてキャラクターを表示したように、コントローラーのボタンが押された時に座標を動かします。
ただし、このキャラクターは紙のノートと同じように消しゴムで消さない限り消えませんので、一度画面をまっさらにします。
その後、新しい位置にキャラクターを表示することで動いたように見える仕組みです。
パラパラ漫画をイメージしていただければ大体合っています。
では、敵キャラクターがいる場合はどうなるでしょうか?
「成れの果て」がいる状態で「モドキ」を動かしてみます。
いけ!モドキ!
右に移動だ!
ごちゃついている感じがどことなく星のカービィスーパーデラックスのラスボスであるギャラクティック・ノヴァみたいになってしまいました。
つまり何が言いたいかというと、キャラクターをそのまま移動させると表示が重なってしまうということです。
そこで登場するのが、「当たり判定」という考え方です。
当たり判定とは?
当たり判定とは、読んで字のごとくキャラクター同士が当たったか(ぶつかったか)というのを数学的に判定しようという考え方です。
最もプリミティブな当たり判定のロジックは、四角形を用いた判定方法です。
キャラクターを四角系で囲み、当たり判定ゾーンとします。
このお互いの四角系が重なり合っているかを計算することで、ぶつかっているかを判定します。
この当たり判定を用いて、キャラクターにダメージを与えたりキャラクターが重ならないように位置を調整したりします。
ただ、ここまでの画像でお気づきの方もいらっしゃるかと思いますが、この判定方法には欠点があります。
それは、当たり判定ゾーンと実際に体がある範囲が異なるということです。
そのため、見かけ上は当たっていないのにやられてしまったり、どう見ても当たっているのにセーフだったりしてしまいます。
その解決方法は単純で、細かい四角形をたくさん作ることです。
ただし、当然これらすべての四角形同士で先ほどの当たり判定の計算を行わなければいけないため、その作業量は一気に膨れ上がります。
ここにきてようやく本題に戻るのですが、これはあくまでも2D(平面)であるうえ、シンプルな図形のみを利用したキャラクターでの話です。
これがMGS4やAPEXなどの3D(立体)となり、より複雑なキャラクターモデルとなった場合、その計算量が膨大な量となることは想像に難くないでしょう。
到底人間にできることではありません。
この他にも光源の位置から影の大きさの計算をおこなったり、自身が敵キャラクターの視界に入っているか、銃弾が発射されてから壁に当たるまでの軌道など、まだまだ計算しなければならないことが山ほどあります。
このような複雑な処理が、ゲームの中では常に行われているということを感じていただけたのなら幸いです。
メモリについて
また、ゲーム開発にはメモリという切っても切り離せない存在があります。
メモリとは上記のようにデータを高速処理するために必要な部品の1つであり、PCやゲーム機本体に組み込まれています。
よく作業机に例えられるので、こんな例を考えてみました。
このように、机の上に初めから使いたい物が置いてあればすぐに作業を開始できますが、置かれてなければそれを探す時間が発生してしまいます。
この探す時間こそが、ゲームで言うところのロード画面です。
じゃあ初めから全部出しておけばいいじゃんと思うかもしれませんが、机のサイズは無限ではありません。物を置けば置くほど新しい物を置くスペースが無くなってしまいます。
ではどうするかというと、現実世界と同じです。一度片付けるのです。
そして、空いたスペースに新しい物を置きます。
これがゲームに限らず、すべてのプログラムの中で起こっています。
また、この操作は通常であればプログラムが自動的に判断するのですが、大量の物が必要で出来るだけ効率よく物を置きたいゲームにおいては、これを開発者が指示します。
これにより、ローディング時間を減らしたり処理が重くならないように努力しています。
ただし、ここで難しいのがメモリの状態は人間の目に見えないということです。
電気のついていない部屋で作業をするようなもので、思ったのと全然違う操作をしてしまうことがあります。
その結果どうなるかというと、ハサミを使おうと思ったら書類同士がくっついたり、電気を付けようと思ったら音が鳴ったり、歩こうと思ったらジャンプしたりします。
つまり、これが意味不明なバグを引き起こします。
APEXの意味不明なバグは、もしかするとこのようなことが原因なのかもしれません。。。
まとめ
ここまでゲーム開発の難しさについて語ってきましたが、これはまだ氷山の一角にしか過ぎません。
実際のゲーム開発の現場ではもっとたくさんの課題や壁が存在すると思います。
そう考えると、変なバグが多くても仕方ないのかもしれないという気持ちになりました。
「いつもゲームを作ってくれてありがとう。」
これからバグを見つけても、このように優しい気持ちになれるといいなと思いました。
・・・
あとがき
後編の内容についてはボヤッとした構想だけあり、ゲーム開発はこういう特有の問題があるから大変なんだよと伝えたいだけだったのですが、思わぬ大作になってしまいました。
仕事でいつも作業量の見積が甘いと指摘されるのですが、プライベートでもそれを実感してしまい落ち込んだりもしましたが達成感が凄いので私は元気です。
本当は前後編を分けることなく行くつもりだったのですが、こんな長くなるとは思っていなかったので結果的には正解でした。
ただ、この記事自体が前編の倍以上あるため、計画性が全く無いことは分かっていただけたかと思います。
最後になりましたが、来月は反動で恐ろしく低クオリティになる可能性が高いので覚悟しておいてください。
それでは、また。