수집·위험·목표와 게임 규칙

수업 프로젝트 /Users/creativeengineer/Desktop/GameEngineI에서 Assets/Scenes/Week05_MicroLevel.unity를 엽니다. 1교시에서 저장한 장면을 사용합니다. 캐릭터, PlayerController, Move·Jump 입력과 기존 Ground·발판을 그대로 이어 갑니다.

파일을 만드는 공통 순서

1. 기존 파일부터 확인

   Play를 종료하고 Project 창의 Assets 전체에서 해당 스크립트를 검색합니다. 1교시의 Collectible.cs는 기존 파일을 열어 이어서 수정합니다. 다른 스크립트도 이미 있다면 그 파일을 사용하고, 같은 이름의 class를 새로 만들지 않습니다.

   확인기존 스크립트와 .meta, 오브젝트의 연결을 유지합니다.

2. 없는 스크립트는 Unity에서 직접 생성

   Project에서 Assets/Scripts 폴더를 선택합니다. 폴더가 없으면 먼저 만듭니다. Create → Scripting → MonoBehaviour Script로 생성하고 해당 단계의 이름을 입력합니다. 예를 들어 PlayerProgress로 만들면 파일은 PlayerProgress.cs, class 이름은 PlayerProgress입니다.

   확인파일 이름과 class 이름의 철자·대소문자를 맞춥니다.

3. 한 단계씩 작성하고 저장

   파일을 두 번 클릭해 코드 편집기로 엽니다. 각 단계에 보이는 추가·수정할 코드를 지정한 위치에 작성합니다. 바로 아래 적용 후 전체 코드를 펼치면 기존 코드와 합쳐진 파일 모습을 비교할 수 있습니다. 저장 → Unity로 복귀 → 컴파일 오류 0개 확인 → 컴포넌트 연결 순서로 진행합니다.

   확인스크립트는 아래 해당 단계에서 하나씩 작성합니다.

PlayerProgress는 수집 → 시작 위치 저장 → 복귀 → 목표 조건 순서로 완성합니다. 단계마다 추가·수정할 코드는 바로 보이고, 적용 후 전체 코드만 펼쳐 확인할 수 있습니다. 이미 이번 수업의 코드를 완성했다면 기존 파일을 유지하고 각 단계의 구성과 실행 결과를 확인합니다. 완성한 뒤에는 최종 코드 확인에서 전체 구성을 비교할 수 있습니다.

코드 위의 위치 안내를 먼저 확인합니다

작업 파일 · 넣을 위치 · 이번 작업은 코드 위에 항상 표시됩니다. 추가·수정할 코드는 본문에 바로 보이며, 적용 후 전체 코드만 눌러 펼칩니다. 필요한 변경만 작성하거나, 전체 파일을 펼쳐 앞뒤 위치와 중괄호를 함께 확인합니다.

코드 안의 노란색 줄은 이번 단계의 핵심 추가·수정 부분입니다. 주석의 // 이번 추가도 앞 단계에서 바뀐 부분을 알려 줍니다. 기존 필드·메서드도 함께 보면서 class 안에서 코드가 놓이는 위치와 실행 순서를 따라갑니다.

새 파일은 Assets/Scripts에 만듭니다. 기존 파일이 다른 폴더에 있으면 그 파일을 그대로 열어 수정합니다. 아래 파일명은 Project 창에서 검색할 이름입니다.

보석은 얻을 때마다 비활성화되지만 Player는 계속 움직입니다. 전체 수집 개수를 Player에 붙은 PlayerProgress 하나에 모으면, 어떤 보석을 먼저 얻어도 같은 기록을 이어 갈 수 있습니다.

지금은 두 정수만 구분합니다. requiredCollectibles는 미리 정하는 필요 개수이고, collectedCount는 실행하면서 늘어나는 현재 개수입니다.

PlayerProgress.cs를 만들고 첫 코드를 작성합니다

Play를 종료하고 Assets/Scripts에 PlayerProgress 이름의 MonoBehaviour Script를 생성합니다. 파일을 열고 아래 추가 위치에 맞춰 작성합니다. 기본 템플릿을 통째로 바꾸려면 ‘적용 후 전체 코드’를 사용합니다. 지금은 수집 개수와 AddCollectible만 작성하고, 시작 위치와 나머지 메서드는 뒤에서 추가합니다.

