ゲーム化!tomo_manaのブログ

ゲーム化!tomo-manaのブログ

Unityでゲームを作る方法について紹介しています

Unity学習#31-1 シーン設計とメッセージ(RPGの例)

シーン間通信を設計するにあたって、先にシーン設計とメッセージ(シーンを切り替える理由)を定義します。

シーン遷移:RPGの例

一般的なRPGでは、タイトルがあって、セーブデータの読み込み、フィールド、戦闘、自動的に進むイベントシナリオ、メニュー、エンディング、ゲームオーバーがあります。またメニュー内にセーブがあります。これらを状態遷移図で表すと以下になります。

f:id:tomo_mana:20210328002936p:plain
シーン遷移(RPGの例)

そのうち、タイトルやプロローグ(ゲームへの導入部)、ゲーム中のイベントやエンディングなどは、スポット的に呼び出すものです()。また、ロード/セーブは、ゲーム設計ごとに作り方が変わるものの、概ねポップアップのように働きます()。残りは、RPGの主要素であるフィールド、戦闘、メニューになります()。サーバー通信エラーなどを含むゲームオーバーは異常系として扱います()。

シーン構成(グループ化)

細かい設計は後で決めるとして、フィールド、戦闘、その他イベントを一つのマネージャー(シナリオ管理)が管理できるようにすると、以下の構成になります。

f:id:tomo_mana:20210328005900p:plain
シーン構成

メニューは少し扱いが難しいので、ここではシーン構成に含めていません。戦闘やイベント中も、実際はキー入力などを受け付けると思われるからです。実際は、メニューをシーンとして独立させる作り方もあると思います。

これらの箱一つ一つが、大規模なゲームになると一つの開発チームになると思います。シーンそのものは、作業範囲を分けるための箱くらいに考えた方が使いやすいように思います。複数の人で開発する場合は、テストしたい単位でシーンを分けるのが良いのではないかと思いました。(後述するメッセージの仮想化が必要になります)

メッセージ

先ほどのシーン構成の時、シーン間のメッセージは以下のようになります。

f:id:tomo_mana:20210328012137p:plain
シーン間メッセージ

メッセージの仮想化

実際には、シーン間のメッセージはマネージャーを介して行います(仮想化)。

f:id:tomo_mana:20210328012335p:plain
シーン間メッセージ(仮想化)

上記のように仮想化することで、先ほど定義したフィールドや戦闘も、担当者レベル、テストに適したレベルに細分化しても、シーン間のメッセージは変更する必要が無く、透過性と拡張性が保たれます。

仮想化の例

たとえば、フィールドマップの0番から、特定リージョンの通常エンカウント(リージョン番号0番の敵グループ0番)を呼び出した場合、マネージャーを経由して以下のようにメッセージが飛ぶようにします。

f:id:tomo_mana:20210328014102p:plain
仮想化の例

「分担」は、たとえばフィールドならどのマップを誰が担当したか、戦闘ならその戦闘方式を誰が担当したか、がマッピングされています。

注意点

このシーン間メッセージの注意点としては、タスク/スレッド設計と違い、シーンは並列処理ができない(アクティブなシーンは常に1つ)ということです。どんな媒体であれ、シーンロードは不揮発領域にアクセスしますので、負荷がかかります。すでにロード済のシーンについて、アクティブ属性を切り替えるだけなら負荷は少ないかもしれません(・・・ということは、疑似的なタスク切り替え(ディスパッチ)が実現できる?)


(以上)