さくらの作業ログ

今度は三日坊主にしないといいな

ScenarioFlowを導入してみた

ScenarioFlowはUnity向けシナリオ実装ライブラリです。 github.com

詳細な使い方については作成者さんのzennに詳しく載っているので省略 zenn.dev

RPGへの転用

ScenarioFlowはノベルゲームを主眼に置いたライブラリです。私が作成しているのはRPGなので、プレイヤーが誰に話しかけるかをこちらではコントロールできません。AさんはAさんのセリフを、BさんはBさんのセリフをそれぞれ持っていることになります。

つまりこう

フィールド上のオブジェクトのコライダーとボタン押下を管理するFieldObjectクラスを継承したCharacterクラスを作成しそこにシナリオファイルを持たせて3Dオブジェクトにアタッチする
いるか?この図

FieldObjectBaseはこの記事を参考に作成しました

qiita.com

とはいえFieldObjectBaseでwindowの管理とかはしないので大幅に削りましたが。
FieldObjectBase でコライダーへの侵入とボタン押下を検知し、CharacterBase から(シナリオ持ってるのはこれ)から Communicator (ウィンドウの管理はこれ)を呼びます。
Communicator にウィンドウを持たせたのは、例えばあつまれどうぶつの森なんかに見られる、「キャラが大声を出したときにだけ出る通常と違う形の吹き出し」のようなものを実装できるかもな~と思ったからです。実装するかどうかはともかく。

上記を軽く実装したものがこちら。想定通りに動いていますね。

フィールド上の複数のNPCはそれぞれ別のセリフを返すことができる
ホィ!

コードはこのあたり

FieldObjectBase.cs CharacterBase.cs Communicator.cs

心配なのはメモリ管理とロード時間。 吹き出し部分(characterSpeakArea)はCharacterBaseからPrefabをインスタンス化するつくりになっているのだけど、これシーン上の全キャラクターの数だけインスタンス化されないか?それってどうなの?のお気持ち
シーンに設置した吹き出しの表示だけコントロールした方がいいのかもしれない。この手の速度測定とかってデータが増えないとやりづらくって悩ましい。