【Unity 6】4人で作るコイン収集ゲーム｜GitHub Desktopチーム開発 実践2（3日間・18限）

2024年10月16日2026年11月12日

Gitチーム開発シリーズ・Unity実践2：シリーズ目次｜前の実践：2人でPrefab分担を学ぶ（6ステップ）。今回は4人を基本に、3日間・18限でUI・効果音・ビルドまで進めます。前の実践として、担当ごとにテストシーンを保存して共有する実務フロー編も学んでおくと、確認方法の選び方が分かります。

この記事の使い方：担当表・時限表・制作手順に沿って進めます。授業の開始時と終了時の話し合いには、進行ガイドの短い確認シートを利用できます。

今回は新しいチーム用プロジェクトCoinCollectorを作る演習です。前編のリポジトリへそのままコードを追加する手順ではありません。前編の経験を使って作り直し、担当を4人に広げます。PlayerMovementやCoinCounterを今回のプロジェクトへ重複して持ち込まないでください。

前の記事のコードの考え方は引き継ぎますが、UnityプロジェクトもGitリポジトリも、前のものは使わず新しく作ります。プロジェクト名は次のとおりです。

期間：基本制作3日間（1日6限・合計18限）＋必要に応じた追加3日間。時限の配分は目安です。Unity・C#の基礎、WinFormsでのチーム開発、2人版Unity（6ステップと実務フロー編）を学習済みとします。

始める前の確認：4人でA〜Dの担当を決め（3人のときはA〜Cの担当を決め、「3人チームの場合」を見ます）、全員がGitHubアカウントとGitHub Desktopを使えることを確認します。Unity Hubに表示されるUnity 6のEditorバージョンを読み合わせ、4人で同じバージョンを使います。各限の終わりには、18限チェックリストで、次へ進める状態かをチームで確認します。

前編との対応と、今回新しく学ぶこと

完成するのは、見下ろし型の画面でPlayerを動かし、Coinを10個集めるゲームです。クリア表示の後にRestartを押すと、Coin・スコア・Playerの位置が初期状態へ戻ります。

4人の担当と、先に決める受け渡し

AはPlayerと統合を担当し、CoinはB、GameManagerとUIはCに分けます。CがGameManager.prefabの編集者です。Dは音声素材（授業用の自作素材を2-3で配布します）をPRで渡し、GameManagerへの音声割り当てはCが行います。

進行係の決め方：この演習では、A〜Dの制作担当とは別に、チーム全体を指揮するリーダーを必ず決める必要はありません。作業開始時に予定を確認し、終了時に進捗や困りごとを共有する「進行係」を日替わりで交代しても構いません。例えば4人チームでは、1日目をB、2日目をC、3日目をDが担当し、Aはシーン統合に集中できます。3人チームの場合はA〜Cで分担を相談してください。他の人を進行係に推薦するときは、本人の意向を確認し、推薦した人も自分が引き受ける仕事を考えましょう。進行係だけが完成の責任を負うのではなく、全員が自分の制作担当・PRレビュー・動作確認に協力します。

Dの画像素材：Player・Coinの画像は、授業用に用意した素材のZIPのSpritesフォルダー（player.pngとcoin.png）を使うか、自分で描いた・探した画像に差し替えます。ZIPを使う場合は、Assets/Spritesへ配置し、InspectorでPixels Per Unitを128、Filter ModeをPointにします。1ユニットの大きさで、ドット絵がくっきり表示されます。自分で探す場合は、商用利用・改変・再配布の条件と、クレジット表記の要否を確認します。どちらの場合も、出典をREADMEに記録して、2限までにPRを出します。

コードの受け渡し：BのCoin.csはGameManager.Instance.AddCoin()を呼びます。そのためCは、GameManager.csとGameManager.prefabを最初の小さなPRで共有します。Bはそれをmainから取り込んでからCoin.csを追加します。Cのスコア表示はHUD内で完結するため、HUDの配置づくりはA・Bの完成を待たずに進められます。

共通ルール：PRは成果物ができた時点で出す

1. Playを止め、担当のコード・Prefabなど必要な成果物を保存してから、GitHub DesktopでChangesを確認します。確認用シーンの変更はPRに含めません。ブランチ切り替え・Pull・Merge・Update from mainの間はUnityを閉じ、未確定の変更を別ブランチへ持ち越さないようにします。Gitの操作が終わったらUnityを開き直し、Consoleにエラーがないことを確認します。
2. 最新mainをFetch → Pullして担当のfeature/…ブランチを作ります。2人用の練習では、2人が同じmainから同時にブランチを作りました。今回は、先に共有するものがある場合（1日目のBは、CのGameManagerがmainに入ってから作ります）、そのPRがmainに入ってから、最新mainを取り込んで作ります。2日目は、1日目の統合が入った最新mainから作ります。編集するファイルと、その担当者をSlackやREADMEで共有します。
3. PrefabはPrefab Modeで編集するか、一時配置したインスタンスから変更をPrefabへ保存します。担当機能の確認用シーンはPRに含めません。何を配置してテストするかは後の「担当別テスト表」で確認します。
4. 小さな成果物ができたらCommit → 初回はPublish branch、以後はPush origin → PR（base = main）を作ります。変更ファイルと確認結果を記載し、別のメンバーがレビューしてからマージします。レビューする組み合わせは最初に決めておきます（例：A↔B、C↔D）。PRを5限までためる必要はありません。
5. 先のPRがmainへ入ったら、次の担当者はmainでFetch → Pullし、自分の作業ブランチへ戻ってBranch > Update from mainを実行します。mainをPullしただけでは作業ブランチは更新されないため、この操作で最新のmainを取り込みます。再確認・PushしてPRを更新します。
6. Aだけが統合用ブランチ（例：feature/integrate-day1）でMainSceneを編集します。統合もPR・レビュー・マージを通し、全員がmainをPullして動作を確認します。

