備忘録の続き。「GameManager」という全体を管理するオブジェクトがある方が、構成を把握しやすいということについて考えを整理したい。
並列関係にあるとスクリプト毎に対象オブジェクトの検索をしないといけないし、過去の記事では参考元がそうだったので気にせずそうやっていたりする。しかしスクリプト数が増えてくると、段々繋がり方が把握しにくくなる感じがする。
「GameManager」を作って、そこに各処理を登録しておけば、以降どこの処理からも共通の呼び出し名で処理を呼べるのでコードが見やすくなる。
public class GManager : MonoBehaviour
{
// ★ゲームマネージャーを入れておくインスタンス
public static GManager Instance { get; private set; } = null;
public UserScriptManager userScriptManager; // スクリプト処理
public MainTextController mainTextController; // テキスト処理
public ImageManager imageManager; // 画像処理
public Live2DManager live2DManager; // Live2D処理
~省略~
シナリオ処理をするスクリプトの場合
public void ExecuteStatement(string statement)
{
// 第一引数の中身を判別する。
switch(statement)
{
case "text":
GManager.Instance.mainTextController.DisplayText();
break;
~省略~
テキストを処理するスクリプトの場合も
public void GoToNextLine()
{
GManager.Instance.lineNumber++;
string statement = GManager.Instance.userScriptManager.GetCurrentCommand();
// switch文で分岐
GManager.Instance.userScriptManager.ExecuteStatement(statement);
}
書式が同じなので見やすい。書きやすそう。
横並びだと、「GManager.Instance」の部分がそれぞれのファイル毎に違ってくるので数が多くなってきたとき命名に一貫性を保っていられるかという疑問がある。
内容によってクラスファイルを分けており追加しやすそうだが、publicでの組み入れになる。
その他。「GameManager」の共通変数(シナリオの現在行)に見慣れない括弧がついてるので調べた。
// カレント行を保持する変数
[System.NonSerialized] public int lineNumber;
publicなフィールドに対して[System.NonSerialized]のAttributeをつけると、シリアライズもしないし、Inspectorにも表示しない、でも外部のスクリプトからはアクセスできる、なんて状態を作れます。
https://ekulabo.com/serializefield-vs-nonserialized
なるほど~。
その他(2)。start()にシナリオをロードする指定をここに書いて起点とした。
コメント