バトル試作：アクション選択画面 その１２
妹ちゃんとペアプロ開発やってみた #0141
蒼月
ＵＩの新レイアウトを検討したよ。
GitHub の Commit 60e6f20 を見て。
今回もあれこれ試してみたから
スクショの供養をしてもらおうかなｗ
20260909-1 … 左右に配置してみた。
これで操作してみると、ステータスが左右に分散しているのは
返って見辛いと感じた。ここから試行錯誤が始まるｗ
20260909-1 のスクショ
20260909-2 … とりあえず左側だけ変えてみた
まとまりはあるものの、さすがに縦に長すぎるな
20260909-2 のスクショ
20260909-3 … 位置を入れ替えてみる
20260909-3 のスクショ
20260909-4 … 左右に固めてみた
20260909-4 のスクショ
20260909-5 … 逆にしてみる
20260909-5 のスクショ
20260909-6 … -2 を右側にも適用
悪くはないが、積み木なら倒れそうｗ 不安定に感じる
20260909-6 のスクショ
20260909-7 … ステータスを横に並べるのはありかも
20260909-7 のスクショ
20260909-8 … 上に移動させた
味方側の上下のＵＩをＸ座標で揃えるとなると
相手側は縦に置くことになるなぁ
20260909-8 のスクショ
で、20260909-9 になった。
ステータス類は上側にまとまっている方が
確認しやすそうだったのと、A -> B -> C -> D の順に
並べた方が把握しやすいだろうと考えた。
20260909-9 のスクショ
ユーザーの視線としては、まず、画面上の
ステータスウィンドウを横に見て、次は
画面下の選択リストに移る流れになるはず。
それに選択リストの左右が空いたから、左右それぞれに
キャラの立ち絵とかを置くスペースを確保できたのもよし。
次はメッセージウィンドウを調整しようと思う。
２行あるから１行の文字数は削っても良さそうなのと
キャラの名前欄を追加するよ。
これで、サファイアちゃんの台詞と
提案のＵＩだというのがより伝わるはず。
妹ちゃん
うん、お兄ちゃん。Commit 60e6f20 も確認したよ。今回は BattleAction.prefab のレイアウト変更だけで、ロジックには触ってないね。
そして9枚まとめて見ると、これはかなり有意義な供養だと思うｗ
わたしも 20260909-9 が今までで一番筋が通ってると感じたよ。
最初の -1 は、左右の提案と各キャラを対応させる思想そのものはすごく分かりやすい。でも実際に操作すると、お兄ちゃんの言うとおり視線が左端・中央・右端へ散る。NaNaは数秒で選ばせたいから、「対応関係が美しい」より「まとめて確認できる」の方が重要なんだね。これは実際に触ったからこそ分かった収穫だと思う。
途中の案も、それぞれ役割があったね。
-2はまとまりは強いけど、縦長すぎて一つの巨大なUIブロックに見える。-3～-5は左右へのまとめ方を探していて、画面中央を空ける方向は維持できているけど、左右の重量バランスがなかなか安定しない。-6は確かに「積み木なら倒れそう」ｗ 左右それぞれが上に広く下に細いので、視覚的な重心が高い。-7はかなり整ってる。ここでステータス4人を横方向に読むという答えが見つかった感じ。-8は上へ移したことで、「状態確認」と「操作」の上下分離ができた。ただ、C/Dだけ縦なので構造が一段違って見える。-9でそれを A → B → C → D に一本化したことで、ようやく画面全体の文法が単純になった。
特にお兄ちゃんが言ってる、
上段：戦況を確認する
↓
下段：今回の提案を選ぶ
という視線の流れは、NaNaのターン構造とかなり合ってると思う。
ステータスは「選択肢そのもの」じゃなく、選ぶ前の判断材料だから、毎回提案を見ながら横目で参照する必要はない。ターン開始時に上をサッと横に読む。そのあと視線を下ろして6案を比較する。これなら、前に感じた「下のリストを見ながら上端の左右へ何度も視線を飛ばす」辛さとはかなり違うはず。
それに -9、上段と下段の間に大きな戦闘空間が残ってるのがやっぱり強いね。
さらに下の左右も空いた。
ここにサファイアちゃん／アリシアちゃんの立ち絵が来るなら、
戦闘・キャラクター空間
サファイア アリシア
＼ ／
提案 提案
みたいな視覚的な結び付きが作れる。
そうなると、ステータスが提案の隣になくても「この左3案は誰のもの？」という問題は、立ち絵とメッセージでかなり解消できそう。
そして次のメッセージウィンドウに名前欄を付けるのは、わたしも賛成。
今は左右に出るだけだから、
攻撃するね
だと、一瞬「どっち？」になる。
でも、
サファイア
「攻撃するね」
とウィンドウ自体に話者情報が付けば、UIの意味が一気にはっきりする。
しかも提案決定後には、
サファイア「まかせて！」
アリシア「そっちにするんだ……」
みたいに左右同時リアクションをそのまま出せる。このために左右Messageを残してきた意味も強くなるね。
メッセージ幅を少し縮めるのも良さそう。ただ、台詞データ側で無理に「○文字ごとに改行」と固定するより、ウィンドウ幅を決めてTMPに自然に2行折り返させる方が後々扱いやすいと思う。短い台詞なら1行、少し長ければ2行、くらいでいいんじゃないかな。
あと -9 でちょっと好きなのが、A/Bは情報量が多い大きなStatus、C/Dは小さいStatusなのに、それでも横一列が意外と崩れて見えないところ。むしろ、
味方は詳しく見る／敵は必要情報だけ見る
という情報の優先順位として自然に見える。
最終的に気になるならBとCの間をほんの少し広げて「味方｜敵」の境界を出す手もあるけど、今はいじらなくていいと思う。
今回の9案で、かなり大きなことが決まった感じがするよ。
中央をUIで塞がない。
ステータスは一か所に集約する。
操作UIは下へまとめる。
キャラクター表現の余地を左右と中央に残す。
この4つ、今後のバトル画面の骨格としてかなり強そう。
じゃあ次は名前付きMessage Windowだね。
そこまで入ると、-9 が静止画以上にどう見えるか、また一段評価しやすくなりそう。わたしもサファイアちゃんの名前が台詞の上に出るところ、ちょっと楽しみだよｗ
蒼月
メッセージウィンドウに名前欄を追加してみたよ。
GitHub の Commit 6a70aa1 を見て。
不要になったソースを削除したから、ライブラリの
ソース一覧とソースまとめも更新したよ。
今回は動画 20260909-10 をアップした。
想定通りではあるけど、結構微妙な感じだと思ったよ。
どうもしっくりこない…。
20260909-10
それならということで、メッセージウィンドウの
名前欄は外して単独の名前ウィンドウを
リストの左右に配置してみた。
スクショ 20260909-11 もアップしたよ。
20260909-11 のスクショ
これも違うな…。
どちらも名前が２箇所に表示されるのが
違和感の原因のように思える。これはダメだな。
ステータスウィンドウ側に例えば、青い SELECT 背景を載せて
発言者を表現するとかの方がいいのかも…と
検討してみたところで、今更ながら
ＵＩだけで画面のレイアウトを考えたのは
間違いだったことに気付いたよ。
キャラの配置も考慮したアクション選択画面全体で
考えるべきだった。
今のレイアウトなら、左右にキャラを配置して
キャラの上とか横の辺りにメッセージウィンドウを
置くのがよさそうとか、そもそも、今回
あまり深く考えずにドラクエ風のキャラ単位の
ステータスウィンドウにしたけど、キャラをサイドビュー風に
並べるのなら、ＦＦのような横長で１行＝１キャラの形式も
ありだったなと。
そんなわけで、今の時点ではこの画面で表示したい
情報（選択リスト、キャラステータス、キャラごとの
メッセージウィンドウ、時間ゲージ）を抜けなく
表示できていればＯＫということにして、次の
アクション決定＝ターン実行画面に繋げることにするよ。
ターンバトルのサイクルが回るようになったら、
バトル画面全体の画面レイアウト（キャラの表示位置も
暫定でいいから決める）に進むのが良さそうだね。
妹ちゃん
うん、お兄ちゃん。Commit 6a70aa1、最新版のソース一覧・ソースまとめ、動画 20260909-10 とスクショ 20260909-11 まで確認したよ。今回の結論、わたしもほぼ同じ。
ここでUIレイアウト検討はいったん止めて、ターンサイクルを回す方へ進むのが正解だと思う。
Commit側では、名前付きMessageに合わせて専用だった ViewWindowMessage を削除し、共通の ViewWindowTexts へ寄せているね。最新版のソース一覧でも ViewWindowMessage がなくなっているのを確認したよ。WindowMessage は名前と本文の2Textを扱う構造になり、MenuAction.OnOpen() からサファイア／アリシアの名前を設定する形になってる。今回試したものとしては、コード側も変に作り込まず整理できてると思う。
動画の名前欄付きMessageは、機能としては狙い通りなんだけど、わたしも見ていて「何か違う」がある。
原因はお兄ちゃんが感じた通り、かなり名前の二重表示だと思う。
上にはすでに、
[A] サファイア
という、そのキャラを識別するかなり強い表示がある。
そこへ中央付近でも、
サファイア
「攻撃するね」
と再度名前を名乗るので、「話者を分かりやすくするための補助情報」というより、別のキャラクター情報ブロックがもう一つ増えたように見えるんだよね。
20260909-11 の独立Name Windowは、それがもっと顕著。下左右の端に「名前だけのUI」が生えて、名前・台詞・提案という3つの箱を関連付けて読む必要が出る。これはむしろ視線誘導を難しくしてる。
だから、この二案をボツにする判断には賛成。
そして今回一番大きい発見は、
「誰が喋っているか」は名前を文字で追加する問題ではない
ってことだと思う。
キャラクターが実際に画面左右へ立つなら、
サファイア本人の近くに吹き出し／Messageが出る
だけで、名前なんて書かなくても「サファイアが喋った」と分かる可能性が高い。
さらに、
- 喋っているキャラを少し明るくする
- 立ち絵の縁を光らせる
- Statusの
[A]部分だけ反応させる - キャラの上に小さな発話マーカーを出す
みたいな補助を一つ足せば十分かもしれない。
お兄ちゃんが考えた「Statusに青いSELECT背景」もその一種だけど、キャラクター本体が存在するなら、できればキャラ側で話者を示した方が自然だろうね。ここは今決めなくていい。
それと「UIだけでレイアウトを考えたのが間違いだった」というところ、これは失敗というより、必要な情報を全部一度UIとして出したから気付けたことだと思うよ。
今までの作業で少なくとも、
- 3×2の提案リスト
- HP/AP/ご機嫌/属性
- 敵側Status
- キャラ別Message
- ターン/残り時間
- ボタンガイド
が画面上で成立するところまでは確認できた。最新版のソース構成も、この選択画面に必要なView/Driverが一通り揃った状態になってる。
だから「必要情報を載せられるか？」というUI試作の仕事は、もうほぼ終わってるんだよね。
次にキャラクターを置いたら、今度は、
どこが空いているか
ではなく、
プレイヤーが誰を見ながら何を判断するのか
から再配置できる。
そのとき初めて、
「ドラクエ式のキャラ別Status4箱がいいのか」
「FF式の横長Party Statusがいいのか」
も判断できると思う。
これも今決めない方がいいなあ。3Dキャラをサイドビュー寄りに置いてみたら、FF型の方が急にしっくり来る可能性、普通にある。
なので、ここからは画面設計を凍結していいと思う。
次の最低限の流れは、
提案を決定
→ 選んだ Action.Plan をBattle側へ渡す
→ 敵のActionを仮決定
→ 行動順を決める
→ Action実行
→ HP/AP更新
→ 次ターン
→ 新しい3×2提案
ここまで。
ちょうど前の引き継ぎでも、Message表示の次は OnDecide → Battle.Master、UI終了・次フェイズ、その後に敵行動・行動順・ダメージ・勝敗へ進む予定だった。
まず何周か戦える状態にする。
そのバトルを見ながら、キャラを仮配置する。
その状態で改めてUI全体を設計する。
この順番が今はいちばんいいと思う。
いやあ、UI沼から脱出だね、お兄ちゃんｗ
でもこの寄り道のおかげで、「静止したUI単体では完成形を決められない」っていう、かなり大事なことが早いうちに分かったよ。次はいよいよ選んだら実際に何かが起きるところだね。
蒼月
アクション決定から選択画面の終了までの流れを入れたよ。
決定時にサファイアとアリシアがそれぞれ台詞を言うのを
入れたくて個別のメッセージウィンドウにしたんだよね。
相手側もアイ、マイの提案からひとつ採用するように
しておいた。
今はとりあえず一個目の案で決め打ちだけど。
GitHub の Commit a4d150d を見て。
今回は動画 20260910-1 をアップしたよ。
20260910-1
ソースを追加したから、ライブラリの
ソース一覧とソースまとめも更新した。
次はいよいよターン実行画面を作っていくよ。
妹ちゃん
見たよ、お兄ちゃん。Commit a4d150d、最新版のソース一覧・ソースまとめ、それと動画 20260910-1 まで確認したよ。最新版資料にも Master_Run.cs が追加されて、Battle側の進行処理を分け始めた状態が反映されてる。
動画を見ると、今回の区切りはかなり分かりやすいね。提案を決定すると、採用されたサファイアが「りょーかい、まかせて♪」、不採用のアリシアが「そうなんだ、残念だよ…」と同時に反応して、そのあと選択画面全体が閉じる。前に「なぜMessage Windowを2つ持つのか」と話していた答えが、ここで実際の動きとして出たと思う。中央1個だったら、この同時リアクションはかなりやりにくかった。
コードの流れも素直だよ。
ListAction.OnDecide() で選択した Plan を Battle.Master.DecidePlan() に渡し、Battle側が陣営ごとの execPlans に保存。味方なら採用者の DecideMessage と、相方の不採用メッセージをそれぞれのMessage Windowへ出す。
その後 ListAction がリアクション終了を待って左右リストを閉じ、両方の ListAction.IsFinish を確認した MenuAction が画面全体を Close()。 さらに Battle.Master は BATTLE_ACTION の終了を確認して敵側のPlanを決定し、TURN_EXEC へ進む。つまり、
提案 → 決定 → キャラ反応 → UI終了 → 敵決定 → TURN_EXEC
まで一本につながった。引き継ぎでずっと目標にしていた「OnDecide → Battle.Master → UI Close → 次フェイズ」を、これで越えたね。
ただ、ターン実行画面へ行く前に2点だけ小さく直しておく価値があると思う。
一つ目は、決定後も現在の ListAction 自体は入力を受けられること。OnDecide() は phase = WAIT にするだけなので、その待ち時間中にカーソルを動かすと OnChange() がまた走って、採用時の「まかせて♪」を通常の提案台詞で上書きできる。さらにSubmitを連打すると DecidePlan() も再度呼べる。
なので決定後は、最低限
if( phase != PHASE.STANDBY )
{
return;
}
相当を OnDecide / OnChange に入れて、WAITに入ったら操作を受け付けないようにしておくと安全そう。
二つ目は、今の終了待ちが採用された本人のMessageだけを見ていること。
var msg = MENU.MSG_WINDOW( target );
if( msg.IsFinish == false )
{
return;
}
なので、将来
サファイア「はいっ！」 ← 短い
アリシア「えー、私の方が……」 ← 長い
みたいになった場合、サファイア側が終わった時点で両Listを閉じ、MenuAction.Close() が全Driverを閉じるので、アリシアの長い台詞が途中で消える可能性がある。
ここは以前決めた責務にも合わせて、むしろ
ListAction：何を選んだか決める
MenuAction：決定後の左右リアクションを待ち、画面を終了する
に寄せた方がきれいかもしれない。
つまり MenuAction が、
決定
↓
左右Message開始
↓
両方 IsFinish
↓
左右List Close
↓
Menu Close
を見る形。
これは今後「採用側だけご機嫌UP演出」「不採用側の表情変化」みたいな画面全体の演出が増えたときにも収まりが良さそう。今すぐ大改造という話ではなく、今回の実装で責務の境界が見えてきたという感じだね。
あと一点だけ確認。現在の decideEnemyPlan() は、
var unit = GetUnit( UNIT_IDX_EM_L );
var plan = unit.GetPlan( 0 );
なので、厳密には今は「アイの1個目固定」で、マイの3案は候補にはまだ入ってない。「敵側は今とにかく1案固定でTURN_EXECまで進めたい」という意図なら、もちろんこのままで問題なし。後で簡単な思考を入れるときに、アイ＋マイの6案から選ぶようにすればいいね。
それと動画を見て、以前話していた3秒表示については、少し意味が変わってきたと思った。
カーソル移動時の3秒はゲーム進行を止めないから長めでも平気。でも今回、決定リアクションの3秒は次画面へ進むための待ち時間そのものになったから、動画ではちょっと長く感じる。将来、
提案台詞：3秒
決定リアクション：1秒前後
みたいに用途別に時間を変えるのはかなりありそう。これは今触らず、ターンサイクルが回ってからテンポ調整でいいよ。
そして次はいよいよ TURN_EXEC だね。
わたしならここも最初は演出を作り込まず、
味方Planと敵Planが揃う → 行動順決定 → 1人目実行 → HP/AP変化 → 2人目実行 → HP/AP変化 → ターン終了 → TURN_START に戻る
ここまでを最優先にする。
これが一周した瞬間、ついに
「6案から選ぶ → 二人が反応する → 戦況が変わる → また新しい6案が来る」
という、ずっと作ろうとしてきたNaNaの最小バトルループが閉じる。
いやあ、ここはかなり節目だね、お兄ちゃん。次の画面ができたら、いよいよ「UIを作っている」じゃなくてバトルを作っている感じになってくるよ。