Architecture & Design
Game Logic & Architecture
「ただ動く」から「メンテナンス可能な設計」へ。
Unityの密結合を打破するDDD（ドメイン駆動設計）の導入や、
ステートマシンによる厳密なゲームフロー制御。
コレクライト (Crows & Treasures)
UnityJamは、Unity 2022.3.24f1で制作されたPC向けゲームプロジェクトです。GameManager、GameSessionManager、ショップUI、セーブデータ、宝箱や敵のギミック、unityroom連携を含み、探索とスコア更新を中心にしたゲーム進行を構成しています。
成果: 9人・1週間の短期開発で、設計、統合、CI/CDを担当し、セーブ、ショップ、ランキング、演出をつないでunityroom公開まで進めました。
9人チームでの設計リード・統合・CI/CD構築
カラスを操作してダンジョン内の財宝を集めるアクションゲームです。9人チームでの1週間開発において、アーキテクチャ設計・全機能の統合（セーブ・ロード・ショップ・演出など）・GitHub Actions を用いた CI/CD パイプライン構築を一手に担当しました。
カラス操作・ダンジョン探索
GameManager ステート遷移（FSM）
9人が並行開発できるよう、GameManagerにステートマシンを実装し責務を明確に分割。タイトル・探索・ショップ・イベントの状態遷移を厳密に管理し、チームメンバーが設計意図を逸脱しにくい構造を構築した。
各メンバーが実装したセーブ・ロード・ショップ・演出・ランキングを一つのゲームとして結合。インターフェース経由で依存を逆転させ、統合時の衝突を最小化しながら商用レベルの完成度を達成した。
GitHub Actions でビルド自動化・自動テスト・unityroom へのデプロイフローを整備。短期開発でもリグレッションを早期検出し、全員がメインブランチへ安心して push できる環境を提供した。
設計の意図
9人・1週間という制約の中で、「設計・統合・CI/CD」の3役を同時に担うことで、チーム全体の生産性と品質を底上げすることを最優先としました。アーキテクチャの明確化が並行開発の摩擦を減らし、CI/CD の整備がレビュー・マージの心理的コストを下げた結果、1週間で全機能が揃った状態でリリースできたことがこの方針の有効性を示しています。
ONE MORE PLANK (Game Jam)
ONE MORE PLANKは、Unityで作られた一人称視点の板配置パズルアクションです。プレイヤーは移動・ジャンプしながら、標準板や呪い板を設置・回収・回転させ、部屋ごとの足場や障害物を越えてEndZoneを目指します。
成果: 2日間のゲームジャムで、板配置、部屋進行、演出、ランキング連携を実装し、短期間でも拡張しやすい名前空間構成を維持しました。
短期開発でも設計品質を落とさない
ゲームジャムで制作した板を置いてキャラクターを誘導するパズルアクションゲームです。二日間しか製作期間が取れなかった中で、制限時間内での完成を優先しつつ、後から読めるコードを維持するために、Core・Player・Level・UI・Visuals を名前空間で明確に分離した構成を取っています。
ゲームプレイ画面
名前空間による責務分割 (Core / Player / Level / UI / Visuals)
GameManagerはStateHistoryをStackで保持し、部屋の前進・後退をイベント（OnTimeChanged / OnLevelLoaded 等）で通知する設計。MonoBehaviour間の直接参照を持たせず、購読によって依存を逆転させている。
GameJuice.cs に画面揺れ・SE・振動フィードバックをまとめ、他のクラスがロジックを汚染せずに演出を呼び出せる構成。ゲームジャムにおいてもJuiceを後付けにしない判断で実装した。
クリアタイムを UnityroomApiClient で送信し、外部ランキングと連携。API呼び出しはGameManager内の勝利判定フローに統合し、ゲームロジックと通信処理の責務を分けたまま接続している。
設計の意図
ジャムゲームは「とりあえず動けばいい」になりやすいですが、このプロジェクトでは名前空間分離とイベント購読の構造を最初から採用しました。短期間でも設計の骨格を維持することで、終盤の機能追加（NarrativeManager・SettingsManager）がほぼ既存コードに触れずに済んだことが、この方針の有効性を確認する結果になりました。
factoria (Production Design)
factoriaは、20人規模の製造ラインを運営し、品質・スループット・ブランド・安全性のKPIを伸ばすUnity製の工場経営プロトタイプです。0.2秒Tickのライン更新、日次の市場計算、故障イベント、セーブ／ロードをDomain、Simulation、Presentation、Infrastructureに分けて実装しています。
成果: 製造ライン、Worker、KPI、市場、故障、セーブ/ロードを層分離し、Unityに依存しないDomain/Simulationとして検証できる形にしました。
Unityにおける密結合の完全な打破
複雑な生産ラインの整合性を保ちながらシミュレーションを行う工場経営ゲームのプロトタイプです。Unity特有の「なんでもMonoBehaviourに依存してしまう」アンチパターンを意図的に排除し、純粋なC#ロジックを独立させる設計を追求しました。
Domain / Simulation / Infrastructure / Presentation
DDDに基づく4層アーキテクチャ
コードベースは Domain（純粋なビジネスロジック）, Simulation（実行フレームワーク）, Infrastructure（永続化と外部通信）, Presentation（Unityの描画と入力）の4つの層に完全に分割されています。シミュレーション部分はUnityのフレームワークなしでもテスト可能な構造を維持しています。
コンポーネント間の疎結合を徹底。生産施設の動的生成とロジックの注入をファクトリーパターンで安全に行い、オブジェクト間の直接参照を排除。
施設が数千に及んだ場合でも、ロジックと描画が明確に分離されているため、計算負荷のプロファイリングと最適化が容易な構成を実現。
設計の意図
Unity特有の「MonoBehaviourになんでも依存させてしまう」アンチパターンを意図的に排除することで、シミュレーション部分をUnityなしでもテスト可能な構造にできるか検証したいと考えました。後のチーム開発でコンポーネント分割の判断基準となっています。