マネジメントのような社会科学では、前提や仮定がそのままパラダイム（支配的な一般理論）となる。それらの前提は、学者、評論家、教師、実務家が無意識のうちにもつ。それが、彼らにとっての現実、その分野における現実となる。現実を規定する。それどころか、その分野が何についてのものであるかさえ規定する。さらには、排除すべきもの、無視すべきものを規定する。
P.F. ドラッカー, 明日を支配するもの―21世紀のマネジメント革命
ゲーム開発には、社会科学の側面があるかもしれないし、ないかもしれない。ないとしても、前提を考えてみるのは重要かもしれない。
疑問： ゲームを開発する上での前提は何だろうか？
この記事では、より具体的に、次の疑問を考えたい。
疑問： より多くの人に、より長い間遊んでもらえるゲームを作る、というのはゲームを開発する上での前提だろうか？
一つ目の前提、より多くの人に遊んでもらえる、楽しんでもらえるゲームを作るというのは、そのままの意味である。
この図では、あるゲームをより多くの人が楽しめるようにするという改善・修正活動は、そのゲームのデザインに適用されるとして表している。ゲームデザインとは、このゲームを作るために決定された結果の集合だと考えている。たとえば、RPGでいえば、LVのあがりやすさのパラメータの調整や、ゲームのテンポ、ユーザインタフェースに関する決定結果を意味する。
二つ目の前提、より長い間遊んでもらえる、楽しんでもらえるゲームを作るというのは、ゲームのクリアに必要な時間ではなく、ゲームを自由にプレイすることを意味する。コンピュータゲームでないゲーム、たとえば将棋は一回の対局で終わりでない。同じように、コンピュータゲームも一度クリアし、エンディングに到達したとしても、楽しみ方が残されていればまだ遊ぶことができる。
「より多くの人に、より長い間遊んでもらえるゲームを作る」を前提とし、「楽しめる人の数」と「楽しめる時間」を軸にして図で表すとこうなる。
この図に基づいて考えると、大雑把には、あるゲームのデザイン状態は次の4つのどれかに当てはまる。
| 楽しめる人の数 | 楽しめる時間 | |
| 理想でないゲーム | 少ない | 短い |
| まだ理想でないゲーム | 少ない | 長い |
| まだ理想でないゲーム | 多い | 短い |
| 理想とするゲーム | 多い | 長い |
もちろん、何人以上もしくは何時間以上あればある状態であるという一般的な基準はない。さらには、あるゲームのデザイン状態から、楽しめる人の数や楽しめる時間のデータを取ること自体も容易ではない。そのため、以前の状態よりより多くの人が楽しめるようになったのか、より長く楽しめるようになったかの比較も容易ではない。
この二つの前提が意味するのは、状態の意図的な変換の向きが決まっているということだといえる。ここで意図的と書いたのは、状態のデータ（楽しめる人の数や楽しめる時間）を得ることは容易でないため、意図しない逆の変換が行われる可能性があるからである。
意図的な変換の向きには、二つある。
（1）楽しめる人の数を増やす変換
（2）楽しめる時間を長くする変換
では、これらの二つの変換の妥当性は何か。言い換えれば、二つの前提は妥当な前提か。妥当でないとするなら、図で表すとこうなる。
この場合、意図的な変換の向きは4つになる。
（1）楽しめる人の数を増やす変換
（2）楽しめる人の数を減らす変換
（3）楽しめる時間を長くする変換
（4）楽しめる時間を短くする変換
次の記事では、これら変換の意味する観点から、ゲーム開発での前提を考えたい。さらには、他の軸がどうかどうかについても考えたい。
PR
「Working IEEE/IFIP Conference on Software Architecture (WICSA) 2008」というカンファレンスでのキーノートに次のものがあるっぽい。
アブストラクトはこんな感じらしい。
カンファレンスは、２月の18日から22日まで開催。開催後、キーノートのプレゼンスライドが公開されるかもしれないので忘れないでチェック。
Software Architecture in Game Development
Andrew Brownsword
Chief Architect, Electronic Arts
アブストラクトはこんな感じらしい。
abstract: Video games have now existed in various forms for over 30 years, and have evolved from humble beginnings into remarkably complex software projects. The ever present emphasis on an immersive audio/visual experience has put game developers in the position of being on the bleeding edge of exploring the performance of modern consumer hardware. This talk will discuss the elements that make up a contemporary video game, the software processes that are involved in development, key challenges, and look at some important design patterns that form the architectural basis.
カンファレンスは、２月の18日から22日まで開催。開催後、キーノートのプレゼンスライドが公開されるかもしれないので忘れないでチェック。
今趣味で作ってるゲームを実例として、ゲーム開発での仕様変更にはどんなものがあるのかを考えてみたい。
昨日作っていてどんな仕様変更があったかというと「ＢＧＭを今まではmidiファイルで鳴らしてたんだけど、mp3のファイルでも鳴らせるように」という変更。
この事例を使って、次の疑問を考えてきたい。
疑問1：この仕様変更は、どこ（誰）から来たのか？
疑問2：この仕様変更は、なぜ起こったのか？
さて、ゲームより一般的なソフトウェアの場合、仕様の変更は次のような理由で起こる[1]。
（1）ステークホルダが要求文書をレビューする。何か新しいものへの欲求が引き出される。
（2）ステークホルダがシステムの使い方を覚える。何か新しいものへの欲求が引き出される。
（3）ステークホルダがプロトタイプを触ってみる。何か新しいものへの欲求が引き出される。
（4）システムが使われる状況が変わる。たとえば、ユーザ数が増えるなど。
（5）顧客は、現在のシステムのバージョンを使っていると、システムにさせたいことをさらに思いつく。
また、変更がどこからやってくるのかというと、次のようなところからくるらしい[1]。
（1）マーケティング
（2）アナリスト
（3）セールス
(4)顧客やユーザ
(5)開発者
このリストは、単に役割を列挙しただけ（詳細は[1]を参照）だけど、とりあえず色々なところから変更が出てくるということが分かる。
分析：
さて、最初の疑問に戻って、僕が昨日直面した仕様変更は、どこからきて、そしてなぜ起こったのかを考えたい。
まず「どこから」という疑問に答えるには、ゲーム開発はどんな役割の人で行われてるのかを特定する必要がある。この記事では、単純に、ゲーム開発は二つの役割を持った人たちで行われるとする。
役割1：ゲームデザイナ
役割2：ゲームプログラマ
また、ゲームは、3つ目の役割を持った人が関わるとする。
役割3：ゲームユーザ（プレイヤー）
ゲームデザイナは、今まで書いてきた記事に従って、次のようなことを決める人だとする。
（１）ゲームのルール
（２）ユーザインタフェース
（３）ゲームバランス。敵のパラメータ設定など。
（4）品質要求。たとえば、ロード時間に対する要求。
ゲームデザイナは、ゲームをソフトウェアの一種だと考えるなら、要求を決める人に対応する。
ゲームプログラマは、ゲームデザイナが決めたことを実現する人だとする。ゲームをソフトウェアの一種だと考えるなら、ソフトウェアの設計やプログラミングなどをする人に対応する。
ゲームユーザは、ゲームをプレイする役割を持つ人だとする。
さて、この枠組みにしたがって考えてみると、僕が昨日直面した仕様変更である「ＢＧＭを今まではmidiファイルで鳴らしてたんだけど、mp3のファイルでも鳴らせるように」は、どの役割の人からきたんだろうか。なお、僕は、「ユーザ」「ゲームデザイナ」「ゲームプログラマ」の3つの役割を持った人である。
一つずつ考えてみよう。
ユーザの場合：ゲームをプレイするユーザは「BGMがmidiで再生されているのか、それとも、mp3で再生されているのかを気にするだろうか？」たとえば、今までゲームをプレイしてきたけど、そんな要望を思ったことがあるだろうか？ 多くの人は、そんな要望を思ったことはないと思う。したがって、この仕様変更は、ユーザから発生したのではないといえる。
しかし、この種の要望（要求）がユーザから発生する可能性はある。たとえば、ゲームのＢＧＭをユーザが自由に選択できるような機能をゲームが備えているとしよう。とすると、どんなフォーマットのファイルを再生できるのかは、ユーザにとっての関心となる。
今回の仕様変更の場合は、そんな機能はとりあえずないとして話を進める。
ゲームデザイナの場合：ゲームデザイナからこの仕様変更が発生するだろうか。つまり、この変更は、
（１）ゲームのルールに関わるか？ Ｎｏ。midiで再生しようがmp3で再生しようがユーザがゲームをどう遊ぶのかには影響しない。
（２）ユーザインタフェースに関わるか？ あきらかにＮｏ。
（３）ゲームバランスに関わるか？ Ｎｏ。
（4）品質要求に関わるか？ Ｎｏ。
したがって、ゲームデザイナから発生したのではないといえる。
ただし、先ほどと同様に、ゲームのＢＧＭをユーザが自由に選択できるような機能をゲームが備えているとすると、話は変わってくる。ゲームデザイナが、ユーザの役割の立場から、midiでもmp3でも再生できるようにと仕様変更をしてくる可能性がある。
とにかく、今回の仕様変更の場合は、そんな機能はとりあえずないとして話を進める。
ゲームプログラマの場合：残りの発生元は、ここだけになる。話の流れとしてはこんな感じに再現できる。
ゲームデザイナとしての僕「今のＢＧＭの曲じゃなくて、この曲をＢＧＭで鳴らすように変更してくれる？」
ゲームプログラマとしての僕「あれ、この曲って、midiバージョンがないのか。mp3からmidiって変換できるのかな？ え、難しいんだ。じゃあ、ソフトウェア側でmp3を再生できるように機能を変更しなきゃいけないな」
ということから、今回の場合は、この要求変更はゲームプログラマが発生元といえる。
まとめ：
今回取り上げた仕様変更は、「ＢＧＭを今まではmidiファイルで鳴らしてたんだけど、mp3のファイルでも鳴らせるように」というもの。
この仕様変更に対し、次のような疑問を投げかけてみた。
疑問1：この仕様変更は、どこ（誰）から来たのか？
疑問2：この仕様変更は、なぜ起こったのか？
疑問1への回答。ゲームデザインの仕様変更を通して、間接的に発生した。「ＢＧＭ曲の変更」というゲームデザイン上の仕様変更の影響として、「midiだけでなくmp3を再生できる機能への変更」というソフトウェアの機能仕様上の変更として発生した。
疑問2への回答。「ＢＧＭ曲の変更」というゲームデザイン上の仕様変更に対し、ソフトウェアの機能としてうまく対応できていなかったため。
考察：
以上のことを踏まえて考察。
まず、ゲームデザイン次第では、今回のような仕様変更が、ゲームデザイン上の仕様変更でありうる。例で挙げたように、ゲームのＢＧＭをユーザが自由に選択できるような機能がゲームデザイン上の仕様としてあるとすると、その機能に付随する変更として「midiでもmp3でも曲を再生できるように」という変更がゲームデザイン上の仕様変更として発生する。
そもそも、この機能仕様をゲームデザイン上のものとして考ええてよいのかを考え直す必要がある。というのも、この機能は「ゲームのルール」でも「ユーザインタフェース」でも「ゲームのバランス」でも「品質」に関わるものではないと思うから。むしろ、この機能は、「ユーザのゲームの楽しみ方」に関わる機能だと思う。とすると、ゲームデザイナは、「ユーザのゲームの楽しみ方」に関わる決定をする人だとして広く捉えるべきと思う。つまり、
（１）ゲームのルール
（２）ゲームの楽しみ方
（３）ユーザインタフェース
（４）ゲームバランス。敵のパラメータ設定など。
（５）品質要求。たとえば、ロード時間に対する要求。
という感じ。ただし、この5項目の間の関係はまだちゃんと分析できてないので今後も行っていく必要がある。
その他思ったこと：
（1）ゲームへのユーザの要望が、ゲームに直接すぐに反映されるわけではない。
参考：
[1] アラン・M・デービス, 成功する要求仕様 失敗する要求仕様
昨日作っていてどんな仕様変更があったかというと「ＢＧＭを今まではmidiファイルで鳴らしてたんだけど、mp3のファイルでも鳴らせるように」という変更。
この事例を使って、次の疑問を考えてきたい。
疑問1：この仕様変更は、どこ（誰）から来たのか？
疑問2：この仕様変更は、なぜ起こったのか？
さて、ゲームより一般的なソフトウェアの場合、仕様の変更は次のような理由で起こる[1]。
（1）ステークホルダが要求文書をレビューする。何か新しいものへの欲求が引き出される。
（2）ステークホルダがシステムの使い方を覚える。何か新しいものへの欲求が引き出される。
（3）ステークホルダがプロトタイプを触ってみる。何か新しいものへの欲求が引き出される。
（4）システムが使われる状況が変わる。たとえば、ユーザ数が増えるなど。
（5）顧客は、現在のシステムのバージョンを使っていると、システムにさせたいことをさらに思いつく。
また、変更がどこからやってくるのかというと、次のようなところからくるらしい[1]。
（1）マーケティング
（2）アナリスト
（3）セールス
(4)顧客やユーザ
(5)開発者
このリストは、単に役割を列挙しただけ（詳細は[1]を参照）だけど、とりあえず色々なところから変更が出てくるということが分かる。
分析：
さて、最初の疑問に戻って、僕が昨日直面した仕様変更は、どこからきて、そしてなぜ起こったのかを考えたい。
まず「どこから」という疑問に答えるには、ゲーム開発はどんな役割の人で行われてるのかを特定する必要がある。この記事では、単純に、ゲーム開発は二つの役割を持った人たちで行われるとする。
役割1：ゲームデザイナ
役割2：ゲームプログラマ
また、ゲームは、3つ目の役割を持った人が関わるとする。
役割3：ゲームユーザ（プレイヤー）
ゲームデザイナは、今まで書いてきた記事に従って、次のようなことを決める人だとする。
（１）ゲームのルール
（２）ユーザインタフェース
（３）ゲームバランス。敵のパラメータ設定など。
（4）品質要求。たとえば、ロード時間に対する要求。
ゲームデザイナは、ゲームをソフトウェアの一種だと考えるなら、要求を決める人に対応する。
ゲームプログラマは、ゲームデザイナが決めたことを実現する人だとする。ゲームをソフトウェアの一種だと考えるなら、ソフトウェアの設計やプログラミングなどをする人に対応する。
ゲームユーザは、ゲームをプレイする役割を持つ人だとする。
さて、この枠組みにしたがって考えてみると、僕が昨日直面した仕様変更である「ＢＧＭを今まではmidiファイルで鳴らしてたんだけど、mp3のファイルでも鳴らせるように」は、どの役割の人からきたんだろうか。なお、僕は、「ユーザ」「ゲームデザイナ」「ゲームプログラマ」の3つの役割を持った人である。
一つずつ考えてみよう。
ユーザの場合：ゲームをプレイするユーザは「BGMがmidiで再生されているのか、それとも、mp3で再生されているのかを気にするだろうか？」たとえば、今までゲームをプレイしてきたけど、そんな要望を思ったことがあるだろうか？ 多くの人は、そんな要望を思ったことはないと思う。したがって、この仕様変更は、ユーザから発生したのではないといえる。
しかし、この種の要望（要求）がユーザから発生する可能性はある。たとえば、ゲームのＢＧＭをユーザが自由に選択できるような機能をゲームが備えているとしよう。とすると、どんなフォーマットのファイルを再生できるのかは、ユーザにとっての関心となる。
今回の仕様変更の場合は、そんな機能はとりあえずないとして話を進める。
ゲームデザイナの場合：ゲームデザイナからこの仕様変更が発生するだろうか。つまり、この変更は、
（１）ゲームのルールに関わるか？ Ｎｏ。midiで再生しようがmp3で再生しようがユーザがゲームをどう遊ぶのかには影響しない。
（２）ユーザインタフェースに関わるか？ あきらかにＮｏ。
（３）ゲームバランスに関わるか？ Ｎｏ。
（4）品質要求に関わるか？ Ｎｏ。
したがって、ゲームデザイナから発生したのではないといえる。
ただし、先ほどと同様に、ゲームのＢＧＭをユーザが自由に選択できるような機能をゲームが備えているとすると、話は変わってくる。ゲームデザイナが、ユーザの役割の立場から、midiでもmp3でも再生できるようにと仕様変更をしてくる可能性がある。
とにかく、今回の仕様変更の場合は、そんな機能はとりあえずないとして話を進める。
ゲームプログラマの場合：残りの発生元は、ここだけになる。話の流れとしてはこんな感じに再現できる。
ゲームデザイナとしての僕「今のＢＧＭの曲じゃなくて、この曲をＢＧＭで鳴らすように変更してくれる？」
ゲームプログラマとしての僕「あれ、この曲って、midiバージョンがないのか。mp3からmidiって変換できるのかな？ え、難しいんだ。じゃあ、ソフトウェア側でmp3を再生できるように機能を変更しなきゃいけないな」
ということから、今回の場合は、この要求変更はゲームプログラマが発生元といえる。
まとめ：
今回取り上げた仕様変更は、「ＢＧＭを今まではmidiファイルで鳴らしてたんだけど、mp3のファイルでも鳴らせるように」というもの。
この仕様変更に対し、次のような疑問を投げかけてみた。
疑問1：この仕様変更は、どこ（誰）から来たのか？
疑問2：この仕様変更は、なぜ起こったのか？
疑問1への回答。ゲームデザインの仕様変更を通して、間接的に発生した。「ＢＧＭ曲の変更」というゲームデザイン上の仕様変更の影響として、「midiだけでなくmp3を再生できる機能への変更」というソフトウェアの機能仕様上の変更として発生した。
疑問2への回答。「ＢＧＭ曲の変更」というゲームデザイン上の仕様変更に対し、ソフトウェアの機能としてうまく対応できていなかったため。
考察：
以上のことを踏まえて考察。
まず、ゲームデザイン次第では、今回のような仕様変更が、ゲームデザイン上の仕様変更でありうる。例で挙げたように、ゲームのＢＧＭをユーザが自由に選択できるような機能がゲームデザイン上の仕様としてあるとすると、その機能に付随する変更として「midiでもmp3でも曲を再生できるように」という変更がゲームデザイン上の仕様変更として発生する。
そもそも、この機能仕様をゲームデザイン上のものとして考ええてよいのかを考え直す必要がある。というのも、この機能は「ゲームのルール」でも「ユーザインタフェース」でも「ゲームのバランス」でも「品質」に関わるものではないと思うから。むしろ、この機能は、「ユーザのゲームの楽しみ方」に関わる機能だと思う。とすると、ゲームデザイナは、「ユーザのゲームの楽しみ方」に関わる決定をする人だとして広く捉えるべきと思う。つまり、
（１）ゲームのルール
（２）ゲームの楽しみ方
（３）ユーザインタフェース
（４）ゲームバランス。敵のパラメータ設定など。
（５）品質要求。たとえば、ロード時間に対する要求。
という感じ。ただし、この5項目の間の関係はまだちゃんと分析できてないので今後も行っていく必要がある。
その他思ったこと：
（1）ゲームへのユーザの要望が、ゲームに直接すぐに反映されるわけではない。
参考：
[1] アラン・M・デービス, 成功する要求仕様 失敗する要求仕様
4Gamer.net の記事だけど
「ロスト プラネット」はクアッドコアCPU「Core 2 Quad」でもっと面白くなる（Core 2）
こういうマルチコアCPUって今まで気にしてこなかったのでよくわからんのだが、ゲームプログラマにとってはどう関係するんだろうか？ 特に僕みたいなJavaプログラマにとっては。そもそもどの言語に依存しない話題なんだろうか。
たんにマルチスレッドでプログラミングしたらいいってだけ？
「ロスト プラネット」はクアッドコアCPU「Core 2 Quad」でもっと面白くなる（Core 2）
こういうマルチコアCPUって今まで気にしてこなかったのでよくわからんのだが、ゲームプログラマにとってはどう関係するんだろうか？ 特に僕みたいなJavaプログラマにとっては。そもそもどの言語に依存しない話題なんだろうか。
たんにマルチスレッドでプログラミングしたらいいってだけ？