[RequireComponent(typeof(Rigidbody2D))]

// Player가 계속 보관할 수집 상태
[SerializeField, Min(1)]
private int requiredCollectibles = 3;

private int collectedCount;

// 보석이 호출하면 이 Player의 개수를 늘립니다.
public void AddCollectible()
{
    collectedCount++;
    Debug.Log("수집: " + collectedCount + " / " + requiredCollectibles);
}

using UnityEngine;

[RequireComponent(typeof(Rigidbody2D))]
public class PlayerProgress : MonoBehaviour
{
    // Player가 계속 보관할 수집 상태
    [SerializeField, Min(1)]
    private int requiredCollectibles = 3;

    private int collectedCount;

    // 보석이 호출하면 이 Player의 개수를 늘립니다.
    public void AddCollectible()
    {
        collectedCount++;
        Debug.Log("수집: " + collectedCount + " / " + requiredCollectibles);
    }
}

public은 다른 스크립트에서 이 메서드를 호출할 수 있게 합니다. void는 실행을 마칠 때 결과값을 돌려주지 않는다는 뜻입니다. Required Collectibles를 3으로 정해도 현재 개수는 0에서 시작합니다. 이제 이 메서드를 실행할 대상을 찾아봅시다.

1. 저장하고 Player에 연결

   파일을 저장하고 Unity에서 컴파일이 끝나면 Player에 PlayerProgress를 하나 붙입니다. Required Collectibles는 3으로 둡니다. Player Tag, PlayerProgress, Player의 Collider2D는 같은 GameObject에 둡니다. 기존 PlayerController는 유지합니다.

   확인Console 오류 0개 · PlayerProgress 하나 · Required Collectibles 3

기존 Collectible.cs를 열고 네 단계로 연결 흐름을 읽습니다. Inspector에서 두 스크립트의 위치를 확인하고, 필요한 컴포넌트를 찾은 뒤 메서드를 호출합니다. 먼저 찾기에 성공한 흐름을 따라가고, 마지막에 찾지 못했을 때의 처리를 연결합니다.

1교시 Collectible.cs에 PlayerProgress를 찾고 AddCollectible을 호출하는 처리를 더합니다. 아래 추가·수정할 코드를 작성하고, 그 안에서 찾기 → 실패 검사 → 호출 → 비활성화 순서를 읽습니다. 다음 중복 수집 방지에서는 이 파일에 처리 여부를 더합니다.

01 · GameObject와 컴포넌트 구조

Play를 종료하고 Hierarchy에서 보석을 선택합니다. Inspector의 Collectible 컴포넌트를 가리킨 뒤 Player를 선택해 PlayerProgress와 Collider2D를 확인합니다. Project의 .cs 파일에서 정의한 기능이 Scene의 어느 GameObject에 컴포넌트로 붙어 있는지 연결해서 봅니다.

두 스크립트는 서로 다른 GameObject에 붙어 있습니다. 실행 중인 Collectible에서, Player에 붙은 PlayerProgress의 기능을 사용하려는 상황입니다. Player의 기존 Rigidbody2D와 PlayerController는 이동을 계속 담당합니다.

Collectible.cs 전체 파일을 함께 작성합니다

private void OnTriggerEnter2D(Collider2D other)
{
    Debug.Log("[접촉] " + other.name);

    // 1교시에서 작성한 Player Tag 검사
    if (!other.CompareTag("Player"))
    {
        Debug.Log("[중단] Player Tag가 아닙니다.");
        return;
    }

    // 이번 추가 1: 접촉한 Player의 진행도 컴포넌트를 찾습니다.
    bool found = other.TryGetComponent(out PlayerProgress progress);
    if (!found)
    {
        Debug.Log("[중단] PlayerProgress가 없습니다.");
        return;
    }

    // 이번 추가 2: PlayerProgress.cs의 메서드를 호출합니다.
    progress.AddCollectible();

    // 호출을 마치면 이곳으로 돌아와 보석을 끕니다.
    Debug.Log("[수집] Collectible 비활성화");
    gameObject.SetActive(false);
}

using UnityEngine;

