MIS.W 公式ブログ

早稲田大学公認、情報系創作サークル「早稲田大学経営情報学会」(MIS.W)の公式ブログです!

で、ゲームって結局どうやって作るの? 〜ソフトウェア工学のすすめ〜 【アドベントカレンダー最終日】

新入生のみなさん、もう大学生活には慣れましたか? 49代・雑用担当のemolga(えもんが)です。

今回の記事は、そんな「ゲームをつくりたい!」という方、特に今後ゲーム制作プロジェクトのリーダーになるかもしれないそこのあなたに向けて書かれたものです。 少し長いですが、難しい概念も噛み砕いて説明するので最後までお付き合いください。

1. なぜソフトウェア工学

サブタイトルで「ソフトウェア工学のすすめ」と謳っているように、この記事はソフトウェア工学ステマ記事です。では、なぜゲーム開発にソフトウェア工学が必要なのでしょうか? それには二つの理由があります。

  • デスマーチ(締め切り直前に何日も徹夜しなくてはならなくなったりして、文字通りプロジェクトが死の行進になること)を回避するため
  • せっかく作ったゲームがクソゲー化することを防ぐため

以上です。 今この段階では「ソフトウェア工学とは何か」を知らなくても構わないので、まずはデスマーチクソゲー化の回避のために、ソフトウェア工学的なセンスが求められる」ということだけを覚えてください。以下詳しく説明します。

1-1. 「ゆーてなんとかなるっしょw」はデスマーチの召喚呪文

米国の著名なコンピュータ・コンサルタントであるEdward Yourdonによると、デスマーチの発生原因は主に

  • 政治的紛糾
  • 人手不足
  • 楽観主義

の三つに大別出来るといいます。このうち政治的紛糾は「踊る大捜査線」のように、「上司同士のいろいろな思惑が重なって、結果的に現場が振り回される」といったようなシチュエーションが代表的ですがここでは触れません。人手不足だとプロジェクトがだんだん死の行進へと近づいていく…… というのも想像に難くないと思います。 問題なのは三つ目の楽観主義です。特にサークルに入りたての一年生が陥りやすい罠で、実際にこれが原因で私もデスマーチを経験しました。ではなぜ、楽観主義がデスマーチの原因になるのでしょうか?

ゲームで、初見の敵を倒す場面を想像してください。プレイヤーのあなたはその敵の情報を何も知らないので、「多分3回攻撃すれば倒れるだろう」とか適当に想像して敵を倒すことになるでしょう。「3回攻撃すれば倒れる」と想像したあなたは、その想像に基づいて「敵をどうやって倒すか」というプロセスを脳内で組み立てることになると思います。ですがもし、そのプロセス通りに行動しても敵が倒れなかったらどうなるでしょうか? こちらの計画は丸つぶれで、最悪の場合はその穴を突かれてこちらが倒されてしまいます。本来プレイヤーは、適当に想像するのではなく、攻略本を読むなどしてちゃんと敵の事を知るべきでした(それではゲームの面白みが失われてしまう、といった議論はさておいて)。

「敵」を「ゲームの完成までにやるべきこと」に置き換えれば、ゲーム制作にも同じ事が言えます。そこのあなた、「とりあえず3ヶ月あればゲームは完成するだろう」とか漠然と計画を立てていませんか? それではデスマーチ一直線で、高確率でプロジェクトは崩壊します。まずは敵=ゲームの完成までにやるべきことをきちんと筋道立てて分析して、その上で計画を立てましょう。今度は「じゃあ、きちんと筋道立てて分析したり計画したりするには一体どうすればいいんだ」という話になってしまいますが、ここでソフトウェア工学の知識が大活躍してくれます。

ソフトウェア工学は、「ゲームの完成までにやるべきこと」をやっつけるためのいわば攻略本のようなものです。

1-2. 「とりあえず適当に作ろうぜw」は失敗作のもと

あなたはゲーム開発プロジェクトのリーダーです。あなたはメンバーであるプログラマーやグラフィッカー、サウンドデザイナー達に指示を出す立場です。こんなとき、「責任は俺がとるから好きにやっちゃっていいよ!」なんて言えたら格好良い理想のボスですね。しかしこれでは、例えプロジェクトが円満に進んだとしても、成功からはどんどん遠ざかってしまいます。なぜでしょうか。

まず第一に、プログラムの中身がめちゃくちゃになります。少しでもプログラミングを囓ったことがある人なら分かると思うのですが、誰かと一緒にコードを共同執筆しているとして、その時相方によくわからない変数や関数を大量生産されたら混乱しますよね。これの、さらにスケールが大きくなったものがゲーム開発の現場で起こります。相方が何を作っているかすら分からず、頑張って理解したくても「作者の気持ちを考える」闇と戦うことになり、仮にゲームを完成させたとしてもデバッグで地獄をみることになります。

また第二に、「皆が勝手にいろいろ作った結果、最終的に出来上がったのは皆が想像していたものと全く違ってた」といった事態が発生します。例えば誰かが「音ゲー作ろうぜ!」と言ったとして、賛同者が集まったとしても皆想像している物がjubeatだったりポップンだったり弐寺だったり果てはDDRだったりと全く違います。十人十色という言葉がありますが、「○○なゲームを作ろう!」とメンバーに呼びかけても全員が全く同じ物を想像しているなんてことはまずあり得ないでしょう。そんな中、メンバーが好き勝手にゲームを作り始めたら…… あとは説明不要ですよね。 では、どうすればいいのでしょうか? 答えは簡単です。プロジェクトの方針を厳格に策定して、そして計画をきちんと立てましょう。ソフトウェア工学では、そのための方法論を扱います。

 ※中上級者の方へ:アジャイル開発とカウボーイコーディングは全くの別物です。アジャイル開発の特徴は「計画の頻繁な再評価」「顔を合わせるコミュニケーションの重視&文書に依存しない」であり、そのためウォーターフォールモデルによる開発と全く対称なものと思われがちですが、実際はアジャイル開発の現場でもウォーターフォールモデルと同様に明確なプロセスに従って作業します。「行き当たりばったりの開発手法がゲーム業界でのトレンド」と最近よく言われますが、「計画を頻繁に再評価し修正していくこと」がトレンドなのであり、決して好き勝手に作業することがトレンドな訳ではありません。

2. それで、ソフトウェア工学って結局なに?

ウィキペディアにはいろいろ難しいことが書いてありますが、これを簡単に要約すると ソフトウェア工学とは、いかに楽をして素晴らしいソフトウェアを開発するのか、そのための方法を研究する学問である」 の一言に尽きます。 これを勉強すれば、「ゲーム開発プロジェクトをどうやって運営すればいいのか」といったことも分かるようになってくるでしょう。 さあ、あなたもソフトウェア工学を勉強してみませんか?