今回の動作確認の進め方：実務フロー編では、担当別テストシーンを保存して共有しました。今回は、UI・効果音・ビルドまで完成させることを優先し、確認用に一時配置したシーンの変更はPRに含めない方法（6ステップと同じ）を基本にします。実務フロー編のテストシーンを使いたいチームは、次の順に進めます。どちらの方法でも、MainSceneを編集するのは統合担当のAさんだけです。

1. Aさんは1日目の最初に、Assets/DevScenesフォルダーを作り、.gitkeepを置いて、Commit・Pushします（1-1の初期Commit・Publishに含めて構いません）。
2. ほかのメンバーは、CloneまたはPullでそのCommitを受け取ってから、各自のテストシーンを作ります。受け取る前に自分でDevScenesを作ると、フォルダーの.metaが別々にでき、PRの統合で衝突します。
3. 担当ごとに別のシーン（例：PlayerCheck、CoinCheck、HUDCheck）を作ります。テストシーンはPRに含めて構いません。MainScene.unityだけは含めません。

レビューではコードだけでなく、Prefabの設定と変更ファイルも確認します。PR説明に確認時の画像や短い動画を付ける方法も使えます。復習が必要な場合はブランチ編・PR編・WinFormsの担当別開発と同期を参照してください。

レビューの進め方：通常のPRレビューは、GitHubのFiles changedで行います。PrefabのInspector設定や動作を実際に確認する必要があるときだけ、次の手順で相手のブランチをUnityで確認します。

レビュー結果で迷ったら：Approve・Request changes・Dismiss review・Closeの違いとレビュー後の進め方を確認してください。メールを見ない場合の確認方法や、修正後の再レビューも説明しています。

1. Playを止め、自分のChangesが残っていないことを確認して、Unityを閉じます。
2. GitHub DesktopでFetch originを行い、Current Branchの一覧から相手のfeature/…ブランチへ切り替えます。
3. Unityを開き、確認します。確認だけで、変更は保存しません。
4. Unityを閉じ、GitHub Desktopで自分の作業ブランチへ戻します。戻したらUnityを開き直して、作業を再開します。

基本制作の3日間は、この記事の仕様どおりに作ります。「こうしたら良くなりそう」と思いついたアイデアはメモしておき、基本制作が終わってから「発展制作」で取り組みます。

1日目：共有準備とコイン収集ゲームの基本動作

到達点：全員のPCでPlayerが動き、Coinが消えてスコアが増える。素材は四角・丸で構いません。

PRとレビューは各時限で随時行います。先に終わった担当者はレビューや別PCでの確認を手伝います。素材と音の担当であるDは、先に終わりやすいので、レビューとテストを積極的に引き受けます。

1-1：新しいチーム用プロジェクトを共有する

README.mdを初めて使う人へ

README.mdは、プロジェクトの説明とチームで共有する約束事を記録するファイルです。リポジトリの一番上（Assetsフォルダーと同じ階層）に置くと、GitHubのリポジトリ画面でも内容を確認できます。今回の演習では、担当ファイル、連絡方法、素材の出典、動作確認の結果を少しずつ書き足します。

初めて作る人は、伝わるGitHub README.mdの書き方 ― 就活で「読まれる」ポートフォリオにするために の「README.mdはどこに、どうやって作るのか」と「基本構成」を先に読んでください。今回必要なMarkdownは、見出しの # と箇条書きの - くらいです。就職活動向けの画像や装飾まで作る必要はありません。

この演習の最小テンプレート

リポジトリの一番上に README.md を作り、次を参考にチームで決めた内容を記入します。名前、連絡方法、PRのリンク、確認結果、素材の出典は、実際に使った情報へ置き換えてください。未確認の項目は確認済みと書かず、後で追記します。

# CoinCollector

## ゲームの概要
Playerを動かしてCoinを10個集めるゲームです。

## 担当と主なファイル
- A：Player・シーン統合（PlayerController.cs、Player.prefab、MainScene.unity、ビルド設定）
- B：Coin・取得エフェクト（Coin.cs、Coin.prefab、CoinCollectEffect.prefab）
- C：スコア・クリア・UI（GameManager.cs、GameManager.prefab、HUD.prefab、UIManager.cs）
- D：素材・音・BGM（Assets/Sprites、Assets/Audio、BGM.prefab）

