Monster Summoners

概要

本プロジェクトは、物理カードとスマートフォンを組み合わせた ARカードバトルゲーム「Monster Summoner」 の開発プロジェクトです。

AR（拡張現実）ならではの視覚体験に加え、ユニットごとのクラス定義（HP/ATK/DEF）や「属性相性」、「バフ・デバフ処理」といったアルゴリズムを組み込みました。単なる映像表示にとどまらず、数値ロジックに基づいた戦略的な駆け引きが成立する対戦環境を設計しています。

使用技術・開発環境

Engine: Unity
AR Framework: AR Foundation, Google ARCore XR Plugin
Language: C# (バトル管理ロジック)
Data: JSON (カードデータベース)
Design: Figma (カードデザイン)

ゲームルールとバトルの流れ

1. ゲームフローとAR体験

プレイヤー（Player1 / Player2）は物理カードから1体のキャラクターをそれぞれ選び、交互にターンを進行します。どちらかのHPが0になった時点で勝敗が決します。

1. 召喚フェーズ（Initialize）

プレイヤーが「キャラクターカード」を場に出し、カメラで認識させます。システムが2枚のカード（Player1 / Player2）を検知すると、AR空間に3Dモデルを生成（Spawn）し、バトルを開始します。

2. ターン進行（Turn Execution）

システムが先攻・後攻およびターン数を管理します。プレイヤーは1ターンにつき1回、以下のいずれかの行動を選択できます。

攻撃: 相手へのダメージ
攻撃力バフ: 自身の攻撃力強化（基礎攻撃力への加算）
HP回復: 自身のHP回復

3. 判定ロジック

プレイヤーがカードを提示すると、システムはその種類（攻撃/バフ）を判定し処理を実行します。

Case A：攻撃カードの場合 相手キャラクターへ攻撃処理を実行します。属性相性と数値を計算し、相手のHPを減算します。
Case B：バフカードの場合 自身のキャラクターへ強化処理を実行します。ステータス（ATK/HP等）を加算し、3Dモデルにエフェクトを表示します。

2. コアロジックとデータ設計

戦略性を生むため、以下の計算式とJSONによるデータ管理を実装しました。

A. ダメージ計算式 プログラム内部では、以下の式でダメージを算出しています。

damage = ( ( BaseATK + CardRate + Buff ) * AttributeBonus ) - EnemyDEF

BaseATK：キャラクターの基礎攻撃力
CardRate：攻撃カードの攻撃力（固定値）
Buff：バフカードによる加算値（ない場合は0）
AttributeBonus：属性有利（炎＞草＞水）の場合 2.0、それ以外は 1.0
EnemyDEF：相手キャラクターの防御力

B. データベース仕様（JSON） カード情報はすべて ImageID (DataID) をキーとしてJSONで管理し、動的にロードしています。

キャラクターカード: 名前 / HP / 基礎攻撃力 / 防御力 / 属性
攻撃カード: 攻撃名 / 攻撃力（固定値）
バフカード: バフ名 / 効果種別（攻撃力UP または回復） / 変動値

C. カード効果の仕様例

不死鳥（キャラクター）：HP: 2500 / ATK: 2900 / DEF: 2100
樹海竜（キャラクター）：HP: 3500 / ATK: 2200 / DEF: 2600
蒼炎の魔剣（攻撃）：ATK +700
新緑の断罪鎌（攻撃）：ATK +600
紅蓮の刻印（バフ）：ATK +400
深海の刻印（バフ）：HP +800

これらにより、単純な殴り合いではなく「属性相性とカード選択による数値変動」が勝敗を分けるゲームバランスを実現しています。

デザインとアセット制作

AR認識の精度とゲームの世界観を両立させるため、デザイン面でも工夫を行いました。

1. カード作成（UI/UXデザイン）

Figmaを使用してカードのデザインを作成しました。既存のトレーディングカードゲームに匹敵するクオリティを目指しつつ、同時に「ARマーカーとして認識しやすいデザイン（特徴点の確保）」である必要がありました。そのため、視認性と世界観を両立させるレイアウトを設計しています。

