「Lighthouse」ってなに？
中規模〜大規模なUnityプロジェクトにおいて、
「構造を強制することで開発効率と保守性を安定させる」
ためのUnityアーキテクチャフレームワークです。
デモ
長ったらしい紹介文を読み始める前に、まずはWebGLで動くデモを触ってみましょう！
GitHub:
何が出来るの？
Lighthouseは
- シーン遷移・UI・入力・非同期処理などのゲームとして必須の処理の基盤化
- イベント駆動 + DIにより依存方向を制御
- コード生成により実装者ごとの品質のばらつきを抑制
という要素を提供することで、
- プロジェクト黎明期にシニアエンジニアが準備しなきゃいけない機能を大幅に削減
- スキル差のあるチームでも一定の開発効率を維持
- LighthouseがラップしたUnityの機能を利用することで「Unityあるある」なバグを踏みにくくする
- 長期運用に耐えやすい設計にメンバーの実装を誘導する
- AIにコーディングしてもらいやすいクリーンアーキテクチャをプロジェクトに採用
といったことが実現出来ます。
（MITライセンスのため無料で利用可能です！）
Lighthouseの設計方針
Lighthouseは以下の3点を設計の軸としています。
1. シーン中心のアプリケーション構造
- シーンを単位としてライフサイクルを定義
- スタックベースで遷移管理
- UIも含めて「状態遷移」として扱う
→ 「どこからどこへ遷移するか」が明確になる
2. イベント駆動による依存制御
- シーンライフサイクルはイベントとして提供
- 各処理はイベントに応答する形で実装
これにより、
- 依存方向が一方向に揃いやすい
- 相互参照や循環依存が発生しにくい
→ 構造的に破綻しにくいコードになる
3. DI前提のモジュール設計
- 各機能はインターフェース経由で利用
- 実装はDIコンテナで差し替え可能
→ 機能の差し替え・拡張が局所化される
Lighthouseの構造
Lighthouseは大きく2層に分かれています。
Lighthouse.Core（基盤）
シーン管理を中心としたアプリケーションの骨格を提供します。
- シーンのスタック型遷移管理
- シーンキャッシュ管理
- ライフサイクルイベント
- 3D/2D(Canvas)の統合管理
- 排他遷移 / クロスフェード
→ Lighthouseは アプリケーション全体の制御フローを担う層
Lighthouse.Extends（ミドルレイヤー）
ゲーム開発で頻出する機能をモジュールとして提供します。
- アニメーション制御
- ダイアログ基盤
- ローカライズ
- 入力レイヤー化システム
- ボタンの排他制御
- 他
Lighthouse.Extendsはこのような
- 「ゲームには絶対必要なんだけど実装するはめんどくさい」
- 「けど量産フェーズに入る前にはないといけない」
といった機能をまとめたモジュール群です。
→ Lighthouse.Extendsは 「毎回作る機能」を削減し、開発の初速を上げる層
なぜ開発効率が上がるのか？
単に機能が揃っているだけではなく、
- ゲームの構造を固定すること
- プロジェクトの工程間の依存を部分的に解消出来ること
が主な理由です。
1. 実装パターンが統一される
コード生成ツールにより、
- シーン
- UI（ScreenStack）
などの雛形が自動生成されます。
→ 実装の書き方が揃うためレビューコストが下がる
2. 依存関係が制御される
イベント駆動 + DIにより、
- 呼び出し関係が明示的になる
- 暗黙の依存が減る
→ 不具合の原因追跡が容易になる
3. 定型処理の再実装が不要
- 入力
- UI遷移
- ローカライズ
- アセット管理
→ プロジェクトごとの“作り直し”を削減
剣（基盤）の品質は、基盤設計に詳しいメンバーが担保する。
剣の品質が一定であれば、兵士（実装者）に実力差があっても、
成果のばらつきを抑えやすくなり、チーム全体の出力を安定させる、という考え方。
プロジェクトワークフロー上の優位性
ゲーム開発は各メンバーが持っている作業を一斉に始めて全部終わらせれば完了、となるものではありません。
作業には順序と依存関係があり、「ダイアログを作る作業」は「ダイアログのシステム」の作業が終わっていて初めて作業を開始することができます。
Lighthouseを利用する優位点は、予め用意されているこれらの機能を利用することで、こういった工程を組み立てる時の依存関係を減らし、プロジェクトワークフローのより早い段階で作業を開始することが出来る所です。
その後もしプロダクトとして必要な変更が発生しても、
シニアエンジニアは「それが発覚した時にDIで実装の拡張・差し替えを行う」という戦略が取れるようになります。
この 「クリティカルパスになりえる項目が、既にある程度実装されている」 という状態は、
プロジェクトの状況に応じて柔軟に作業工程を組み替えることが出来るということを意味し、プロジェクト全体の安定感に繋がります。
こんなプロジェクトに向いてます
適しているケース
- 中規模〜大規模開発
- 長期運用（運営型ゲーム）
- 複数人開発（5人以上）
- スキル差があるチーム
こんなプロジェクトには向いてません
- 数シーンで完結する小規模プロジェクト
- ハイパーカジュアル
- 1〜3人の短期開発
※初期導入コストに対してリターンが小さい
技術スタック
- クリーンアーキテクチャベース
- UniTask（非同期処理）
- DI（依存性注入）
これにより、
- ビジネスロジックの分離
- テスト容易性の向上
- 純C#部分の再利用性
を狙っています。
まとめ
Lighthouseは、
- 構造を強制することで、
- 属人性を下げ、
- 長期開発に耐えるコードベースを維持する
ことを目的としたフレームワークです。
特に、
- チーム開発
- 運営型タイトル
において効果を発揮します。
その他
インディーズ向けに、セットアップ済みの空プロジェクトも用意しています。
VContainerやUniTaskなどを含めた構成になっているため、
これらの技術を実践的に学びたい場合にも利用出来ます。