［GC_2007＃007］AoEシリーズのBruce Shelley氏が語る，面白いゲームの作り方。「Designing by Playing」とは？

Age of Empiresシリーズの生みの親の一人，Bruce Shelley氏

　RTSファンにはお馴染み，Ensemble StudiosのBruce Shelley氏が，GCDC二日目となる現地時間8月21日に講演を行った。そのタイトルは，「Designing by Playing」。これは，テストプレイを繰り返しながらゲームをデザインしていくという開発手法の呼び名で，Age of Empiresシリーズの作品はすべて，この手法を用いて開発したという。

　Designing by Playingの具体的な手順は，大きく分けて，次の2ステップである。

・プロトタイプを作る
・テストプレイを経て，デザインを変えていく

　とにかく少しでも早い段階でプレイアブルなバージョン（プロトタイプ）を作ることが重要だと，Shelley氏は語る。細かい部分は全部後回しにして，一刻も早く動くものを作ってテストし，その結果をプロトタイプに反映してまたテストし……という繰り返しで，徐々にゲームの完成度を高めていくわけだ。
　プレイテストを行うときには，何ができて何ができないのか，面白い部分はあるか（あるとしたらどこか），つまらない部分はあるか（あるとしたらどこか）を常に考えるという。それらを次のバージョンのプロトタイプに反映し，またテストし……の繰り返しを，毎日のように行う（使われたスライドには，“Repeat”の後ろに，括弧書きで“daily?”とついていた）。



　では，なぜこのような（確実にプログラマは眉をしかめるだろう）方法を使うのだろうか？（※編集部注）
　まず，「面白いのかどうか」は，（企画書/仕様書などでなく）プレイをベースに考えるべきであるという，当然といえば当然の，しかしながら実際には忘れられがちな原則が挙げられた。またShelley氏は，どんなにベテランのゲームデザイナーといっても，実際にプレイしないことには，そのゲームの良い点/悪い点が本当には分からない，とも語った。事前に面白そうと思っていても，いざ動かしてみたら，想像と全然違ったというのは，よくある話なのである。そしてもう一つ，最近のゲームは要素が多いので，それらがちゃんと消化できているのかを確かめるにも，この手法が適しているとのことだった。



　ではEnsemble Studiosは，どのようにこのDesigning by Playingを実践しているのだろうか。
　同社では，最初のプロトタイプを作るまでの期間は，わずか6か月が目安だという。Shelley氏に言わせれば，例えばAge of Empiresシリーズの場合，その段階ではシングルプレイモードもAIもいらず，基本的なマップとシステムがあってマルチプレイができれば十分。1セッションに8〜16人が参加し，毎日1，2時間のテストを行う。また週に一度くらいのペースで，より大規模なテストも行うという（余談だが，「Age of Empires III」では毎週火曜日に行っており，そのため“angry Tuesday”と呼ばれていたらしい）。
　このように，とにかくテストを繰り返してフィードバックを集め，ゲームの方向性を決めていくわけだ。ちなみにAge of Empires IIIでは，実に4000以上のバージョンが存在するというから，凄い話である。

　続いてShelley氏は，Designing by Playingの長所と短所を挙げた。それぞれ，以下のとおりだ。

＜長所＞
・デザインを変えるたびに，全体を検討できる
・一つのゲームに対して，いろんな視点から検証できる
・プレイヤーが面白いと感じる方向へ作っていける

＜短所＞
・いつ完成するのか予測しづらく，開発期間とコストが読めなくなる
・ゲームがテスターに寄っていく（テスターが少数の場合はコアなほうに寄りやすく，大勢の場合は万人受けしやすくなる代わりに，コアな部分が減ってしまう）
・問題がある（つまらない，バグがあるなど）場合，それを直さなければならない
・永遠には繰り返せない
・大勢でやっているので，一つの方向にまとめるのが難しい

　数だけでいえば長所よりも短所のほうが多いが，短所は一番上以外はおまけみたいなもの。開発期間/コストに余裕がさえあれば（これが難しいわけだが），この手法を積極的に使うことで，そのゲームをより面白くできるとのことだった。



　さて，Shelley氏の講演の主な内容は以上だが，筆者はこの講演中に，「Gears of War」のリードデザイナー，クリフィーBことCliff Bleszinski氏が言うところの，“iteration”（繰り返し）によるゲームデザインを思い出していた。2007年3月に行われたGDC（Game Developers Conference）でのBleszinski氏の講演の記事と読み比べてもらえば分かると思うが，二人の話は，多くの部分で共通している（Shelley氏が短所として挙げた項目のいくつかは，Bleszinski氏のCabalシステムで解消されるかもしれない）。アメリカの人気開発者二人が，面白いゲームを作る方法をテーマに，同じような内容の講演を行ったというのは，非常に興味深いところだ。
　ちなみに，GDCの直後に話をした某国産メーカーの開発者は，GDCにおけるベストカンファレンスに，前述のBleszinski氏の講演を推していた。曰く，「クリフィーBの話した内容は，実は凄く当たり前のことなんですね。我々も頭では，そうすることでゲームが面白くなることは分かっているのですが，現実には，なかなか実践できない。基本に忠実に進めて，しっかりあんなに面白いゲームを作った彼は，本当に素晴らしい」。
　会社は「一刻も早く完成させろ」と言うし，プログラマ達は「最初から完璧な仕様書を出してくれ」と言う。その中で，ついつい，この当たり前のことを見失いがちだと，そのゲーム開発者は語ってくれた。Shelley氏やBleszinski氏のように名作を生み出すためには，誰に何を言われようが，意地でも面白いゲームを作ってやるんだという強い信念と，周りの人々の理解が必要なのかもしれない。（Iwahama）

編注：Shelley氏の手法は，Test First，短期反復開発など，最近流行のAgileプログラミングの開発スタイルそのものであるように思われる。これは途中での仕様変更を前提とした手法で，どちらかといえばプログラマから嫌われるものではない（どうせ仕様変更があるのは見えているので）。開発手法というよりデザイン手法として使っているのが面白い。10年以上前からこのようなことを実践していたというのは注目すべきであろう。