以前から、ゲームをデザインするとは、以下のようなことについて決定することだとして考えてきました。
（１）ゲームのルール
（２）ユーザインタフェース
（３）ゲームバランス。敵のパラメータ設定など。
（4）品質要求。たとえば、ロード時間に対する要求。
たとえば、ＲＰＧにおけるゲームデザインでは、戦闘に参加できるプレイヤーキャラクターの最大人数の決定があります。他にも、キャラクターの成長をレベルアップ制にするのかそうでないのか、といった決定があります。このような様々な決定を行うことがゲームデザインであると考えてきました。
さて、以前の記事で、決定には、ルーチン的なものと、クリエイティブ的なものがあると議論しました。
（1）ルーチンゲームデザイン：過去の経験の積み重ねなどからうまくいくことが分かっている項目に対して、適切な決定を行います。たとえば、ゲーム中のムービーに対する項目として「スキップできる」と「スキップできない」のどちらがユーザが望んでいるゲームでしょうか？多くのユーザは「スキップできる」ことを望んでいます。したがって、ゲームデザイナは、ムービーに対する項目に対して、「スキップできる」と「スキップできない」のどちらにするかを迷う必要はなくなります。
（2）クリエイティブゲームデザイン：従来のゲームでは存在しなかったような項目を考え出す決定を行います。
ルーチンゲームデザインは、その名が示すように、クリエイティブさは必要ありません。とはいえ、ユーザが満足できるゲームをデザインするためには、ルーチン的な決定は適切に行う必要があります。ルーチン的なデザインがうまくできてないゲームは、クリエイティブな部分を台無しにしてしまいがちです。しかし、商業のゲームでさえ、このようなルーチン的なゲームデザインが適切に行われていないことがあるのが現状です。そこで、ルーチン的なゲームデザインがうまくできているかを確認するためのチェックリストがあれば便利でないかと思いました。
ＲＰＧとシミュレーション系のゲームに特化しているかもしれませんが、いくつかチェック項目を考えてみました。
（1）イベントはスキップできますか？
（1.1）ムービーはスキップできますか？
（1.2）戦闘シーンはスキップできますか？
（2）ゲームのテンポは適切ですか？
（2.1）戦闘開始までの時間は十分に短いですか？
（2.2）ユーザの入力をテンポよく受け付けていますか？
（2.3）メニュー画面はすぐに表示されますか？
今後は、mk2 やアマゾンなどのレビューサイト、2chのスレなどを参考にチェック項目を増やしていきたいと考えています。
信頼できるチェックリストにするためにあると良いと思うのは、次のことです。
（1）ルーチンデザインに反している具体的なゲームタイトルを挙げること。
（2）ルーチンデザインである理由を書くこと。たとえば、なぜムービーはスキップできるべきなのか。
疑問：ゲームプログラマは、ゲームデザインの知識をどれだけ持っているべきか？ ゲームプログラマがより多くのゲームデザイン知識を持っていれば、ゲームデザイナがより品質の高いゲームデザインを生み出せることにつながるのか？
少～し前の話になるけど 同人ど～らく さん経由で PlatineDispositif さんの「スペース大納言(仮」の体験版をやってみた。
今回の記事では、ゲーム内容に直接関わることではないけど、ゲームデザインの観点から感じたことを書いてみようと思う。特にユーザインタフェース（ＵＩ）のメニューにか関わる部分について。メニューとは、たとえば、ゲーム開始、設定（コンフィグ）、ゲーム終了などのこと。
ＵＩは、ゲームの面白さに直接関わらないのかもしれないけど、ここでは、ゲームデザインの一部だと考えます。ゲームデザインとは、次のようなことを決めることだとします。
（１）ゲームのルール
（２）ユーザインタフェース
（３）ゲームバランス
（4）品質要求。たとえば、ロード時間に対する要求。
ゲームデザイナとは、ゲームをデザインする役割を持った人のことだとします。
ゲームデザインだけでは、ソフトウェアとしてのゲームは作れないため、ゲームデザインを実際に実現する役割を持つ人が必要です。ここではその人を、ゲームプログラマ、もしくはソフトウェア設計者と呼びます。ゲームデザインは、言い方を変えれば、いわゆる要求仕様に対応すると考えられます。
役割としたのは、一人の人がゲームデザイナかつゲームプログラマである場合があるためです。
なお、ゲームデザイナは、ゲームプログラミングのことを知らなくてもいい、というわけでもないです。たとえば、ロード時間は、1ミリ秒以下でなければならない、といった要求は実現不可能な場合があります。
一般的に、工学におけるデザイン、つまり人工物を創るという行為は、探索的であり、試行錯誤を伴います[1]。ここでは、ゲームデザインもそのような行為を伴うとします。また、同じことですが、ゲームデザインを要求仕様として捉えるなら、仕様が変化することは避けられません[2]。
さて、ゲームデザイン（要求仕様）を変更するきっかけとなるとは、どのような場合でしょうか？ 一つは、他の人のゲームデザインを見たときです。以下では、具体的な例で説明したいと思います。
さきほど、ゲームデザインとしてユーザインタフェースが含まれるとしました。とすると、自分がゲームデザイナであり、ゲームを作っているとすると、他人が作ったゲームを見たりプレイすることが、自分の作っているゲームのユーザインタフェースに影響を与える場合があります。これが、PlatineDispositif さんの「スペース大納言(仮」の体験版をやっていて気づいたことです。ユーザインタフェース、特にメニュー項目の選択のグラフィックを見て、こんな選択の見せ方もありだな、と思いました。
一般的に、あるゲームデザイナが、他人のゲームデザインのある部分を見たときの反応としては、以下が考えられます。
（1）破棄。
（2）自分のゲームデザイン知識への反映。反映された知識は、現在もしくは後のゲームデザイン時に使われる。
（3）自分のゲームデザイン知識への反映を通じて、作成中の自分のゲームデザインへの反映。そのまま反映させれば、悪く言えば、ぱくり。
ここでは、3のケースについて考えていきます。ゲームデザイナとしては、自分の部分的なゲームデザインＡを、他人の部分的なゲームデザインＢで置き換えるように変更すると決めるのは容易です。また、ゲームデザインは試行錯誤を伴うとするなら、後に、ＢからＣ、もしかすると、ＣからＡというような変更を伴うかも知れまへん。ここでの問題は、一般的に、そのような変更にはソフトウェア設計やプログラミング上のコストを伴うことです。
ユーザインタフェースは、よく変更が伴うとして知られています。そのため、ソフトウェア設計では、ユーザインタフェースに関わる部分とその他の部分を分離し、ユーザインタフェースの変更が他の部分の変更をなるべく伴わないような工夫が行われれます。いわゆる、Model-View-Controller (MVC) アーキテクチャの適用です[3]。
問題は、知識と経験がなければ、ゲームのソフトウェア設計者やゲームプログラマは、ゲームデザイン上のどの部分が変わりやすく（可変の部分）、変わりにくい（不変の部分）かといったことが分からないということです。たとえば、ＲＰＧにおける戦闘への最大参加人数などの決定は変わりにくいと思われますが、敵のパラメータ設定などは変わりやすい部分であると思われます。とすると、変わりにくい部分に関しては、ソフトウェア設計上やゲームプログラミング上の工夫は必要なくなります。
しかし、可変な部分、不変な部分に関する知識、もしくはゲームプログラミングの経験がなくては、ソフトウェア設計やプログラミング上の工夫も難しいのではないかと思われます。
ここで、やっと、最初に書いた疑問が出てきます。
疑問：ゲームプログラマは、ゲームデザインの知識をどれだけ持っているべきか？ ゲームプログラマがより多くのゲームデザイン知識を持っていれば、ゲームデザイナがより品質の高いゲームデザインを生み出せることにつながるのか？
もし、ゲームデザイナーがより素早くゲームデザインを変更でき、多くのゲームデザインを探索できるとするなら、より品質の高いゲームデザインに到達できる可能性も増えると考えられます。しかし、探索のしやすさは、ソフトウェア設計上の柔軟性に依存します。ソフトウェア設計を柔軟にするには、ゲームデザインのどの部分が変わりやすいのか、変わりにくいのか、といった知識と経験が重要な役割を持つと考えられます。
ただし、ソフトウェア設計は、ゲームデザインの変化に耐えられるようにできる限りあらかじめ柔軟でなければならない、というわけではありません。変化を予測して設計を行うことは、設計を複雑にします。必要以上に複雑な設計は、保守や後の変化への対応を難しくします。
プログラミングは、設計行為の一部と考えられますが[4]、設計は思考的にも行えます[5]。思考的に行うとしても、ゲームデザインが変化しやすい部分・変化しにくい部分に関する知識が必要であると考えられます。
ゲームデザインに関する知識がゲームプログラマにとって重要であるとするなら、どうやってその知識を表現し、文章化し、伝えるのが効率的・効果的であるのかを考える必要があります。
最後に、次の本は、今回の記事に関連するかな？ と思う本です。ちゃんと読んだ本ではないので関連しないかもしれませんが列挙しておきます。
・マーチン ファウラー,アナリシスパターン―再利用可能なオブジェクトモデル
・Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software
・マイケル・ジャクソン, プロブレムフレーム ソフトウェア開発問題の分析と構造化,
・Staffan Bjork, Jussi Holopainen, Patterns In Game Design
参考：
[1] Nigel Cross, Engineering Design Methods: Strategies for Product Design
[2] アラン・M・デービス, 成功する要求仕様 失敗する要求仕様
[3] マーチン・ファウラー, エンタープライズ アプリケーションアーキテクチャパターン
[4] P. Kruchten, Casting Software Design in the Function-Behavior-Structure Framework, IEEE Software, Vol. 22, No. 2, Mar./Apr., 2005, pp.52-58. ここ からＤＬできるようです。
[5] Robert L. Glass, Software Conflict 2.0: The Art And Science of Software Engineering
さて、記事を読んでいて思ったことを。世界樹では、パーティは5人で編成されるんだけど、前衛と後衛のワクがある。珍しい（？）のは、5人ということで、「前衛３人/後衛２人」「前衛3人/後衛２人」のどちらかを選択できる。
で、そこでバリエーションを思い浮かべてみたんだけど、理論的には、「前衛5人/後衛０人」「前衛4人/後衛１人」などなどもありえるんだよなーと。そういうのもあっても悪くなさそうな気がしたんですよ。
ただ、その理論的というのを邪魔してるのが、画面レイアウトの物理的な制約なんだな、と。今の世界樹の画面レイアウトだと4人分のステータスを一列で表示できないもんなー、と。もちろん、表示できなくても理論的（プログラム的）には問題なくて、画面上は後衛にいるけど、内部的には前衛にいるとかはできる。
さて、何が分かったかというと、画面レイアウトが異なればキャラクターの立ち位置、つまり一般的にはパーティの陣形に幅が出る、ということ。たとえば、初代ロマサガでは、前衛、中衛、後衛でキャラを配置できる（だったよね？）。ミンサガではどうだったか忘れたけど。
一言でまとめてみよう。
画面レイアウトに関わる決定は、パーティの陣形の自由度に影響する。
このシリーズはやったことがないのだけど、どうやら最新作では、コンボシステムが進化しているらしい。僕の目に留まったのは「コンボ数が一定値（100）以上になると、敵から小判が出現するようになる」という部分。小判がどんな嬉しい特典なのかは知らないけどー。
で、何が言いたいのかというと、コンボをつなげると嬉しいけど、もっとご褒美があるともっと嬉しいんじゃないか、ということ。
ご褒美が直接ゲームに関わるとなると、ゲームバランスとかが難しくなるかもしれないので、常にご褒美があると良いとはいえないかもしれない。でも、コンボという要素を導入しようとした場合、コンボ数やその他コンボに関わる観点から、プレイヤーの行いを認めてあげる要素を検討するのは良いことかもしれない。
「Patterns in Game Design」本にはこういうことは書いてるのかなあ？ 「コンボ」で索引を見てみたけど、載ってないっぽい。
さて、今までの記事で何度かゲームデザインとは選択肢から選択する行為だ、と書いてきた。また、ゲームデザインの表現方法としてフィーチャダイアグラムが使えるんじゃないかと書いてもみた。
じゃあ、そういう視点で今回の「操作キャラ交代システム」を考えてみよう。シレン３では、どんな選択が行われたのか。
まず一つ目は、この新システム導入自体に関するもの。つまり、
（１）仲間キャラクターは、AIで行動するだけでなく、プレイヤーが直接操作できる。
二つ目。ファミ通によると、どうやら、装備品やアイテムなどの持ち物はキャラクターごとではなく、一括して管理されるみたい。ということで、
（２）装備品やアイテムなどの持ち物は一括管理する。
となる。
さて、このような選択を図で表すと分かりやすくてよい。フィーチャダイアグラムを使って表してみよう。
図のルートノード「不思議のダンジョンは」コンセプトノードと呼ばれる。コンセプトって何？ってのはおいとくとして、とりあえずは「不思議のダンジョン」というジャンルでゲームデザインを考えているとしよう。
その下のノードは、「仲間キャラクター」を表す。これはオプショナルで、選択しなくても良い。たとえば、初期のトルネコの不思議のダンジョンの場合は、仲間キャラという要素はなかった。
次は、もし「仲間キャラクター」という要素を選んだら、じゃあ、その仲間の行動はどうやって処理されるのか、ということに関する選択。図では「AI行動」と「プレイヤー操作行動」の二つを考えてる。この二つはORフィーチャで、どちらか一つだけを選んでもいいし、二つ選んでもいいことを表す。つまり、
（１）AI行動のみ： この場合は、仲間キャラクターはAIにより行動する。
（２）プレイヤー操作行動： この場合は仲間キャラクターもプレイヤーが操作する。
（３）AI行動＋プレイヤー操作行動： この場合は、特定の場合は、AI行動で、その他の場合は、プレイヤーが操作する。シレン３は恐らくこの選択を行っていると思う。
次に「プレイヤー操作行動」が選ばれたとしたら、持ち物はどうするのかという点。ここでは、「持ち物共有」と「持ち物個別所有」の二つを考えてる。シレン３では前者が選ばれてるっぽいが、可能性としては後者もありうる。
というように、フィーチャダイアグラムを使うことで、次の点が明確になる。
（１）あるゲームデザイン（この場合はシレン３）で、どんな選択が行われたのか
（２）どんな選択が行われなかったのか
特に、二つ目のどんな選択が行われなかったのか考えるのは、ゲームデザインをさらに考えるのに役立つ気がする。つまり、
（１）選択肢、つまり、選択される候補としては存在したけど、結果として選ばれなかった選択肢を明確にする。それにより、ある選択肢が没になった理由を考える手がかりとなる。
（２）新しい選択肢、つまり、新しいゲームデザインの可能性を考えるきっかけとなる。
実際フィーチャダイアグラムを書いてみると、文章としてシレンの新システムの説明を書いたときは抜けていた考えが分かった。たとえば、上記のフィーチャダイアグラムでは、「プレイヤー操作行動」を選択した場合にのみ、持ち物の共有についての選択を行うとしている。けれど、AIの場合でも、持ち物についてどうするかを考えてもよかったはずだと思う。もう一つの発見は、シレン３では「AI行動＋プレイヤー操作行動」が選ばれたという先入観から、「AI行動＋プレイヤー操作行動」と「AI行動」のどちらかから選択されたと思っていた。だけど、実際は可能性としては三つ目の「プレイヤー操作行動」がありえることが明確になった。
最後に、フィーチャダイアグラムをつかってゲームデザインを表現する利点は、知識の共有にあると思う。たとえば、これから不思議のダンジョン系のゲームを作るろうとするとき、このようにして表されたゲームデザインがあり参考にできるのは役立つと思う。