## 連絡と変更の進め方
- 連絡方法：（チームで決めた方法を記入）
- 担当ファイルとシーンの編集者を共有する
- 変更は作業用ブランチからPRを出し、レビュー後にmainへ統合する

## 素材の出典と利用条件
- （使った画像・音ごとに、配布元・URL・利用条件を記入）

## PRと動作確認
- 統合したPR：（番号・タイトル・リンクを記入。例：#12 Player・Coin・GameManager・HUDの統合 https://github.com/…/pull/12）
- 動作確認：（確認した日・PC・mainのコミット・結果・残った問題を記入。書き方は3日目の記入例を見る）

初回のREADMEは、Aがリポジトリを共有し、全員のCloneを確認した後に、担当と連絡方法から書き始めます。READMEの変更も作業用ブランチからPRで共有します。Dは画像・音の出典と利用条件が分かった時点で追記し、3日目にはBとCがPR・テスト結果を整理します。同じ行を同時に編集しないよう、追記する前に最新のmainを取り込み、担当する欄をチームで確認してください。3人チームでは、本文の役割分担どおりDの作業をBが引き継ぎます。

基本制作は1〜3日目の18限です。発展制作を行う場合だけ4〜6日目を使い、Issueで決めた追加機能の担当・PR・確認結果をこのREADMEへ追記します。担当を交換した場合は、初日の担当表を消さず、追加機能の担当を別に記録してください。

1. Aが2DプロジェクトCoinCollectorを作り、標準のAssets/ScenesにMainScene.unityを保存します。Unity内でScripts・Prefabs・Sprites・Audioを用意します。空のフォルダーはGitに入りません。Cloneした人のPCでフォルダーが作られなかったり、同じ名前のフォルダーを別々に作って衝突したりするのを防ぐため、4つのフォルダーに.gitkeepという空のファイルを置きます（作り方は下の折りたたみ）。初回Commitの前に、Package ManagerでInput Systemが導入されていることと、Edit > Project Settings > Player > Active Input HandlingがInput System Package (New)またはBothになっていることを確認します。導入や設定の変更後に求められたら、Unity Editorを再起動します。
2. 既存のUnityプロジェクトのルートをGitHub Desktopへドラッグ＆ドロップし、create a repository hereで作成します。Git IgnoreはUnityを選びます。初期Commitは自動で作られます。Publish前にHistoryを開き、Assets/Scenes/MainScene.unityとMainScene.unity.meta、Scripts・Prefabs・Sprites・Audioの各フォルダーの.metaと.gitkeep、PackagesとProjectSettingsの設定ファイルがCommitに含まれることを確認します。必要なファイルがChangesに残っている場合は、内容を確認してCommitしてからPublishします。
3. Publish repositoryでGitHubへ共有し、Settings > CollaboratorsからB・C・Dを招待します。授業ではプライベートで構いません。
4. 全員が承認してCloneし、Unity Hubへ既存プロジェクトとして追加します。全員がMainSceneを開けたら、READMEへ担当ファイルと連絡方法を書きます。

Assets・Packages・ProjectSettingsと対応する.metaを共有します。フォルダーの追加や移動もUnity内で行います。LibraryやUserSettingsは、各自のPCの作業状態（キャッシュ、開いているシーン、画面の配置）なので共有しません。Cloneした直後の最初の起動は、Unityが各自のPCでLibraryを作るため、時間がかかります。詳しくは、.gitignoreの解説・Libraryフォルダ・.metaファイルの解説を参照してください。

補足：初期CommitやCloneを確認したい場合

CloneはFile > Clone repository、またはCode > Open with GitHub Desktopから行えます。Changesに初期プロジェクトの必要ファイルが残る場合だけ、内容を確認してCommitします。リポジトリ作成の画面はGitHub公式ガイドも参照してください。

Dの素材の受け渡し：Dは最新mainから作業ブランチfeature/spritesを作ります（GitHub DesktopのCurrent Branch > New Branch）。素材はGameManagerに依存しないので、CのPRを待たずに始められます。Player・Coinの画像をAssets/Spritesへ入れると、Unityが.metaを自動で作ります。画像と.metaをCommitし、Publish branchしてPR（base = main）を出します。A・Bは、素材を待たずに四角・丸のSpriteでPlayer・Coinを作り、基本動作を進めて構いません。素材づくりが長引くときも、図形のまま基本動作を完成させます。素材がmainへ入ったら取り込み、自分のPrefab ModeでSprite RendererのSpriteへ画像を割り当てます。Player.prefabはA、Coin.prefabはBだけが変更します。割り当てたらPrefabを保存し、変更したPrefabをCommit・PushしてPRで共有します。自分のPrefabのPRがまだmainに入っていなければ、同じブランチでPRを更新します。

1-2：CがGameManagerを先に共有する

Cはfeature/game-manager-coreを作り、以下をAssets/Scripts/GameManager.csとして保存します。4人でつなぐ中心となる完成形のコードです。2日目に使う欄（クリア表示・音）を最初から含めてあります。2日目にGameManager.csを書き換えると、ほかの担当の作業と重なりやすいためです。Cさんだけが編集するファイルとして、最初に全体を共有します。まずは「CoinからAddCoinを呼ぶ → coinCountが増える → Coin Textへ表示する」という流れを読みます。2日目用のクリア表示と音の欄は、最初は未設定で構いません。