public class Collectible : MonoBehaviour
{
    private void OnTriggerEnter2D(Collider2D other)
    {
        Debug.Log("[접촉] " + other.name);

        // 1교시에서 작성한 Player Tag 검사
        if (!other.CompareTag("Player"))
        {
            Debug.Log("[중단] Player Tag가 아닙니다.");
            return;
        }

        // 이번 추가 1: 접촉한 Player의 진행도 컴포넌트를 찾습니다.
        bool found = other.TryGetComponent(out PlayerProgress progress);
        if (!found)
        {
            Debug.Log("[중단] PlayerProgress가 없습니다.");
            return;
        }

        // 이번 추가 2: PlayerProgress.cs의 메서드를 호출합니다.
        progress.AddCollectible();

        // 호출을 마치면 이곳으로 돌아와 보석을 끕니다.
        Debug.Log("[수집] Collectible 비활성화");
        gameObject.SetActive(false);
    }
}

저장하고 Unity로 돌아와 컴파일 오류가 0개인지 확인합니다. 아래 설명은 방금 작성한 전체 코드 안의 줄을 순서대로 읽습니다.

02 · 컴포넌트 검색과 참조

1교시의 other는 이번에 들어온 상대의 Collider였습니다. other.를 앞에 붙이면 그 Collider가 속한 GameObject에서 컴포넌트를 찾습니다. Player의 Collider와 PlayerProgress가 같은 GameObject에 있어야 하는 이유입니다.

찾기와 조건 판단을 나누어 읽기 위해, 성공 여부를 found라는 변수에 받아 봅니다. 위 전체 코드의 bool found = other.TryGetComponent(out PlayerProgress progress); 줄을 확인합니다. OnTriggerEnter2D의 중괄호 안, Player Tag 검사 다음에 있습니다.

PlayerProgress는 찾을 종류이고, progress는 찾은 대상을 가리키는 이름입니다. 예를 들어 int count에서 int가 자료형이고 count가 변수 이름이듯, PlayerProgress progress도 같은 순서로 읽습니다. 여기서 progress가 가리키는 대상은 Inspector에서 확인한 기존 PlayerProgress 컴포넌트입니다.

다음 단계는 찾기에 성공한 경우입니다. 이 참조를 통해 PlayerProgress에 있는 메서드를 실행합니다.

03 · 메서드 호출과 실행 복귀

위 Collectible.cs 전체 코드에서 // 이번 추가 2 바로 다음 줄을 가리킵니다. progress.AddCollectible();은 “progress가 가리키는 PlayerProgress의 AddCollectible을 지금 실행한다”는 뜻입니다.

호출한 줄에서 PlayerProgress.cs의 AddCollectible 메서드로 이동해 본문을 읽습니다. 앞에서 작성한 PlayerProgress 전체 코드에서 메서드 안의 두 줄을 확인합니다. 처음 개수가 0이라면 1로 바뀌고, 수집: 1 / 3이 출력됩니다.

메서드의 끝에 도달하면 다시 Collectible.cs의 호출한 줄 바로 다음 줄로 돌아옵니다. 이어서 비활성화 로그를 출력하고 보석을 끕니다. AddCollectible의 void는 결과값을 돌려주지 않는다는 뜻이며, 호출한 쪽의 다음 코드로 이어지는 실행 흐름은 그대로입니다.

04 · 컴포넌트 검색 실패 처리

지금까지는 PlayerProgress를 찾은 경우를 읽었습니다. 이번에는 Player Tag는 맞지만 필요한 컴포넌트가 없는 경우를 예상합니다. 찾기에 실패하면 found는 false이고, progress에는 사용할 컴포넌트 참조가 없습니다. 이때는 AddCollectible을 호출하기 전에 실행을 끝내야 합니다.

위 전체 코드에서는 bool found = ...; 다음의 if (!found)가 실패를 검사합니다. 다음 단계의 전체 코드에서는 이를 if (!other.TryGetComponent(out PlayerProgress progress))로 묶습니다. 두 형태 모두 찾지 못했을 때 호출 전에 멈추는 순서입니다.

이 검사를 통과하면 progress로 메서드를 호출할 수 있습니다. 다음 단계에서는 Collectible.cs 전체를 새 모습으로 갱신하므로, found를 사용하는 검사와 한 줄로 묶은 검사가 중복되지 않습니다.

