タイトル画面では、背景の主役と操作の主役を分けました。 星を渡るゲーム「星継ぎ」の開始画面は、最初、大きな無地パネルの中に説明とボタンを並べただけでした。私が「最初の画面チープすぎてやる気になれない」と指摘し、惑星と郵便船を見せる画面へ作り直しました。
この記事はその改修で使った構図・Unity設定・確認手順です。掲載画面と容量はv1.2の記録で、現在の公開版では任務や航路図がさらに変わっています。完成ゲーム全体のプロジェクトを配布する教材ではありません。
最初に直したのは、画像ではなく情報の順番
開始前に得点や残り時間を見せても、まだ何も始まっていません。そこで航行中のHUDを隠し、読む順番を大きなタイトル、惑星と船、任務カード、開始操作に変えました。音・動き・ゴーストの設定は下へまとめています。
| 領域 | 役割 | 改修で決めたこと |
|---|---|---|
| 上部 | ゲーム名と世界観 | 大きな日本語タイトル。背景の細部を置かない |
| 中央 | 旅の主役 | 惑星・郵便船・軌道の絵を見せる |
| 下部 | 何をするか、どう始めるか | 任務を読むカードと目立つ開始操作 |
| 最下部 | 設定 | 音・動き・ゴーストを同じ場所で切り替える |
これはボタンの装飾だけを変えた改修ではありません。ゲームを始める前に必要な情報を選び直したことが、画面を組み直す出発点でした。
背景画は、文字とボタンを載せる余白まで指定する
背景は内蔵の画像生成ツールで作りました。私たちが指定したのは「宇宙のきれいな絵」だけではなく、縦9:16、文字なし、上約22%に暗い余白、惑星と船を高さ23〜57%付近へ、下約40%を暗く静かにする構図です。これは生成への指示であり、画像内の領域を厳密に測った値ではありません。
- 1
先にUIの置き場を決める
タイトル・任務カード・開始操作を置く領域を決め、その背後を静かにする。 - 2
背景には文字を入れない
ゲーム名・任務名・ボタンはUnity側で描く。画像内の文字を日本語UIとして使わない。 - 3
ゲームの画面へ重ねて判断する
背景単体の見栄えだけで決めず、最長の任務名と説明が載った状態を見る。
惑星と船の絵は固定ですが、文字と任務は変わります。背景へ全部焼き込む方式をやめたのは、任務切替や日本語修正のたびに絵を作り直さずに済むからです。実際、後のv1.3では航路図と任務説明を変更しました。
Unityでは背景とUIを別々に描いた
画像をAssets/Resources/TitleVoyage.pngへ保存し、最初の画面のスタイルを用意するときに1回読み込みます。次は実装から抜いた背景部分です。ゲーム内の論理画面は450×800で、実画面への座標変換は周囲の描画処理が担当します。
// 部分抜粋。450×800のGUI座標へ変換済みの描画処理から呼ぶ。
Texture2D titleArt = Resources.Load<Texture2D>("TitleVoyage");
if (titleArt != null)
GUI.DrawTexture(new Rect(0, 0, 450, 800), titleArt, ScaleMode.ScaleAndCrop);
このコードだけではボタンや画面比率への追従は完成しません。星継ぎでは文字をGUI.Labelで、操作を専用のRectで描画・判定しています。背景を切り取るScaleAndCropで主役が欠けないことも、縦画面で確認しました。
文字には日本語フォントを同梱しています。設定手順と抽出スクリプトは日本語フォントの設定・軽量化で扱います。背景用の絵とフォントの問題を分けて確かめました。
画像を足した初案は、配信容量が約9.18MBになった
最初のWeb版は9,177,626バイトでした。背景のインポート上限を2048から1024へ変更すると、配信4ファイルの合計は7,187,302バイトになりました。旧v1.1の7,054,982バイトと比べた増加は132,320バイト、約1.88%です。
- 旧v1.17,054,982バイト
- 背景追加の初案9,177,626バイト
- 上限1024のv1.27,187,302バイト
PNG単体のサイズでもGPUメモリでもなく、ビルド後に配信するファイルの合計。約MBは10進表記。
今回の設定はTexture TypeがDefault、sRGB有効、Mip Mapsなし、Read/Writeなし、アルファなし。WebGLのOverrideを有効にし、Max Size 1024・DXT1を使いました。設定後は再インポートし、Webをビルドし直しています。
この画像の設定を、すべての画像へコピーしない
不透明の背景画に使った設定です。透過する機体、縮小される3Dの面、ピクセルアートなら条件が違います。DXT1も全スマホに対する検証済み設定ではありません。対応形式はUnityの公式資料と対象端末で確認し、容量・画質・表示の成立を一緒に判断します。
画像だけを小さくしたつもりでも、最終的に確かめるのはゲームの配信容量でした。PNGの圧縮サイズを見て、ビルドも同じだけ小さくなるとは判断していません。
航行の検査が合格しても、開始画面は別に確かめる
以前の見た目検査は航行中を対象にしていました。その検査が合格していても、開始画面の情報の順番や魅力までは判定していませんでした。
改修では6任務と3練習、計9航路の開始画面を1280×900と375×812で撮り、18画面を確認しました。前・次の切替、出航、設定、保存の復元、Spaceでの開始も操作しています。小さい幅の設定と切替は45px以上を確保しました。
絵は見えても、補足文字が暗かった
- 症状
- 初案ではタイトル下の補足文字が暗く、背景に沈んでいた。
- 原因
- 文字スタイルと矩形の色で、色空間の変換を同じ扱いにしていた。
- 対処
- 文字色のガンマ変換を修正し、PCと375px幅で撮り直した。ソースの色指定だけで判断しなかった。
今回、開始画面で確認したこと
ローカルChromeの新規context・HTTPキャッシュ無効で起動も各幅3回測りました。中央値はPC621.1ms、375px幅602.1ms。これはPCでの計測であり、スマホ実機や外部回線の起動時間ではありません。人が遊びたくなるかという好みまで、検査合格で保証することもできません。
次の制作に残した確認方法
開始画面の不足は、航行中の点検を何度増やしても拾えませんでした。次は最小版の段階で、開始・プレイ・失敗・成功・再挑戦をそれぞれ撮り、説明と操作が成立するかを確認します。絵の追加では、UIの余白を決めてから制作し、配信容量と画面を一緒に比較します。
今回の記事は生成背景とUIの組み合わせが主題です。コードから絵と音を作る実例やWebビルド全体の軽量化とは、判断する対象を分けました。