考えてみよう：Bさんは、CさんのGameManagerのPRがmainに入ってからCoin.csを書きます。なぜ先にGameManagerを共有するのでしょう。

using UnityEngine;
using TMPro;

[RequireComponent(typeof(AudioSource))]
public class GameManager : MonoBehaviour
{
    public static GameManager Instance { get; private set; }

    public TextMeshProUGUI coinText;
    public int coinsToWin = 10;
    public GameObject gameClearUI; // 2日目に設定
    public AudioClip collectSound; // 2日目に設定
    public AudioClip gameClearSound; // 2日目に設定

    private AudioSource audioSource;
    private int coinCount;
    private bool cleared;

    private void Awake()
    {
        Instance = this;
        audioSource = GetComponent<AudioSource>();
        Time.timeScale = 1f;
    }

    private void Start()
    {
        if (gameClearUI != null) gameClearUI.SetActive(false);
        UpdateCoinUI();
    }

    public void AddCoin()
    {
        if (cleared) return;

        coinCount++;
        UpdateCoinUI();
        if (collectSound != null) audioSource.PlayOneShot(collectSound);
        if (coinCount >= coinsToWin) GameClear();
    }

    private void UpdateCoinUI()
    {
        if (coinText != null)
            coinText.text = $"Coins: {coinCount} / {coinsToWin}";
    }

    private void GameClear()
    {
        cleared = true;
        if (gameClearUI != null) gameClearUI.SetActive(true);
        if (gameClearSound != null) audioSource.PlayOneShot(gameClearSound);
        Time.timeScale = 0f;
    }

    private void OnDestroy()
    {
        if (Instance == this) Instance = null;
    }
}

Awakeは起動時の準備、Startは最初の表示、AddCoinはCoinから呼ぶ入口です。Instanceは同じシーンに1個あるGameManagerへアクセスするためのものです。全行を暗記することは求めず、担当間で使うAddCoinとInspectorの設定欄を先に確認してください。

1. 空のGameObjectをGameManagerと命名し、スクリプトを付けます。RequireComponentによってAudioSourceも付きます。
2. Assets/Prefabs/GameManager.prefabへ保存します。Coin TextとGame Clear UIは空のままで構いません。音声欄も2日目に設定します。
3. GameManager.cs・GameManager.prefab・対応する.metaの小さなPRを先に出します。コンパイルエラーがなく、GameManagerを1個置いたシーンをPlayできれば、このPRの確認は完了です。
4. A・B・C・Dはマージ後に最新mainを取り込みます。BはここからCoinのコード追加を始めます。

1-3：AがPlayerを作る

Aは最新mainからfeature/playerを作り、青い四角などのSpriteをPlayerにします。

1. Box Collider 2Dを追加しIs TriggerはOFF。Rigidbody 2DはBody Type = Dynamic、Gravity Scale = 0、Freeze Rotation Z = ONにします。
2. Tagを標準のPlayerに設定します。前編ではシーン上のPlayerに付けましたが、今回は4人で共有するPlayer.prefabに付けます。全員のCoinが同じ判定を使うためです。
3. Assets/Scripts/PlayerController.csを以下で作り、Playerへ付けてPlayer.prefabに保存します。

using UnityEngine;
using UnityEngine.InputSystem;

[RequireComponent(typeof(Rigidbody2D))]
public class PlayerController : MonoBehaviour
{
    [SerializeField] private float moveSpeed = 5f;
    private Rigidbody2D rb;
    private Vector2 moveInput;

    private void Awake()
    {
        rb = GetComponent<Rigidbody2D>();
    }

    private void Update()
    {
        Keyboard keyboard = Keyboard.current;
        if (keyboard == null)
        {
            moveInput = Vector2.zero;
            return;
        }

        float x = 0f;
        float y = 0f;
        if (keyboard.aKey.isPressed || keyboard.leftArrowKey.isPressed) x -= 1f;
        if (keyboard.dKey.isPressed || keyboard.rightArrowKey.isPressed) x += 1f;
        if (keyboard.sKey.isPressed || keyboard.downArrowKey.isPressed) y -= 1f;
        if (keyboard.wKey.isPressed || keyboard.upArrowKey.isPressed) y += 1f;
        moveInput = new Vector2(x, y).normalized;
    }

    private void FixedUpdate()
    {
        rb.linearVelocity = moveInput * moveSpeed;
    }
}

前編と同じKeyboard.currentでWASD・矢印キーを読みます。入力方式の切り替えは今回の基本制作に含めません。.normalizedは、斜めに入力したときも移動の速さが変わらないよう、方向の長さを1にそろえます。

確認：担当別テスト表の「A：移動」のとおり、MainSceneへPlayer.prefabを一時的に配置し、Playして、WASD・矢印で上下左右に動くことを確かめます。確認後は、後の「テスト後」の手順で確認用の配置を片付けてから、PRを出します。

1-4：BがCoinを作る

