更新履歴
2009/7/18: この記事の内容を修正して「ゲームデザインの理論」のドキュメントに追加しました。今後は、こちらのドキュメントを更新していきます。
-----
この記事では以下を主張する。
ゲームデザインにおけるデシジョン（決めたこと）には、ルーチン的なものとルーチン的でないなものが存在する。
これまでの記事では、ゲームデザインを、ゲームデザイナーが決めたこと（デシジョン）の集合であると定義してきた。この記事では、あるデシジョンが既に知られているかどうかの観点から区別する。既に知られているとき、「ルーチン的デシジョン」と呼び、知られていないとき「ルーチン的でないデシジョン」と呼ぶ。
ルーチン的かどうかの区別は、ゲームデザインが全く新しいもの（デシジョン）のみで構成されるわけでないことを強調する。ゲームデザインは、ルーチン的デシジョンとルーチン的でないデシジョンから成る。
ゲームデザインにおいては、しばしば、創造性（クリエイティビティ）が強調され、創造的であることが求められる。創造性は、ルーチン的でないデシジョンを生み出すことを意味する。
しかし、ゲームデザインがルーチン的デシジョンとルーチン的でないデシジョンから成ると見なすなら、創造性のみを強調するのは不十分である。ルーチン的でないデシジョンを行うだけでなく、ルーチン的デシジョンを適切に行わなえなければ、ゲームプレイヤーが満足するようなゲームデザインは生み出せない。
ゲームデザインのプロセス（活動）とは、ここでは、次のような側面に対する様々な決定（デシジョン）を行うことだする。
（1）ゲームのルールの側面: キャラクターのレベルは上がる。レベル制限は99。戦闘はターン制であり、敵と見方が交互に行動を行う、など。
（1.1）ゲームバランスの側面： ある敵のHPは500といった、パラメータの設定など。
（2）ゲームシステムの側面: セーブ数は、10件など。
（2.1）ユーザインタフェースの側面: LボタンとRボタンでキャラクターの切り替えができるなど。
（2.2） システムの品質に関わる非機能要素の側面： たとえば、ロード時間に対する要求。3秒以内に戦闘画面を表示し、ユーザの入力を受け付けなければならない、など。
（3）ゲームの遊び方に関する側面: ゲーム中のBGMを自由に変更できるなど。
ゲームデザインとは、このプロセスの結果として決めたこと（デシジョン）の集合であるとする。
詳細は「ゲームデザインの理論」のドキュメントを参照。
ここでは、具体例をもとに、デシジョンをルーチン的なデシジョンとルーチン的でないデシジョンに区別できることを議論する。
ルーチン的デシジョンとは、既に知られているデシジョンのことを指す。一方で、ルーチン的でないデシジョンとは、知られていないデシジョンを指す。たとえば、現代のRPGにおいて「アイテムの預り所の機能がある」というデシジョンは、ルーチン的である。一方で、過去に初めて「アイテムの預り所の機能がある」というデシジョンが行われた時、そのデシジョンは、ルーチン的でないデシジョンである。
あるデシジョンがルーチン的かどうかは、歴史的な観点により決まる。
もちろん、歴史的な判断を行うのは人であり、ある人がある時点まででの歴史上の全てのゲームを知ることは不可能なため、どの時点であるデシジョンがルーチン的になったかは知ることはできない。
個々のゲームプレイヤーの観点から、あるデシジョンがルーチン的であるかどうかを区別することもできる。
あるゲームプレイヤーがプレイを通じて、ゲームに対する不満を持つ時、それはあるゲームデザイナーが行ったデシジョンとゲームプレイヤーが期待するデシジョンとの間のミスマッチが原因である。この時、そのデシジョンがルーチン的かどうかは問題でなく、不満として扱われる。
ここで重要なのは、二つの種類のデシジョンが存在するということである。つまり「ゲームデザイナーが行った実際のデシジョン」と「ゲームプレイヤーが期待するデシジョン」である。これまでのデシジョンがルーチン的かどうかの区別は、前者、つまり「ゲームデザイナーが行った実際のデシジョン」を対象としてきた。しかし、「ゲームプレイヤーが期待するデシジョン」もルーチン的かどうかで区別することもできる。
また、あるゲームデザイナーの観点から、ゲームプレイヤーが期待するデシジョンがルーチン的かどうかも区別できる。
これら二の観点の観点と歴史的な観点から、5つのケースが考えられる。
(1)歴史的ルーチン的/ルーチン的期待する/ルーチン的期待される: この場合、ゲームデザイナーは、プレイヤーを不満にせずに済んだのかもしれないのに、不満にしてしまったケースだと言える。プレイヤーは、ゲームデザイナーが何も分かってないと思うかもしれない。ただし、もちろん、全てのゲームプレイヤーを満足させることはできない。
(2)歴史的ルーチン的/ルーチン的期待する/ルーチン的でない期待される: この場合、ゲームデザイナーのゲームデザインに対する知識不足が原因で、プレイヤーを不満にさせてしまったケースだと言える。
(3)歴史的ルーチン的/ルーチン的でない期待する/ルーチン的期待される: この場合、(1)と同様であるが、プレイヤーの不満度合いは低いかもしれない。というのも、プレイヤーは、自身が提案する期待するデシジョンにより作られたゲームをプレイした経験がなく、妥当性を評価できていないためである。
(4)歴史的ルーチン的/ルーチン的でない期待する/ルーチン的でない期待される: この場合、(2)と同様であるが、単なる知識獲得だけでなく、適切なデシジョンを行う分析能力と創造性がゲームデザイナーに要求されるかもしれない。
(5)歴史的ルーチン的でない/ルーチン的でない期待する/ルーチン的でない期待される: この場合、不満を避けるのが最も困難だったケースだと言える。
この分析の不十分な点は、あるデシジョンに対して、どれだけのプレイヤーが不満を持っているのかを考慮していない点である。多くのプレイヤーが不満を持つほど、ゲームデザインの不適切さを意味する。
しかしながら、この5つのケースは、上から順に、プレイヤーとデザイナーの間でミスマッチが発生してはならない度合いの大まかな指針となる。
この記事では、以下を主張した。
ゲームデザインにおけるデシジョン（決めたこと）には、ルーチン的なものとルーチン的でないなものが存在する。
ゲームプレイヤーが満足するようなゲームデザインは生み出すには、ルーチン的でないデシジョンを行うだけでなく、ルーチン的デシジョンを適切に行わなえなければならない。
Gero, JS and Kannengiesser, U. Creative designing: An ontological view.
この記事を書くにあたっては、上記の論文を参考にした。特に、ルーチン的・ルーチン的でないという言葉はこの論文から拝借した。この論文では、ルーチン的でないは、さらに、革新的と創造的に区別されている。
ただし、この記事とこの論文では焦点が異なる。この記事では、プロセスの結果としてのデシジョンに着目しているが、論文ではデザインのプロセスの観点からも議論されている。
2009/7/18: この記事の内容を修正して「ゲームデザインの理論」のドキュメントに追加しました。今後は、こちらのドキュメントを更新していきます。
-----
この記事では以下を主張する。
ゲームデザインにおけるデシジョン（決めたこと）には、ルーチン的なものとルーチン的でないなものが存在する。
これまでの記事では、ゲームデザインを、ゲームデザイナーが決めたこと（デシジョン）の集合であると定義してきた。この記事では、あるデシジョンが既に知られているかどうかの観点から区別する。既に知られているとき、「ルーチン的デシジョン」と呼び、知られていないとき「ルーチン的でないデシジョン」と呼ぶ。
ルーチン的かどうかの区別は、ゲームデザインが全く新しいもの（デシジョン）のみで構成されるわけでないことを強調する。ゲームデザインは、ルーチン的デシジョンとルーチン的でないデシジョンから成る。
ゲームデザインにおいては、しばしば、創造性（クリエイティビティ）が強調され、創造的であることが求められる。創造性は、ルーチン的でないデシジョンを生み出すことを意味する。
しかし、ゲームデザインがルーチン的デシジョンとルーチン的でないデシジョンから成ると見なすなら、創造性のみを強調するのは不十分である。ルーチン的でないデシジョンを行うだけでなく、ルーチン的デシジョンを適切に行わなえなければ、ゲームプレイヤーが満足するようなゲームデザインは生み出せない。
ゲームデザインとは何か？
ゲームデザインのプロセス（活動）とは、ここでは、次のような側面に対する様々な決定（デシジョン）を行うことだする。
（1）ゲームのルールの側面: キャラクターのレベルは上がる。レベル制限は99。戦闘はターン制であり、敵と見方が交互に行動を行う、など。
（1.1）ゲームバランスの側面： ある敵のHPは500といった、パラメータの設定など。
（2）ゲームシステムの側面: セーブ数は、10件など。
（2.1）ユーザインタフェースの側面: LボタンとRボタンでキャラクターの切り替えができるなど。
（2.2） システムの品質に関わる非機能要素の側面： たとえば、ロード時間に対する要求。3秒以内に戦闘画面を表示し、ユーザの入力を受け付けなければならない、など。
（3）ゲームの遊び方に関する側面: ゲーム中のBGMを自由に変更できるなど。
ゲームデザインとは、このプロセスの結果として決めたこと（デシジョン）の集合であるとする。
詳細は「ゲームデザインの理論」のドキュメントを参照。
ルーチン的デシジョンとルーチン的でないデシジョン
ここでは、具体例をもとに、デシジョンをルーチン的なデシジョンとルーチン的でないデシジョンに区別できることを議論する。
ルーチン的デシジョンとは、既に知られているデシジョンのことを指す。一方で、ルーチン的でないデシジョンとは、知られていないデシジョンを指す。たとえば、現代のRPGにおいて「アイテムの預り所の機能がある」というデシジョンは、ルーチン的である。一方で、過去に初めて「アイテムの預り所の機能がある」というデシジョンが行われた時、そのデシジョンは、ルーチン的でないデシジョンである。
あるデシジョンがルーチン的かどうかは、歴史的な観点により決まる。
もちろん、歴史的な判断を行うのは人であり、ある人がある時点まででの歴史上の全てのゲームを知ることは不可能なため、どの時点であるデシジョンがルーチン的になったかは知ることはできない。
ゲームプレイヤーにとってのルーチン的デシジョン
個々のゲームプレイヤーの観点から、あるデシジョンがルーチン的であるかどうかを区別することもできる。
あるゲームプレイヤーがプレイを通じて、ゲームに対する不満を持つ時、それはあるゲームデザイナーが行ったデシジョンとゲームプレイヤーが期待するデシジョンとの間のミスマッチが原因である。この時、そのデシジョンがルーチン的かどうかは問題でなく、不満として扱われる。
ここで重要なのは、二つの種類のデシジョンが存在するということである。つまり「ゲームデザイナーが行った実際のデシジョン」と「ゲームプレイヤーが期待するデシジョン」である。これまでのデシジョンがルーチン的かどうかの区別は、前者、つまり「ゲームデザイナーが行った実際のデシジョン」を対象としてきた。しかし、「ゲームプレイヤーが期待するデシジョン」もルーチン的かどうかで区別することもできる。
また、あるゲームデザイナーの観点から、ゲームプレイヤーが期待するデシジョンがルーチン的かどうかも区別できる。
これら二の観点の観点と歴史的な観点から、5つのケースが考えられる。
(1)歴史的ルーチン的/ルーチン的期待する/ルーチン的期待される: この場合、ゲームデザイナーは、プレイヤーを不満にせずに済んだのかもしれないのに、不満にしてしまったケースだと言える。プレイヤーは、ゲームデザイナーが何も分かってないと思うかもしれない。ただし、もちろん、全てのゲームプレイヤーを満足させることはできない。
(2)歴史的ルーチン的/ルーチン的期待する/ルーチン的でない期待される: この場合、ゲームデザイナーのゲームデザインに対する知識不足が原因で、プレイヤーを不満にさせてしまったケースだと言える。
(3)歴史的ルーチン的/ルーチン的でない期待する/ルーチン的期待される: この場合、(1)と同様であるが、プレイヤーの不満度合いは低いかもしれない。というのも、プレイヤーは、自身が提案する期待するデシジョンにより作られたゲームをプレイした経験がなく、妥当性を評価できていないためである。
(4)歴史的ルーチン的/ルーチン的でない期待する/ルーチン的でない期待される: この場合、(2)と同様であるが、単なる知識獲得だけでなく、適切なデシジョンを行う分析能力と創造性がゲームデザイナーに要求されるかもしれない。
(5)歴史的ルーチン的でない/ルーチン的でない期待する/ルーチン的でない期待される: この場合、不満を避けるのが最も困難だったケースだと言える。
この分析の不十分な点は、あるデシジョンに対して、どれだけのプレイヤーが不満を持っているのかを考慮していない点である。多くのプレイヤーが不満を持つほど、ゲームデザインの不適切さを意味する。
しかしながら、この5つのケースは、上から順に、プレイヤーとデザイナーの間でミスマッチが発生してはならない度合いの大まかな指針となる。
まとめ
この記事では、以下を主張した。
ゲームデザインにおけるデシジョン（決めたこと）には、ルーチン的なものとルーチン的でないなものが存在する。
ゲームプレイヤーが満足するようなゲームデザインは生み出すには、ルーチン的でないデシジョンを行うだけでなく、ルーチン的デシジョンを適切に行わなえなければならない。
参考
Gero, JS and Kannengiesser, U. Creative designing: An ontological view.
この記事を書くにあたっては、上記の論文を参考にした。特に、ルーチン的・ルーチン的でないという言葉はこの論文から拝借した。この論文では、ルーチン的でないは、さらに、革新的と創造的に区別されている。
ただし、この記事とこの論文では焦点が異なる。この記事では、プロセスの結果としてのデシジョンに着目しているが、論文ではデザインのプロセスの観点からも議論されている。
PR
更新履歴
2009.06.17: この記事の内容を修正して「ゲームデザインの理論」のドキュメントに追加しました。今後は、こちらのドキュメントを更新していきます。
-----
この記事では以下を主張する。
・ゲームプレイヤーは、ゲームデザインを合理的に評価するため、ゲームデザインのプロセスは、合理的なゲームデザインを創るためのプロセスである必要がある。
この主張は次の論理に基づく。
(1) ゲームプレイヤーは、ゲームデザインを合理的に評価する。
(1.1)あるプレイヤーは、合理的でないデザインを不満があるとして評価する。
(2)あるプレイヤーの不満を解消するには、合理的なゲームデザインが必要となる。
(3)ゲームデザインのプロセスは、合理的なゲームデザインを創れるプロセスである必要がある。
項目(1)の妥当性は、私が行っているゲームレビューの分析結果に基づく。
ゲームデザインのプロセス（活動）とは、ここでは、次のような側面に対する様々な決定を行うことだする。
（1）ゲームのルールの側面: キャラクターのレベルは上がる。レベル制限は99。戦闘はターン制であり、敵と見方が交互に行動を行う、など。
（1.1）ゲームバランスの側面： ある敵のHPは500といった、パラメータの設定など。
（2）ゲームシステムの側面: セーブ数は、10件など。
（2.1）ユーザインタフェースの側面: LボタンとRボタンでキャラクターの切り替えができるなど。
（2.2） システムの品質に関わる非機能要素の側面： たとえば、ロード時間に対する要求。3秒以内に戦闘画面を表示し、ユーザの入力を受け付けなければならない、など。
（3）ゲームの遊び方に関する側面: ゲーム中のBGMを自由に変更できるなど。
ゲームデザインとは、このプロセスの結果として決めたことの集合であるとする。
詳細は「ゲームデザインの理論」のドキュメントを参照。
gooの国語辞典によれば「合理的」とは次の意味を持つ。
(1) 論理にかなっているさま。因習や迷信にとらわれないさま。
(2) 目的に合っていて無駄のないさま。
ここでは、ゲームプレイヤーのゲームレビューを分析することで得られた観察から、ゲームプレイヤーはゲームデザインを合理的に評価することを示す。
NDSのRPGの一つである『セブンスドラゴン』のレビューでは、次のような不満があった。
・オートバトルの機能がない。
この不満は、この記事を書いている時点での全94件中７件あった。この不満は単なる機能不足を不満に思っているものもあるが、多くはプレイヤー個人の理由付けに基づいて不満となっている。以下にまとめる。
(a) オートバトルの機能がない（1/7件）。
(b) エンカウント率が高いため、バトルが多いのに、オートバトルの機能がない（3/7件）。
(c) LとRボタンが使われておらず空いているのに、オートバトルの機能が割り当てられていない（2/7件）。
(d) 過去のゲーム（ファミコン時代の『女神転生』と『世界樹の迷宮II』）では、オートバトルの機能があったのに、このゲームにはない(2/7件)。
項目(a)は、不満の理由が書かれていないため、合理的とは判断できない。
項目(b)は、オートバトル機能が何故必要となるのかの理由を挙げている。
項目(c)は、オートバトル機能の実現の容易性を挙げている。もし、LとRボタンが埋まっているなら、ゲームデザイナーはインタフェース上の新たな決定を行わなければならないが、空いているため、そうではない。
項目(d)は、オートバトル機能は新規性を伴うような実現の困難な機能ではないことを挙げていると推測できる。
もちろん、プレイヤーの不満には合理的との判断が難しいものも存在する。たとえば以下のような不満があった。
・職業選択式なのに転職できない。
この不満は、94件中1件あった。この不満には、以下の理由付けがされている。
・違う職業を使いたくなった場合、別キャラを1から育てなければいけない為、非常に手間がかかる。
しかし、この理由が合理的かどうかは以下のような疑問があるため判断が難しい。
・この理由が合理的であるとすると、職業選択式の場合、転職できることが必須となる。
・しかし、この不満は、94件中1件であり、多くのプレイヤーがこの不満の解消を望んでいるのかどうか分からない。
ここまでをまとめる。
(A) プレイヤーの不満には、以下が存在する。
(A1) 不満の理由付けがされているもの。「エンカウント率が高いため、バトルが多いのに、オートバトルの機能がない」
(A2) 不満の理由付けがされていないもの。「オートバトルの機能がない」
(B) 不満の理由付けがされたものには、以下が存在する。
(B1) 合理的な理由付けがされているもの。「エンカウント率が高いため、バトルが多いのに、オートバトルの機能がない」
(B2) 合理的でない、もしくは合理的と判断が難しいような理由付けがされているもの。「違う職業を使いたくなった場合、別キャラを1から育てなければいけない為、非常に手間がかかるのに、転職できない」
(C) 不満の理由付けは、個々のプレイヤーにより異なる観点から行われる。「エンカウント率が高いため、バトルが多いのに、オートバトルの機能がない」「 LとRボタンが使われておらず空いているのに、オートバトルの機能が割り当てられていない」
上記で書いたことをまとめるなら、
・あるプレイヤーは、合理的でないゲームデザインを不満があるとして評価する。
ということである。プレイヤーを満足させることがゲームデザインの目標であるとすると、これは、以下を意味する。
・あるプレイヤーにとって合理的でないゲームデザインから発生する不満を解消するには、合理的なゲームデザインが必要である。
したがって、ゲームデザインのプロセスに対する以下の要件があると考えられる。
・ゲームデザインのプロセスは、少なくとも、部分的には合理的なゲームデザインを創るプロセスである必要がある。
ここで「部分的に」としたのは、ゲームデザインの全ての部分、つまり、全てのデシジョン（決めたこと）が合理的である必要があるかは不明のためである。
ゲームデザインのプロセスは、ゲームデザイナーが決定を行うプロセス、つまり、意思決定のプロセスであるため、上記の要件を言い換えるなら、以下を意味する。
・ゲームデザイナーは、合理的な意思決定を行わなければならない。
ここで注意が必要なのは、ゲームプレイヤーとゲームデザイナーは異なるゲームデザインを評価するということである。ゲームプレイヤーは、ゲームデザイナーが行った全ての決定を知ることはできない、もしくは困難である。したがって、
・ゲームプレイヤーにとっては、ある不満に対する合理的な理由付けであっても、ゲームデザイナーにとっては、合理的でない可能性がある。
つまり、たとえば、「オートバトル機能の有無」では、「オートバトル機能が存在しない」のは、ゲームデザイナーが行った合理的な理由付けによるかもしれない。
また、ゲームデザイナーが合理的な決定を常に行うことは現実には困難であるということも注意が必要である。つまり、ゲームデザイナーは、合理的である最適なゲームデザインを生み出すのは困難である。というのは、最適である決定を行うために必要となる情報、認知能力、時間などの制約がゲームデザイナーには存在するためである。一般に、意思決定者がこのような制約のもとでしか意思決定を行えないことは、限定合理性（Bounded rationality）と呼ばれる。
ここまでをまとめると、ゲームプレイヤーにとってのゲームデザインの合理性の欠如から不満が発生する場合、以下がありえる。
(1) ゲームプレイヤーにとっては合理的なゲームデザインであるが、ゲームデザイナーにとっては合理的でないゲームデザイン
(2) ゲームプレイヤーにとっては合理的なゲームデザインであるが、ゲームデザイナーが合理的にできなかったゲームデザイン
項目(1)に関しては、以下が必要となる。
(a) ゲームプレイヤーを満足させることが目標である場合、ゲームデザイナーが妥協し、プレイヤーにとっての合理性を優先する。
項目(2)に関しては、以下が必要となる。
(b) ゲームデザイナーが合理的な決定を行えるように支援する仕組み。たとえば、ある決定（「バトル機能がある」「エンカウント率は高めである」）を行った場合、次にどんな決定を行うのが合理的なのか（「オートバトルの機能がある」）を提示するようなシステム。
この記事では、以下を主張した。
・ゲームプレイヤーは、ゲームデザインを合理的に評価するため、ゲームデザインのプロセスは、合理的なゲームデザインを創るためのプロセスである必要がある。
ゲームデザインは、ゲームデザイナーによって行われる。しかし、
・ゲームデザイナーが合理的な決定を行うのは容易でないため、ゲームデザイナーの決定を支援するような仕組みが必要である。
2009.06.17: この記事の内容を修正して「ゲームデザインの理論」のドキュメントに追加しました。今後は、こちらのドキュメントを更新していきます。
-----
この記事では以下を主張する。
・ゲームプレイヤーは、ゲームデザインを合理的に評価するため、ゲームデザインのプロセスは、合理的なゲームデザインを創るためのプロセスである必要がある。
この主張は次の論理に基づく。
(1) ゲームプレイヤーは、ゲームデザインを合理的に評価する。
(1.1)あるプレイヤーは、合理的でないデザインを不満があるとして評価する。
(2)あるプレイヤーの不満を解消するには、合理的なゲームデザインが必要となる。
(3)ゲームデザインのプロセスは、合理的なゲームデザインを創れるプロセスである必要がある。
項目(1)の妥当性は、私が行っているゲームレビューの分析結果に基づく。
ゲームデザインとは何か？
ゲームデザインのプロセス（活動）とは、ここでは、次のような側面に対する様々な決定を行うことだする。
（1）ゲームのルールの側面: キャラクターのレベルは上がる。レベル制限は99。戦闘はターン制であり、敵と見方が交互に行動を行う、など。
（1.1）ゲームバランスの側面： ある敵のHPは500といった、パラメータの設定など。
（2）ゲームシステムの側面: セーブ数は、10件など。
（2.1）ユーザインタフェースの側面: LボタンとRボタンでキャラクターの切り替えができるなど。
（2.2） システムの品質に関わる非機能要素の側面： たとえば、ロード時間に対する要求。3秒以内に戦闘画面を表示し、ユーザの入力を受け付けなければならない、など。
（3）ゲームの遊び方に関する側面: ゲーム中のBGMを自由に変更できるなど。
ゲームデザインとは、このプロセスの結果として決めたことの集合であるとする。
詳細は「ゲームデザインの理論」のドキュメントを参照。
ゲームデザインに対するゲームプレイヤーの合理的評価
gooの国語辞典によれば「合理的」とは次の意味を持つ。
(1) 論理にかなっているさま。因習や迷信にとらわれないさま。
(2) 目的に合っていて無駄のないさま。
ここでは、ゲームプレイヤーのゲームレビューを分析することで得られた観察から、ゲームプレイヤーはゲームデザインを合理的に評価することを示す。
NDSのRPGの一つである『セブンスドラゴン』のレビューでは、次のような不満があった。
・オートバトルの機能がない。
この不満は、この記事を書いている時点での全94件中７件あった。この不満は単なる機能不足を不満に思っているものもあるが、多くはプレイヤー個人の理由付けに基づいて不満となっている。以下にまとめる。
(a) オートバトルの機能がない（1/7件）。
(b) エンカウント率が高いため、バトルが多いのに、オートバトルの機能がない（3/7件）。
(c) LとRボタンが使われておらず空いているのに、オートバトルの機能が割り当てられていない（2/7件）。
(d) 過去のゲーム（ファミコン時代の『女神転生』と『世界樹の迷宮II』）では、オートバトルの機能があったのに、このゲームにはない(2/7件)。
項目(a)は、不満の理由が書かれていないため、合理的とは判断できない。
項目(b)は、オートバトル機能が何故必要となるのかの理由を挙げている。
項目(c)は、オートバトル機能の実現の容易性を挙げている。もし、LとRボタンが埋まっているなら、ゲームデザイナーはインタフェース上の新たな決定を行わなければならないが、空いているため、そうではない。
項目(d)は、オートバトル機能は新規性を伴うような実現の困難な機能ではないことを挙げていると推測できる。
もちろん、プレイヤーの不満には合理的との判断が難しいものも存在する。たとえば以下のような不満があった。
・職業選択式なのに転職できない。
この不満は、94件中1件あった。この不満には、以下の理由付けがされている。
・違う職業を使いたくなった場合、別キャラを1から育てなければいけない為、非常に手間がかかる。
しかし、この理由が合理的かどうかは以下のような疑問があるため判断が難しい。
・この理由が合理的であるとすると、職業選択式の場合、転職できることが必須となる。
・しかし、この不満は、94件中1件であり、多くのプレイヤーがこの不満の解消を望んでいるのかどうか分からない。
ここまでをまとめる。
(A) プレイヤーの不満には、以下が存在する。
(A1) 不満の理由付けがされているもの。「エンカウント率が高いため、バトルが多いのに、オートバトルの機能がない」
(A2) 不満の理由付けがされていないもの。「オートバトルの機能がない」
(B) 不満の理由付けがされたものには、以下が存在する。
(B1) 合理的な理由付けがされているもの。「エンカウント率が高いため、バトルが多いのに、オートバトルの機能がない」
(B2) 合理的でない、もしくは合理的と判断が難しいような理由付けがされているもの。「違う職業を使いたくなった場合、別キャラを1から育てなければいけない為、非常に手間がかかるのに、転職できない」
(C) 不満の理由付けは、個々のプレイヤーにより異なる観点から行われる。「エンカウント率が高いため、バトルが多いのに、オートバトルの機能がない」「 LとRボタンが使われておらず空いているのに、オートバトルの機能が割り当てられていない」
合理的なゲームデザインを創るゲームデザインプロセス
上記で書いたことをまとめるなら、
・あるプレイヤーは、合理的でないゲームデザインを不満があるとして評価する。
ということである。プレイヤーを満足させることがゲームデザインの目標であるとすると、これは、以下を意味する。
・あるプレイヤーにとって合理的でないゲームデザインから発生する不満を解消するには、合理的なゲームデザインが必要である。
したがって、ゲームデザインのプロセスに対する以下の要件があると考えられる。
・ゲームデザインのプロセスは、少なくとも、部分的には合理的なゲームデザインを創るプロセスである必要がある。
ここで「部分的に」としたのは、ゲームデザインの全ての部分、つまり、全てのデシジョン（決めたこと）が合理的である必要があるかは不明のためである。
ゲームデザインのプロセスは、ゲームデザイナーが決定を行うプロセス、つまり、意思決定のプロセスであるため、上記の要件を言い換えるなら、以下を意味する。
・ゲームデザイナーは、合理的な意思決定を行わなければならない。
ここで注意が必要なのは、ゲームプレイヤーとゲームデザイナーは異なるゲームデザインを評価するということである。ゲームプレイヤーは、ゲームデザイナーが行った全ての決定を知ることはできない、もしくは困難である。したがって、
・ゲームプレイヤーにとっては、ある不満に対する合理的な理由付けであっても、ゲームデザイナーにとっては、合理的でない可能性がある。
つまり、たとえば、「オートバトル機能の有無」では、「オートバトル機能が存在しない」のは、ゲームデザイナーが行った合理的な理由付けによるかもしれない。
また、ゲームデザイナーが合理的な決定を常に行うことは現実には困難であるということも注意が必要である。つまり、ゲームデザイナーは、合理的である最適なゲームデザインを生み出すのは困難である。というのは、最適である決定を行うために必要となる情報、認知能力、時間などの制約がゲームデザイナーには存在するためである。一般に、意思決定者がこのような制約のもとでしか意思決定を行えないことは、限定合理性（Bounded rationality）と呼ばれる。
ここまでをまとめると、ゲームプレイヤーにとってのゲームデザインの合理性の欠如から不満が発生する場合、以下がありえる。
(1) ゲームプレイヤーにとっては合理的なゲームデザインであるが、ゲームデザイナーにとっては合理的でないゲームデザイン
(2) ゲームプレイヤーにとっては合理的なゲームデザインであるが、ゲームデザイナーが合理的にできなかったゲームデザイン
項目(1)に関しては、以下が必要となる。
(a) ゲームプレイヤーを満足させることが目標である場合、ゲームデザイナーが妥協し、プレイヤーにとっての合理性を優先する。
項目(2)に関しては、以下が必要となる。
(b) ゲームデザイナーが合理的な決定を行えるように支援する仕組み。たとえば、ある決定（「バトル機能がある」「エンカウント率は高めである」）を行った場合、次にどんな決定を行うのが合理的なのか（「オートバトルの機能がある」）を提示するようなシステム。
まとめ
この記事では、以下を主張した。
・ゲームプレイヤーは、ゲームデザインを合理的に評価するため、ゲームデザインのプロセスは、合理的なゲームデザインを創るためのプロセスである必要がある。
ゲームデザインは、ゲームデザイナーによって行われる。しかし、
・ゲームデザイナーが合理的な決定を行うのは容易でないため、ゲームデザイナーの決定を支援するような仕組みが必要である。
この記事では、以下を主張する。
ゲームデザインのプロセスは、繰り返しのプロセスとして特徴付けられる。これは、ゲームデザイン上の決定（デシジョン）の変更が繰り返し必要になるということである。デシジョンの変更は、そのゲームをプレイするユーザの満足度に影響を与える。ゲームデザインのプロセスの目標の一つは、できる限り多くのユーザを満足させることであると考えられるため、デシジョンの変更によるユーザの満足度の変化の理解が重要になる。
この記事では、ゲームデザイン上のデシジョンの変更結果には、以下の二つがあることを述べる。
（1）あるユーザを満足させつつ、不満だった他のユーザも満足させるようなもの
（2）あるユーザを満足させずに、不満だった他のユーザを満足させるようなもの
ゲームデザインのプロセス（活動）とは、ここでは、次のような側面に対する様々な決定を行うことだする。
（1）ゲームのルールの側面: キャラクターのレベルは上がる。レベル制限は99。戦闘はターン制であり、敵と見方が交互に行動を行う、など。
（1.1）ゲームバランスの側面： ある敵のHPは500といった、パラメータの設定など。
（2）ゲームシステムの側面: セーブ数は、10件など。
（2.1）ユーザインタフェースの側面: LボタンとRボタンでキャラクターの切り替えができるなど。
（2.2） システムの品質に関わる非機能要素の側面： たとえば、ロード時間に対する要求。3秒以内に戦闘画面を表示し、ユーザの入力を受け付けなければならない、など。
（3）ゲームの遊び方に関する側面: ゲーム中のBGMを自由に変更できるなど。
ゲームデザインとは、このプロセスの結果として決めたことの集合であるとする。
NDSの『女神異聞録デビルサバイバー』のレビューの79件（2009/5/29時点）を分析した結果、以下の不満は2件あった。
所持金が99999マッカまでしか持てない
たったの2件の不満であるが、この実例をもとに考察していく。
この不満を解消する一つの方法は、99999より十分大きな値を設定するようにデシジョンを変更することである。たとえば、二桁増やして9999999などにする。
ここで着目したいことは、このデシジョンの変更は、他の77人（件）のユーザを満足させつつ、不満だった2人も満足させるだろうということである。
しかし、一般的には、変更後のデシジョンが、元々満足だったユーザを満足させたままとは限らない。そのため、デシジョンの変更結果は、ユーザ満足の保持するかどうかの観点から分類できる。
（１）ユーザ満足を保持するデシジョン変更： あるデシジョンＡからＢの変更は、デシジョンＡで満足していたユーザを満足させたまま、満足していなかった（一部の）ユーザを満足させる。
（２）ユーザ満足を保持しないデシジョン変更： あるデシジョンＡからＢの変更は、デシジョンＡで満足していた（一部の）ユーザを不満足にし、満足していなかった（一部の）ユーザを満足させる。この場合、ユーザ間に好みの衝突が発生したといえる。
この記事では、ゲームデザイン上のデシジョンの変更結果には、二つあることを主張した。この二つの分類がどんな意味を持つか？ 一つは、
（1）あるデシジョンの変更がどちらの種類に分類されるのかが十分に分析されず理解されていない
ということである。そのため、不十分なゲームデザインになりうる。
（a）ユーザ満足を保持するデシジョン変更であるのに、ユーザを不満足なままにしてしまう。
（b）ユーザ満足を保持しないデシジョン変更であるのに、元々満足であったユーザを不満足にしてしまう。
ある種のデシジョンは、一般的なデシジョンとして扱えると考えられる。たとえば、例としたマッカの最大値は、ＲＰＧのような所持金があるようなゲームでは、「所持金の最大値」に関するデシジョンとして一般化できる。このデシジョンは恐らくユーザ満足を保持するデシジョン変更として扱えるため、最大値はできる限り大きくしたほうがよい。
ただし、以下の考慮が必要である。
(A)あるデシジョンは他のデシジョンと依存関係を持つため、デシジョン間の関係を考慮して、デシジョンの構造としてユーザ満足の保持性を考える必要がある。たとえば、マッカの最大値が99999なのは、ユーザインタフェースを考慮してのことかもしれない。表示する桁数が増えるとユーザインタフェースに悪影響を与えるからかもしれない。
| ゲームデザイン上のデシジョンの変更結果には、以下の二つがある。 （1）あるユーザを満足させつつ、不満だった他のユーザも満足させるようなもの （2）あるユーザを満足させずに、不満だった他のユーザを満足させるようなもの |
ゲームデザインのプロセスは、繰り返しのプロセスとして特徴付けられる。これは、ゲームデザイン上の決定（デシジョン）の変更が繰り返し必要になるということである。デシジョンの変更は、そのゲームをプレイするユーザの満足度に影響を与える。ゲームデザインのプロセスの目標の一つは、できる限り多くのユーザを満足させることであると考えられるため、デシジョンの変更によるユーザの満足度の変化の理解が重要になる。
この記事では、ゲームデザイン上のデシジョンの変更結果には、以下の二つがあることを述べる。
（1）あるユーザを満足させつつ、不満だった他のユーザも満足させるようなもの
（2）あるユーザを満足させずに、不満だった他のユーザを満足させるようなもの
ゲームデザインとは何か？
ゲームデザインのプロセス（活動）とは、ここでは、次のような側面に対する様々な決定を行うことだする。
（1）ゲームのルールの側面: キャラクターのレベルは上がる。レベル制限は99。戦闘はターン制であり、敵と見方が交互に行動を行う、など。
（1.1）ゲームバランスの側面： ある敵のHPは500といった、パラメータの設定など。
（2）ゲームシステムの側面: セーブ数は、10件など。
（2.1）ユーザインタフェースの側面: LボタンとRボタンでキャラクターの切り替えができるなど。
（2.2） システムの品質に関わる非機能要素の側面： たとえば、ロード時間に対する要求。3秒以内に戦闘画面を表示し、ユーザの入力を受け付けなければならない、など。
（3）ゲームの遊び方に関する側面: ゲーム中のBGMを自由に変更できるなど。
ゲームデザインとは、このプロセスの結果として決めたことの集合であるとする。
ユーザ満足を保持するデシジョン変更と保持しないデシジョン変更
NDSの『女神異聞録デビルサバイバー』のレビューの79件（2009/5/29時点）を分析した結果、以下の不満は2件あった。
所持金が99999マッカまでしか持てない
たったの2件の不満であるが、この実例をもとに考察していく。
この不満を解消する一つの方法は、99999より十分大きな値を設定するようにデシジョンを変更することである。たとえば、二桁増やして9999999などにする。
ここで着目したいことは、このデシジョンの変更は、他の77人（件）のユーザを満足させつつ、不満だった2人も満足させるだろうということである。
しかし、一般的には、変更後のデシジョンが、元々満足だったユーザを満足させたままとは限らない。そのため、デシジョンの変更結果は、ユーザ満足の保持するかどうかの観点から分類できる。
（１）ユーザ満足を保持するデシジョン変更： あるデシジョンＡからＢの変更は、デシジョンＡで満足していたユーザを満足させたまま、満足していなかった（一部の）ユーザを満足させる。
（２）ユーザ満足を保持しないデシジョン変更： あるデシジョンＡからＢの変更は、デシジョンＡで満足していた（一部の）ユーザを不満足にし、満足していなかった（一部の）ユーザを満足させる。この場合、ユーザ間に好みの衝突が発生したといえる。
考察
この記事では、ゲームデザイン上のデシジョンの変更結果には、二つあることを主張した。この二つの分類がどんな意味を持つか？ 一つは、
（1）あるデシジョンの変更がどちらの種類に分類されるのかが十分に分析されず理解されていない
ということである。そのため、不十分なゲームデザインになりうる。
（a）ユーザ満足を保持するデシジョン変更であるのに、ユーザを不満足なままにしてしまう。
（b）ユーザ満足を保持しないデシジョン変更であるのに、元々満足であったユーザを不満足にしてしまう。
ある種のデシジョンは、一般的なデシジョンとして扱えると考えられる。たとえば、例としたマッカの最大値は、ＲＰＧのような所持金があるようなゲームでは、「所持金の最大値」に関するデシジョンとして一般化できる。このデシジョンは恐らくユーザ満足を保持するデシジョン変更として扱えるため、最大値はできる限り大きくしたほうがよい。
ただし、以下の考慮が必要である。
(A)あるデシジョンは他のデシジョンと依存関係を持つため、デシジョン間の関係を考慮して、デシジョンの構造としてユーザ満足の保持性を考える必要がある。たとえば、マッカの最大値が99999なのは、ユーザインタフェースを考慮してのことかもしれない。表示する桁数が増えるとユーザインタフェースに悪影響を与えるからかもしれない。
今まで、ゲームデザインについての定義や特徴付けを行ってきた。今回記事は、もっと根本的な、以下の疑問に答えてみたい。
コンピュータ（or ビデオ）ゲームとは何か？
より具体的には、
コンピュータゲームとは少なくとも何か？
という観点から考えてみたい。
得られた回答を基に、コンピュータゲームのデザインについての定義も再考する。
まず言えるのは、コンピュータゲームというのは、プロセスではなくプロダクトであるということである。別の言い方をするなら、コンピュータゲームは、人工物の一種である。
人工物とは、ある目的を達成するために作られたモノである。たとえば、ゴミ箱は、ゴミを入れておくためのものである。
コンピュータゲームとは、人を楽しませたり、面白くさせるためのものである。
このコンピュータゲームの定義では、不十分である。たとえば、人と人が向かい合って行うような将棋やチェスをコンピュータゲームとして分類してしまう。そこで、コンピュータゲームをソフトウェアの一種としてさらに分類する。
ここでは、デザインを「達成したい目的の集合」を満たすような機能を備える「人工物」を作るプロセスとして定義する。この定義は、従来のデザインの定義より広い意味で使っているため、受け入れにくいかもしれない。
次に、ソフトウェアのデザインについて考える。上の図と同様の考え方をするなら、ソフトウェアのデザインは次の図になる。
しかし、この図は、実際に我々がソフトウェアを作るプロセスの観点からは受け入れにくい部分がある。たとえば、ソフトウェアは、ソースコードをコンパイルするようなプロセスを含む。この場合、コンパイルのプロセスをソフトウェアデザインのプロセスの一部と見なしてしまう。
ここでは、コンパイルのようなプロセスをソフトウェアデザインのプロセスの一部でないと見なす。一部であるかどうかの基準は、ここでは、「達成したい目的の集合」を満たす「ソフトウェア」を作るにあたって、設計者の介入が必要かどうかであるとする。
この基準に従えば、コンパイルは、ソフトウェアデザインのプロセスの一部でない。なぜなら、このプロセスは設計者が介入しないからである。
改良した図は以下のようになる。
次に、コンピュータゲームデザインを考える。上の改良したソフトウェアデザインの図と同様の考え方をするなら、コンピュータゲームのデザインは次の図になる。
しかし、この図は、実際に我々がコンピュータゲームを作るプロセスの観点からは受け入れにくい部分がある。たとえば、ゲームプログラミングを、コンピュータゲーム用のソースコードを出力するプロセスであるとすると、ゲームプログラミングは、コンピュータゲームデザインのプロセスの一部となる。しかし、通常、プロダクトとしてのコンピュータゲームデザインを示すとき、ソースコードorより正確には、プログラムがどのように構成されているかは気にしない。たとえば、変数がどのように命名されているかどうかは、関係がない。
したがって、ここでは、コンピュータゲームデザインを二つのプロセスに分割する。分割前のプロセスを「コンピュータゲームソフトウェアデザイン」と呼ぶ。
二つのプロセスをそれぞれ「コンピュータゲームデザイン」と「コンピュータゲームプログラミング」と呼ぶ。
この二つのプロセスの間に存在するプロダクトを「コンピュータゲームデザイン」と呼ぶ。
コンピュータゲームデザインとは、人を楽しませたり、面白くさせるという目的を達成するために必要であるとして決定した事柄の集合である。
コンピュータ（or ビデオ）ゲームとは何か？
より具体的には、
コンピュータゲームとは少なくとも何か？
という観点から考えてみたい。
得られた回答を基に、コンピュータゲームのデザインについての定義も再考する。
コンピュータゲームとは何か？
まず言えるのは、コンピュータゲームというのは、プロセスではなくプロダクトであるということである。別の言い方をするなら、コンピュータゲームは、人工物の一種である。
人工物とは、ある目的を達成するために作られたモノである。たとえば、ゴミ箱は、ゴミを入れておくためのものである。
コンピュータゲームとは、人を楽しませたり、面白くさせるためのものである。
このコンピュータゲームの定義では、不十分である。たとえば、人と人が向かい合って行うような将棋やチェスをコンピュータゲームとして分類してしまう。そこで、コンピュータゲームをソフトウェアの一種としてさらに分類する。
コンピュータゲームのデザインとは何か？
人工物、ソフトウェア、コンピュータゲームの分類を基に、次に、デザイン（のプロセス）について考えたい。ここでは、デザインを「達成したい目的の集合」を満たすような機能を備える「人工物」を作るプロセスとして定義する。この定義は、従来のデザインの定義より広い意味で使っているため、受け入れにくいかもしれない。
次に、ソフトウェアのデザインについて考える。上の図と同様の考え方をするなら、ソフトウェアのデザインは次の図になる。
しかし、この図は、実際に我々がソフトウェアを作るプロセスの観点からは受け入れにくい部分がある。たとえば、ソフトウェアは、ソースコードをコンパイルするようなプロセスを含む。この場合、コンパイルのプロセスをソフトウェアデザインのプロセスの一部と見なしてしまう。
ここでは、コンパイルのようなプロセスをソフトウェアデザインのプロセスの一部でないと見なす。一部であるかどうかの基準は、ここでは、「達成したい目的の集合」を満たす「ソフトウェア」を作るにあたって、設計者の介入が必要かどうかであるとする。
この基準に従えば、コンパイルは、ソフトウェアデザインのプロセスの一部でない。なぜなら、このプロセスは設計者が介入しないからである。
改良した図は以下のようになる。
次に、コンピュータゲームデザインを考える。上の改良したソフトウェアデザインの図と同様の考え方をするなら、コンピュータゲームのデザインは次の図になる。
しかし、この図は、実際に我々がコンピュータゲームを作るプロセスの観点からは受け入れにくい部分がある。たとえば、ゲームプログラミングを、コンピュータゲーム用のソースコードを出力するプロセスであるとすると、ゲームプログラミングは、コンピュータゲームデザインのプロセスの一部となる。しかし、通常、プロダクトとしてのコンピュータゲームデザインを示すとき、ソースコードorより正確には、プログラムがどのように構成されているかは気にしない。たとえば、変数がどのように命名されているかどうかは、関係がない。
したがって、ここでは、コンピュータゲームデザインを二つのプロセスに分割する。分割前のプロセスを「コンピュータゲームソフトウェアデザイン」と呼ぶ。
二つのプロセスをそれぞれ「コンピュータゲームデザイン」と「コンピュータゲームプログラミング」と呼ぶ。
この二つのプロセスの間に存在するプロダクトを「コンピュータゲームデザイン」と呼ぶ。
コンピュータゲームデザインとは、人を楽しませたり、面白くさせるという目的を達成するために必要であるとして決定した事柄の集合である。
この前書いた「ゲームデザインの構造に対する制約」の内容を修正して、「ゲームデザインの理論」のドキュメントに追加しました。