이제 필요한 기능을 찾아 실행하는 과정이 연결되었습니다. 마지막으로, 이미 얻은 보석이 다시 수집을 요청하지 않도록 각 보석의 처리 여부를 확인합니다.

마지막으로 중복 처리 여부를 확인합니다. 전체 개수는 Player가 기억하고, “이 보석을 이미 얻었는가?”는 각 Collectible의 collected가 따로 기억합니다. 별도 값을 지정하지 않은 bool 필드는 false로 시작합니다. 보석 A를 얻어도 아직 남아 있는 보석 B의 collected는 false입니다.

아래 전체 코드에서 private bool collected;는 class 안, OnTriggerEnter2D 밖에 있습니다. if (collected || !other.CompareTag("Player"))는 OnTriggerEnter2D 안, 접촉 로그 다음에 있습니다.

전체 코드에서는 이 검사가 PlayerProgress 찾기보다 먼저 실행됩니다. 이미 얻었거나 Player가 아닌 경우를 먼저 끝내고, 나머지 경우에 필요한 컴포넌트를 찾습니다. 찾기에 성공하면 collected = true;를 기록한 뒤 개수를 늘리고 보석을 끕니다.

처리 여부를 기억하는 것과 화면에서 사라지게 하는 것은 서로 다른 역할입니다. 아래 Collectible 전체 코드에서 다섯 순서를 확인하고 기존 파일에 반영합니다.

Collectible.cs를 완성하고 저장합니다

1교시부터 이어 쓴 Collectible.cs를 엽니다. ‘추가·수정할 코드’에서 필드 추가와 메서드 교체를 진행하고, ‘적용 후 전체 코드’로 파일 구성을 비교합니다. 같은 class나 OnTriggerEnter2D를 두 번 선언하지 않습니다. 파일이 없다면 Assets/Scripts에 Collectible 이름으로 생성한 뒤 작성합니다.

private bool collected;

private void OnTriggerEnter2D(Collider2D other)
{
    Debug.Log("[접촉] " + other.name);

    if (collected || !other.CompareTag("Player"))
    {
        Debug.Log("[중단] 이미 수집했거나 Player Tag가 아닙니다.");
        return;
    }

    if (!other.TryGetComponent(out PlayerProgress progress))
    {
        Debug.Log("[중단] PlayerProgress가 없습니다.");
        return;
    }

    collected = true;
    progress.AddCollectible();
    Debug.Log("[수집] Collectible 비활성화");
    gameObject.SetActive(false);
}

using UnityEngine;

public class Collectible : MonoBehaviour
{
    private bool collected;

    private void OnTriggerEnter2D(Collider2D other)
    {
        Debug.Log("[접촉] " + other.name);

        if (collected || !other.CompareTag("Player"))
        {
            Debug.Log("[중단] 이미 수집했거나 Player Tag가 아닙니다.");
            return;
        }

        if (!other.TryGetComponent(out PlayerProgress progress))
        {
            Debug.Log("[중단] PlayerProgress가 없습니다.");
            return;
        }

        collected = true;
        progress.AddCollectible();
        Debug.Log("[수집] Collectible 비활성화");
        gameObject.SetActive(false);
    }
}

수집 규칙은 이제 연결되었습니다. 먼저 보석 하나로 실행을 확인한 뒤, 위험에 닿았을 때 무엇을 되돌리고 무엇을 남길지 정합니다.

1교시와 같은 보석을 향해 움직입니다. 겉으로는 보석이 사라지는 모습이 같지만, 이번에는 Player에 수집 개수도 남습니다. 그림의 변화와 Console의 기록을 함께 확인하세요.

1. 수집 기능 실행

   Console을 Clear하고 Play합니다. 기존 이동·점프를 사용해 보석에 닿습니다.

   확인보석이 비활성화되고 수집: 1 / 3이 출력됩니다.

2. 비활성화 및 재접촉 확인

   보석이 있던 자리를 한 번 더 통과합니다. 관찰을 마치면 Play를 종료합니다.

   확인개수는 추가로 늘지 않습니다. Play를 끝내면 보석이 원래 상태로 돌아옵니다.

[접촉] Player
수집: 1 / 3
[수집] Collectible 비활성화