2. 3Dモデルの選定

AR表示用の3DモデルはSketchfabより選定しました。静止画ではなく、バトル時の臨場感を出すために「アニメーションが含まれていること」を選定条件とし、商用利用可能な無料アセットを活用しています。

実装詳細と技術チャレンジ

本開発では、AR認識の基盤構築と、それをゲームロジックへ融合させる工程において多くの技術的障壁がありました。具体的な実装内容と、そこで直面した課題・解決策をまとめます。

1. 画像表示・AR実装【カード認識→3Dモデル表示】

UnityのAR機能（AR Foundation）を活用し、マーカー認識から3Dモデル描画までのパイプラインを構築しました。標準的な実装サンプルでは「1つのマーカーに対し1つのオブジェクト」を表示するケースが多いですが、本ゲームは対戦形式であるため、 「複数のカードを同時に認識し、それぞれ固有のモデルを表示する」 機能が必要でした。

この複雑な要件を実現するため、以下の課題を一つずつ解決していきました。

■ 課題：開発環境と実機ビルドの壁 Unity上でAndroid SDK/NDKが正しくインストールされていないと端末を選択できず、またAndroid端末側も適切な設定を行わないと認識されませんでした。 → 解決策:

SDK/NDKの導入: Unity Hub経由で推奨バージョンのAndroid SDK/NDKをインストールし、パスを正しく通すことでビルド環境を整備。
USBデバッグ: Android端末の設定で「開発者向けオプション」を解放し、USBデバッグモードを有効化することで、Unityとの通信・実機転送を確立しました。

■ 課題：ARテンプレートの制約と最適化 既存の「AR Core」テンプレートは不要な機能が多く、ゼロからアプリを作り上げるには制約が多いことが判明しました。 → 解決策: テンプレートに頼らず、3D Core (URP) をベースに環境を構築。デフォルトのMain Cameraを削除し、代わりに AR Session、XR Origin (Mobile AR)、XR Interaction Manager を配置することで、軽量かつ制御しやすいAR環境を実現しました。

■ 課題：複数マーカーの識別とPrefab生成 ReferenceImageLibraryを用いた画像認識において、1枚の画像に対し1つの決まったPrefabしか出せない制約や、3Dモデルの座標管理が難しい問題がありました。 → 解決策:

名称一致による動的生成: 「登録画像のファイル名」と「Prefab名」を一致させ、スクリプト側で自動的に紐付けてInstantiate（生成）するロジックを実装。
透明Cubeによる座標統一: 3Dモデルを直接Prefab化すると表示されない、あるいは向きが安定しない問題に対し、「透明なCube」を親オブジェクトとして設定し、その子要素にモデルを格納する方法を採用。位置合わせの基準点が統一され、安定した描画に成功しました。

2. ゲーム内部実装【カード認識→ゲーム実行】

ゲームの核心となる戦闘ロジックの実装を行いました。各カードの能力値を管理するデータベースを作成し、それに基づいて戦闘の進行をプログラムしています。

特に工夫したのは、 「カード識別とプレイヤー識別の紐付け」 です。単にカードを認識するだけでなく、カメラに映ったカードのIDから、そのカードが「自分（Player）」のカードなのか「相手（Enemy）」のカードなのかをシステム内部で動的に識別し、適切なターゲットへ攻撃処理やパラメータ計算が行われるよう設計しました。

このロジックの実装中には、以下の課題に直面しました。

■ 課題：複数カードの同時認識とゲーム開始 プレイヤーを2人（自分と相手）読み込みたいのに、ARシステムが「1枚の画像」しか認識せず、ゲームが始まらない問題がありました。 → 解決策: AR Foundationの設定を見直し、トラッキング可能な最大画像数を拡張。さらに、認識されたカードIDをリスト化して管理し、 「2つの異なるIDが揃った瞬間」 をトリガーとしてバトルを開始するロジックを構築しました。

