Q&A
実現したいこと
こんにちは。見てくださりありがとうございます。
UIなどをInstantiateによって動的に生成したいと考えたとき、実行してから配置されるのでEditor状態で自由な編集ができないですが、それを可能にする代替案のようなものを募集しております。
発生している問題・分からないこと
いきなりたとえで申し訳ないのですが、マイクラのHPバーをUnityで例えば実装するとき
スケーラブル（コマンドでHPを増やすなどなど）にするためには、GUIのハートオブジェクトをPrefab化する必要がありますよね？
また、実際のHP値をGUIに反映させるために、すべてのハートオブジェクトの参照を持っていなければなりません。
よって、ゲーム開始時にInstantiateをforで回して生成、返り値のゲームオブジェクトをキャッシュしておくという発想になりました。
しかし、
これではたとえばゲームプレイしていない状態でのGUIの配置（位置、マージンなど）、デザインの調整が視覚的かつ迅速にできないという問題に直面します。
これはどうするべきなのでしょうか？
該当のソースコード
特になし
試したこと・調べたこと
- teratailやGoogle等で検索した
- ソースコードを自分なりに変更した
- 知人に聞いた
- その他
上記の詳細・結果
思いついた実装方法としては
- ExecuteAlways または ExecuteInEditMode を使う
- Layout Group と ダミーオブジェクト の併用
- ハートの最大数をあらかじめ並べておく
なのですが、
ExecuteAlwaysは常に起動しているのでリソースを食いますし、バグがあればクラッシュするおそれもあります。また、意図せずSceneに差分が生じる可能性もあると思いました。
LayoutGroupとダミーの併用については、今回はHPバーだからこの方法が通用しそうですがもうすこし複雑なものなら対応できないと思いました。特に例えばスキルツリーの実装など？
ハートの最大数をあらかじめ並べておくという手法も、これもまた数が少ないなら良いのですがクッキークリッカーのツリーのように複雑で巨大なものを並べてInspectorで紐づけるのはあまりにも非効率的ですよね、、、。
補足
Unity6
Windows11
回答2件
0
まず最初に。
LayoutGroupとダミーの併用については、今回はHPバーだからこの方法が通用しそうですがもうすこし複雑なものなら対応できないと思いました。特に例えばスキルツリーの実装など？
これは、今回の質問に関係のあることなんですか？
HPバーがスキルツリーのようになる可能性がある、とか。(そんなはずはないと思うのですが)
別に、 実行時に Instantiate で生成しても同様の問題がありますよね。
☓☓の場合はどうしよう、と考えることはいいですが、それはまず現状の問題を解決してから考えるべきでしょう。
ハートの最大数をあらかじめ並べておく
これで問題ないなら、これが一番です。
ハートの最大数をあらかじめ並べておくという手法も、これもまた数が少ないなら良いのですがクッキークリッカーのツリーのように複雑で巨大なものを並べてInspectorで紐づけるのはあまりにも非効率的ですよね、、、。
HPバーが複雑で巨大なんですか？(これも先に話した実装しようとしていること以上のことを考えているのではないですか)
HPバーのハート程度であれば、手動で設定しても構わないと思いますが。
とはいえ、めんどくさいというのは理解できます。
であれば、「ある決まり」に従ってハートを配置して、実行時に 直下の子オブジェクトを列挙して取得し 、「ある決まり」に従ってソートしなおしてしまえばいいです。
「ある決まり」は色々あると思いますが、
- Hierarchy上に順番に並べておいて、 `Transform.GetSiblingIndex の値でソートする。
- オブジェクトの名前でソートする。(ソートできるような名前をつける。
Heart01、Heart02とか)
といった感じでしょうか。
もし 実行時に Instantiate することが絶対であれば、gizmosを使ってハートの位置を表示するという手もあると思います。
コメントを受けて追記します。
質問にあるような問題に当たった場合、
Instantiateを使わずに対処する方法を考える。- エディタ上で確認する。
という対策をまず考えます。
(先の回答で話したHPバーのハートの件は、1の対処ということになりますね）
もちろん、これで解決しない場合があれば別途対策を考えますが、大抵の場合そのようなことはほとんどありません。
ですので、質問に対する一般的なベストプラクティスなんて、これ以外ないんですよ。
Instantiate は、エディタ上でシーンにプレハブなどのGameObjectを配置する、という操作をランタイムで行うだけのものです。
ですので、大抵の場合はエディタ上の確認で十分であり、ゲーム中で調整するということはありません。
最近の話で言えば、表示の切り替えをアニメーションで行う。というやり方を取るところも多いです。
例えば、HPバーのHPが0の状態を1フレーム目に、HPがフルの状態を10フレーム目になるようにアニメーションを作成します。
このようにすれば、プログラム側ではアニメーションを停止させて、アニメーションフレームを(10 * 現在のHP値 / HPの最大値)に設定することにより表示でき、プログラム量が減ることになります。
それだけでなく、デザイナ側もアニメーションをエディタ上で確認すればいいわけで、プログラムを動かさなくてもいいわけです。
(質問にあるようなハートでの表現であれば、もうひと工夫いることになりますが)
事前配置や実行時のソートといった回避策ではなく、動的生成の柔軟性を維持したまま、Editモード上でダミー生成してレイアウトを確認できるような仕組みを想定しておりました。
どうもこの言い回しが気になるのですが。
ちょっと昔話をしましょうか。
Unityなどが存在していなかった頃、このようなUIの作り方はどうしていたかというと、デザイナがPhotoshopなどで画面のイメージを作成し、それぞれの表示物の座標をメモしてプログラマに渡して、プログラマが一つ一つコードで表示するようコードを記述していました。
これがデザイナにとってもプログラマにとっても非常にコストのかかる作業であり、問題になっていました。
実際、自分もデザイナから「この作業、どうにかならないものですかね」と相談を受けたことがあります。
それが、Unityなどの登場により、UI設計が画面上で行えるようになり、設計された情報がそのままデータとしてプログラマに渡せるようになり、プログラマは大したコードも書かずにUIを表示することができるようになったわけです。
つまり、あなたの言っている「動的作成」というのは昔やっていた手法であり、 ローテクでであるので、まずなくすことを考えるべきです。
もちろん、使えばより良くなるのであれば使うべきですが、過去の問題まで巻き戻すような使い方は避けるべきではないでしょうか。
投稿2026/05/07 23:03
編集2026/07/26 00:30
総合スコア3660
0
Prefabを使うほどのことでもないと思います。
自分だったら、こうするという方法を書くと、
- 開発時には普通にオブジェクトなどを並べて、レイアウトを調整します。
- 実行時には、不要なときには、SetActive()などを用いて非表示にしておく。必要になったら表示する。
あと、HPバーは、「Unity HPバー」で検索すると、さまざまな実装方法がでてくると思います。
投稿2026/05/08 04:42
編集2026/05/08 04:46
総合スコア319
あなたの回答
tips
プレビュー
2026/07/24 10:51