첫 줄의 이름은 실제로 접촉한 오브젝트 이름에 따라 달라집니다. 수집: 1 / 3에서 1은 지금 모은 개수이고, 3은 목표에 필요한 개수입니다. 앞에서 만든 PlayerProgress가 개수를 저장하고 Collectible이 AddCollectible을 호출한 결과입니다.

위험에 닿았을 때 시작점으로 돌아오려면 출발한 위치를 남겨 두어야 합니다. PlayerProgress는 개수와 함께 이 좌표도 보관합니다. 4주차에서 사용한 Rigidbody2D의 참조를 얻고, 이동하기 전 위치를 한 번 읽습니다.

Play를 종료하고 PlayerProgress.cs를 다시 엽니다. 아래는 수집 코드에 시작 위치 저장까지 더한 전체 파일입니다. 기존 AddCollectible 위에 body·startPosition 필드와 Awake·Start가 들어가는 모습을 함께 작성합니다.

private Rigidbody2D body;
private Vector2 startPosition;

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

private void Start()
{
    startPosition = body.position;
}

using UnityEngine;

[RequireComponent(typeof(Rigidbody2D))]
public class PlayerProgress : MonoBehaviour
{
    [SerializeField, Min(1)]
    private int requiredCollectibles = 3;

    private int collectedCount;

    // 이번 추가 1: class 안에서 참조와 시작 좌표를 보관합니다.
    private Rigidbody2D body;
    private Vector2 startPosition;

    // 이번 추가 2: 참조를 준비하고 첫 위치를 한 번 저장합니다.
    private void Awake()
    {
        body = GetComponent<Rigidbody2D>();
    }

    private void Start()
    {
        startPosition = body.position;
    }

    // 기존 수집 메서드는 같은 class 안에 그대로 둡니다.
    public void AddCollectible()
    {
        collectedCount++;
        Debug.Log("수집: " + collectedCount + " / " + requiredCollectibles);
    }
}

body는 움직이는 Rigidbody2D를 가리키고, startPosition은 출발할 때 읽은 좌표 값을 보관합니다. 몸체가 움직여도 복사해 둔 좌표가 함께 바뀌지는 않습니다. Update에서 매번 저장하면 복귀 기준도 Player를 따라 움직이므로, 이번 규칙에서는 Start에서 한 번만 기록합니다.

이번 위험 규칙은 수집 기록을 유지한 채 출발점으로 돌아오기입니다. 돌아온 위치는 같아도 이미 얻은 보석까지 되돌릴 필요는 없습니다. 무엇을 바꾸는지 코드에서 확인합니다.

먼저 PlayerProgress.cs를 아래 전체 코드로 갱신합니다. 기존 수집·시작 위치 코드 아래에 ResetToStart가 추가됩니다. AddCollectible과 같은 깊이의 메서드인지 확인한 뒤 저장하고, 다음 HazardZone.cs를 작성합니다.

public void ResetToStart()
{
    body.linearVelocity = Vector2.zero;
    body.position = startPosition;
    Debug.Log("시작점 복귀 / 수집: " + collectedCount);
}

using UnityEngine;

[RequireComponent(typeof(Rigidbody2D))]
public class PlayerProgress : MonoBehaviour
{
    [SerializeField, Min(1)]
    private int requiredCollectibles = 3;

    private int collectedCount;

    private Rigidbody2D body;
    private Vector2 startPosition;

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

    private void Start()
    {
        startPosition = body.position;
    }

    public void AddCollectible()
    {
        collectedCount++;
        Debug.Log("수집: " + collectedCount + " / " + requiredCollectibles);
    }

    // 이번 추가: 수집 기록은 유지하고 속도와 위치만 되돌립니다.
    public void ResetToStart()
    {
        body.linearVelocity = Vector2.zero;
        body.position = startPosition;
        Debug.Log("시작점 복귀 / 수집: " + collectedCount);
    }
}

linearVelocity는 4주차에서 다룬 Rigidbody2D의 속도입니다. 위치만 옮기면 떨어지던 속도가 남을 수 있으므로 함께 초기화합니다. 계속 정지시키는 코드는 아닙니다. 이후 입력과 중력이 다시 작용하므로 이동 키를 누른 채 돌아오면 곧바로 움직일 수 있습니다.

