tkrte!

ゲームデザイン方法論2003(2)

Game Design Methods: A 2003 Survey(ゲームデザイン方法論2003)についての続きです。

Game Design Documents(ゲームデザインドキュメント)

ゲームデザインドキュメントについては、以下の様に定義されています。

The design document (or "Design Bible Method") is a common attempt to organize the development process.

ゲームデザインドキュメント(またはデザインバイブル方法論)は開発プロセスを構造化・組織化しようという共通の試みである。

＊（日本語訳は私によるものです） 

これに対する議論は色々あるものの、ゲームデザイン方法論の議論のほとんどはゲームデザインドキュメントを記述する議論の一部と捉えることも出来るといいます。もしこのゲームデザインドキュメントをテンプレート化できたとすると、ゲームデザイナーに対して質問を投げかけ、決定を強制するようなものになると考えられるそうです。 ここにおける問題として以下の様に記されています。

The problem with the structured query approach is that it attempts a single top-down solution at a time when game design as a craft is lacking both overarching concepts and complete foundation.

構造化された質問型アプローチの問題は、技術としてのゲームデザインが包括的なコンセプトと基礎を欠いていた場合に、一度にひとつのトップダウン型の解決方法しか試みられないということである。

＊（日本語訳は私によるものです）

また、同様に、プロトタイプを用いた開発プロセスや、ゲームデザインの改良・改善をしながら開発してゆくプロセスの場合にも適さない方法である、と言えます。このように様々な問題を抱えている訳ですが、それでも構造化された質問というコンセプトは重要であると結論付けられています。

この問題は、形式化することでクリエイティビティが低下するのではないか？という問いの形でよく言われることです。難しく考えすぎてしまうことによって、柔軟な考えが出来なくなってしまう、と言う状況は十分考えられることです。しかしながら、全くのゼロから誰もがゲームデザインを産み出していけるか、というとそうともいえず、たとえ可能であっても、車輪の再発明を何度も行うと言う、非効率なことに時間を費やしてしまうという可能性も十分あります。

クリエイティビティを抑圧せず、上手く手助けできる程度の形式化というのは今後も考えていかねばならない部分だと考えます。

Discourse by Anecdote(逸話をもちいた議論)

逸話をもちいて議論・談話してゲームデザインについて論じていこうという方法です。Francoise Dominic Larame氏の"Game Design Perspectives"やCris　Crowford氏の"The Art Of Computer Design(クロフォードのゲームデザイン論)"などが例として挙げられています。 この方法の利点として、自然な形で議論が始められるということが挙げられています。もっとも分かりやすい形と言うことも出来るかと思います。

Formal Abstract Design Tools

以前のエントリーを参照してください。ここでは1999年に投稿された25の用語が紹介されています。

The 400 Project: Rules

The 400 ProjectはThe 400 Projectのページに以下の様に書かれています。

The 400 Project is an ambitious attempt to collect "The 400 Rules of Game Design."

ここで言われるルールとは、開発や制作の諸問題に関わることを避け、ゲームデザインの中身に注目するものとされています。

この活動の中心人物のひとり、Noah Falstein氏はこれらの「ルール」について、単に過去のものを観察するというのではなく、ゲームデザイナーが道具として使えるものでなくてはならない、また実用性を重視し、純粋な学問の議論ではない、としています。

このあたりは、開発者たちから生まれたということもあって、実用性を明確に追うという姿勢が強調されているようです。個人的には、基本的に机上の空論であってはならないと考えているので賛成で頷く事が多いです。しかしながら、実利を追わない方法論もまた存在し、結果的にその方法が有用になるということもまた、存在します。なかなか、難しい所だと思います。

Patterns

ソフトウェア工学でのデザインパターンをゲームデザインに適用したものです。簡単な例が挙げられています。ゲームデザインパターンについては、より詳しい記事が存在します。そちらを参照してください。

FADTや「ルール」、ゲームデザインパターンは具体的な活動の例として挙げられています。それらは一長一短がありますがある程度形となっています。これらがどのように発展してゆくかは注目に値します。

もっとも、これらの将来がどうなるのか、というとまだ不明瞭、とも言えます。これらの活動が統合されて「ゲームデザイン大全」のようなものになるとは考えにくいですし、途中で座礁しないとも限りません。また、完成したものが個人の考えに強く依存するものになる可能性もあります。また現に既に見られることですが、市場の受け入れられるゲームの違いによって、いくら世界で共有されることが多いコンピューターゲームと言えども、市場によるゲームデザイン方法論の違いが出てくることも考えられます。ざっと考えてみるだけでも、なかなか問題がありそうです。

元記事にはこれらの問題や、解決されていない問題が挙げられていますので、次回紹介します。