BはGameManagerのPRがmainに入ったことを確認して取り込み、feature/coinsを作ります。すでに別の作業ブランチで準備していた場合はUpdate from mainで取り込みます。Assets/Scripts/Coin.csを作り、次のコードをファイル全体として保存します。

using UnityEngine;

public class Coin : MonoBehaviour
{
    public ParticleSystem collectEffect; // 2日目に設定。未設定でも動きます。
    private bool collected;

    private void OnTriggerEnter2D(Collider2D other)
    {
        if (collected || !other.CompareTag("Player")) return;
        if (GameManager.Instance == null)
        {
            Debug.LogError("確認用シーンにGameManager.prefabを1個配置してください。");
            return;
        }

        collected = true;
        if (collectEffect != null)
            Instantiate(collectEffect, transform.position, Quaternion.identity);

        GameManager.Instance.AddCoin();
        Destroy(gameObject);
    }
}

collectedは、接触処理が重複してもCoinを2回数えないための印です。2Dのトリガー通知には、接触するColliderの少なくとも片方にRigidbody 2Dが必要です。この実習ではPlayer側に付けます。

考えてみよう：collectedがなかったら、何が問題になるでしょう。

1. 黄色い丸などのSpriteをCoinにし、Circle Collider 2DのIs TriggerをONにします。Coin.csを付け、Coin.prefabへ保存します。Coin自身のTagはUntaggedで構いません。
2. 下の担当別テスト表の「B：Coinの接触」のとおり、MainSceneへ一時的に配置してPlayで確認します。確認後は、後の「テスト後」の手順で確認用の配置を片付けてから、Coin.cs・Coin.prefab・対応する.metaをPRで共有します。collectEffectは2日目まで空のままで構いません。この欄を最初から用意しているのは、2日目にCoin.csを書き換えず、Prefabの設定だけでエフェクトを加えるためです。

1-5：CがHUDのスコア表示を作る

CはGameManagerのPRをマージした後、最新mainからfeature/ui-scoreを作ります。GameManagerの変更とHUDの変更を同時に別ブランチで進めないようにします。

1. UI > CanvasでCanvasを作り、名前をHUDにします。Render ModeはScreen Space – Overlayにします。
2. Canvas ScalerのUI Scale ModeをScale With Screen Size、Reference Resolutionを1280 × 720、Matchを0.5にします。
3. HUDの子にUI > Text – TextMeshProを作り、ScoreTextと命名します。求められた場合はTMP EssentialsをImportします。
4. 次の配置表のScoreTextの値を設定し、初期テキストをCoins: 0 / 10にします。
5. HUDをAssets/Prefabs/HUD.prefabへ保存します。HUDとその子だけを保存し、EventSystemはHUDの外に置きます。確認のためにMainSceneへ置いたEventSystemは、HUD.prefabと同じく確認用の配置として、テスト後に取り除きます。（ゲーム用のEventSystemは、Aが統合のときに1個にそろえます。）
6. 担当別テスト表の「C：HUDの単独確認」のとおり、MainSceneへHUD.prefabを一時的に配置してPlayし、左上にCoins: 0 / 10が見えることを確認します。スコアの更新は、Aの統合後に全員で確認します。確認後は、後の「テスト後」の手順で確認用の配置を片付けてから、PRを出します。

UIの最小構成と配置の目安

数値は1280×720を基準とした目安です。Rect Transformを設定するときはAnchorとPivotを先に決め、その後Pos X・Pos Y・幅・高さを入力します。ボタンの子のTMPはボタン全体にStretchします。ScoreText・GameClearText・ボタン内TMPのRaycast TargetはOFFにし、ボタン本体のImageはONのままにします。

担当別テスト：配置するものと成功条件

Bのテスト用Player：AのPlayerがまだmainにない場合は、四角のSpriteにBox Collider 2D・Rigidbody 2D（Gravity Scale = 0）・Playerタグを付けます。Play前にその四角とCoinが重なる位置へ置き、Playして最初の物理更新でCoinが消えることを確認します。移動スクリプトは不要です。GameManagerがない場合はCoin.csがConsoleへ理由を出すため、配置を見直してください。

テスト後：Playを終了し、Prefabに残す変更だけを保存します。確認用に配置したオブジェクトを取り除き、MainSceneの差分を確認します。担当外のシーン変更だけが残っている場合は、その内容を確認して元へ戻してください。担当のコード・Prefabまで一括でDiscardしないようにします。

1-6：Aがシーンへ配置し、参照をつなぐ

Aは最新mainから、統合用ブランチfeature/integrate-day1を作ります（GitHub DesktopのCurrent Branch > New Branch）。Player・Coin・GameManager・HUDのPRがmainへ入るたびに、Branch > Update from mainで取り込み、このブランチでMainSceneを組み立てます。Scene上の設定はAが担当します。

考えてみよう：MainSceneを編集するのは、なぜAだけなのでしょう。

