このリポジトリは、私がこれまでに開発したゲームプロジェクトのソースコードをまとめたポートフォリオです。 プロジェクト全体には公開できないアセット等が含まれているため、設計思想や実装の工夫が分かる主要なスクリプトを抜粋して掲載しています。
個人制作の3Dアクションゲームのプロトタイプです。「GameClientCollege」で学んだ内容の実践、試行錯誤を主目的として掲げつつ、これまでの集大成となる作品を目指して制作中です。
このプロジェクトでは、特に拡張性と保守性を重視した設計を目指しました。DIコンテナ（VContainer）とStateMachineパターンを組み合わせることで、機能の追加や変更が容易な疎結合なアーキテクチャを実現しています。
-
DI (VContainer) による依存関係の解決
CompositionRootにて、依存関係の注入を集約的に管理しています。- Presenter層をDIコンテナで代替することでコードの総数を削減しています。
- BehaviourとTransition についてはリフレクションを用いてAssembly内からインターフェースの実装を自動検出しコンテナに登録することで、新しいクラスを追加するだけでDIの仕組みに組み込まれるようにし、拡張性を高めています。
- （パフォーマンスへの考慮：起動時の処理負荷は増加しますが、開発中の拡張性を優先するトレードオフとして許容しています。）
-
複数のTimeScaleを管理するTimeManager
- 演出に使用するため複数のTimeScaleを管理できるクラスを定義しています。
- インターフェースでのみ公開し意図しないアクセスを除外するため、各Tickを管理するTimeModelをinternalで隠蔽しています。
-
StateMachineによるプレイヤーキャラクター管理
- プレイヤーの状態（待機、移動、攻撃など）をStateMachineパターンで管理しています。
- 各Stateに「振る舞い」「遷移条件」「遷移時の演出（カメラワークなど）」を責務として分離し、それぞれをDIで結合しています。これにより、既存のコードに影響を与えることなく、新しいStateや振る舞いを追加できます。
StateKeyAttributeのようなカスタム属性を活用し、どの振る舞いがどのStateに対応するかを宣言的に記述できるようにすることで、可読性とメンテナンス性を向上させています。
- Presenter層の省略による構造把握の難しさ
- DIによる依存関係の自動解決を多用した結果、各クラスがどのように連携しているかの全体像がコードから読み取りにくくなる側面がありました。
- この点はドキュメントで補うことで緩和できますが、その場合はドキュメントを常に最新に保つという新たな課題が生まれると考えています。
3人チームで開発したネットワーク対戦3Dアクションゲームです。ゲームジャム「Re;Build in 愛知 2025」にて制作しました。（担当：インゲームの動作全般、ネットワーク同期など）
このプロジェクトでは、ネットワーク対戦における判定の堅牢性と、プレイヤーの操作感（手触り）の両立を目指しました。通信の遅延による影響を最小限に抑えつつ、整合性を確保するアーキテクチャを設計しています。
-
使用ネットワークライブラリ: Photon
- 採用理由: 無料で利用可能である点と、ゲームジャム「Re;Build in 愛知 2025」という10日間の短期開発において、扱い慣れている技術で迅速にプロトタイピングを行う必要があったためです。
-
ユーザーを意識した同期方針
- ダメージ処理: プレイヤーの操作への即時フィードバックを優先するため、ダメージ計算は各クライアントのローカルで先行して実行し、その結果を他のクライアントに同期します。これにより、攻撃がヒットした際のレスポンスが良く、快適な操作感を実現しています。
- 勝敗判定: ゲームの勝敗に関わる重要な判定（例：オブジェクトの破壊、勝敗決定）については、Masterクライアントが権威を持つ形（Authoritative）で処理します。各クライアントからのリクエストをMasterクライアントが受け取り、両クライアントのダメージ処理結果が揃うのを待つための遅延を挟むことで、公平な判定を下して全クライアントに通知します。これにより、プレイヤー間の状態の不整合を防ぎ、堅牢性を担保しています。