ゲームのUIキットを自作する：共通部品の整理
遊びをつくる執筆にClaudeを使用しています。
ゲームのUIを作るとき、ボタンやダイアログ、HPバーをそのつど一から書いていると、途中でスタイルがバラバラになります。フォントサイズが画面によって違う、ボタンの角丸が統一されていない、色の指定がHTMLの各所に散在している――こうした状態は、ゲームの見た目の完成度を下げるだけでなく、修正コストも膨らませます。 UIキットとは、ゲーム全体で使い回す部品（コンポーネント）と、それを動かすルール（デザイントークン）をひとつにまとめたものです。大規模なWebサービスで使われる概念ですが、個人が作るブラウザゲームでも同じ考え方が使えます。むしろ1人で作業するときほど、最初に部品を整理しておくメリットが大きいです。 この記事では、ブラウザゲームのUIキットを自作するための考え方と、実際にHTMLとCSSで組む手順を示します。何を部品にすべきか、どの順番で整理するか、失敗しやすいポイントはどこかを具体的に説明します。
まず「共通部品」の範囲を決める
UIキットを作ろうとして最初に詰まるのは、「何を部品にすべきか」という問いです。すべてを部品にしようとすると設計が複雑になりすぎ、逆に何も部品にしないと整理の意味がなくなります。
判断基準はシンプルです。同じ見た目・同じ動作が2回以上登場するなら部品にする。1回だけ使う要素は部品にせず、ローカルなスタイルで十分です。
ブラウザゲームで頻繁に登場する共通部品は、おおよそ次のカテゴリに分かれます。
- ボタン類：通常ボタン、アイコン付きボタン、無効（disabled）状態
- テキスト表示：見出し、説明文、スコア・数値表示
- ステータスバー：HPバー、経験値バー、進捗バー
- オーバーレイ：確認ダイアログ、チュートリアルポップアップ、ゲームオーバー画面
- アイコン・バッジ：アイテムアイコン、通知バッジ、コイン表示
- レイアウト枠：ヘッダー、フッター、サイドパネル
この中でゲームに登場するものをリストアップし、最初から全部作ろうとせず、開発中に実際に必要になったものから順番に部品化していくのが現実的な進め方です。
デザイントークンを先に定義する
部品を作り始める前に、ゲーム全体で共有する「値」を変数として定義します。これをデザイントークンと呼びます。CSSカスタムプロパティ（--変数名）で書くのが最もシンプルな実装方法です。
最低限定義しておくべきトークンは4種類です。
1. カラーパレットゲームのトーンを決める基本色（プライマリ・セカンダリ）、背景色、テキスト色、危険状態を示す赤などを:rootに書きます。色を直接コード（#ff4444など）で各所に書くのではなく、すべてトークン経由で参照するルールにします。
2. タイポグラフィスケールフォントサイズを--text-sm、--text-md、--text-lgのように段階で決めておきます。ピクセル値でなくrem単位にすると、全体のスケール変更が楽になります。
3. スペーシング要素間の余白も変数にします。--space-1（4px相当）〜--space-6（32px相当）程度の段階があれば、ほとんどのレイアウトに対応できます。
4. ボーダーとシャドウ角丸の大きさ（--radius-sm、--radius-lgなど）とドロップシャドウを変数化します。ゲームのUIは「シャープで硬い印象」か「丸くて柔らかい印象」かでキャラクターが決まるため、ここを揃えることで統一感が生まれます。
これらをui-tokens.cssという独立したファイルに書いておき、すべてのHTMLやJSからimportする構造にします。トークンのファイルが1つあることで、ゲーム全体の色や余白を一括変更できるようになります。
部品をHTMLとCSSで組む手順
トークンが決まったら、部品を1つずつ作ります。以下はボタンコンポーネントを例に手順を示します。
ステップ1：部品の状態（ステート）を洗い出すボタンであれば、通常・ホバー・押下・無効の4状態が必要です。最初からすべての状態を設計してCSSに書きます。あとから「無効状態を追加しないといけない」となると、スタイルが崩れやすいです。
ステップ2：クラス名の命名規則を決めるBEM（Block-Element-Modifier）という命名方式が広く使われています。.btnが基底クラスで、.btn--primaryや.btn--dangerがバリアント、.btn--disabledが状態を表すという構造です。命名規則を最初に決めることで、ゲームが大きくなってもクラス名が衝突しません。
ステップ3：トークンだけを使ってスタイルを書くCSSを書くとき、色や余白の値は必ずトークン変数で参照します。background-color: var(--color-primary);のように書き、#3a86ffなどの生の値をここに書かないことをルールにします。これを守ることで、トークンを変更するだけでゲーム全体のデザインが一括変更できます。
ステップ4：部品のプレビューページを作るui-preview.htmlというファイルを1つ作り、すべての部品を一覧表示するページを用意します。ここには通常状態・ホバー状態・無効状態のボタンが横に並び、各サイズのテキストが並び、HPバーが100%・50%・10%で並んでいます。開発中にデザインの確認をするためだけのファイルで、ゲームには同梱しません。このプレビューページがあると、部品の変更が他の状態に影響していないかを素早く確認できます。
失敗しやすいポイントと対処法
UIキットを自作するときに詰まりやすい場所が3つあります。
「汎用すぎる部品」を作ろうとして設計が止まるあらゆるケースに対応しようとすると、ボタンひとつにオプションが10個以上生まれ、結局どれを使えばいいか分からなくなります。まず「このゲームで実際に使う形」に限定して作り、後から必要になったときに拡張するほうが速く完成します。
トークンとハードコードが混在する開発途中で急いでいるとき、color: #ffffffを直接書いてしまうことがあります。こうした例外が積み重なると、後で色変更をしたときにその場所だけ変わらなくなります。Linterや検索で定期的にハードコードされた値を洗い出す習慣をつけると防げます。
部品が増えてファイルが大きくなるすべての部品を1つのCSSファイルに書き続けると見通しが悪くなります。btn.css、dialog.css、statusbar.cssのように部品ごとにファイルを分け、HTMLの<link>またはCSSの@importでまとめて読み込む構成にします。ただし、HTTPリクエスト数が増えすぎないよう、最終的なゲームではビルドツールでまとめるか、ZIPで配布する構成に合わせます。
JavaScriptで部品を動的に生成する場合
ステータスバーやダイアログのように、ゲームの状態に応じて表示が変わる部品は、JavaScriptで生成・更新する必要があります。この場合も、クラス名やカスタムプロパティを通じてCSSトークンを活用するのが基本です。
たとえばHPバーであれば、HPの割合（0〜1の数値）をelement.style.setProperty('--hp-ratio', ratio)でCSS変数に渡し、バーの幅をwidth: calc(var(--hp-ratio) * 100%)で表現します。JavaScriptはデータを渡すだけで、見た目の計算はCSSが担います。こうすると、HPが30%以下になったら色が変わるといった演出も、JavaScriptを変更せずCSSの@propertyやclamp()だけで実装できます。
次の行動
まずui-tokens.cssを1つ作り、ゲームで使う色・フォントサイズ・余白をCSS変数として書き出してみてください。次に、今作っているゲームの中で2回以上登場するUI要素を1つ選び、その部品だけをクラス名ベースで切り出す練習をするとUIキットの感覚がつかめます。部品が3〜5個揃ったらui-preview.htmlを作り、全部品を並べて見られる環境を整えると、以降の開発が大幅にスムーズになります。