1. MainSceneへPlayerを1個、Coinを10個、GameManagerとHUDを1個ずつ配置します。CameraのGameビューで全て見え、Playerが各Coinに届くようにします。
2. HierarchyのGameManagerを選びます。ProjectウィンドウのGameManager.prefabやPrefab Modeを選ばないようにします。
3. InspectorのGameManagerコンポーネントのCoin Textへ、HierarchyのHUDを開いた中のScoreTextをドラッグします。コード上のcoinTextがInspectorではCoin Textと表示されます。
4. Coins To Winは10にします。1日目はGame Clear UIと音声欄が空でも構いません。
5. MainSceneをCtrl+S（MacはCmd+S）で保存します。HUDへの参照はこのシーンに保存するため、GameManager.prefabへApplyしません。
6. Playし、Coin1個につき1加算されることと、10個で停止することを確認します。1日目はPlayを終了して戻ります。
7. MainSceneの統合PRをレビュー・マージし、全員が最新mainをPullして同じ結果を確認します。

試してみよう：マージ後に、GameManagerのCoin Textを空にしてPlayすると、何が起きるでしょう。予想してから確認します。確認が終わったら、シーンを保存せずにCtrl+Z（MacはCmd+Z）で元に戻します。

2日目：クリア・Restart・音とエフェクトを完成させる

到達点：クリア表示からRestartまで動き、音とエフェクトを含む一連の操作が完成する。全員が最新mainを取り込み、担当ファイルを再確認します。

2-1：Cがクリア表示とRestartを作る

Cは最新mainからfeature/ui-clearを作り、HUD.prefabをPrefab Modeで編集します。GameManager.csは1日目のままです。Assets/Scripts/UIManager.csだけ追加します。

using UnityEngine;
using UnityEngine.SceneManagement;

public class UIManager : MonoBehaviour
{
    public void StartGame()
    {
        Time.timeScale = 1f;
        SceneManager.LoadScene(SceneManager.GetActiveScene().name);
    }
}

1. HUDの子にUI > Text – TextMeshProからGameClearText、UI > Button – TextMeshProからRestartButtonを作り、先ほどのUI配置表を設定します。GameClearTextは初期状態を非表示にします。RestartButtonはHUDの直下に置き、非表示になるGameClearTextの子には置きません。今回は操作を簡単にするため、Restartボタンをゲーム開始時から常時表示する仕様にしています。
2. HUDのルートにUIManager.csを付けます。RestartButtonのButtonコンポーネントのOn Click()で＋を押します。
3. Prefab Mode内のHUDルートをOn Click()のオブジェクト欄へドラッグし、UIManager > StartGame()を選びます。同じHUD内の参照なので、HUD.prefabに保存できます。
4. HUD.prefabとUIManager.cs・対応する.metaをPRで共有します。表示とOn Click()の設定をレビューし、シーン再読み込みの確認はAの統合後に行います。

2-2：AがUIをシーンへつなぎ、Restartを確認する

1. Aは最新mainから、2日目の統合用ブランチfeature/integrate-day2を作ります。UIのPRがmainに入ったらBranch > Update from mainで取り込み、MainSceneを開きます。HierarchyのGameManagerのGame Clear UIへ、HierarchyのHUD内のGameClearTextを割り当てます。
2. File > Build ProfilesのScene ListへMainSceneを追加して有効にします。Restartで同じシーンを読み込み直すために必要です。
3. EventSystemがシーンに1個あるか確認します。ない場合はGameObject > UI > Event Systemで作ります。Inspectorの入力モジュールはInputSystemUIInputModuleを使い、旧StandaloneInputModuleがある場合は置換ボタンで切り替えます。EventSystemはHUD.prefabの外に置きます。
4. Sceneを保存してPlayします。10個でGame Clear!が表示され、Playerが止まることを確認します。Restartを押し、Coinが10個、表示が0 / 10、Playerが初期位置へ戻って再び動くことを確認します。
5. 統合PRをマージし、全員のPCで同じ操作を確認します。

考えてみよう：クリアしたとき、Time.timeScale = 0fでPlayerが止まるのはなぜでしょう。

RestartはSceneManager.LoadSceneでシーンを再読み込みします。時間を1へ戻し、GameManagerもシーン内で作り直してCoin数を初期化します。DontDestroyOnLoadは使いません。

2-3：Dが音を共有し、Cが管理Prefabへ設定する

1. Dは最新mainからfeature/audioを作り、授業用に用意した素材のZIP（取得音・クリア音・BGM）を使うか、自分で探した音に差し替えます。ZIPを使う場合は、展開したAudioフォルダーの3ファイルをAssets/Audioへ配置します。自分で探す場合は、商用利用・改変・再配布の条件と、クレジット表記の要否を確認します。どちらの場合も、READMEに出典（サイト名・URL・利用条件）を記録し、InspectorのPreviewで各音声が聞こえることを確認します。ZIP内のREADME.txtに、書き方の例があります。
2. Dは空のBGMオブジェクトにAudioSourceを付け、BGMを割り当てます。LoopとPlay On AwakeをON、Spatial Blendを0（2D）にしてBGM.prefabへ保存します。素材とBGM.prefabをPRで共有します。
3. CはそのPRをmainから取り込み、feature/game-audio-settingsでGameManager.prefabを開きます。Collect SoundとGame Clear SoundにProject内の音声を割り当てます。
4. GameManagerのAudioSourceはPlay On AwakeをOFF、Spatial Blendを0にし、Volumeを調整します。CoinにはAudioSourceを追加しません。CがGameManager.prefabの変更をPRで共有します。
5. AがPRを取り込み、MainSceneにBGM.prefabを1個配置します。Audio Listenerがシーンに1個あることを確認し、取得音・クリア音・BGMをテストします。