HazardZone.cs를 생성하고 복귀 요청을 작성합니다

Assets/Scripts에 HazardZone 이름으로 MonoBehaviour Script를 생성하고 추가·수정할 코드의 안내에 맞춰 기본 템플릿에 작성합니다. Player인지 확인한 뒤, 방금 만든 ResetToStart를 호출합니다. 저장하고 Unity에서 컴파일 오류가 0개인지 확인합니다.

private void OnTriggerEnter2D(Collider2D other)
{
    if (!other.CompareTag("Player"))
    {
        return;
    }

    if (other.TryGetComponent(out PlayerProgress progress))
    {
        progress.ResetToStart();
    }
}

using UnityEngine;

public class HazardZone : MonoBehaviour
{
    private void OnTriggerEnter2D(Collider2D other)
    {
        if (!other.CompareTag("Player"))
        {
            return;
        }

        if (other.TryGetComponent(out PlayerProgress progress))
        {
            progress.ResetToStart();
        }
    }
}

위험 구역 스프라이트 PNG 내려받기 ↓

1. 위험 구역 구성

   Play를 종료합니다. 기존 위험 구역이 있으면 Sprite Renderer의 Sprite를 HazardSpikes로 교체합니다. 없다면 Project의 HazardSpikes 스프라이트를 Scene으로 드래그하고 HazardZone으로 이름을 정합니다. Sprite Renderer의 Color는 흰색으로 둡니다. Box Collider 2D의 Is Trigger를 켜고 방금 작성한 HazardZone.cs를 하나 붙입니다. 이미 연결되어 있다면 기존 컴포넌트를 확인합니다. 가시가 바닥 위에 보이도록 배치하고 시작점과 보석에서는 떨어뜨립니다.

   확인Sprite Renderer · Trigger Collider · HazardZone이 같은 GameObject에 있습니다. 별도 Rigidbody2D는 추가하지 않습니다.

위 HazardZone.cs 전체 코드에서 progress.ResetToStart();는 if (other.TryGetComponent(...))의 중괄호 안에 있습니다. PlayerProgress를 찾았을 때만 호출합니다.

HazardZone은 접촉을 감지하고 PlayerProgress에 복귀를 요청합니다. 시작 좌표를 직접 저장하지 않으므로 위험 구역이 늘어나도 같은 Player의 출발점으로 돌아옵니다.

보석은 값을 늘리고, 위험은 위치를 되돌렸습니다. 목표에서는 새로 수집하지 않고 지금까지 남은 기록을 읽습니다. GoalZone이 PlayerProgress에 “필요한 만큼 모았나요?”라고 묻도록 만듭니다.

PlayerProgress.cs를 아래 최종 전체 코드로 갱신합니다. 이번에 달라지는 부분은 AddCollectible과 ResetToStart 사이의 HasAllCollectibles입니다. 수집 기록·시작 위치·복귀 코드도 같은 파일에 함께 둡니다.

public bool HasAllCollectibles()
{
    return collectedCount >= requiredCollectibles;
}

using UnityEngine;

[RequireComponent(typeof(Rigidbody2D))]
public class PlayerProgress : MonoBehaviour
{
    [SerializeField, Min(1)]
    private int requiredCollectibles = 3;

    private int collectedCount;
    private Rigidbody2D body;
    private Vector2 startPosition;

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

    private void Start()
    {
        startPosition = body.position;
    }

    public void AddCollectible()
    {
        collectedCount++;
        Debug.Log("수집: " + collectedCount + " / " + requiredCollectibles);
    }

    public bool HasAllCollectibles()
    {
        return collectedCount >= requiredCollectibles;
    }

    public void ResetToStart()
    {
        body.linearVelocity = Vector2.zero;
        body.position = startPosition;
        Debug.Log("시작점 복귀 / 수집: " + collectedCount);
    }
}

위 전체 파일을 저장한 뒤 세 public 메서드의 위치를 확인합니다. AddCollectible, HasAllCollectibles, ResetToStart는 class 안에서 나란히 있는 세 메서드이며, 서로의 중괄호 안에 들어가지 않습니다.

return;은 이번 실행을 끝내고, return 비교식;은 실행을 끝내며 결과도 돌려줍니다. 이 질문을 여러 번 해도 개수는 늘지 않습니다. 정확히 같은 값만 보는 ==와 달리 >=는 필요 개수를 넘겨도 조건을 충족하게 합니다.

