Unity 2D アイドル育成シミュレーション（Steam向け）
ゲームのロジックとバランスのデータを分けた、データ駆動型のゲーム基盤を8週間で構築。
Overview
プロジェクト概要
2Dの画面を中心としたアイドル育成シミュレーションゲームを対象に、ゲームのロジックと、バランスを決めるデータを分けた「データ駆動型」の基盤を構築しました。プレイヤーは、年・月・週で進む時間の中でスケジュールを見ながら育成のコマンドを選び、Vocal・Dance・Mental・HPの4つのパラメータを育てます。条件を満たすとイベントが起き、最後はそれまでの状態に応じてエンディングが分かれます。
このプロジェクトの中心となる課題は、2Dの画面の実装そのものではありませんでした。「ゲームのバランスを変更する担当者」と「ゲームを実装する担当者」の責務を、どう分けるかにありました。コマンド、イベント、パラメータ、エンディングの条件、テキストはGoogleスプレッドシートで管理し、Unity側では検証・取り込みを経てゲームのロジックから参照します。Steamworks、ゲームパッド、日本語・英語・簡体字中国語の多言語化、デバッグ用ツールも同じ基盤の上で扱い、将来のSwitchへの移植で変更する範囲を限定できるように設計しました。
※ 掲載している画面、キャラクター、ゲームタイトルは、説明用に再構成したイメージです。
- 分類
- Unityによる2Dゲームの開発（アイドル育成シミュレーション）
- プラットフォーム
- Windows（Steam）。将来のSwitchへの移植を考慮した設計
- 開発期間
- 8週間（約2か月）
- 体制
- Unityエンジニア1名
- 対応言語
- 日本語 / 英語 / 簡体字中国語
- 業種
- ゲーム（PC / Steam）
- ロール
- ゲームの基盤の設計・実装 / ゲーム進行 / マスタデータの取り込み / 開発用ツール / 多言語化 / Steam・ゲームパッド対応 / セーブ・ロード / 画面の構成
- 技術
- Unity / C# / uGUI / TextMeshPro / Unity Input System / Steamworks.NET / Google スプレッドシート / JSON / Git
01 — ゲームの流れ
選んだ行動が、アイドルの未来を変えていく
ゲームの中心は、「スケジュールの確認 → コマンドの選択 → パラメータの変化 → イベントの発生 → 次のターン」という繰り返しです。プレイヤーはボーカルレッスンやダンスレッスン、宣伝・SNS、休みなどのコマンドを選びます。画像の例では、ダンスレッスンを選ぶとDanceが+8、HPが−10になります。コマンドの効果でパラメータが変わり、日付・パラメータ・フラグ・前に起きたイベントを条件にイベントが起きます。最後は、条件と優先順位をもとにエンディングが1つに決まります。画面はTitle・Schedule・Command・Event・Status・Endingの6つで、uGUIとTextMeshProで作りました。
- 年・月・週で進む時間と、スケジュールの確認
- コマンドの効果で4つのパラメータが上下
- 日付・パラメータ・フラグを条件にイベントが発生
- 条件と優先順位でエンディングを判定
開発中の課題と解決
ゲームのルールを、画面の側に分散させない
- 課題
- ゲームのルールが画面ごとの処理に散らばると、画面が増えるたびに条件分岐が増え、通常のプレイ・デバッグ・セーブで動きが食い違うおそれがあります。
- 解決
- 時間、パラメータ、フラグなどを持つGameStateをゲームのルールの中心に置き、進行・コマンド・パラメータ・イベント・エンディング・セーブをそれぞれのサービスに分けました。負の数、上限・下限、コスト不足などのルールはサービスの層に集め、画面は表示と入力だけを受け持ちます。
02 — データ駆動のゲームバランス
ゲームバランスを、データから育てる
ゲームのバランスをコードに埋め込まないことを、設計の原則にしました。コマンドの効果、イベントの条件と効果、パラメータの初期値と範囲、エンディングの条件、テキストは、すべてGoogleスプレッドシートで管理します。Unity Editorの上には、Validate（検証）、Import（取り込み）、Export（書き出し）をまとめた開発用ツールを作りました。スプレッドシートの内容をCSVで取り込み、IDの一意性、参照の正しさ、必須項目、型と範囲を検証してから、ゲームが参照するデータにします。リリース版は、スプレッドシートとの常時の通信に依存しません。
- コマンド・イベント・パラメータ・エンディング・テキストをマスタで管理
- スプレッドシートを編集の場所にし、CSVで取り込み
- Unity Editor上の取り込みツール（検証・取り込み・書き出し）
- データの不整合を、実行時ではなく取り込みの時点で検出
開発中の課題と解決
マスタの入力の誤りを、取り込みの時点で見つける
- 課題
- マスタを手で入力すると、存在しないIDを参照する、単位や範囲の認識の違いで異常な値が入る、列の構造が変わる、といった不整合が起こりえます。
- 解決
- 取り込みの前に、参照の検証と、スキーマ・範囲の検証を行う構成にしました。スキーマには版を持たせ、マスタの構造の変更にも備えています。不整合はゲームの実行時ではなく、取り込みの時点で検出されます。
03 — デバッグ用ツール
何時間も進めなくても、見たい場面へ
育成ゲームでは、特定のイベントやエンディングを確かめるために、長時間のプレイを何度も行う必要があります。そこで、開発ビルド用のデバッグメニューを作りました。年・月・週、Vocal・Dance・Mental・HPの値、イベントのフラグを指定して適用でき、「次の週へ進める」「イベントを発生させる」「エンディングへ移動」もボタン1つで行えます。デバッグメニューは、通常の画面と同じサービスの層を通してGameStateを操作するので、デバッグ専用のロジックが二重になることはありません。
- 時間・パラメータ・フラグを指定して状態を再現
- 週の進行、イベントの発生、エンディングへの移動
- 通常の画面と同じサービスの層を経由
- エンディングの境界値（閾値の前後）の確認に活用
開発中の課題と解決
最初から、ゲームパッドで操作できる設計にする
- 課題
- マウスのクリックだけを前提に画面を作ると、後からゲームパッドに対応するときに、画面の設計を変える必要が出ます。
- 解決
- Unity Input SystemのInput ActionとUI Navigationを、初期の設計から採用しました。決定・取消・移動・ページ送りなどの操作をInput Actionとして定義し、キーボード・マウスとゲームパッドの両方に割り当てています。
04 — Steam対応と将来の展開
Steamで遊べる。その先の展開にも備える
Steamとの接続にはSteamworks.NETを使い、初期化、実績（Achievement）、コントローラーに関する処理を、プラットフォームとの境界にまとめました。表示する文章は画面やコードに直接書かず、Text IDをキーにして日本語・英語・簡体字中国語を参照します。セーブは、画面に表示している値ではなくGameStateから作ったデータをJSON形式で保存し、ロード時に検証してから復元します。リリース候補の段階では、起動、シーンの移動、メモリ、入力、SDKの初期化を、Steamで配布する形のビルドで確かめました。
- 日本語・英語・簡体字中国語の3言語に対応
- Steamの実績とコントローラーに対応
- キーボード・マウスとゲームパッドの両方で操作
- JSON形式でのセーブ・ロードと、読み込み時の検証
開発中の課題と解決
Steam固有の処理を、ゲームのルールから切り離す
- 課題
- SDKの呼び出しがコードのあちこちに散らばると、ゲームがプラットフォームに強く結び付き、ほかのプラットフォームへ移植するときに変更する範囲が広がります。
- 解決
- Steam固有のAPIはゲームのルールの層に直接書かず、Platform Serviceの奥に隔離しました。ゲームのロジックはGoogleのAPIやSteamのSDKに直接依存しないため、将来Switchへ移植するときも、プラットフォーム用の部分を差し替えるだけで済む構造です。
Scope
担当範囲
当社は、Unityエンジニア1名の体制で、ゲームの基盤の設計と実装を担当しました。要件を領域ごとに分け、それぞれに設計上の対応を決めています。
| 工程 | 担当 |
|---|---|
| Game（ゲーム本体） | 年間の育成、スケジュール、コマンド、イベント、エンディング（GameFlow、GameState、Event） |
| Data（データ） | Googleスプレッドシートをマスタとして使う（Loader、Validator、Repository） |
| Tool（開発用ツール） | マスタの取り込み、デバッグ（Unity Editor上のツール、Debug UI） |
| Localization（多言語化） | 日本語、英語、簡体字中国語 |
| Platform（プラットフォーム） | Steamの実績、コントローラー（Platform Adapter、Input System） |
| Future（将来への備え） | Switchへの移植を考慮し、プラットフォームに依存する部分を分離 |
Architecture
使用技術・システム構成
- エンジン・言語
- Unity 2022.3 / C#
- 画面（UI）
- uGUI（Unity UI） / TextMeshPro
- 入力
- Unity Input System（Input Actions、UI Navigation）
- プラットフォーム
- Steam（Steamworks） / Steamworks.NET
- マスタデータ
- Googleスプレッドシート（編集） / CSVでの取り込み / Loader・Validator・Repository
- 多言語化
- Text IDをキーにしたLocalizationManager（日本語・英語・簡体字中国語）
- セーブ・ロード
- SaveData DTO / JSON形式のSerializer / ローカルのセーブファイル
- デバッグ・管理
- ゲーム内のDebug UI（開発ビルド用） / Git
主な技術の選定理由
マスタデータ駆動
バランスの値をコードに埋め込まず、スプレッドシートで調整できるようにするためです。バランスを変える担当者と、実装する担当者の責務を分けられます。
UI・ゲームのルール・データ・プラットフォームを分ける構成
バランスの変更、表示言語の変更、入力デバイスの変更、Steam固有の処理を、それぞれ独立して変更できるようにするためです。
ローカルの実行時データで動かす
開発版ではスプレッドシートを編集元として使いつつ、リリース版を常時の通信に依存させない選択肢を確保するためです。
GameStateを中心に置く
通常のプレイ、デバッグ、セーブ・ロードが、同じ状態のモデルを使えるようにするためです。
Process
開発の進め方
- 1
最初にゲームを最後まで通せる最小の形（Vertical Slice）を作り、その後に、データの量、画面、Steamの機能を広げる方式で進めました。
- 2
週ごとに、その週の終わりに何が動く状態になるかを区切りとして定めました。1週目：中心の設計 / 2週目：データの読み込み / 3週目：中心の繰り返し / 4週目：最後まで通して動く / 5週目：画面の接続 / 6週目：3言語とコントローラー / 7週目：Steamとの統合 / 8週目：リリース候補。
- 3
ソースコードはGitで管理しました。
Quality & Security
品質・セキュリティ・運用
マスタ
取り込みの時点で、IDの一意性、参照、必須項目、型と範囲を検証します。
エンディングの判定
閾値の1つ下・閾値・1つ上の境界値、複数の条件が同時に成り立つ場合の優先順位、成り立たない場合に通常の流れへ戻ることを確かめます。
多言語
未翻訳、重複、参照切れを検証し、言語を切り替えた直後の描き直しを確かめます。
入力
キーボード・マウスとゲームパッドの、それぞれの操作を確かめます。
ビルド
Steamで配布する形として、起動、シーンの移動、メモリ、入力、SDKの初期化を、リリース相当の設定で確かめます。
デバッグ用ツール
確かめたい状態をデバッグメニューから再現して、イベントやエンディングを確認します。
Results
成果
多言語化、入力、Steamworksをゲームのルールから分けることで、PC版の開発の速さを保ちながら、将来のプラットフォームの変更に対して、一部の変更で対応できる構造にしました。
- ゲームのロジックとバランスのデータを分けた、データ駆動型の基盤を構築しました。
- バランス、表示言語、入力デバイス、Steam固有の処理を、それぞれ独立して変更できる構造にしました。
- Unity Editor上の取り込みツールで、データの不整合を取り込みの時点で検出できるようにしました。
- 日本語・英語・簡体字中国語の3言語と、Steam（実績、コントローラー）、ゲームパッドに対応する基盤にしました。
- Unityエンジニア1名で、要件の整理からリリース候補のビルドまでを、8週間で進めました。
FAQ
技術面のよくあるご質問
- Q. 何を使って作りましたか？
- Unity 2022.3とC#です。画面はuGUIとTextMeshPro、入力はUnity Input System、Steamとの接続はSteamworks.NETを使いました。マスタはGoogleスプレッドシートで作り、CSVで取り込みます。セーブはJSON形式です。
- Q. ゲームのバランスは、どこで調整しますか？
- Googleスプレッドシートを、マスタの作成と編集の場所にしています。バランスの値はコードに埋め込まず、コマンドの効果、イベント、エンディングの条件もデータとして持たせています。
- Q. リリース版は、常にスプレッドシートとつながっている必要がありますか？
- いいえ。ゲーム側には「検証 → 取り込み → ローカルの実行時データ」という経路を持たせ、リリース版を常時の通信に依存させない選択肢を確保しています。
- Q. ほかのプラットフォームへの移植は考えられていますか？
- Steam固有の処理をPlatform Serviceに隔離し、将来Switchへ移植するときに、変更の範囲を限定できるように設計しています。
Tech Stack