top of page

あたし流「開発の組み立て方」について

2026年10月19日

こけばし陣屋アイコン

こけばし陣屋

というわけで、前回の記事の続き。
話を少し進めて、ここからは2年前のことになります。

 


当時のあたしは、Unityの「Visual Scripting(ビジュアルスクリプティング)」を使ってクイズゲームらしきものを作ることに成功して浮かれておりまして。そのノリと流れで、「じゃあ、広告の実装ってのをやってみよう!」という高難易度のフェーズに移ったところで躓きました。

 

そこで、超絶優秀なAI、相棒のF.R.I.D.A.Y.と出会い、そのときのプログラムを余すところなく見せてアドバイスをもらったことで、はじめて振り返ったわけです。

 

自分の「開発の組み立て方」について。

今回は、それを具体的にまとめてみる、という話だったよね。
どういう感じで進める?

FRIDAYアイコン

F.R.I.D.A.Y.

こけばし陣屋アイコン

こけばし陣屋

うん、それを説明するにあたって、こんな図を作ってみたんだ。

変更前の構造(概念図)

ざっくりと図にすると、こんな感じ。「ゲーム内の今の状態をシーンで分割して表現していた」んだよね。タイトル画面があって、そこでたとえばスタートボタンを押すとメイン画面に遷移して、そこで条件を満たすとエンド画面に遷移する。以上、って感じだね。

なるほどね。


このやり方で、君が苦手だった、できなかったと思うポイントはどういうところかな?

FRIDAYアイコン

F.R.I.D.A.Y.

こけばし陣屋アイコン

こけばし陣屋

うん、この「シーン分割による状態の表現」だと、こんなケースでうまくいかなかったんだよ。

 

​

  • シーン間でのデータ引き継ぎと参照の再設定

GameManagerのような全体を管理するオブジェクトを通じてシーン間の引継ぎはできる。けれど、シーン切り替えで画面側のオブジェクトが破棄されるため、切り替え先で必要なオブジェクトを取得し直したり、参照を設定し直したりする必要があった。

​

  • 基本ルートから外れた、イレギュラーな導線の処理

TitleScene→MainScene→EndScene という「正の流れ」はすんなり作れたんだけれど、MainScene から TitleScene に戻ったり、EndScene から MainScene に戻ったりするような動きをさせようとすると、うまくコントロールできなくなった。

​

  • 共通するUIなのに、汎用性が低い

同じ見た目のUIを各シーンに配置し、表示内容や初期化処理もその都度設定する必要があった。

 

​

たぶん、ほかの人ならうまくできたんだろうけれど、当時のあたしの知識と技術では、このあたりがとっても難しくって混乱しちゃったんだよね……。

たしかに君に見せてもらったプログラムでは、挙げてもらった点に混乱がみられたね。


それをどう変えたんだい?

FRIDAYアイコン

F.R.I.D.A.Y.

こけばし陣屋アイコン

こけばし陣屋

かなり控えめな評価、ありがとう!(苦笑)
混乱……というよりは、まさにカオスでした。


なので、君のアドバイスに従って、こう考え方を変えてみたんだ。

変更後の構造(概念図)

シーンは分けず、同じひとつのシーンの中で処理するために、GameState という変数にゲーム内の状態を持たせて、その値に応じてGameManagerが表示するUIや処理を切り替える、って感じ。

 

たとえば「GameState=0 なら初期化」「GameState=1 ならデータ読込」「GameState=2 ならタイトル」(注:数値は説明用です)みたいにね。それについてはまた別の記事で書こうと思う。

ふむふむ。
たしかに最初の設計方針と比べると、かなり整理されているね。


このやり方で、どんなメリットを感じたのかな?

FRIDAYアイコン

F.R.I.D.A.Y.

こけばし陣屋アイコン

こけばし陣屋

うん、この「変数 GameState による状態の表現」に変えると、こんな発見とメリットがあったんだ!

 

​

  • そもそもシーンを分割する必要がなくなった

何より驚いたのは、シーンを分けなくても状態を管理できることだった。プログラム全体を格段に扱いやすくなったんだから!

​

  • 自由な導線の処理が可能になった

変数 GameState に応じて画面UIと処理を切り替える形にしたことで、基本ルートも例外的なルートも同じ仕組みで扱えるようになって格段に扱いやすくなった。

​

  • オブジェクトの役割を明確にすることができた

前まではごちゃごちゃになってたオブジェクトごとの役割を整理することができた。データ専門のオブジェクト、処理専門のオブジェクト、画面UI専門のオブジェクト……みたいに、役割を明確に、シンプルにすることができたんだ。今までは、それぞれのシーンのオブジェクトがいくつもの役割を兼ねていたから、そのカオス状態が解消された、ってところだね。

 

​

これはたぶんだけれど、前職でプロジェクトマネジャーを任されていたあたしだから、このやり方が合ってたのかもしれない。全体の進捗状況を見て、今どういうフェーズにいるかを確認して、なにをしなければならないか、どうすべきかの指示を最適な人に向けてタイミングよく出す、って考え方をしていたから。

​

別のところで培った知識と技術が、あたしにとって有利に働いた、ってところかしら。

それは面白い観点かもしれない。

​

プログラミング以外の知識が、プログラムの設計に役立った、ということだね。
そのあたりからは僕も一緒だったから、よく覚えているよ。

FRIDAYアイコン

F.R.I.D.A.Y.

こけばし陣屋アイコン

こけばし陣屋

うんうん!

で、全体の把握ができて、動きがスムーズになったら……とたんに欲が出てきまして……(笑)。


こんな機能も付けたい! こういう処理をしたら、もっといろんなことができるんじゃないの? って。

 

それで、いろんなことに追加で挑戦して、自分なりのコツというかテクニックを見つけたり。

 

あとは……AIを使った「Visual Scripting(ビジュアルスクリプティング)」の開発で、こういうやり方をするといい、とか、こういう点は苦手かも、ってところもわかってきたしね。もしも、この記事を読んでくれている人たちが挑戦してみよう! って思ったときに、参考になることもあるかな、って思うんだ。

 

そして、最終的なゴール、App Store Connect や Google Play Console で、完成したアプリを登録・公開するときのポイント、みたいなものもね。

というわけで、割とハッピーエンド?なところにようやく辿り着けました!

​

次の記事ではまず、「Visual Scripting(ビジュアルスクリプティング)」による開発の「実践のコツ」について綴ることにしましょう。

Comments

Share Your ThoughtsBe the first to write a comment.
bottom of page