済み
- ゲーム開発分野の前提（2008/5/31）：より多くの人に、より長い間遊んでもらいたい、というのは、ゲーム開発分野の前提条件だろうか？
- 設計問題の構造変化と解の構造変化（2008/4/15）：このことをデザインパターンの観点から考えてみると、複数の設計者のそのときの設計知識を基にして抽象化・一般化して記述されたのがパターンといってもいいきがする。したがって、オリジナルの筆者に加えて他の人がパターンの執筆に加わっていたとしたら、パターンの記述内容は変化する可能性がある。さらには、オリジナルの執筆者が後にパターン記述を見直したとき、記述内容は変化する可能性がある。とここまで書いた思ったのだけど、もしかするとパターンの品質とか妥当性の評価は、元々の記述内容が '変化しない度合い' によって測ることができるのか？ 元々のアレクサンザーのパターンの定義はここでは置いておくとして。各パターンが解決の対象とする設計問題があるとして、パターンはその問題への解を与える。一方で、その解は、問題を解決する解法候補の１つにすぎないともいえる。パターン解と代替案の違いの１つの側面は、解の安定性にあるのかもしれない。問題の状況が変化するとして、パターン解から代替案への変換の度合いと、代替案からパターン解の変改の度合いには違いがあるはず。 別の言葉で言えば、代替案からパターン解へのリファクタリングを行う度合いと、代替案からパターン解へのリファクタリングの度合いは異なるといえるきがする。この変換の度合いの違いは、恐らく問題空間の問題の変換の度合いの違いに関わってくると思う。とすると、設計問題Ａ－＞Ｂの変換と、設計問題Ｂ－＞Ａの変換の度合いが異なるのは何故だ？もっと一般的には、問題の変換のプロセスに、何か特徴があるのか？ たとえば、問題の（構造？）は複雑になっていくように変化していく、など。これは、リーマンのソフトウェア進化の法則からなんとなく言ってみただけだけど。再びソフトウェアの文脈でいいなおしてみると、要求仕様（ソフトウェアの機能・非機能、振る舞い）の変化、もしくは設計問題（ソフトウェアの構造、構造の品質）の変化を観察するとき、何か法則はあるのか？
- FBSでパターンの形成プロセスの説明（2008/3/31）：パターンの記述も人工物の一種だとしたら、そこにも設計プロセスが存在するとしてもいいかもしれない。で、John Geroさんが、ＦＢＳフレームワークという、一般的に設計プロセスを表現するための枠組みを提案しているので、これをつかってパターンの形成・構築・記述のプロセスを説明できるかもしれない、と思ったのであった。
- 設計原則のモデル（2008/1/27）:情報隠蔽を例として。
- パラメータとオペレータの例（2007/11/12）：パラメータが決まればオペレータが決まる。
- 設計手法と解の生成（2007/10/11）：フィールドを隠す
- 進化の単位（2007/10/8）：enumで定数追加の例
- ゲームデザインとソフトウェアデザイン（2007/9/9）：シレンの二刀流
- ゲームデザインでフィーチャダイアグラム（2007/9/29）
- パターンとして特定できるかどうかの重要性（2007/9/23）：Context
最終更新：2008年06月22日 23:19
