ゲームプログラムにおける「シーン管理」をデザインパターン（あるいはアーキテクチャパターン）として書くことに挑戦するシリーズ。
シーン管理の現状：
どの分野でもそうであるように、ゲーム開発でもそこで関わる人たちの間で使われる言葉がある。たとえば、「タスクシステム」であったり、今回パターン化を目指してみる「シーン管理」がある。
みんながどんな意味で「シーン」という言葉を使用しているか。たとえば、ゲームのタイトル画面の場面、ゲームプレイ時の場面、スコア表示の画面の場面、ゲームオーバー時の画面の場面など、そういう構成単位を「シーン」と呼んでいる。
参考：
・Javaによるゲーム解説 －８－
・第七章．シーン管理クラスの設計１
・その８ CS３: シーンを切り替え初期化し再生する
・Ruby/SDL で始めるゲームプログラミング【後編】
比較的実装の話の参考：
・シーン管理その2
・サブシーンについて1
これらの参考ページから分かるのは、シーンとはなんぞやという簡単な説明からはじまり（ない場合もある）、続いてすぐにコード、つまり実現方法の話になるということ。
しかし、パターンとして記述するには、シーンとは何か、に加えてもう少し問題の文脈を明確にし、問題に対する解としてのプログラム構造をガイドできるようにする必要がある。
シーンのコンセプトの特徴付け：
ということで、シーンというコンセプト自身の特徴付けを行う。この特徴付けは、特定の実現方法（プログラミング言語など）に依存せずに行う。
シーンのコンセプトを特徴付ける基本要素を4つ考えてみた。
（１）シーンは、１つ以上ある： よほどシンプルなゲームでない限り、シーンは１つ以上存在する。
例： タイトル画面のシーン、デモ画面のシーン、ゲームプレイ時のシーン、ゲームオーバー画面のシーンなど。
（２）シーン毎に、画面描画が異なる： あるシーンと他のシーンとの違いの１つは、画面描画の違いにある。
例： タイトル画面のシーンでは、タイトルに関連する描画要素を描画するが、ゲームオーバーに関連する描画要素を描画する。
（３）シーン毎に、ゲームユーザからの入力制御が異なる： あるシーンでは意味のある入力が他のシーンでは意味がない、もしくは別の意味がある。意味とは、入力に対する処理の違い。
例： タイトル画面のシーンでのキーボード入力"↑"はゲームのメニュー項目（たとえば新規ゲーム、続きからプレイ）を決定するという処理を行うが、デモ画面のシーンでは、入力"↑"に対する処理は行わない。
例： タイトル画面のシーンでのキーボード入力"A"はゲームのメニュー項目を決定するという処理を行うが、ゲームプレイ時のシーンでの入力 "A" は、キャラクターの攻撃処理である。
（４）あるシーンと他のシーンとの関係がある： つまり、あるシーンから他のシーンへの遷移がある。
例： ゲームオーバー画面のシーンからタイトル画面のシーンへの遷移がある。
例： タイトル画面のシーンからデモ画面のシーンへの遷移があり、デモ画面のシーンからタイトル画面のシーンへの遷移がある。
これらの要素はすごく当たり前かもしれないは、これらがプログラム構造を規定する基本要素となる。
シーンのコンセプト図：
上で特徴づけしたことを図（メタモデル）で表すとこうなる。
具体例を図（モデル）で表すとこうなる。
今後の調査内容：
今回は、シーン管理のデザインパターン記述の前準備として、シーンのコンセプトの特徴づけとして４つの基本要素を定義したけれど、これだけでは不十分といえる。議論しなかったものには次がある。
（１）シーンの関係の動的性： ゲームで必要なシーンの集合、もしくはシーン間の遷移関係は、ゲーム開始から終了まで静的に決まっているのではなく、ゲームプレイ時の状況に応じて動的に変化するかもしれない。
（２）シーンの粒度と分割の基準の考慮： どんな粒度で１つのシーンと見なすのか。その分割基準は何か。シーンをあまり細かな粒度に分けると、シーン数が増えて管理が難しくなるかもしれない。シーンを管理するプログラム構造は、粒度の異なるシーンに適切に対処できる必要があるかもしれない。
シーン管理の現状：
どの分野でもそうであるように、ゲーム開発でもそこで関わる人たちの間で使われる言葉がある。たとえば、「タスクシステム」であったり、今回パターン化を目指してみる「シーン管理」がある。
みんながどんな意味で「シーン」という言葉を使用しているか。たとえば、ゲームのタイトル画面の場面、ゲームプレイ時の場面、スコア表示の画面の場面、ゲームオーバー時の画面の場面など、そういう構成単位を「シーン」と呼んでいる。
参考：
・Javaによるゲーム解説 －８－
・第七章．シーン管理クラスの設計１
・その８ CS３: シーンを切り替え初期化し再生する
・Ruby/SDL で始めるゲームプログラミング【後編】
比較的実装の話の参考：
・シーン管理その2
・サブシーンについて1
これらの参考ページから分かるのは、シーンとはなんぞやという簡単な説明からはじまり（ない場合もある）、続いてすぐにコード、つまり実現方法の話になるということ。
しかし、パターンとして記述するには、シーンとは何か、に加えてもう少し問題の文脈を明確にし、問題に対する解としてのプログラム構造をガイドできるようにする必要がある。
シーンのコンセプトの特徴付け：
ということで、シーンというコンセプト自身の特徴付けを行う。この特徴付けは、特定の実現方法（プログラミング言語など）に依存せずに行う。
シーンのコンセプトを特徴付ける基本要素を4つ考えてみた。
（１）シーンは、１つ以上ある： よほどシンプルなゲームでない限り、シーンは１つ以上存在する。
例： タイトル画面のシーン、デモ画面のシーン、ゲームプレイ時のシーン、ゲームオーバー画面のシーンなど。
（２）シーン毎に、画面描画が異なる： あるシーンと他のシーンとの違いの１つは、画面描画の違いにある。
例： タイトル画面のシーンでは、タイトルに関連する描画要素を描画するが、ゲームオーバーに関連する描画要素を描画する。
（３）シーン毎に、ゲームユーザからの入力制御が異なる： あるシーンでは意味のある入力が他のシーンでは意味がない、もしくは別の意味がある。意味とは、入力に対する処理の違い。
例： タイトル画面のシーンでのキーボード入力"↑"はゲームのメニュー項目（たとえば新規ゲーム、続きからプレイ）を決定するという処理を行うが、デモ画面のシーンでは、入力"↑"に対する処理は行わない。
例： タイトル画面のシーンでのキーボード入力"A"はゲームのメニュー項目を決定するという処理を行うが、ゲームプレイ時のシーンでの入力 "A" は、キャラクターの攻撃処理である。
（４）あるシーンと他のシーンとの関係がある： つまり、あるシーンから他のシーンへの遷移がある。
例： ゲームオーバー画面のシーンからタイトル画面のシーンへの遷移がある。
例： タイトル画面のシーンからデモ画面のシーンへの遷移があり、デモ画面のシーンからタイトル画面のシーンへの遷移がある。
これらの要素はすごく当たり前かもしれないは、これらがプログラム構造を規定する基本要素となる。
シーンのコンセプト図：
上で特徴づけしたことを図（メタモデル）で表すとこうなる。
具体例を図（モデル）で表すとこうなる。
今後の調査内容：
今回は、シーン管理のデザインパターン記述の前準備として、シーンのコンセプトの特徴づけとして４つの基本要素を定義したけれど、これだけでは不十分といえる。議論しなかったものには次がある。
（１）シーンの関係の動的性： ゲームで必要なシーンの集合、もしくはシーン間の遷移関係は、ゲーム開始から終了まで静的に決まっているのではなく、ゲームプレイ時の状況に応じて動的に変化するかもしれない。
（２）シーンの粒度と分割の基準の考慮： どんな粒度で１つのシーンと見なすのか。その分割基準は何か。シーンをあまり細かな粒度に分けると、シーン数が増えて管理が難しくなるかもしれない。シーンを管理するプログラム構造は、粒度の異なるシーンに適切に対処できる必要があるかもしれない。
PR