デビルサバイバーを結構プレイしたので、個人的感想を。一週目のラスボス手前でまだクリアしてないけど。
良い点は以下。
（1）合体検索のシステムが追加されたこと。便利だと思う。
（2）そこそこの高難易度。
（3）バトル->合体->バトルのサイクルが楽しい。
（4）EXTRA TURNは悪くないアイディア。
悪い点は以下。
（1）合体のインタフェースの劣化。悪魔の顔グラフィックはいらない。そのせいで表示できる悪魔数が減ってる。文字だけにして情報量増やすモードがあればよかった。
（2）プレイ時間が表示されない。ゲーム内容とは直接関係ないけど、何時間プレイしたかは気になる人なので欲しかった。
（3）オークションは微妙。オークションで購入できるのはいいとしても、システム的には対して楽しめる部分がない。
（4）ストーリーは微妙。後半ぐらいからは適当に読み飛ばした。
（5）弱い悪魔を育てにくい。まあ、今までのシリーズタイトルでもそうだったかもしれないけど、気に入った悪魔を最後まで連れて行くのが困難。モー・ショボーをレベル25まであげたけど、限界だった。
（6）選択肢はいっぱいでてくるけど、選択の影響がよくわからない。
（7）自動効果スキルを自由に更新・上書きできない。コマンドスキルはできるけど。もちろん、ゲームバランスとかてきには、今のままが適切だったのかもしれないけど。
（8）スキル数６個は少ないかも？ ８個がよかった。
（9）コマンドスキルと自動効果スキルは一緒の枠がよかったかも？
悪い点or改善してもらえると嬉しい点を結構挙げたけど、ゲームとしては楽しめてるので良いゲー。
良い点は以下。
（1）合体検索のシステムが追加されたこと。便利だと思う。
（2）そこそこの高難易度。
（3）バトル->合体->バトルのサイクルが楽しい。
（4）EXTRA TURNは悪くないアイディア。
悪い点は以下。
（1）合体のインタフェースの劣化。悪魔の顔グラフィックはいらない。そのせいで表示できる悪魔数が減ってる。文字だけにして情報量増やすモードがあればよかった。
（2）プレイ時間が表示されない。ゲーム内容とは直接関係ないけど、何時間プレイしたかは気になる人なので欲しかった。
（3）オークションは微妙。オークションで購入できるのはいいとしても、システム的には対して楽しめる部分がない。
（4）ストーリーは微妙。後半ぐらいからは適当に読み飛ばした。
（5）弱い悪魔を育てにくい。まあ、今までのシリーズタイトルでもそうだったかもしれないけど、気に入った悪魔を最後まで連れて行くのが困難。モー・ショボーをレベル25まであげたけど、限界だった。
（6）選択肢はいっぱいでてくるけど、選択の影響がよくわからない。
（7）自動効果スキルを自由に更新・上書きできない。コマンドスキルはできるけど。もちろん、ゲームバランスとかてきには、今のままが適切だったのかもしれないけど。
（8）スキル数６個は少ないかも？ ８個がよかった。
（9）コマンドスキルと自動効果スキルは一緒の枠がよかったかも？
悪い点or改善してもらえると嬉しい点を結構挙げたけど、ゲームとしては楽しめてるので良いゲー。
PR
疑問：優れたゲームデザインの構造には、何らかの繰り返し起こる特性があるのか？
前準備
上記の疑問に答えるには、まず、以下のような事柄に対する何らかの定義が必要です。
（1）ゲームデザインとは何か？
（2）ゲームデザインの構造とは何か？
（3）ゲームデザインの構造の特性とは何か？
（4）優れたゲームデザインの構造とは何か？
ゲームデザインとは何か？
ゲームデザインのプロセス（活動）とは、ここでは、次のような側面に対する様々な決定を行うことだとします。
（1）ゲームのルールの側面: キャラクターのレベルは上がる。レベル制限は99。戦闘はターン制であり、敵と見方が交互に行動を行う、など。
（1.1）ゲームバランスの側面： 敵のパラメータ設定など。
（2）ゲームシステムの側面: セーブ数は、10件など。
（2.1）ユーザインタフェースの側面: LボタンとRボタンでキャラクターの切り替えができるなど。
（2.2） システムの品質に関わる非機能要素の側面： たとえば、ロード時間に対する要求。3秒以内に戦闘画面を表示し、ユーザの入力を受け付けなければならない、など。
（3）ゲームの遊び方に関する側面: ゲーム中のBGMを自由に変更できるなど。
ゲームデザインとは、このプロセスの結果として決めたことの集合であるとします。
ゲームデザインの構造とは何か？
ゲームデザインとは、決めたことの集合であるとしました。決めたことは、独立しているのではなく、他の決めたことと関係を持ちます。たとえば「レベル制限は99」という決定は「キャラクターのレベルは上がる」という決定がまずなされていなければなりません。
ここでは、ゲームデザインの構造とは、決めたこと（構造要素）とその間の関係からなる概念だとします。
ゲームデザインの構造の特性とは何か？
構造が得られたのなら、構造から何らかの性質・特性を考察することができます。たとえば、ある決めたことは、決めたことの多くとの関係を持つかもしれません。他の分野での例を挙げるなら、たとえば、建物と建物の間の関係です。駅の周辺にある建物の種類や数は、病院の周辺にある建物の種類や数とは異なると考えられます。
優れたゲームデザインの構造とは何か？
優れていると見なされるゲームデザインの構造には、共通の特性があるかもしれません。
この疑問に答えるには、以下の順序での分析が必要です。
（1）優れている、優れていないに関わらず、個々のゲームのデザインがどのような構造を持つのか、そして、その構造からどのような特性が得られるのか。
（2）得られた特性は、繰り返し起こるような共通性があるのか。
構造特性の例：対称性（シンメトリー）
対称性とは、Wikipediaによると次のような性質です。
対称性（たいしょうせい）、又はシンメトリー(Symmetry)とは、ある変換に関して不変である性質のことを言う。この例では、ゲームデザインの構造には、（局所的な）対称性があるかもしれないということを議論します。
例とするのは、ゲームでの呪文・魔法・スキルの要素です。たとえば、ドラクエでは「メラ」、FFでは「ファイア」、女神転生シリーズでは「アギ」などです。
これらある種の呪文・魔法・スキルで共通する点として、以下の二つに着目したいと思います。
（1）属性でグループ化されている。たとえば、炎系、氷系、雷系など。
（2）威力の観点から段階的な関係がある。たとえば、メラ、メラミ、メラゾーマ。
これらの点が、要素間の関係性となります。したがって、構造を形成します。
具体的には、たとえばペルソナ4では以下です。
| アギ系 | ブフ系 | ジオ系 | ガル系 |
| アギ | ブフ | ジオ | ガル |
| アギラオ | ブフーラ | ジオンガ | ガルーラ |
| アギダイン | ブフダイン | ジオダイン | ガルダイン |
| ラグナロク | ニブルヘイム | 真理の雷 | 万物流転 |
FF5では以下です。
| ファイア系 | ブリザド系 | サンダー系 |
| ファイア | ブリザド | サンダー |
| ファイラ | ブリザラ | サンダラ |
| ファイガ | ブリザガ | サンダガ |
ドラクエ5では以下です。
| メラ系 | ギラ系 | イオ系 | ヒャド系 | バギ系 |
| メラ | ギラ | イオ | ヒャド | バギ |
| メラミ | ベギラマ | イオラ | ヒャダルコ | バギマ |
| メラゾーマ | ベギラゴン | イオナズン | マヒャド | バギクロス |
一方で、ドラクエ4では以下です。
| メラ系 | ギラ系 | イオ系 | ヒャド系 | バギ系 |
| メラ | ギラ | イオ | ヒャド | バギ |
| メラミ | ベギラマ | イオラ | ヒャダルコ | バギマ |
| メラゾーマ | ベギラゴン | イオナズン | ヒャダイン | バギクロス |
| マヒャド |
構造の特性の観点から、考察したいのは、なぜ以下の事実があるのかという点です。
（1）ペルソナ4、FF5、ドラクエ5では、ある属性に含まれる魔法の数が同じである。それぞれ、４個、３個、４個。
（2）ドラクエ4では、ヒャド系だけが、４個でなく、５個の魔法がある。
（3）ドラクエ5では、ヒャド系が他の属性の数と同じに変更されている。
この観察はある意味では、正しくありません。なぜなら、観察対象とする魔法の属性を制限しているためです。たとえば、ザキ系には、ザキとザラキの二つしかありません。とはいえ、ザキ系が、大きなグループとしてのメラ系、ギラ系、イオ系、ヒャド系、バギ系とは異なり、このグループに属さないというのは直感的に正しく思えます。この点については別の記事で考察します。
これらペルソナ、FF、ドラクエは単なる例です。後に、一般的な考察をするために、以下では、先ほどの表を次のように簡略化した図で議論したいと思います。
この図では、丸い図が、魔法・呪文を表します（なお、ドラクエ5については省略しました）。今回の議論では、以下の部分を抽象化（情報のフィルタリング）しています。
・威力の関係： 各魔法は、威力ごとに丸の大きさを変化させるのではなく、全て同じ大きさで表現しています。
・属性間の関係： 各属性を四角や三角で区別することなく丸で表現しています。
対称性が観察できるのは、ある属性からある属性への横の関係を見た場合です。ペルソナ4やFF5では、属性の位置を横にずらしても、丸は変わりません。たとえば、「アギ系、ブフ系、ジオ系、ガル系」を「ガル系、アギ系、ブフ系」として横にずらしても、丸の図の部分は同じです。
一方で、非対称性があるのは、ドラクエ4です。横に一つずらすと、異なる図になります。
少し分かりにくいので、図自体を変更してみます。
一般化した図で、対象性・非対称性を含む構造を持つゲームデザイン構造を表すと次のようになります。
対称性の構造を持つゲームをデザインする
図で示したような特性を、対称性と呼んでいいのかは議論の余地があるかもしれません。しかし、何と呼ぼうとも、ゲームデザインの構造上の可変な部分として図で示したような特性があるのは事実です。また、恐らく現在の多くのRPGなどのゲームが、魔法・呪文・スキルについては、対称性を持つようにデザインされているのではないかと思います。
このことからは、次の疑問を生みます。
（1）魔法・呪文・スキルについて、現在の多くのゲームデザインが対称性を備えているのは、何か合理的な理由があるのか？ 何らかの原理に基づいているのか？
（2）面白い・優れている（といわれる）ゲームのデザインは、魔法・呪文・スキルについて対称性を備えているのか？
（3）魔法・呪文・スキルといった部分的な構造だけでなく、ゲームデザインの構造の全てが、対称性もしくは、非対称性のどちらかを備えているべきなのか？
おまけ：参考文献
この記事を書くにあたっては、Christopher Alexander さんの『The Nature of Order』という本を意識しました。この本によれば、生き生きとしたモノ（建物のような人工物と生き物）は、次のような、15の構造上の特性を備えるとしています。
1. LEVELS OF SCALE
2. STRONG CENTERS
3. BOUNDARIES
4. ALTERNATING REPETITION
5. POSITIVE SPACE
6. GOOD SHAPE
7. LOCAL SYMMETRIES
8. DEEP INTERLOCK AND AMBIGUITY
9. CONTRAST
10. GRADIENTS
11. ROUGHNESS
12. ECHOES
13. THE VOID
14. SIMPLICITY AND INNER CALM
15. NON-SEPARATENESS
7番目のLOCAL SYMMETRIESが今回の記事の議論と関係します。
ゲームデザインについてのすごく基本的（当たり前）な前提を構築しながら、ゲームデザインの理論化を目指していきたい。
今回は、ゲームデザインの一つの側面は、ゲームをプレイするユーザ間の好みの衝突を解消するプロセスである、ということを考えたい。
その前に、まず、ゲームデザインとは何か、ということについての定義をしておきたい。
ゲームデザインのプロセス（活動）とは、ここでは、次のような側面に対する様々な決定を行うことだとする。
（1）ゲームのルールの側面: キャラクターのレベルは上がる。レベル制限は99。戦闘はターン制であり、敵と見方が交互に行動を行う、など。
（1.1）ゲームバランスの側面： 敵のパラメータ設定など。
（2）ゲームシステムの側面: セーブ数は、10件など。
（2.1）ユーザインタフェースの側面: LボタンとRボタンでキャラクターの切り替えができるなど。
（2.2） システムの品質に関わる非機能要素の側面： たとえば、ロード時間に対する要求。3秒以内に戦闘画面を表示し、ユーザの入力を受け付けなければならない、など。
（3）ゲームの遊び方に関する側面: ゲーム中のBGMを自由に変更できるなど。
ゲームデザインとは、このプロセスの結果として決めたことの集合であるとする。
まず、次の前提があるとしたい。
（前提1） できる限り面白いゲームを作ることがゲームデザインの目的である。
もちろん、現実的には、面白いという評価基準のみでゲームをデザインすることはできない。コストや時間の制約があるため、これらの制約を無視して面白さのみを追求することはできない。けれど、ここではこの制約は無視する。
（前提2） あるゲームの面白さの度合いを評価するのは、そのゲームをプレイした時の特定のユーザである。
続いて、次のような仮定をする。
（仮定1） 特定の誰かのみのために ゲームを作るとする
この場合、ゲームの面白さは、この特定の誰かが評価する。評価結果は、次の二つとなる。
（評価結果1） 面白い、もしくは、面白くないところはない
（評価結果2） 面白しろくない
1の場合、ゲームデザインのプロセスは終了となる。
2の場合、次のことが行える。
(評価対応a) 悪いと指摘された部分を修正する
(評価対応b) 面白くなることを期待して修正する
修正後は、評価のプロセスに戻る。
続いて、仮定を少し変更してみる。
（仮定2） 特定の二人（AさんとBさん）のために ゲームを作るとする
この場合、仮定1のようなプロセスは行えなくなる。まず、評価のプロセスでは、4つの評価結果が考えられる。
（評価結果1） AさんBさんとも、面白い、もしくは、面白くないところはない。
（評価結果2） Aさんは、面白い、もしくは、面白くないところはない。Bさんは、面白しろくない。
（評価結果3） Bさんは、面白い、もしくは、面白くないところはない。Aさんは、面白しろくない。
（評価結果4） Aさんも、Bさんも面白しろくない。
1の場合、ゲームデザインのプロセスは終了となる。
2の場合、次の対応が考えられる。
（評価対応2-a) Bさんに悪いと指摘された部分を修正する
（評価対応2-b) Bさんに面白くなることを期待して修正する
3の場合、次の対応が考えられる。
(評価対応3-a) Aさんに悪いと指摘された部分を修正する
(評価対応3-b) Aさんに面白くなることを期待して修正する
4の場合、次の対応が考えられる。
(評価対応4-a) AさんやBさんに悪いと指摘された部分を修正する
(評価対応4-b) AさんやBさんに面白くなることを期待して修正する
仮定1の場合と違い、たとえば、対応2（Bさんが面白くなるように修正）の場合の修正後の評価は、次のようになる。
（修正後評価結果1） Aさんは面白いままであり、Bさんは面白しろくなった
Aさん：面白い->面白い（もしくは面白い部分が増えた）
Bさん：面白くない->面白い（もしくは、面白くなかった部分が減った）
（修正後評価結果2） Bさんは面白くないまま
Aさん：面白い->面白い（もしくは面白い部分が増えた）
Bさん：面白くない->面白くない（もしくは、面白くなかった部分が増えた）
（修正後評価結果3） Bさんは面白くなったが、Aさんは面白くなくなった
Aさん：面白い->面白くない（もしくは面白かった部分が減った）
Bさん：面白くない->面白い（もしくは、面白くなかった部分が減った）
（修正後評価結果4） Bさんは面白くないままであり、かつ、Aさんは面白くなくなった
Aさん：面白い->面白くない（もしくは面白かった部分が減った）
Bさん：面白くない->面白くない（もしくは、面白くなかった部分が増えた）
この3番目の項目から分かるように、AさんとBさんの面白さの好みが異なる場合、好みの衝突を解消し、AさんとBさんを同時に満足させるようなゲームデザインの提案は簡単でなくなる。
現実的には、ゲームのプレイする対象が二人というように少ないことはありえないため、衝突の解消はさらに困難となる。
しかし、ある種のこのような好みの衝突はゲームデザイン上の決定として解消できる場合がある。既存のゲームでの代表的な解消方法としては、ユーザ自身が自分の好みを選択できるような機能の導入がある。たとえば、難易度が選択できる機能、特定の機能（たとえば音声）のオン・オフを選択できる機能などがある。
以上のことから、ゲームデザインの一つの側面は、ゲームをプレイするユーザ間の好みの衝突を解消するプロセスである、といえる。
今回は、ゲームデザインの一つの側面は、ゲームをプレイするユーザ間の好みの衝突を解消するプロセスである、ということを考えたい。
その前に、まず、ゲームデザインとは何か、ということについての定義をしておきたい。
ゲームデザインのプロセスとは
ゲームデザインのプロセス（活動）とは、ここでは、次のような側面に対する様々な決定を行うことだとする。
（1）ゲームのルールの側面: キャラクターのレベルは上がる。レベル制限は99。戦闘はターン制であり、敵と見方が交互に行動を行う、など。
（1.1）ゲームバランスの側面： 敵のパラメータ設定など。
（2）ゲームシステムの側面: セーブ数は、10件など。
（2.1）ユーザインタフェースの側面: LボタンとRボタンでキャラクターの切り替えができるなど。
（2.2） システムの品質に関わる非機能要素の側面： たとえば、ロード時間に対する要求。3秒以内に戦闘画面を表示し、ユーザの入力を受け付けなければならない、など。
（3）ゲームの遊び方に関する側面: ゲーム中のBGMを自由に変更できるなど。
ゲームデザインとは、このプロセスの結果として決めたことの集合であるとする。
好みの衝突解消プロセスとしてのゲームデザイン
まず、次の前提があるとしたい。
（前提1） できる限り面白いゲームを作ることがゲームデザインの目的である。
もちろん、現実的には、面白いという評価基準のみでゲームをデザインすることはできない。コストや時間の制約があるため、これらの制約を無視して面白さのみを追求することはできない。けれど、ここではこの制約は無視する。
（前提2） あるゲームの面白さの度合いを評価するのは、そのゲームをプレイした時の特定のユーザである。
続いて、次のような仮定をする。
（仮定1） 特定の誰かのみのために ゲームを作るとする
この場合、ゲームの面白さは、この特定の誰かが評価する。評価結果は、次の二つとなる。
（評価結果1） 面白い、もしくは、面白くないところはない
（評価結果2） 面白しろくない
1の場合、ゲームデザインのプロセスは終了となる。
2の場合、次のことが行える。
(評価対応a) 悪いと指摘された部分を修正する
(評価対応b) 面白くなることを期待して修正する
修正後は、評価のプロセスに戻る。
続いて、仮定を少し変更してみる。
（仮定2） 特定の二人（AさんとBさん）のために ゲームを作るとする
この場合、仮定1のようなプロセスは行えなくなる。まず、評価のプロセスでは、4つの評価結果が考えられる。
（評価結果1） AさんBさんとも、面白い、もしくは、面白くないところはない。
（評価結果2） Aさんは、面白い、もしくは、面白くないところはない。Bさんは、面白しろくない。
（評価結果3） Bさんは、面白い、もしくは、面白くないところはない。Aさんは、面白しろくない。
（評価結果4） Aさんも、Bさんも面白しろくない。
1の場合、ゲームデザインのプロセスは終了となる。
2の場合、次の対応が考えられる。
（評価対応2-a) Bさんに悪いと指摘された部分を修正する
（評価対応2-b) Bさんに面白くなることを期待して修正する
3の場合、次の対応が考えられる。
(評価対応3-a) Aさんに悪いと指摘された部分を修正する
(評価対応3-b) Aさんに面白くなることを期待して修正する
4の場合、次の対応が考えられる。
(評価対応4-a) AさんやBさんに悪いと指摘された部分を修正する
(評価対応4-b) AさんやBさんに面白くなることを期待して修正する
仮定1の場合と違い、たとえば、対応2（Bさんが面白くなるように修正）の場合の修正後の評価は、次のようになる。
（修正後評価結果1） Aさんは面白いままであり、Bさんは面白しろくなった
Aさん：面白い->面白い（もしくは面白い部分が増えた）
Bさん：面白くない->面白い（もしくは、面白くなかった部分が減った）
（修正後評価結果2） Bさんは面白くないまま
Aさん：面白い->面白い（もしくは面白い部分が増えた）
Bさん：面白くない->面白くない（もしくは、面白くなかった部分が増えた）
（修正後評価結果3） Bさんは面白くなったが、Aさんは面白くなくなった
Aさん：面白い->面白くない（もしくは面白かった部分が減った）
Bさん：面白くない->面白い（もしくは、面白くなかった部分が減った）
（修正後評価結果4） Bさんは面白くないままであり、かつ、Aさんは面白くなくなった
Aさん：面白い->面白くない（もしくは面白かった部分が減った）
Bさん：面白くない->面白くない（もしくは、面白くなかった部分が増えた）
この3番目の項目から分かるように、AさんとBさんの面白さの好みが異なる場合、好みの衝突を解消し、AさんとBさんを同時に満足させるようなゲームデザインの提案は簡単でなくなる。
現実的には、ゲームのプレイする対象が二人というように少ないことはありえないため、衝突の解消はさらに困難となる。
しかし、ある種のこのような好みの衝突はゲームデザイン上の決定として解消できる場合がある。既存のゲームでの代表的な解消方法としては、ユーザ自身が自分の好みを選択できるような機能の導入がある。たとえば、難易度が選択できる機能、特定の機能（たとえば音声）のオン・オフを選択できる機能などがある。
以上のことから、ゲームデザインの一つの側面は、ゲームをプレイするユーザ間の好みの衝突を解消するプロセスである、といえる。
いまだに、不思議のダンジョン系のゲームをしつこく開発中。目的の一つは、ゲーム開発とはどのような活動なのかを知ること。この記事では、ゲームデザインの変化過程or進化の履歴からゲームデザインに役立つ何かを考察したい。
ゲームデザインの活動とは、ここでは、次のような側面に対する様々な決定を行うことだとする。
（1）ゲームのルールの側面: キャラクターのレベルは上がる。レベル制限は99。戦闘はターン制であり、敵と見方が交互に行動を行う、など。
（1.1）ゲームバランスの側面： 敵のパラメータ設定など。
（2）ゲームシステムの側面: セーブ数は、10件など。
（2.1）ユーザインタフェースの側面: LボタンとRボタンでキャラクターの切り替えができるなど。
（2.2） システムの品質に関わる非機能要素の側面： たとえば、ロード時間に対する要求。3秒以内に戦闘画面を表示し、ユーザの入力を受け付けなければならない、など。
（3）ゲームの遊び方に関する側面: ゲーム中のBGMを自由に変更できるなど。
ゲームデザインとは、この活動の結果として決めたことの集合であるとする。
実際、昨日遭遇した仕様orゲームデザインorゲームのルールの変化は、次のようなもの。
・変更前： ダンジョン生成時に、罠は、部屋のどこかにランダムに配置される。
・変更後： ダンジョン生成時に、罠は、部屋の入り口を除いて、部屋のどこかにランダムに配置される。
分かりやすいように図を描いてみた。
このことから次の疑問を考えたい。
ルール変更の妥当性： このルールの変更の妥当性は？ なぜルールを変更した？
ルールの変更理由は、入り口に罠があると理不尽に思えたから。快適性を下がると思ったから。
もちろん、この変更理由は、僕の主観的な判断による。ある人は、変更前を好むかもしれないし、他の人は、変更後を好むかもしれない。
（1）ゲームルールとゲームユーザと品質： ルールの変更は、ある時点でのあるユーザが感じる品質に影響を与える。
（2）ゲームデザイン原則の適用： ルールの変更には、妥当性or原則に従っていることが望まれる。ここでは、ゲームデザインの原則とは、ゲームデザイン上の選択肢からある決定を行う際に、どの選択肢を選択するのが多くの場合に適切なのかを示すガイドラインであるとする。ゲームルールAとBではどちらが適切か。
（3）システムによる多様なゲームルールのサポート： 1の項目からは、ゲームの品質は、個々のゲームユーザに依存することが分かる。ゲームユーザのある集合は、ルールAを好み、他のユーザの集合は、ルールBを好む。さらには、他のユーザは、ゲームデザイナが想像していなかったような他のルールを好む。
もし、ルール集合の中からどれか一つだけを選択しなければならないとするなら、選択されなかったルールを好むユーザを満足させることができなくなる。一方で、ルールの集合の中から、ユーザが自分に適したルールを選べるような機能の導入をシステム上の決定として行えば、多くのユーザを満足させられる可能性が出る。
この考え方は、シンプルであるが、実際の商用のゲームでこのような多様性or可変性がゲームに十分に導入されているとはいえない。理由の一つは、このような可変性をソフトウェアの技術の観点からサポートするのが容易ではない点があげられる。
ゲームデザインとは
ゲームデザインの活動とは、ここでは、次のような側面に対する様々な決定を行うことだとする。
（1）ゲームのルールの側面: キャラクターのレベルは上がる。レベル制限は99。戦闘はターン制であり、敵と見方が交互に行動を行う、など。
（1.1）ゲームバランスの側面： 敵のパラメータ設定など。
（2）ゲームシステムの側面: セーブ数は、10件など。
（2.1）ユーザインタフェースの側面: LボタンとRボタンでキャラクターの切り替えができるなど。
（2.2） システムの品質に関わる非機能要素の側面： たとえば、ロード時間に対する要求。3秒以内に戦闘画面を表示し、ユーザの入力を受け付けなければならない、など。
（3）ゲームの遊び方に関する側面: ゲーム中のBGMを自由に変更できるなど。
ゲームデザインとは、この活動の結果として決めたことの集合であるとする。
ゲームルールの変更例
実際、昨日遭遇した仕様orゲームデザインorゲームのルールの変化は、次のようなもの。
・変更前： ダンジョン生成時に、罠は、部屋のどこかにランダムに配置される。
・変更後： ダンジョン生成時に、罠は、部屋の入り口を除いて、部屋のどこかにランダムに配置される。
分かりやすいように図を描いてみた。
このことから次の疑問を考えたい。
ルール変更の妥当性： このルールの変更の妥当性は？ なぜルールを変更した？
ゲームルールの変更理由
ルールの変更理由は、入り口に罠があると理不尽に思えたから。快適性を下がると思ったから。
もちろん、この変更理由は、僕の主観的な判断による。ある人は、変更前を好むかもしれないし、他の人は、変更後を好むかもしれない。
考察
（1）ゲームルールとゲームユーザと品質： ルールの変更は、ある時点でのあるユーザが感じる品質に影響を与える。
（2）ゲームデザイン原則の適用： ルールの変更には、妥当性or原則に従っていることが望まれる。ここでは、ゲームデザインの原則とは、ゲームデザイン上の選択肢からある決定を行う際に、どの選択肢を選択するのが多くの場合に適切なのかを示すガイドラインであるとする。ゲームルールAとBではどちらが適切か。
（3）システムによる多様なゲームルールのサポート： 1の項目からは、ゲームの品質は、個々のゲームユーザに依存することが分かる。ゲームユーザのある集合は、ルールAを好み、他のユーザの集合は、ルールBを好む。さらには、他のユーザは、ゲームデザイナが想像していなかったような他のルールを好む。
もし、ルール集合の中からどれか一つだけを選択しなければならないとするなら、選択されなかったルールを好むユーザを満足させることができなくなる。一方で、ルールの集合の中から、ユーザが自分に適したルールを選べるような機能の導入をシステム上の決定として行えば、多くのユーザを満足させられる可能性が出る。
この考え方は、シンプルであるが、実際の商用のゲームでこのような多様性or可変性がゲームに十分に導入されているとはいえない。理由の一つは、このような可変性をソフトウェアの技術の観点からサポートするのが容易ではない点があげられる。