■ 課題：ターン管理と入力判定の不整合 「プレイヤーターンでは反応するが、敵ターンでカードを出しても攻撃処理が走らない」、あるいは「読み込んだ瞬間に意図しないタイミングで攻撃してしまう」といったバグが発生しました。 → 解決策: BattleManager（全体進行）と ARCardInput（入力検知）の役割分担を明確化。ターン状態（IsPlayerTurn）を監視し、現在のターン所有者以外の入力は無視しつつ、適切なフェーズでのみカード読み込みイベントを発火させるステート管理を導入しました。

■ 課題：データ駆動設計とJSONの扱い 攻撃、バフ、回復など、カードの種類によって処理内容が異なるため、これらをハードコーディングすると拡張性が損なわれる懸念がありました。 → 解決策: JSONデータベース側で「カードタイプ（Type）」を持たせ、プログラム側でそのタイプに応じた処理クラスへ振り分ける設計としました。

AIツールの活用

本プロジェクトでは、新しい技術領域であるAR開発を効率的に進めるため、生成AIを「技術メンター」および「ペアプログラマー」として積極的に活用しました。具体的には以下の3つのフェーズで特に効果を発揮しました。

1. 未経験技術の学習と環境構築の加速 AR開発は初挑戦だったため、最初の学習コストが最も大きな課題でした。そこでAIに対し、AR Foundationの構成要素・画像トラッキングの仕組み・Android実機ビルドの手順など、初期導入に必要なベストプラクティスを段階的に質問しました。YouTubeの解説動画とAIの技術補足を組み合わせることで、環境構築から必要コンポーネントの理解までの時間を大幅に短縮できました。

2. 設計レビューとコードスケルトンの生成 コーディング前の設計フェーズで、クラス設計や責務分割についてAIと壁打ちを行いました。「戦闘管理（BattleManager）」「画像入力の受取（Input）」「カードデータの読み込み（Data）」などの役割整理を行い、必要なメソッドの枠組み（コードスケルトン）を一緒に作成しました。これにより、実装時の迷いや手戻りが減り、コアロジックの実装に集中できました。

3. "沈黙するバグ"の解決支援 最も効果を感じたのはデバッグ工程です。コンパイルエラーは出ないのにゲームが意図通り進まない、いわゆる「沈黙するバグ（ロジックエラー）」に何度も直面しました。

カードトラッキングイベントが発火しない
ターンフラグが切り替わらず攻撃が反応しない
ARトラッキングの位置判定が誤って敵/味方が入れ替わる

これらの原因特定が難しい箇所に対し、AIにコード全体を解析させ、「この条件分岐が常にfalseになる」「イベントの登録が解除されている」などの仮説を提示してもらいました。それらを一つずつ検証することで、効率的に解決に至りました。

成長点

私たちのグループでは、今回初めてUnityのARを触りました。Unityを完全に触ったことが無いプログラミング初心者も2人いる中で、デザインやデバッグ、3Dモデルを探したりなど、それぞれが重要な役割を果たして実装を完成させることが出来ました。今回、１週間の事前準備で全員の環境構築を行ったり、ゲームのアイデアを考えたりして、実装はこの2日間で行いました。22日の夜まで3D表示やゲーム実装すらできていなかったので、今回を通してARのゲーム実装が出来るようになったという、大きな成長を感じています。

今後の展望

現在は基本的な対戦ロジックのみですが、ゲーム体験をさらに向上させるため、以下の実装を予定しています。

アニメーションの実装: 現在は3Dモデルを静止状態で表示していますが、使用しているモデルデータには既にアニメーションが含まれています。今後はこれらをスクリプトで制御し、攻撃や待機モーションを再生させることで、視覚的な臨場感を強化します。
カード種類の拡充: より深い戦略を実現するため、新しいスキルや属性を持ったカードを追加します。
勝敗ルールの拡張: 1回のバトルで終わるのではなく、「3回勝利で決着（Bo5形式など）」といったマッチシステムの導入を検討しています。