音声はPrefabが参照できるアセットなのでGameManager.prefabへ保存できます。HUDの文字はシーン上の別オブジェクトなので、Aがシーン上で割り当てます。設定先が異なる理由を確認してください。

2-4：Bが取得エフェクトを加える

1. Bは最新mainからfeature/coin-effectを作り、メニューのGameObject > Visual Effects > Particle Systemから一時的にParticle Systemを作り、名前をCoinCollectEffectに変えます。
2. 最初の目安は、MainのDuration = 1、Looping = OFF、Start Lifetime = 0.4、Start Speed = 2、Start Size = 0.1。TransformのRotationを(0, 0, 0)にします。作成直後はX = -90で上向きに粒子が出るため、2D画面で広がるように0へ戻します。ShapeはCircle、Radiusは0.1にします。EmissionのRate over Time = 0、BurstをTime = 0・Count = 12で1回追加します。短い放射状のエフェクトをSceneビューの再生で確認します。
3. MainのDelta TimeをUnscaledに設定、Stop ActionをDestroyにしてCoinCollectEffect.prefabへ保存します。クリアで時間が止まった後も再生され、終了後に消える設定です。Stop ActionをDestroyにすると、Particle Systemの見出しに「!」の印が出ます。マウスを載せると「Procedural simulation is not supported」と表示されますが、これは再生時間を前後に動かす確認ができないという案内で、ゲーム中の再生には影響しません。
4. Coin.prefabのCollect Effectに、ProjectのCoinCollectEffect.prefabのParticle Systemを割り当てます。Coin.csの変更は不要です。
5. GameManager・Coin・テスト用Playerの組み合わせで、Coinが消えた位置に1回だけエフェクトが出ることを確認します。Prefabと.metaをPRで共有します。
6. AがPRを取り込み、実際のシーンで取得音・クリア音・エフェクト・Restartを確認します。全員がmainをPullして同じ結果なら完了です。

Coinはcollectedで重複加算を防ぎ、音は消えないGameManagerのAudioSourceから鳴らします。Restart後も音・エフェクトが正常か確認してください。

3日目：相互テスト・修正・ビルド・完成ゲームの紹介

到達点：全員のPCでゲームが動き、完成ゲームを紹介できる。18限の後半が押したときは、ZIP・タグ・GitHub Releasesより、全員のPCでクリアとRestartが動くことを優先します。

1. 未統合のPRをレビュー・マージし、AとDがFile > Build Profilesで対象プラットフォームとScene ListのMainSceneを確認します。必要なモジュールがない場合だけUnity Hubから追加します。
2. ビルド設定に変更があれば、Aが作業ブランチでCommit・Push・PRを行い、レビュー後にmainへマージします。AはmainをFetch → Pullし、Changesが空であることを確認して、その時点のコミットを記録します。画面説明はBuild Profilesの説明を参照してください。
3. Aはこの確認済みmainからBuildします。出力先は、Unityプロジェクト直下のBuildフォルダーにします。Buildフォルダーは.gitignoreで除外されるので、ビルド後にGitHub DesktopのChangesへビルドしたファイルが出ないことを確認します。ビルド時に共有すべき設定変更が追加で生じた場合は、PRで統合してからmainを取り込み、作り直します。
4. Aはビルド出力先と記録したコミットをDへ伝えます。DはAのPCで、Windowsなら.exeと_Dataなどの付属物を含む出力フォルダー全体をZIPにします。MacもAのPCで生成物一式をZIPにします。そのZIPを別のPCへ渡して展開し、移動・収集・クリア・Restart・音を確認します。不具合を直した場合は、修正PRを統合し、新しいmainから再ビルド・再確認します。
5. ここから先は、5限の完成発表のあとの6限に、AとDで行います。配布物の動作確認が通ったら、AはGitHub DesktopのHistoryでそのビルドに使った確認済みコミットを選び、タグv1.0.0を作成してPushします。後から別の変更がmainへ入っていても、ビルドに使ったコミットを選びます。詳しくはGitHub公式：GitHub Desktopでのタグ管理を参照してください。
6. DはGitHub Releasesで作成済みのv1.0.0タグを選び、リリース名・変更内容と、確認したZIPを添付してPublish releaseで共有します。これでソース・タグ・配布物が同じ状態を指します。プライベートリポジトリではアクセス権のあるメンバーが取得できます。

ビルドしたゲームの閉じ方：ビルドしたゲームは、設定によっては全画面で起動し、×ボタンがありません。閉じるときは、Windowsは Alt+F4、Macは Cmd+Q を押します。ウィンドウ表示にしたい場合は、Edit > Project Settings > Player の Fullscreen Mode を Windowed にして、ビルド設定の変更としてPRで統合します。