아래 GoalZone.cs 전체 파일의 OnTriggerEnter2D에서 PlayerProgress를 찾은 다음 if (!progress.HasAllCollectibles())를 확인합니다. 미완료이면 return하고, 통과하면 completed = true;와 성공 로그로 이어집니다.

2개라면 질문의 답은 false입니다. 앞의 !로 조건이 true가 되어 미완료 로그를 남기고 끝납니다. 3개라면 답이 true이므로 if를 지나 성공 처리로 내려갑니다. GoalZone의 completed는 성공을 이미 기록했는지 저장하는 bool 필드입니다. 첫 조건의 completed || !other.CompareTag("Player")로 재진입 때 같은 성공을 반복하지 않습니다.

GoalZone.cs를 생성하고 목표 조건을 작성합니다

Assets/Scripts에 GoalZone 이름으로 MonoBehaviour Script를 생성합니다. 추가·수정할 코드의 안내에 맞춰 기본 템플릿에 작성하고 저장합니다. HasAllCollectibles를 먼저 추가했으므로 이제 GoalZone에서 이 메서드를 호출할 수 있습니다.

private bool completed;

private void OnTriggerEnter2D(Collider2D other)
{
    if (completed || !other.CompareTag("Player"))
    {
        return;
    }

    if (!other.TryGetComponent(out PlayerProgress progress))
    {
        return;
    }

    if (!progress.HasAllCollectibles())
    {
        Debug.Log("아직 수집물이 남았습니다.");
        return;
    }

    completed = true;
    Debug.Log("LEVEL COMPLETE");
}

using UnityEngine;

public class GoalZone : MonoBehaviour
{
    private bool completed;

    private void OnTriggerEnter2D(Collider2D other)
    {
        if (completed || !other.CompareTag("Player"))
        {
            return;
        }

        if (!other.TryGetComponent(out PlayerProgress progress))
        {
            return;
        }

        if (!progress.HasAllCollectibles())
        {
            Debug.Log("아직 수집물이 남았습니다.");
            return;
        }

        completed = true;
        Debug.Log("LEVEL COMPLETE");
    }
}

1. 목표 구역 구성

   Play를 종료합니다. 4주차 도착 표지판이 있다면 그 오브젝트를 사용합니다. 없다면 기존 GoalSign 스프라이트를 Scene에 놓습니다. GoalZone으로 이름을 정하고 Box Collider 2D의 Is Trigger를 켠 뒤 GoalZone.cs를 하나 붙입니다. 마지막 보석과 Trigger가 겹치지 않도록 떨어뜨립니다.

   확인Player가 수집 전에도 들어갔다 나올 수 있는 통과 구역입니다.

GoalSign 파일이 필요하면 4주차 GoalSign.png를 다시 사용할 수 있습니다. 캐릭터·보석·목표 표지판은 기존 그림을 재사용하고, 위험 구역에는 위에서 제공한 HazardSpikes.png를 사용합니다.

목표는 통과 가능한 판정 구역입니다. 수집이 부족해도 문이 닫히지 않고, 성공해도 이동은 계속됩니다. 이번 수업의 성공 표시는 Console의 LEVEL COMPLETE입니다.

보석 하나의 수집을 확인했으므로 이제 세 개로 늘립니다. 1교시의 보석은 Assets/Week2/Prefabs/Collectible.prefab에서 가져온 instance입니다. 여기에 추가한 Trigger와 스크립트를 5주차용 구성으로 저장합니다.

1. Prefab Variant 생성

   Play를 종료합니다. 검증한 Collectible을 Hierarchy에서 Assets/Prefabs로 드래그합니다. 선택 창에서 Prefab Variant를 선택하고 PF_Collectible로 이름을 정합니다. 앞 주차 원본에는 변경 사항을 Apply하지 않습니다.

   확인Project에 PF_Collectible이 생기고 원래 Collectible의 그림을 이어받습니다.

