ゲームデザインパターンについて考えてみる

y_miyakeさんのこの記事に反応にしてみる。

• ゲームデザインパターン：　過去の自分と協力プレイ

ゲームデザインパターンは、重要な役割を持つだろうコンセプトだと思っている。このコンセプトを、できるなら楽に、パターンを作る側も使う側も把握したい。上記の記事を読んで、ぱっと思った疑問を書いてみる。

上記の記事では、「過去の自分と協力プレイ」というゲームデザインパターンを紹介している。また、このパターンを観察できる具体的なゲームのタイトルと、「過去の自分と協力プレイ」に対応するような各タイトルのシステム的な仕組むを紹介している。

タイトル	仕組み？
ロットロット	時間差カーソル
超思考型新頭脳挑戦ゲーム　頭脳４９８９	ミサイルと自機をある規則に従って操る
Cursor*10	過去の自分と協力プレイ
プリズマティカリゼーション	記録と解放によって謎を解いて行く
Braid	時間巻き戻し機能によって、自分の多重プレイでステージを解く
己の信ずる道を征け	なし：一言で説明するのが難しかった？
時限回廊	なし：一言で説明するのが難しかった？

図で表現すればこんな感じになると思われる。

あるゲームは、様々な要素からなる。システム的なものやインタフェース的な要素などがある。ゲームデザインパターンは、このようなゲームの部分的な要素が似た特徴を持っており、繰り返し発生するとし、その部分を抽象化したものであると考えられる。抽象化したものには、名前を付ける。名前がデザイナー間、あるいは、ユーザ間で使われるデザインの語彙となる。

ゲームデザインパターンは、実際のデザインにおいて使われる役割を持つ。ただし、そのままでは使えない。ゲームデザインパターンは抽象化されたモノであるため、抽象化の逆の操作である具象化を行う必要がある。

まとめるなら、ここまでがゲームデザインパターンの二つの過程を表しているといえるorモデルである。

• ゲームデザインパターンが形成される過程
• ゲームデザインパターンが使用（適用）される過程

いくつかの疑問がある。

• (1) ゲームデザインパターンとして表さるものは、名前だけなのか。現状では、入力されたゲーム要素に対する出力結果は、名前だけに見える。名前だけなく、抽象化されたゲーム要素も表現されれば良いのではないか。
  • 恐らく、されていないのは難しいからだと思われる。他の分野での同様のパターン化の試み、たとえば、ソフトウェアでのデザインパターンでは、抽象化の対象はプログラムである。抽象化されたプログラムは、UMLのダイアグラムなどによってその構造や振る舞いが表現される。

• (2) ゲームデザインパターンは、どのような場合に使えるのか。たとえば「過去の自分と協力プレイ」は、RPGでも適用できるのか。適用できるかどうかをどう判断すればいいのか。

• (3) ゲームデザインパターンとして、形成するための条件は何か。さまざまなゲームで同様の要素を認識できれば、それをゲームデザインパターンとして形成すれば良いのか。

以上、大雑把ではあるが、個人的に思った疑問を書いてみた。

追記

続きはこちら。

• ゲームデザインパターンについて考えてみる　その２：弱点属性パターン

参考

参考になるかもしれないものを3つほど。この3つは、ゲームデザインでのパターンという視点に近そうなものから順に並べてみた。僕としては、まだ十分に把握していないので、今後考えていく上での出発点としてこれらを参考にしていくつもりである。

Patterns In Game Design (Game Development Series)

『Patterns In Game Design』という本では、ゲームデザインパターンを次のように定義してる。

game design patterns are semiformal interdependent descriptions of commonly recurring parts of the design of a game that concern gameplay.

アナリシスパターン―再利用可能なオブジェクトモデル (Object Technology Series)

『アナリシスパターン』では、パターンを次のように定義している。

筆者は「パターン」を、「ある実践の文脈で有用であり、他の文脈でも有用と思われるアイデアと定義する。「アイデア」と言ったのは、パターンは何でも構わないという意味からである。『ギャング・オブ・フォー』のパターンのように協調するオブジェクトのグループでもよいし、Coplienの「プロジェクト組織の原則」のようなものでもよい。[...]

Organizational Patterns of Agile Software Development

『Organizational Patterns of Agile Software Development』という本では、パターンのコンセプトを次のように説明している。

To fully understand what a pattern is, you must first understand what a pattern language is. A pattern does't exist apart from a pattern language; in fact, its first purpose is to establish connections to other patterns in the language ([Alexander 1977], p. xii).

Here is a short and necessarily incomplete definition of a pattern:

A recurring structural configuration that solves a problem in a context, contributing to the wholeness of some whole, or system, that reflects some aesthetic or cultural value.

Some of these aspects of a pattern don't come out in the popular literature, and you may not find them all in the same place in Alexander's definitions. But they are the key elements of what makes a pattern a pattern and of what makes a pattern different from a simple rule. A pattern is a rule: The word configuration should be read as "a rule to configure." But it is more than just a rule; it is a special kind of rule that contributes to the overall structure of a system and that works together with other patterns to create emergent structure and behavior.