【Unity 6】GitHubを使ったUnityアプリのリリース版作成｜ビルド・ZIP・タグ・Release

完成したUnityのゲームを、ほかの人が遊べる形にして、GitHubで配る手順です。ビルド → ZIP → タグ → R ...

 https://soft-rime.com/post-2503/

完成ゲームの紹介：1チーム3〜5分でゲームを実演し、各自が担当した機能を一言ずつ説明します。チームで困ったことと解決方法を1つ紹介してください。スライドは不要です。PRやコードは説明に必要な場合だけ示します。

READMEに担当ファイル・PR・確認結果・素材の出典を残します。パフォーマンス改善は必要なときにProfiler（Window > Analysis > Profiler）で測って進めます。外部公開は必要に応じてItch.ioなどを使います。

## PRと動作確認
- 統合したPR
  - #12 Player・Coin・GameManager・HUDの統合（A） https://github.com/…/pull/12
  - #18 音・BGM・エフェクトの統合（A） https://github.com/…/pull/18
- 動作確認（3日目）
  - 確認：Bさんのノートパソコン（Windows）、mainのコミット a1b2c3d
  - 結果：起動○ 移動・収集○ クリア○ Restart○ 共有○ ビルド○
  - 残った問題：Restart後にBGMが重なって聞こえる（未修正）

マージ後の後片付け：マージが済んだ担当ブランチは、GitHubのPR画面のDelete branchで削除できます。自分のPCのブランチも、別のブランチに切り替えてから、GitHub DesktopのBranch > Deleteで削除します。削除する前に、mainをPullして、自分の変更がmainに入っていることを確認します。マージしていないブランチは、休んだ人の作業中のものがあるので削除しません。

発展制作：さらに3日間使える場合

最初の追加機能は1つに絞り、完成したら次を選びます。追加後も移動・収集・Restartが壊れていないか確認します。日本語フォント、Input Actions、アニメーションも、必要に応じてこの期間に取り入れられます。

発展制作で試す：仕様の変更はIssueで提案する

Issue（イシュー）は、GitHubで「やりたいこと」や「相談したいこと」を書いて、チームで共有する場所です。基本制作で決めた画面の文字、ゲームのルール、操作方法はチーム共通の仕様なので、変えたいときはIssueに書いてから進めます。【GitHub入門】Issueで仕様変更を提案する｜CoinCollector発展制作の準備（1コマ）で、Issueの作り方から、話し合い、PRとつなぐところまでを練習できます。発展制作に入る前に、1度取り組んでおくと安心です。

1. Issueに提案を書きます（今の仕様、変更案、理由、影響する範囲）。
2. チームで話し合い、全員が納得したら仕様を更新します。
3. 別のブランチで実装し、PRでレビューしてもらいます。

たとえば、ボタンの文字を「Restart」から「もう一度遊ぶ」に変えたい場合です。日本語を表示するにはTMP Font Assetが必要になり、Aが組むシーンや各自のテスト内容にも影響します。先にIssueで共有しておけば、全員が同じ完成形を見ながら作業できます。アイデアを出すことは大歓迎です。まず仲間に伝えることを、チーム開発の習慣にしましょう。

メンバーが休んだ日の進め方

休む人がいても、担当ごとにファイルが分かれているので、作業は止めずに進められます。進み具合を見て、チームで代役を決めてください。

困ったときに、最初に見る場所

問題のある担当と統合担当が一緒に、該当ファイルとConsoleを確認します。競合を片方の内容だけで解消したり、理解できない変更をまとめてDiscardしたりせず、変更した本人と相談してください。

振り返り：もしバージョン管理ツールを使わなかったら

3日間の開発では、ブランチ、PR、レビュー、マージを使いました。もしGitやGitHubを使わず、同じ4人で同じゲームを作るとしたら、どうなるでしょうか。グループで5〜10分話し合い、困ることを1つ以上挙げてみましょう。

1. 4人が同じPlayer.csを、同時に直したら、どうなりますか
2. 昨日は動いたのに、今日は動かないとき、昨日の状態にどうやって戻しますか
3. 誰がいつ、何を変えたかを、どうやって分かるようにしますか
4. 他の人の変更を、混ぜる前に確認するには、どうしますか

「共有フォルダーで受け渡す」「ファイル名に日付を付ける」といった方法も出てくるはずです。その方法で、上の1〜4が解決するかどうかも、あわせて考えてみましょう。

参考資料

以下は必要に応じて読む発展資料です。本教材のGit運用は「担当ブランチからPRでmainへ統合する」流れです。Git Flow、CI/CD、Addressables、Test Frameworkは今回の完成条件には含めません。

Unityチーム開発チュートリアル進行ガイド — 授業の開始時・終了時に、今日の作業、困りごと、次の受け渡しを共有するための短い確認シートです。

• Unity公式チュートリアル
• GitHub Desktopガイド
• GitHub ActionsによるCI/CD
• Unityのバージョン管理
• GitHub Flow
• Git Flow
• Unity Test Framework
• C#プログラミングガイド
• アドレス可能アセット