2. Prefab 연결 확인

   Scene의 보석이 PF_Collectible을 가리키는지 확인합니다. 이전 원본을 가리킨다면 위치를 기록하고 PF_Collectible을 같은 위치에 배치한 뒤 기존 instance를 제거합니다. 새 원본을 열어 Is Trigger 켬과 Collectible 하나를 확인합니다.

   확인Scene에 PF_Collectible에서 온 보석 한 개가 있습니다.

3. Prefab 인스턴스 배치

   PF_Collectible을 Scene에 두 번 더 드래그합니다. 총 세 개를 서로 떨어진, Player가 도달할 수 있는 곳에 놓습니다. 마지막 보석은 Goal 밖에 둡니다.

   확인세 보석의 Collider와 스크립트 구성은 같고 위치는 다릅니다.

Scene에 배치한 원본의 사용본을 instance라고 합니다. 원본과 다르게 바꾼 설정은 override입니다. 공통 Collider나 스크립트 구성은 PF_Collectible에서, 각 위치는 Scene에서 관리합니다. 하나만 다르게 반응하면 그 instance에 별도 변경이 있는지 확인합니다.

각 규칙을 따로 확인했다면 한 장면에서 이어 봅니다. 아래 기본 흐름을 한 번 시연합니다. Console을 비우고 새 Play를 시작하며, 다음 행동 전에 예상 개수를 먼저 말해 봅니다.

표는 개수·복귀·완료 로그를 중심으로 읽습니다. 보석 접촉 때의 [접촉]과 [수집] 로그도 함께 출력됩니다. 이번 관찰의 핵심은 “작동했다”를 넘어 어떤 값이 바뀌었고 어떤 값이 남았는지 설명하는 것입니다.

보석은 사라졌지만 기록은 Player에 남았습니다. 위험에 닿으면 위치가 바뀌고, 목표에 닿으면 그 기록을 읽어 결과를 정합니다. 이제 세 질문에 먼저 답한 뒤 해설을 확인하세요.

3교시에서는 이미 확인한 단계는 다시 만들지 않고 연결 상태부터 검사합니다. 위험을 두 개로 늘리고 각 구역을 Prefab으로 정리한 뒤, 보석의 순서와 발판 간격을 직접 정합니다. 같은 규칙도 배치가 달라지면 다른 플레이 경험으로 이어집니다.

다음 실험은 50분 필수 흐름에 포함하지 않습니다. 수업 후 복습하거나 3교시의 기본 동작을 완성한 뒤 선택합니다. 한 번에 한 항목만 바꾸고 예상과 실제 결과를 비교하세요.

기본 상호작용과 필수 테스트를 마친 뒤 선택합니다. 이번 필수 테스트는 기존 Ground·발판으로 통과할 수 있으며 Tilemap 여부로 판정하지 않습니다.

본문의 각 작성 단계에서 추가·수정할 코드는 바로 확인하고, 적용 후 전체 코드는 필요할 때 펼쳐 볼 수 있습니다. PlayerProgress는 아래 네 버전 순서로 커지고, 최종 제출에는 마지막 목표 조건까지 포함된 코드를 사용합니다.

1. PlayerProgress.cs · 수집 개수 저장
2. PlayerProgress.cs · 시작 위치 저장 추가
3. PlayerProgress.cs · 위험 복귀 추가
4. PlayerProgress.cs · 목표 조건까지 포함한 최종 파일

상호작용 스크립트도 해당 단계의 전체 파일과 비교합니다.

• Collectible.cs 전체 코드 · 중복 방지까지 완성
• HazardZone.cs 전체 코드 · 복귀 요청
• GoalZone.cs 전체 코드 · 조건 확인과 성공

• TryGetComponent ↗컴포넌트 존재 확인과 참조 얻기
• Rigidbody2D.position ↗물리 위치
• Rigidbody2D.linearVelocity ↗물리 속도
• Prefabs ↗컴포넌트와 설정을 원본으로 재사용
• Tilemaps ↗Grid와 Tilemap
• Tilemap Collider 2D ↗타일의 접촉 경계

• Prefab Mode ↗원본 편집과 instance의 관계

• Sprite Import Settings ↗스프라이트 가져오기와 크기 설정
• Prefab Variants ↗기존 원본을 이어 쓰는 5주차용 변형
• MinAttribute ↗Inspector 입력의 최솟값

• 스크립트 생성 ↗Unity에서 새 스크립트를 만드는 메뉴