疑問：ゲームプログラマは、ゲームデザインの知識をどれだけ持っているべきか？ ゲームプログラマがより多くのゲームデザイン知識を持っていれば、ゲームデザイナがより品質の高いゲームデザインを生み出せることにつながるのか？
少～し前の話になるけど 同人ど～らく さん経由で 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
