ゲームデザインは、基本的には芸術的なものだが、同時に技術的なものでもある。ゲームデザイナーは、がりがりとプログラムを書いているときでさえ、雄大で芸術的な目標を追い求めているものだ。ゲーム開発において、デザイナーは芸術と技術というふたつの非常に異なった世界で暮らしている。そのような異なった世界に、どのように折り合いをつけるべきだろう。どういう順序でコンピュータゲームのデザインを進めて行くのが良いのだろうか。前章では、このような手順に関係する若干の問題に触れ、いくつかの指針を定めた。この章では、実際にコンピュータゲームをデザインし、プログラムするまでの手順を提案しよう。
以下の手順は、私自身のゲームデザインの経験に基づいていて、私がゲームデザインにおいて使っている習慣の多くが反映されている。しかしながら、私は、この手順を段階的に用いたことは一度もないし、他の人が厳密にこの手順に従うことも勧めない。だいいち、ゲームデザインというのは、形式的な手順にまとめてしまうには、あまりにも複雑な活動である。そして、ゲームをデザインしていく工程には、各デザイナーの個性が反映されるべきである。教条的に手順を守ることに依存してしまえば、ゲームデザインの芸術面が台無しになってしまう。最後に、私は主にパソコンゲームのデザインに関わってきたため、アーケード機や家庭用ゲーム機のデザイナーには、私の提案は完全には当てはめられない。したがって私は、公式としてではなく、将来のゲームデザイナーが仕事に取り入れることを望むかもしれない習慣集として、この手順を公開するのだ。このことを念頭において進もう。
この段階が非常に重要だということは明白と思われるのだが、はっきりとした意志なしで出発したゲームデザイナーは、この段階を無視することがままある。ゲームデザイナーたちと話し合ってみると、ゲームの明確な目標の必要性に対する関心が欠けていると感じることが多い。ゲームデザイナーたちは良く、「楽しい」ゲームや「刺激的な」ゲームの創作を目指したなどと語るものだが、それ以上に明白な目標を持っていないことが多いのである。
ゲームは、目標が明確に定められている必要がある。プレイヤーに何を与えたいのかをはっきりさせる必用がある。ゲームが楽しいとか、面白いとか、刺激的であるとかいうだけでは不十分なのである。目標は、ゲームがどんな空想世界を作り出すのか、それがプレイヤーにどんな感情を呼び起こすのかを明示してなくてはならない。前にも述べたようにゲームの多くは何らかの意味で教育的であるから、目標はプレイヤーが何を学ぶのかを明示すべきである。ゲームがそのプレイヤーにどのような作用を与えるのか、ゲームデザイナーに尋ねてみる必用がある。
ゲームの目標をはっきりさせておくことの重要性が表面に現れてくるのは、ゲームデザインがかなり終盤になってからである。コンピュータゲームのデザインでは、何を捨てて何を残すかというトレードオフの問題が必ず出てくる。デザイナーが何かをゲームに盛り込みたいと思えばそれには必ず余分なメモリが必要になるし、コンピュータのメモリというものは常に不足しているものである。したがってデザイナーはトレードオフを考えなくてはならない。いくらかの要素は含めることができるが、いくらかは切り捨てなければならない。入れたい要素がふたつあり、どうしてもどちらかひとつを切り捨てなければならなくなったとき、どちらを残したら良いかを決める基準は、最初に明示した目標しかないだろう。明確な目標を持っていれば、辛いながらも毅然としてどちらかを切り捨てることができるだろう。目標がはっきりしていないと、間違った選択をする可能性が高いし、どちらを選択したとしても、その決定が正しかったかどうかを判断することができないだろう。
どうすれば適切な目標が選択できるのだろうか。この質問に対する客観的な回答は存在しない。目標の選択は、コンピュータゲームデザインの芸術面における、最も主観的なプロセスである。これはデザイナー自身を表現する機会である。自分の信念や哲学、世界観を表現できるような目標を選択すれば良いのだ。正直であることが肝心である。もし、自分の好みではなく、観衆に媚びるような目標を選択するとしたら、生気のないゲームが出来上がることだろう。目標が、自分の興味や信念、感情と一致している限り、それが何であるかは重要ではない。自分に忠実に目標を選択しているかぎり、どんなゲームのであっても、他の人たちに対してそれなりの説得力を持つだろう。逆に、自分に対して正直でなければ、まわりくどく物まねのようなゲームができあがってしまうだろう。
これはあくまで理想論であり、実現することが不可能な場合もある。たとえば、子どもたちのためのゲームは、未熟で子どもっぽい人がデザインすれば良いというわけではないし、優れたシューティングゲームは、射撃の名人しか作れないというわけでもない。現実には、市場の要請から、自分の趣味に反したゲームを作らなくてはならなくなる場合もある。そんな場合でも、熟練したプロのデザイナーがデザインするほうが、作り笑いしかできないような愚か者にデザインさせるよりはずっと良いだろう。しかしながら、そのような感情的に間接的なゲームは、決して、心からストレートに伝わってくるような、心理的なインパクトや芸術的なパワーを持つことはないだろう。
目標を決めたら、次には題材を選択しなくてはならない。題材は目標を表現する手段であり、ゲームがプレイされる環境である。それは、抽象的な目標へと到達するための、具体的な状況と出来事を集めたものである。たとえば、『スター・レイダーズ』 (STAR RAIDERS) の目標は、プレイヤーの戦術眼と操縦テクニックに挑戦し、怒りの暴力的解決を通してプレイヤーのストレスを解消しようというものだ。題材は宇宙の戦闘である。『東部戦線1941』 (EASTERN FRONT 1941) の目標は、近代的な戦争の性質、特に火力と効果を表現しようとした。題材は独露間の戦争である。
最初に題材を選択したために、目標が題材に従属させられているゲームデザイナーが多い。というよりも、彼らはゲームを開発するとき、目標よりも題材によって記述するのである。私が、他のデザイナーに、リーダーシップについてのゲームに取り組んでいると言うと、不思議そうな顔をされる。それはいったい何だ、ウォーゲームなのかダンジョンゲームなのかと。私が、アーサー王についてのゲームだと言えば、彼らは納得するようだ。それは、目標を題材に従属させてしまうという、重大な間違いなのである。最初に思いついた時点では、目標よりも題材に焦点が合っているかもしれないが、題材の勢いに身を任せるのではなく、目標実現のために題材があるのだという意識を持っていなくてはならない。
良い題材を選択するのには時間がかかる。なぜなら、それぞれの題材候補について、ゲームの目標をうまく実現する能力があるかどうか、慎重に吟味しなくてはならないからだ。多くの題材には、ゲームの目標を妨害しかねない余計なお荷物がついてくる。たとえば、私の最近のゲームは、アーサー王伝説をその題材として用いる。このゲームでの私の目標は、リーダーシップの性質を考察することである。私は、アーサー王伝説が、この目標のための説得力ある伝達手段だと考えた。しかし不幸にもこれらの伝説は、腕力で対抗者を征服するという強力な構成要素を含んでいるのだ。このテーマは、私がゲームで表現したいことの若干を否定し、したがって最終的に題材の有益性を弱めてしまう。しかし私は、不利な点を勘案しても、この伝説は、とても力強くて融通が利くと判断したのである。
目標と題材がしっかりと決まったら、その次の段階は、題材を深く知ることである。その題材について、できる限りの資料を読むのだ。目標と題材を関連付ける努力をする前に、すべてを研究しなければいけない。どんな面が気に入り、どんな面が気に入らないのか。あなたがゲームにおいて「世界の再現」をしようと試みる環境を、確実に理解しておくことだ。あなたのゲームは、実世界のリアルな感触を与えなくてはならない。それは、あなた自身がゲーム環境をしっかりと理解していなければ達成できないことである。私は『エクスカリバー』 (EXCALIBUR) の研究段階で、西暦400〜700年の間の英国の歴史を勉強した。リーダーシップの性質を描写するという私の目的に直結した記述は、歴史の本の中にはわずかしか見つけられなかった。しかし、アーサー王伝説の中に、私の目的により近いテーマを発見した。このように、研究を進めていくにつれて、自然と目的を再調整していることに気付くだろう。このような気まぐれは、目的がもともと不完全だったことを認めるようで決まりが悪いが、題材環境の要求に対応する、率直な自発的意志を反映している。これまで何度も自分を甘やかしてきた、罪深き理想主義からの脱却なのである。
この段階において重要なのは、資料にこだわりすぎないことと、コードを絶対に書かないことである。あなたのゲームを熟考するため、長い散歩に出かけると良い。考えて考え抜くのだ。目標、題材、そしてあなたが勉強したことを、心の中で一緒にして、ぐつぐつ煮込むようにしてほしい。それらを合わせて、全体の中に織り込むのである。この段階にはゆっくり時間をかけることだ。焦りは、ゲームそのものを台無しにしてしまうような失敗のもとになる。私は、少なくとも3週間をこの段階にあて、ゲームのアイデアを発展させるようにしている。『エクスカリバー』では数ヶ月をこの段階に費やした。私はこの間、最終的なゲームにほとんど関係のない、オープニングのグラフィックを描くことによって、早くコードを書きたくてうずうずしている自分の手をまぎらわせていた。
あなたはこの段階で、ゲームに実装したい多様なアイデアを生み出すはずである。しかし、それらをすべて寄せ集めたとしても、うまく組み合わせることはできないだろう。アイデアは、実際に使用する前に、整理することが必要だ。あなたは、どのアイデアにも執着すべきではない。実装のアイデアの山は、デザイン段階での有用な資源である。しかし、これは絶対必用だというアイデアのリストにすることは、足かせにしかならない。アイデアは自由に出すべきだが、実際のデザインのときには、それらを容赦なくふるいにかける用意をしておくことが大切である。
たとえば最近私は、もう一人の人と共同で、会社のシミュレーションゲームをデザインした。研究段階の間に、ぜひともゲームに取り入れたいアイデアをたくさん思いついた。この時点でゲームがフェミニストの見地を持ち、かつお説教っぽくならないようにしようということで同意していた。我々は、厳しい上司、難しいプロジェクト、納期、人間関係、男性優越主義者、中立の男性、中立の女性、家族と家庭義務、助言者、昇進のための競争・・・といった要素も取り入れようと考えた。我々は最終的なデザインに、これらのアイデアのほとんど全部を含めることに成功したが、家族の要素を統合することはできなかった。全てのアイデアに公平な待遇を与えることはさすがにできず、結局、我々は入れたかった家族の要素を切り捨てなければならなかったのだ。
これまでの段階で、概念的なゲームのアイデアは明確になっているが、その具体的な形式については何も決まっていない。ここまでくれば、実際のデザイン段階に入る準備はできている。デザイン段階での主な目標は、互いに相互依存する三つの構造のアウトラインを作成することである。I/O構造、ゲーム構造、そしてプログラム構造だ。I/O構造は、コンピュータとプレイヤーの間で情報を伝達するシステムである。ゲーム構造は、プレイヤーがゲームの中で制覇する障害を定義する因果関係の、内部的な構造である。プログラム構造は、メインルーチン、サブルーチン、割り込みルーチン、そしてデータから成る、プログラム全体を構成する機構である。これら三つの構造は協調して働かなければならないから、同時に制作する必要がある。ひとつの構造に対して何かを決定するとき、他の構造に影響がないかどうかチェックしなくてはならない。
I/O構造
私が好きなのは、三つの構造の中で最も制約が大きい、I/O構造から作り始めることだ。I/Oは、コンピュータとプレイヤーの間を取り持つ言葉であり、人間の言葉と同じように、我々が仲間と共有しようと望む思考や、理念や、感情の洪水といったものを集めてきて取り込む、じょうごのような存在である。I/Oによって、できることとできないことが決まってくるだろう。
I/Oは、入力と出力で構成される。人間の言葉と違って、そのふたつは対称的なものではない。コンピュータは、人間への出力の方法として、グラフィックとサウンドのふたつを持っている。将来、もっと変わった出力装置が現れるかもしれないが、差し当たり、このふたつが最も普遍的なものである。
人間は聴覚よりも視覚のほうを重視するので、サウンドよりもグラフィックのほうが重要だと思われる。このため、多くのゲームデザイナーが、そのエネルギーの大部分を、きれいな画面を作成することに費やす。それどころか、一部のデザイナーは、最初に表示部を設計してからゲームを開発するので、目標を見失ったゲームデザインになりやすい。
ただ見せびらかすためだけに格好良いグラフィックを作ろうとするのは、ありがちな間違いである。グラフィックは、プレイヤーに情報を伝えるという目的のために存在するのだ。プレイヤーとのコミュニケーションを、説得力と感動を伴ったものにするためだけに、グラフィックを使うべきである。他のどのような理由のためでもない。ゲームが再現する空想世界をサポートするために、重大な情報を伝達する、機能的で意味のあるグラフィックを設計することだ。ゲームデザインのお粗末さを、グラフィックでごまかそうとしてはいけない。もし、ゲームが単調で退屈であるなら、どんなに素晴らしいグラフィックも、それを包み隠すことはできない。最悪なのは、退屈なゲーム部の代わりに、格好良いけれど無意味なグラフィックをでっちあげることである。また、サウンドも同じルールに従い、ゲームで何が起こっているのかをプレイヤーに伝えるために使うべきである。印象的だが無意味なグラフィックやサウンドが唯一役立つ場面は、ゲームのはじめに、雰囲気や気分を盛り上げるのを手伝う場合に限られる。
絵コンテというものは、映画産業で確立された技術であり、多くのゲームデザイナーを誘惑する、グラフィックのデザインツールである。それはしかし、ゲームにはふさわしくない。なぜかというと、絵コンテは本質的にシーケンシャル（連続的）な技術だからである。ゲームはシーケンシャルではなく、ツリー構造である。本質的にシーケンシャルなツールを使うゲームデザイナーは、無意識のうちに、自分のデザインをシーケンシャルにしてしまう。道具は使用者の心に影響を与えるのだ。のこぎりを持てば木を切りたくなるし、フリーウェイに乗れば、目的地に行くより、どこまでもドライブしていたい気分になる。同じように、絵コンテを使うと、ゲームが自然とシーケンシャルな代物になってしまうのである。
ゲームの入力には、特に注意を払わなければいけない。入力は、プレイヤーの触覚との接点である。人間は触覚を非常に重視する。あなたは、プログラマがキーボードの手触りにこだわることに気付いたことがあるだろうか。プレイヤーは、あなたのゲームに対してそれと同じように感じる。良い例が『ジョーブレイカーズ』 (JAWBREAKERS) や『ムスクアタック』 (MOUSKATTACK) だ。これらのゲームでは残念なことに、ジョイスティックを斜めに入れたときの挙動があいまいである。これは、プレイヤーに、ジョイスティックの操作性が悪いという印象を与える。私は、プレイヤーがいらついてジョイスティックをたたきつけ、もう二度とプレイするものかと言っているのを見たことがある。あなたが入力を設計するときには、それがプレイヤーをいらつかせ、怒らせるかもしれないということを忘れてはいけない。
入力は、すべてのゲームデザイナーが直面する、根本的なジレンマの中心に横たわっている。優秀なゲームというのは、プレイヤーの性格をゲームの中に十分に反映させるため、対抗者との頻繁な相互作用を可能にするものだ。それには、プレイヤーが彼の性格のニュアンスを表現できるだけの、多数の意味を持つ十分な選択肢が必要である。プレイヤーの決定は入力されなければならないから、プレイヤーを怖じけさせるような、大規模で複雑な入力が必要になってしまう。我々のジレンマというのは、優秀なゲームは、複雑な入力を必要とするように思われるということである。
多くの選択肢を可能とするシンプルな入力方法というジレンマを解決するためにはデザイナーの創造力が必用である。これは容易なことではない。満足のいく解決方法が見つかるまで、多くの案を出しては捨てるという試行錯誤が必要である。しかし、不可能ではない。私が『スクラム』 (SCRAM : 原子力発電所シミュレーション) をデザインしたとき、私は次のような問題に直面した。プレイヤーはジョイスティックだけで、どうやって原子力発電所の全体をコントロールすれば良いのだろう。一見、これは絶望的に思われる。だが、私はやがて大変うまく動作する入力法を発見した。プレイヤーは、発電所の表示の中でカーソルを動かす。コントロールできる装置にカーソルをあてて、オンにしたり力を強めたりするにはスティックを上に、オフにしたり力を弱めたりするにはスティックを下に入れるのだ。このシステムはシンプルで簡単であり、プレイヤーはそれを見ただけで理解できる。
理論的なレベルにおいては、選択肢の豊富さと入力の綺麗さのジレンマに対して、普遍的な解が存在する。私はこの解のことを「網の目作用」 (the webwork) と呼んでいる。網の目作用のゲームをデザインするためには、少数のコマから始める。そして、すべてのコマのペアに当てはまる関係を定義する。コマの関係が集まって、網の目作用を構成するのだ。網の目作用は容易に複雑にすることができるが、網の目作用を作るためには少数のコマで十分である。一般に、Nをコマの数としたとき、ペアの数は N*(N-1)/2 である。したがって、4コマで6組のペアができ、8コマで28組のペアができ、16コマでは120組のペアができるわけだ。コマの数が少なければ、ゲームにおいての関係の豊富さを犠牲にすることなく、プレイヤーが直面するI/Oの問題が少なくてすむことになる。
バックギャモンは、網の目作用によって、いかに小数のコマで複雑な関係を作ることができるかを示す好例である。バックギャモンには、たった30のコマと、それらが置かれる26のマスがあるだけだ。コマの間の関係はかなりシンプルで、動いたりぶつかったりする能力で表現される。それでもなお、どんな規定された動きでも、それぞれのコマが、ボード上の他の多くのコマと、攻めている、守っている、ふさいでいる、ふさがれている、などの関係を持っている。コマの関係はそれだけに限らない。なぜなら、コマの前にある、ほとんどすべてのマスは、サイコロの目によって届く可能性があるからだ。プレイングエリアの長さ（24マス）がちょうどサイコロの最大の目に等しいことは、偶然ではない。互いの射程範囲内にすべてのコマを位置させるため、そうでなくてはならなかったのである。それによって、重要なペア関係の数が最大になっているのだ。
たいていの網の目作用ゲームは、空間的に表現された網の目作用に頼っている。描写するのが簡単だし、プレイヤーが思い浮かべるのも簡単だからである。しかし少数のゲームは、空間的でない網の目作用を持っている。私の『ゴシップ』 (GOSSIP) もそのようなゲームのひとつである。奇妙なことに、ゲーム自体の網の目作用は空間的ではないのに、内部計算では空間的な網の目作用を使うのだ。このことは、ゲームの網の目作用は本質的に空間的なものであることを意味するのかもしれないし、私が空間的な網の目作用の固定観念から抜け出せていないことを意味するのかもしれない。
入力装置に何を使うかという選択は、デザイン上非常に重要である。私は、良いゲームデザイナーは、入力のためにキーボードを使うことは避け、ひとつのシンプルな装置、つまりジョイスティック、パドル、マウスなどに限定すべきだと考えている。これらの装置の価値は、キーボードと比べての直接的な優越から生じるのではなく、デザイナーを抑制することにある。シンプルな装置を使用すれば、自然とシンプルな入力ができるし、複雑な装置は、複雑な入力を促進するのである。
I/O構造は、プレイヤーが見るゲームの顔であるから、三つの構造の中で最も重要である。それはゲームの相互作用のための媒介なのだ。それはまた、三つの構造の中で最も難しいものでもある。人間の感受性と、コンピュータの技術的な熟達の両方を要求するからだ。相応の注意を払わなくてはいけない。
ゲーム構造
ゲーム構造の設計において中心的な問題は、目標と題材の空想を、どのように実行可能なシステムの中に蒸留すべきかを理解することである。ゲームデザイナーは、題材の中からキーとなる要素を見つけ、そのもとでゲームを構築しなければならない。このキー要素は、題材の中心であり、ゲームにおいて述べられる問題を象徴するものであって、かつ操作しやすく、そして理解しやすくなければならない。たとえば『東部戦線1941』では、私は近代戦争の巨大な複雑さの中から、ひとつのキー要素を抽出した。「移動」である。移動が、軍のユニットの性質を規定する。敵の位置に移動すれば戦闘が始まる。敵の背後に移動すれば、補給経路や逃走経路を絶つことができる。都市に移動すれば占領することができる。移動は、戦争のすべてを表現できるわけではないが、多くの局面が表現可能なキー要素である。それは簡単に操作できるし、すぐに理解することが可能である。
『ゴシップ』では、いっそう難しいゲームデザインに挑戦している。このゲームは、社会的な人間関係を扱う。主題の複雑さと人間の相互作用の捻じ曲がり具合は、主題がゲームの振る舞いを超えたところにあることを示唆している。熟考の後、私はキー要素を抽出することができた。それは「親近感の主張」である。社会の相互作用の多くは、余分なものを取り払えば、次のふたつのどちらかに要約することができる。「私はどちらかというとサンドラのことが好きだ」という一人称の主張と、「トムはサンドラのことがちっとも好きではないと言っていたよ」という三人称の主張のふたつである。キー要素がなかなかうまい具合に、人間の相互作用を要約しているのがわかるだろう。それは簡単に操作できる。定量的ということだ。そして理解もしやすい。人間の相互作用から、「親近感の主張」をキー要素として分離したことが、『ゴシップ』というゲームを可能にしたのだ。
操作性は、ゲームの成功にはとても重要である。キー要素は操作しやすくなければならない、しかし非常に限定された方法で。それは表情豊かに操作しやすくなければならない。すなわち、プレイヤーが、ゲームの空想世界を体験する上で欲する、あるいは必要とすることを行ない、彼自身を表現することができなければならないのだ。たとえば、コンバットゲームは、ほとんど常に「射撃」がキー要素である。もし、撃つことに関してプレイヤーの自由がひどく制限されているとしたら、プレイヤーは空想を楽しむどころではない。同時に、操作性は簡潔でなくてはならない。ふたたびコンバットゲームの例を出すと、もし弾を撃つたびに火薬を消費するなどと言われたら、プレイヤーは、操作性に障害があると感じるだろう。操作性は、ゲームの空想世界をサポートする上で意味のあるものでなくてはならない。最後に、操作性は、プレイヤーの選択がキー要素を操ることと密接に関連することに、焦点が合わせられる必要がある。たとえば『ゴシップ』で、キー要素（親近感の主張）は、憎悪から愛に至るまでの値が、直線的に並んでいることを想定している。『エナジー・ツァー』 (ENERGY CZAR : エネルギー経済学シミュレーション) は、この原則に違反している。プレイヤーに、巨大でまとまりがない選択肢から選ぶことを要求するからだ。メニュー構造やキーボードの使用は、キー要素に焦点が合っていないことから生じるのだ。
複数のキー要素を使用するゲームも多い。たとえば、たいていのコンバットゲームは「移動」と「射撃」の両方を含んでいる。これは必ずしも悪いことではない。両方のキー要素がシンプルさを保てるなら、あるいはひとつのキー要素が首位を保つなら、ゲームは成功しうる。しかし、これらの原則に違反しているキー要素があまりに多ければ、焦点の定まらない、ピンボケのゲームになってしまうだろう。
I/O構造を作る上での主な問題は、制約を克服することであり、ゲーム構造を作る上での主な問題は、可能性を実現することである。I/O構造におけるあなたの仕事は、ゲーム構造における限界を定義する。 プレイヤーは直接それに遭遇しないだろうから、あなたは内部の構造でもっと多くの自由をとることができる。たとえば、私は『タクティクス』 (TACTICS) というゲームで、鎧を突き刺す一撃の効果を現実的に計算する、非常に複雑な戦闘アルゴリズムを開発した。もし私がそれを説明しようとしていたら、このアルゴリズムの複雑さは、プレイヤーを混乱させることになっただろう。しかし、プレイヤーはアルゴリズムの内部の働きを理解する必要はなく、ただその効果を把握していれば良いのである。したがって私は、シンプルで直感的なアルゴリズムを設計することを強いられるようには感じなかった。
ゲームがリアルな感触を伝達することを保証する、十分な特色を提供することに集中しよう。ディテールを加える間、あなたのバランス感覚を保持することが大切である。ディテールの正確さを追求するあまりに、他の部分で基本的な要素を見落としてしまったら、それだけでゲームは台無しになってしまう。
あまりにも多くの要素を、ゲーム構造にどかどかと積み上げるというミスを犯すゲームデザイナーは多い。その結果、過度に複雑で例外だらけのゲームができてしまう。第四章で論じたように、例外処理は望ましくない。ゲームはシンプルさと表現力を兼ね備えていなくてはならない。第四章では述べなかったことだが、例外処理には、第二の問題点がある。それは、ゲームのI/O構造を台無しにしてしまうということである。たとえば、『スター・レイダーズ』の長距離スキャンは、なかなか良い追加能力を提供するが、それは、プレイヤーが覚えなければならないキー操作がひとつ増えてしまうということでもある。これは望ましくない。幸い、この問題は『スター・レイダーズ』では無視できる。なぜなら空想世界の中ではプレイヤーは「宇宙船のコクピットに座っている」のだから、コントロールレイアウトの複雑さは、障害よりもむしろ、宇宙船を操縦しているという空想をサポートしてくれる要素となりうるからである。ゲームデザインを進めるうちに、I/O構造の品質を維持するために、ゲームに盛り込みたいアイデアを断念することを強いられることがあるだろう。逆に、どうしても捨てたくないゲーム要素を取り入れるために、I/O構造を変更することを強いられることがあるかもしれない。そのときには、ただ単に、新しいコマンドを追加するだけではいけない。I/O構造全体を見直して、新しいコマンドがうまく適合するように修正することが必要である。
ゲーム構造のデザインは、I/O構造のデザインとは感情的に非常に異なる。I/O構造をデザインするときには、ハードウェアの限界という名の嵐がデザインを前後左右に揺さぶる中で、表現能力という名のスキラの巨石と、表現の明快さという名のカリブディスの大渦に挟まれた、危険な航路を通り抜けなければならない。一方、ゲーム構造をデザインするときには、デザイナーは、水平線に向かって果てしなく広がった海の上にいる。いま突きつけられている課題は、「どちらへ行くのか」ということである。
プログラム構造
プログラム構造は、ゲームデザインの中で注目すべき第三の対象である。これは、I/O構造およびゲーム構造を、実際の製品に変換する媒介である。プログラム構造の最も重要な要素のひとつは、メモリマップである。重要なタスクに多くのメモリを割り当てなくてはならない。このような予防措置をとらないと、つまらない機能に大量のメモリを費やしてしまい、重要なタスクに使うためのメモリが十分に残っていないというはめになる。同じように、重要な変数とサブルーチンの定義も必要である。最後に、プログラムの流れに関する若干の文書も重要である。フローチャートとかWarnier-Orr図とか、何でも構わないが、あなたの好みに適したものを使うことだ。この本はプログラミングの本ではないから、あなたがプログラム開発においてガイダンスを必要とするなら、そういった専門書を読むと良いだろう。
デザインの査定
さて、ここまでで、三つの構造ができあがった。I/O構造、ゲーム構造、そしてプログラム構造だ。あなたは、三つの構造すべてが共存できることを確信しているはずである。次の工程は、ゲームを壊すようなデザイン上の欠陥がないかどうか、デザイン全体を査定することである。最初の質問は、このデザインは自分の目標を満足させるかどうかということである。ゲームは望みどおりのことをするだろうか。プレイヤーは本当に、こちらが意図したような経験をしてくれるだろうか。問題ないようなら、次に進もう。
ゲーム構造の安定性を調べよう。ゲームが動的なプロセスであることを思い出してほしい。ゲームが制御不能になるようなことはないだろうか。たとえば、そのゲームにお金の要素があるとしたら、プレイヤーが常識外れの大金持ちになってしまうような欠陥はないだろうか。つまり、ゲーム構造は、すべての値を妥当な範囲に収めることを保証しているかということである。万一そのような欠陥があるのなら、それを改善する構造的な変更を想定し、ゲーム構造を再検討しなければいけない。どうしてもやむを得ないときは、強引に解決する必要に迫られるかもしれない（たとえば、IF MONEY > 10000 THEN MONEY = 10000 といった具合に）。
勝利への近道が予測できてしまわないかどうか検討しよう。プレイヤーがほとんど努力せずに確実に勝てる方法を見つけてしまったら、もう、そのゲームがプレイされることはないのである。プレイヤーが、あなたが望んだプロセスを必ず経験するように、すべての思いがけない近道が、うまく妨害できているかどうか確認することだ。妨害といっても、わざとらしくなく、妥当なものでなくてはならない。プレイヤーは決して、決められた道に誘導されていることに気付いてはならないのである。不自然な妨害の例が、『東部戦線』 (WAR IN THE EAST) に見られる。このウォーゲームは、第二次世界大戦の東部戦線を扱う。ドイツはロシアに猛攻したが、彼らの前進はモスクワの手前で停止した。この状況を再現するため、デザイナーはドイツに圧倒的な優越を与え、補給の可能な距離を調節して、ちょうどモスクワの手前で足を引っ張られるようなルールを作った。効果は正しかったが、それを達成する手段はいかにもわざとらしかった。
最後の、そして最も重大な決定は、ゲームの製作を中止するか続行するかという決定である。これは、プログラミングを始める前に決定すべきである。この段階で、製作を中止することを躊躇してはいけない。たとえ中止するとしても、いままでの努力に価値はあったといえるだろう。後々の段階になってギブアップする場合は、それこそ本当の損失である。致命的な損失なしで中止できるいまだからこそ、この選択を注意深く考えることが必要なのである。そのゲームにもう興奮を感じないなら、中止しよう。成功の可能性に疑問があるなら、中止しよう。首尾よく作り上げることに自信がないなら、中止しよう。私は自分のファイルに、100本近いゲームアイデアを持っていて、そのうち30〜40本くらいのアイデアを詳細に検討した。しかし、デザイン段階で中止されなかったゲームはたったの8本しかないのだ。
ここまでで、アイデアを紙にまとめる準備ができたことになる。いままでに作った文書は概略だけであり、単なるメモや落書きのようなものだった。ようやく、ゲームの完全な仕様書を書く用意ができたのである。まず、これまでのすべてのデザイン結果を紙にまとめ、I/O構造とゲーム構造を定義しよう。この文書は、技術的な検討よりも、プレイヤーの経験することを強調したほうが良い。そして、この最初の文書を、事前に作成したプログラム構造のメモと比較し、必要に応じてプログラム構造を調整しよう。
この段階は、全段階の中で最も容易である。プログラミングは、他の何よりも多くを詳述するために注意を必要とする、単純で泥臭い仕事である。プログラマの技術が不足していたというだけの理由で失敗したゲームは、ほとんどない。プログラマが十分な努力をしなかったとか、仕事を急がせたとか、アセンブリ言語で書こうとしなかったとか、そういった理由でゲームの可能性を実現できないということはある。ゲームプログラミングにおいて決定的な要素は、才能があるかないかではなく、努力をしたかしなかったかというところが大きい。もし、プログラミングこそ、全てを決める一番重要な要素だと考えているのなら、ゲームデザインやシステム設計はやめておいたほうが良い。さあ、後はコードを書いて、デバッグするだけだ。
理想的には、テストプレイは、ゲームデザインに磨きをかけ、洗練するための情報をもたらすプロセスである。しかし実際には、テストプレイは、修正しなくてはならない、ゲームデザイン上、プログラミング上の問題を明らかにする。そのため、テストプレイはしばしば、プログラムのデバッグ作業とごっちゃにされる。
テストプレイは、ときに、ゲームの致命的な欠陥を明らかにすることがある。致命的でない欠陥は普通、大した問題ではない。特色に欠けているとか、コマが多すぎるとか、アクションが足りないとか、プレイヤーに要求される計算が多すぎるとか、そういった問題は修正可能である。致命的な欠陥というのは、ゲームに絶対に必用な二つの要素が真っ向から対立してしまい、その不適合が予測できなかったような場合に生ずる。あなたは、そういった致命的な欠陥を抱えたゲームを、思い切って捨てる勇気を持っていなくてはならない。プログラム済みのゲームにパッチを当てたとしても、せいぜい限定された利得を達成することができるだけだ。もしゲームがひどく奇形であるなら、手術よりも中絶のほうが望ましい。
テストプレイによって、重大だが致命的ではない問題が明らかになった場合、あなたは慎重に選択を検討しなくてはならない。手っ取り早いが汚らしい、臭いものにふた式の仕事に陥る誘惑に屈してはいけないのだ。多くの場合、テストプレイで発見される問題は、真に根本的なデザインの欠陥の徴候にすぎない。詳細な分析を行って、問題の本質を見つけなければならない。いったん問題の本質を見いだしたなら、さまざまな解決方法を考えるのに、長い時間をかけるべきである。このプロセスを急いではいけない。ときに、理想的な解決は意外な角度から得られるものである。あなたのゲームの目標に、着実に近づけるような解決方法を選択しよう。あなたの目標に一番近づける解決方法の代わりに、最も簡単な解決方法を選択してはならない。
たとえば、『東部戦線1941』のデザイン中に、私は厳しい問題に遭遇した。プレイヤーが操作するには、あまりにもユニットの数が多すぎたのである。マップを縮小する方法を考えたり、単純にユニット数を減らせないか考えたりして時間を費やしたあと、結局、ゾーン単位のコントロールという方法に落ち着いた。ウォーゲームにおいてユニットの影響範囲を大きくする、標準的なテクニックである。この方法によって、ユニット数の問題を解決できただけでなく、兵站業務のルールをいっそう重要にし、ゲームの戦略性を豊かにすることができた。ユニット数を減らすというだけの目標で始めたわけだが、結果として、ずっと大きな改良点を見つけることができたのである。
あなたの最初のデザインがうまくいっていれば（または、あなたが単に幸運だったなら）、ゲームはこのような危機には直面しないだろう。その代わりに直面するのは、洗練の問題である。ゲームを構成するすべての要素は調子はずれで、あなたが思い描いていたような、しなやかなヒョウのようには動いてくれず、酔っ払った恐竜のように動くことだろう。ゲームの調整には何週間もの時間を要する。あなたが他の問題に取り組んでいる間は、それほど調整はしなくて良い。ゲームの調整は、すべての要素にデリケートに依存するので、ゲームに何か変更を加えれば、それまでの調整がムダになってしまうからである。したがって、洗練段階の本当の終わりまで、最終調整の仕事は持ち越したほうが良い。
実は、テストプレイにはふたつの形式がある。ひとつめは、デバッグの最終段階でなされる、あなた自身のテストプレイで、ふたつめは、あなたがゲームを他のテストプレイヤーに引き渡してからの話である。このふたつの重要な違いは、発見されるバグの性質にある。あなた自身のテストプレイでは、すべてのプログラムバグ（プログラム構造の欠陥から生じるもの）と、多くのゲームバグ（ゲーム構造の欠陥から生じるもの）を明らかにして、排除すべきである。あなたがテストプレイヤーに見せるゲームには、プログラムバグがなく、彼らはゲームバグだけを発見するというのが望ましい。テストプレイヤーにわざわざ不完全なゲームを見せることはないし、それどころか、あまり早い段階から見せてしまうと、彼らの客観性を損なってしまう恐れもある。ゲームの完成に近づいて、あなた自身の改良案が減ってきていると感じるときがくるはずだ。そのときこそ、少数の選り抜きのテストプレイヤーに、ゲームを見せるときである。
テストプレイヤーは、注意深く選択しなくてはならない。そのあたりの友人たちをつかまえて、ゲームについてどう思うかと彼らに尋ねたりすることはできない。ゲームに精通し、何がしかの経験に基づいて、あなたのゲームを分析し批評することのできる人材が必要である。理想的には、テストプレイヤーは、彼ら自身ゲームデザイナーであるのが望ましい。彼らであれば、良いゲームデザインに欠かせない、トレードオフの評価を共有することが出来るからだ。あなたはまた、彼らの性格とゲームの嗜好を良く知っているべきである。テストプレイヤーの人数は5〜6人にとどめたほうが良い。それ以上だと、各テストプレイヤーの反応を慎重に吟味することができなくなる。
これまで試されたテストプレイの形式は、他にもいろいろある。一般の人たちを集めてきてゲームをプレイさせ、彼らの反応を評価することに頼っていることも多い。私は、このようなシステムは良いとは思わない。それは確かに、科学的で、客観的で、民主的であるけれども、消費者というのはお粗末な批評家であるゆえ、彼らはめったに有用なデザイン情報をもたらしてはくれないのだ。彼らの提案は、無意味で非実用的である。彼らは、実用的な提案ができるだけの、コンピュータやゲームについての知識を持っていない。こういう方法は、洗剤とかシェービング・クリームなどではうまくいくだろう。しかし私は、優れた映画や本や音楽が、この種の市場調査によって作られたということに対して非常に懐疑的である。このような方法が、才能のないデザイナーが安っぽいゲームの大量生産をする場合に役立つということは理解できる。それは認めるが、この本は、そういう考え方をする人には向けられない。
テストプレイヤーたちは、事前にゲームのマニュアルを必要とするだろう。それはゲーム本体ほど完成されたものである必要はなく、テストプレイヤーが、ゲームで何をすれば良いのかわかるだけの情報があれば十分である。マニュアルを見れば解決できるような問題を批判されて、時間を浪費しないようにしておこう。テストプレイヤーの隣に座って、ゲームをしながら教えたりしてはいけない。そんなことをすれば、彼の客観性を汚染してしまうだけである。テストプレイヤーの最初の反応は、マニュアルのわかりやすさを示すベストな情報なのである。実際にテストプレイヤーに会って話を聞く前に、一週間くらいゲームをしてもらうと良い。ただし、プレイの様子を、こと細かく記録するように頼んだりしてはいけない。彼はそんなことをしないだろう。その代わり、心配な点に関して、マニュアルに若干のことを書いておけば良い。ゲームでどの選択肢を選んだかということと、それに続くスコアの単純な記録さえ書面で尋ねれば十分である。
テストプレイヤーに、ゲームを理解するのに十分な時間を与えたら、インタビューを行おう。そのとき、すべてのテストプレイヤーに尋ねる質問を、あらかじめ用意しておくと良い。テストプレイヤーの回答を誘導してはいけないし、賞賛を求めてもいけない。あなたの仕事は欠陥を見つけることであって、賞賛を受けるのはもっと後の話である。インタビューに第三者を使うことはいっそう科学的であるが（それにより、いっそう公正な回答が期待できるから）、その場合は、テストプレイヤーの間に仲介役が必要となる。私は、テストプレイヤーから直接情報を受け取るほうが良いと思う。私はまた、インタビューの間、わざと自分から否定的な態度を取り、テストプレイヤーとともにゲームを批評して、その改善案が出されるように仕向けることを好む。
テストプレイヤーの批評は、評価することが困難である。たいていの批評は、さまざまな理由で否定されなくてはならない。いくつかは、あなたの目標と相容れないものだろうし、いくつかは、残っているメモリ容量では実現できない。いくつかは合理的であるが、利得と釣り合わないような、大掛かりなソフトウェアの改造が必要になるだろう。なされた提案の90％を否定することを躊躇してはいけない。残った10％は適切な提案なのだから、それを実装して、時間を浪費しないようにしよう。では、どうやってその10％を見分ければ良いのか。それは知恵や分別の問題であり、私には何ともいえない。
ゲームデザインの最終段階は、ゲームに磨きをかけることに尽きる。洗練段階は、実はテストプレイ段階の後半と同じであり、そのいくつかは、テストプレイヤーを伴っても良い。この段階は非常に重要である。デザイナーはいままで長い間ゲームに取り組んできて、新しいデザインの輝きは次第に薄れてきた。いまとなっては、数ヶ月前に終えられるべきだった大仕事にすぎない。テストプレイヤーはゲームに夢中になっているし、出版社もこのゲームを気に入り、いますぐ欲しがっているのだが、当のデザイナーはうんざりしているのだ。この厄介物を投げ出してしまいたいという衝動は強烈である。この衝動に抵抗して断固として維持しなくてはいけない。そして、ひたすら磨き続けよう。ゲームをテストし、調整し、小さな装飾を加え続けよう。ドアから外に出したら最後、永久に戻ってはこないのである。私が手がけたゲームは、すべて同じパターンに従った。私は、これでもかというくらいにゲームを磨いた。うんざりして、もう二度と見たくもなくなるくらいにである。ついにゲームを送り出したときは大喜びだった。ついに、あの厄介物から解放された。私は自由だ。しかし、一ヶ月と経たないうちに後悔して、私が気付かなかった恥ずかしいバグをひとつ修正するチャンスがあれば良いのにと思っていた。三ヶ月のうちに、もっとたくさんのバグが発見され、私の後悔は羞恥心に変わっていた。そのころには、そのプログラムが広く知れ渡らないことを願っている始末だった。
ゲームをリリースする前に行わなくてはならない最後の仕事のひとつが、ゲームのマニュアルを準備することである。マニュアルは、コンピュータゲームに関係するすべての人たちから、しばしば軽視される。これは大間違いであって、マニュアルは、ゲームのパッケージ全体の中で、極めて重要な要素である。コンピュータには多くの限界があるが、いくらかはマニュアルで補うことが可能だ。ゲームに関係する不変の情報の多くは、マニュアルで提供することができる。マニュアルはまた、絵やバックグラウンド・ストーリーのような、空想世界をサポートする要素を加える恰好の場所である。そして、うまく書かれたマニュアルは、ゲームでしばしば発生する誤解の多くを解くことができるだろう。
マニュアルは、デザイナー自身が執筆しなければならない。作文能力があるかどうかにかかわらず、また、プロのライターが最終的なマニュアルを用意することになっていたとしてもである。自分でマニュアルの執筆を試みることで、プロのライターの技能への敬意が増し、生産的な人間関係を持てる可能性が高くなるだろう。また、綺麗なゲームデザインのために有用なフィードバックが得られるだろう。不器用なデザインは記述が難しいのに対して、クリーンなデザインは記述が容易だからである。最終的にこのマニュアルは、プロのライターのための有用な情報源となるだろう。ライターがあなたの書いたマニュアルを捨てて、すべてを始めることができるようにしておこう。素人の努力にプロが磨きをかけるより、新たにマニュアルを書き起こしたほうがましだろうから。あなたは、ライターのすべての質問に、可能な限り完全に答えなくてはならない。デザイナーとライターがお互いに意思疎通を図って、助け合ってこそ、優れたマニュアルを作り出すことができるのである。
プログラムが終わったら、批評家に備えて身を引き締めることだ。あなたの愛しいゲームを、彼らはその不潔な手でわしづかみにして恐ろしいことをしてくれるだろう。彼らは、ルールも読まずにプレイするだろう。ストラテジーゲームなら、彼らは、エキサイティングではないといって非難するだろうし、アクションゲームなら、知的な面で不十分だと判定するだろう。勝手に想像した技術的な欠陥を見つけて、あなたがなぜこのようなゲームを作ったのかという深層心理について、あれこれと的外れな憶測を始めることだろう。私の批評家の一人は、『タンクティクス』は明らかにきついスケジュールで急いで作られたと結論したが、実際には、開発を開始してから発売するまでの期間は5年と2ヶ月だった。また、『エナジー・ツァー』の場合は、彼の好きなアーケードゲームと比べてエキサイティングではなかったという理由で酷評された。こういった批評家の言うことを真に受けてはいけない。たいていの批評家は、プログラムを批評するだけの資格を持っていないのだから。コメントに耳を傾けるに値する思慮深い批評家は、ほんの一握りしか存在しない。3人以上の批評家の意見が一致している場合のみ、注意を払うようにするのが良いだろう。また、目標が批評家の好みでないときは、良い批評家でさえあなたを酷評するということを覚えていてほしい。
大衆はもうひとつの問題である。彼らがゲームを買ってくれない場合、あなたはふたつの意味で損をする。第一に、あなたとあなたの雇用者が儲からないということ。第二に、あなたのメッセージが人々に届かないということである。美しいメッセージを誰も聞いてくれなかったとしても、気に病むことはない。あなたは芸術家として失敗した。一回失敗したからといって心配するには及ばない。どんな芸術家だって、ときおり大失敗するものである。二回続けて失敗した場合はさすがに良くないので、三度目は、芸術的な価値を真剣に再考すべきである。さて、あなたは、気高いが貧乏な芸術家でありたいだろうか。それとも、いくぶん裕福な職人でありたいだろうか。自分の胸に聞いてみると良い。心の奥深くで、あなたが自分の目標を達成したことを知っているのならば、批評家と大衆を無視するのだ。