GAMEFARM

[Unity] 코루틴 (Coroutine)

Farmmachine — Fri, 7 Feb 2025 15:24:19 +0900

Unity 엔진에서 사용하게 되는 코루틴(Coroutine)에 대해 간단하게 정리하려고 합니다.

정확한 정보가 아닌, 정리 용도의 글이니, 참고해주시길 바라겠습니다.

[Unity] Coroutine, 코루틴

목차

1. 코루틴의 개념과 정의

2. 특징

3. 코루틴의 생명주기와 제어

4. 코루틴과 가비지 컬렉션

5. 결론

코루틴의 개념과 정의

1.1. 코루틴의 개념과 정의

코루틴(Coroutine)은 실행을 일시 중지하고 나중에 다시 시작할 수 있는 특별한 종류의 함수입니다.

Unity에서 코루틴은 MonoBehaviour 클래스에서 제공하는 기능으로, 시간이 걸리는 작업을 여러 프레임에 걸쳐 분산하여 실행할 수 있게 해줍니다.

1.2. 작동 원리

실행 등록
- StartCoroutine이 호출되면 해당 코루틴이 Unity의 코루틴 관리자에 등록됩니다
- 각 코루틴은 IEnumerator 객체로 변환되어 관리됩니다
- MonoBehaviour 컴포넌트와 연결되어 생명주기가 관리됩니다
실행 사이클
- Unity는 매 프레임마다 등록된 모든 코루틴을 순회합니다
- 각 코루틴의 현재 상태(yield return 값)를 확인합니다
- yield return 값에 따라 다음과 같이 처리됩니다:
  - null: 다음 프레임에 즉시 실행
  - WaitForSeconds: 지정된 시간만큼 대기
  - WaitForFixedUpdate: 다음 물리 업데이트까지 대기
  - CustomYieldInstruction: 사용자 정의 조건이 만족될 때까지 대기
실행 흐름
- 코루틴은 yield return 문을 만날 때마다 실행을 일시 중단합니다
- 중단된 지점의 모든 상태(지역 변수, 실행 위치 등)가 보존됩니다
- 다음 실행 시점에 중단된 지점부터 다시 시작됩니다
- 이 과정은 코루틴이 완료되거나 수동으로 중지될 때까지 계속됩니다
메모리 성능
- 코루틴은 별도의 스레드를 생성하지 않고 메인 스레드에서 실행됩니다
- 상태 정보는 힙 메모리에 저장되어 관리됩니다
- yield return 지점마다 약간의 오버헤드가 발생할 수 있습니다
- 하지만 일반적으로 스레드 생성/관리 비용보다 훨씬 효율적입니다
종료 처리
- 코루틴이 마지막 명령을 실행하거나 yield break를 만나면 자동으로 종료됩니다
- MonoBehaviour가 비활성화되거나 제거될 때 연관된 모든 코루틴이 자동으로 종료됩니다
- StopCoroutine이나 StopAllCoroutines 호출로 수동 종료도 가능합니다

1.3. 일반 함수와의 차이점

// 일반 함수: 한 번에 모든 작업 실행
void NormalFunction()
{
    for (int i = 0; i < 1000; i++)
    {
        ProcessHeavyTask(); // 프레임 드롭 발생 가능
    }
}

// 코루틴: 작업을 여러 프레임에 분산
IEnumerator CoroutineFunction()
{
    for (int i = 0; i < 1000; i++)
    {
        ProcessHeavyTask();
        if (i % 10 == 0)
            yield return null; // 다음 프레임에 계속
    }
}

특징

2.1. 비동기 실행

메인 게임 로직을 차단하지 않고 백그라운드에서 작업 실행 가능
프레임 드랍 없이 무거운 작업 처리 가능
자연스러운 시간 기반 동작 구현 가능

2.2. 실행 제어

실행 일시 중지 및 재개 가능
특정 조건이나 시간 간격으로 실행 제어
여러 코루틴의 동시 실행 및 관리 가능

2.3. 메모리 효율

스레드와 달리 추가적인 시스템 리소스 필요 없음
Unity의 이벤트 루프 내에서 실행되어 동기화 문제 없음

코루틴의 생명주기와 제어

3.1. 코루틴 시작 방법

public class CoroutineExample : MonoBehaviour
{
    void Start()
    {
        // 1. 메서드 참조로 시작
        StartCoroutine(MyCoroutine());
        
        // 2. 문자열로 시작
        StartCoroutine("MyCoroutine");
        
        // 3. 파라미터와 함께 시작
        StartCoroutine(ParameterizedCoroutine(5f));
    }
}

3.2. 대기(Wait) 처리

private IEnumerator WaitingExample()
{
    // 1. 다음 프레임까지 대기
    yield return null;

    // 2. 지정된 시간(초) 대기
    yield return new WaitForSeconds(2f);

    // 3. 실제 시간으로 대기 (타임스케일 영향 받지 않음)
    yield return new WaitForSecondsRealtime(2f);

    // 4. 조건이 충족될 때까지 대기
    yield return new WaitUntil(() => someCondition);
}

3.3. 코루틴 종료

public class CoroutineTermination : MonoBehaviour
{
    private Coroutine myCoroutine;

    void StopCoroutineExample()
    {
        // 1. 특정 코루틴 정지
        if (myCoroutine != null)
            StopCoroutine(myCoroutine);

        // 2. 이름으로 코루틴 정지
        StopCoroutine("MyCoroutine");

        // 3. 모든 코루틴 정지
        StopAllCoroutines();
    }
}

3.4. 중첩 코루틴

중첩 코루틴은 한 코루틴 내에서 다른 코루틴을 시작하고 관리하는 패턴을 말합니다.

이를 통해 복잡한 시퀀스를 구조화하고 제어할 수 있습니다.

public class NestedCoroutineExample : MonoBehaviour
{
    // 1. 순차적 중첩
    IEnumerator ParentCoroutine()
    {
        Debug.Log("부모 코루틴 시작");
        yield return StartCoroutine(ChildCoroutine());
        Debug.Log("자식 코루틴 완료 후 실행");
    }

    // 2. 병렬 중첩
    IEnumerator ParallelParentCoroutine()
    {
        StartCoroutine(ChildCoroutine1());
        StartCoroutine(ChildCoroutine2());
        yield return StartCoroutine(ChildCoroutine3());
    }

    // 3. 조건부 중첩
    IEnumerator ConditionalNestedCoroutine()
    {
        while (true)
        {
            if (someCondition)
                yield return StartCoroutine(ChildCoroutine());
            yield return null;
        }
    }
}

- 중첩 코루틴의 제어 흐름

부모 코루틴이 중지되면 자식 코루틴도 함께 중지됨
yield return StartCoroutine()은 자식 코루틴이 완료될 때까지 대기
StartCoroutine() 만 호출하면 비동기적으로 실행

코루틴과 가비지 컬렉션

Unity의 코루틴 시스템은 게임 개발에서 강력한 도구이지만, 잘못 사용하면 가비지 컬렉션(GC)으로 인한

성능 문제를 야기할 수 있습니다. 특히 모바일 게임이나 대규모 시스템에서는 이러한 문제가 두드러질 수 있습니다.

주요 원인

반복적인 객체 생성:
- 매 프레임 또는 짧은 간격으로 새로운 코루틴 시작
- yield 인스트럭션 객체의 무분별한 생성
- 코루틴 내부에서의 임시 객체 생성
동적 메모리 할당:
- 코루틴 실행 상태 정보 저장
- 로컬 변수와 파라미터의 힙 메모리 할당
- delegate와 람다 표현식 사용
리소스 관리 미흡:
- 종료되지 않은 코루틴 누적
- 미사용 객체의 지연된 정리
- 순환 참조로 인한 메모리 누수

방지 방법

1. 코루틴 캐싱

코루틴 캐싱은 자주 사용되는 yield 인스트럭션 객체를 재사용하는 기법입니다. 매번 새로운 객체를 생성하는 대신,

한 번 생성한 객체를 계속 재사용함으로써 가비지 생성을 줄일 수 있습니다.

주요 특징:

자주 사용되는 대기 시간을 가진 WaitForSeconds 객체를 미리 생성
고정된 시간 간격으로 실행되는 코루틴에서 특히 효과적
MonoBehaviour 클래스의 멤버 변수로 선언하여 재사용

장점:

간단하고 직관적인 구현
즉각적인 메모리 사용량 감소
특히 반복적으로 실행되는 코루틴에서 효과적

public class CoroutineExample : MonoBehaviour
{
    // 자주 사용하는 yield 인스트럭션 캐싱
    private readonly WaitForSeconds oneSecondWait = new WaitForSeconds(1f);
    private readonly WaitForFixedUpdate waitForFixed = new WaitForFixedUpdate();

    // 캐시된 인스트럭션 사용
    IEnumerator CachedCoroutine()
    {
        while (true)
        {
            // 캐시된 객체 재사용
            yield return oneSecondWait;
            DoSomething();
        }
    }
}

2. 풀링

코루틴 객체 풀링은 여러 개의 코루틴을 미리 생성하여 재사용하는 패턴입니다. 동적으로 코루틴을 생성하고 파괴하는

대신, 미리 생성된 코루틴을 재사용함으로써 가비지 생성을 최소화합니다.

주요 특징:

필요한 코루틴을 미리 생성하여 풀에 보관
필요할 때 풀에서 가져와 사용
사용이 끝나면 다시 풀로 반환

장점:

동적 할당 횟수 감소
메모리 단편화 감소
대량의 코루틴을 사용하는 시스템에서 효과적

public class CoroutinePool : MonoBehaviour
{
    private Queue<IEnumerator> coroutinePool = new Queue<IEnumerator>();
    private int poolSize = 10;

    void Start()
    {
        // 코루틴 객체 미리 생성
        for (int i = 0; i < poolSize; i++)
        {
            coroutinePool.Enqueue(CreateCoroutine());
        }
    }

    IEnumerator GetCoroutineFromPool()
    {
        if (coroutinePool.Count > 0)
            return coroutinePool.Dequeue();
        return CreateCoroutine();
    }

    void ReturnToPool(IEnumerator coroutine)
    {
        coroutinePool.Enqueue(coroutine);
    }
}

이러한 최적화 기법들을 통해 성능을 가비지 생성을 줄이고, 게임 성능을 향상 시킬 수 있을 것입니다.

결론

코루틴은 시간 기반 작업들인 애니메이션 효과, 타이머, 스킬 쿨다운 관리 등의 기능을 효과적으로 구현할 수 있게 도와줍니다. 또한, 게임 로직과 비동기 작업 처리에 있어서는 필수적이라고도 할 수 있습니다. AI 캐릭터의 패턴과, 이벤트의 진행, 게임 리소스의 로딩 등을 효과적으로 처리할 수 있도록 도와줍니다.

따라서, 코루틴은 Unity 개발에서 없어서는 안 될 중요한 도구입니다. 시간에 따른 동작이나 비동기 처리가 필요한 상황에서 코루틴을 활용하면, 깔끔하고 효율적인 코드를 작성할 수 있습니다. 다만 최적화와 관리에 주의를 기울여야만 그 장점을 최대한 활용할 수 있습니다.

[ARCANA] 아르카나 긴급! 뉴스 속보!

Farmmachine — Fri, 24 Jan 2025 05:59:12 +0900

Unity 엔진으로 개발 중인, ARCANA 게임 프로젝트의 스토리 콘셉에 맞는

영상을 하나 만들어 봤습니다. 재미있게 봐주셨으면 합니다.

[ARCANA] 아르카나 긴급! 뉴스 속보! ACTV BREAKING!

목차

1. ACTV 긴급 속보

2. 마무리

위의 목차를 클릭하면 해당 글로 자동 이동 합니다.

ACTV 긴급 속보

[NEWS] 긴급 뉴스 속보!

[NEWS]

아르카나 공영 방송 (ACTV)는 아르카나 인류 연방 정부의 요청에 따라,

긴급 속보를 보내드립니다.

연방군 대변인이 직접 뉴스를 전해드리겠습니다.

신이시여, 인류에게 축복을!

아르카나 공영 방송 긴급 속보, ACTV Breaking News

자유와 평등을 위한 인류의 성전이 시작되었습니다!

마무리

ARCANA는 Unity 엔진을 활용해, 개발 중인 덱 빌딩 로그라이크 카드 게임입니다.

인류의 지도자로서, 용족에게 억압받는 인류에게 구원을 가져다 주십시오!

게임 스토리와 관련된 영상을 하나 만들어 보았습니다.

아무쪼록, 재미있게 시청하셨으면 좋겠습니다!

[Unity] ScriptableObject, 스크립터블 오브젝트

Farmmachine — Fri, 17 Jan 2025 18:44:01 +0900

Unity의 ScriptableObject에 대해 간단하게 정리해보려 합니다.

잘 못 알고있는 정보가 있을 수 있으니, 참고해주시길 바라겠습니다.

[Unity] ScriptableObject, 스크립터블 오브젝트

목차

1. 개요

2. ScriptableObject

3. 예제

4. 결론

개요

Unity로 게임을 만들다 보면 다양한 데이터를 관리해야 합니다. 캐릭터의 체력, 아이템의 정보, 스킬의 효과 등 수많은 정보들을

어떻게 효율적으로 관리할 수 있을까요?

많은 개발자들이 처음에는 이런 방식을 사용합니다:

코드에 직접 숫자를 입력
변수에 하드코딩
MonoBehaviour 컴포넌트에 일일이 값을 넣기

하지만 이런 방식들은 다음과 같은 불편함이 있을 수 있습니다.

데이터 수정이 필요할 때마다 코드를 변경해야 함
같은 데이터를 여러 번 복사해야 함
기획자가 직접 데이터를 수정하기 어려움
버전 관리가 복잡해짐
메모리 사용이 비효율적

이러한 문제들을 해결하기 위해 Unity는 ScriptableObject를 제공합니다.

ScriptableObject

ScriptableObject는 Unity에서 제공하는 특별한 데이터 저장소입니다. 엑셀 시트처럼 게임에 필요한 데이터를 저장하고
관리할 수 있는 도구라고 생각하면 됩니다.

ScriptableObject는 다음과 같은 장점을 가집니다.

- 데이터를 에셋으로 관리

Unity 에디터에서 직접 데이터 수정 가능
프로그래머가 아닌 기획자도 쉽게 데이터 수정 가능
버전 관리 용이

- 메모리 효율성

같은 데이터를 여러 번 복사하지 않음
한 번 메모리에 로드하면 여러 곳에서 재사용 가능

- 데이터 관리

데이터의 형식을 미리 정의할 수 있음
실수로 잘못된 데이터를 입력하는 것을 방지

기존의 방식과 비교하여, 한 번 알아보겠습니다.

기존 데이터 관리 방식 [ex. 무기 정보]

1. MonoBehaviour에 직접 입력

public class Weapon : MonoBehaviour
{
    public string weaponName = "기본 검";
    public int damage = 10;
    public int durability = 100;
}

2. 변수에 직접 하드코딩

public class WeaponData
{
    public static Dictionary<string, int> weaponDamage = new Dictionary<string, int>()
    {
        {"기본 검", 10},
        {"강화된 검", 20}
    };
}

각각의 방식을 사용했을 때, 불편한 점이 어떤 것이 있을까요?

1. 여러 무기를 만들 때마다 같은 내용을 반복해서 입력하여야 함.

2. 코드를 수정하지 않고는 데이터를 변경할 수 없음.

다음과 같은 불편한 점이 발생하게 됩니다.

하지만, 아래 예제에서 설명할 방식으로 ScriptableObject를 사용한다면, 위의 불편함을 해결할 수 있습니다.

예제

[무기 정보]를 예를 들어 각각의 방식의 차이에 대해 알아보겠습니다.

MonoBehaviour 사용 방식

- 무기 정보

// WeaponMonoBehaviour.cs
public class WeaponMonoBehaviour : MonoBehaviour 
{
    public string weaponName = "기본 검";
    public int damage = 10;
    public float attackSpeed = 1.0f;
    public Sprite weaponIcon;
}

- ex) 여러 검이 필요하다면 [기존 검 데이터 공유]

// 여러 검이 필요한 경우
public class Sword1 : MonoBehaviour { public int damage = 10; }
public class Sword2 : MonoBehaviour { public int damage = 15; }
public class Sword3 : MonoBehaviour { public int damage = 20; }

- 데이터의 중복 (모든 데이터가 인스턴스마다 복제됨)

- 메모리 낭비

ScriptableObject 방식

- 무기 정보

// WeaponData.cs
[CreateAssetMenu(fileName = "New Weapon", menuName = "Game/Weapon Data")]
public class WeaponData : ScriptableObject
{
    [Header("기본 정보")]
    public string weaponName;
    public Sprite weaponIcon;
    
    [Header("무기 스탯")]
    public int damage;
    public float attackSpeed;
}

- ex) 여러 검이 필요하다면 [기존 검 데이터 공유]

// WeaponInstance.cs
public class WeaponInstance : MonoBehaviour 
{
    public WeaponData weaponData; // ScriptableObject 참조
    private int currentDamage;    // 이 무기 인스턴스의 현재 데미지

    private void Start()
    {
        // weaponData의 기본 데미지 값으로 초기화
        currentDamage = weaponData.damage;
        
        // 이후 currentDamage는 독립적으로 변경 가능
        // 예: 강화, 버프 등으로 인한 데미지 변경
    }

    public void UpgradeDamage(int amount)
    {
        // 각 무기 인스턴스별로 독립적으로 데미지 수정 가능
        currentDamage += amount;
    }

    public int GetDamage()
    {
        return currentDamage;
    }
}

- 기본 데이터(이름, 아이콘, 공격 속도 등)는 ScriptableObject에서 공유

- 개별 상태(데미지 등)는 각 인스턴스가 별도 관리

즉, 다음과 같은 차이점이 있습니다.

MonoBehaviour 방식: 모든 데이터가 인스턴스마다 복제됨
ScriptableObject 방식: 공통 데이터는 공유하고, 변경되는 데이터만 인스턴스가 가짐

- 메모리를 효율적으로 사용하며너 각 무기의 독립적인 상태 관리가 가능하게 됩니다.

주요 차이점

각자 인스턴스를 생성하는 것에는 큰 차이가 없습니다.

하지만, 다음과 같은 차이가 있습니다.

- 데이터 관리

기존 방식: 각 프리팹마다 데이터 중복
ScriptableObject: 하나의 데이터를 여러 곳에서 참조

- 메모리 효율

기존 방식: 인스턴스마다 메모리 할당
ScriptableObject: 데이터 공유로 메모리 절약

- 데이터 수정

기존 방식: 각 프리팹마다 수정 필요
ScriptableObject: 한 곳에서 수정하면 전체 반영

이러한 예제와 비교를 통해 ScriptableObject가 제공하는 이점을 실제로 확인할 수 있습니다.

특히 대규모 프로젝트에서 크게 체감할 수 있을 것 같습니다.

결론

Unity의 ScriptableObject (스크립터블 오브젝트)에 대해서 알아보았습니다.

게임 프로젝트에서 공통으로 사용되는 데이터들을 관리하기 편리하며,

예를 들어, 다음과 같은

아이템 정보
캐릭터 스탯
스킬 효과

부분에서 효과적으로 공통 데이터들을 관리할 수 있을 것입니다.

ScriptableObject는 Unity에서 데이터를 관리하는 강력한 도구입니다.

처음에는 설정이 조금 번거로울 수 있지만, 한번 구축해 놓으면 데이터 관리가 매우 편리해집니다.

특히 팀 프로젝트에서 기획자와 프로그래머가 효율적으로 협업할 수 있게 해주는 중요한 도구입니다.

오늘도, 방문해주셔서 감사하며, 틀린 정보가 많을 수 있지만, 키워드라도 얻어가셨으면 좋겠습니다.

감사합니다!

[ARCANA] ARCANA 개발일지 EP.1 Map_1

Farmmachine — Fri, 10 Jan 2025 16:38:30 +0900

덱 빌딩 로그라이크 게임 [ARCANA]를 개발하며

맡은 파트를 정리하는 용도로 작성하는 글입니다.

[ARCANA] ARCANA 개발일지 EP.1 Map_1

목차

1. Map?

2. 참고할 맵

3. 맵 구조

4. 개발사항

참조

Map?

맵은 플레이어가 게임 내에서 활동하는 공간적 영역과 그 안에서의 이동 경로,

상호 작용 가능한 요소들을 정의한 게임의 기본 구조입니다.

핵심적인 요소는 다음과 같이 있습니다.

공간적 구성 : 플레이어가 상호작용할 수 있는 물리적 공간
게임플레이 요소 : 시작과 끝 지점, 리소스의 분포, 이벤트 및 적의 배치, 상호작용 가능한 게임 오브젝트의 위치
진행구조 : 게임 진행을 위한 동선
시각적 요소 : 이동 가능한 경로의 시각화, 게임 오브젝트의 시각화

위와 같은 요소들이 모여 전체적인 맵 시스템을 구성하며, 게임의 장르와 목적에 따라 다양하게 구현됩니다.

그러면, 어떤 맵들이 있을까요?

선형 맵

가장 단순한 형태의 맵 구조로, 플레이어가 정해진 하나의 경로로만 진행 할 수 있는 맵을 의미합니다.

간단하게, 아래와 같은 구조로 이루어져 있습니다.

Start ~> A ~> B ~> C ~> End

따라서, 선형 맵은 다음과 같은 구조적 특징을 가집니다.

시작 포인트 부터 끝 포인트까지 하나의 고정된 경로만 존재
다른 경로로의 분기는 거의 없음
순차적인 진행방식
제작자가 의도한 대로 이끌어가기 좋음.

장 점	단 점
명확한 게임 진행 방향 제시	선택의 자유도가 낮음
스토리 전개가 용이	재플레이시 재미가 상대적으로 낮음
난이도 조절이 쉬움	탐험 요소는 제한적
게임에 익숙해지기 쉬움	-

다음과 같은 특징들을 가지며, 대표적인 게임은 다음과 같습니다.

슈퍼마리오와 콜오브듀티

분기 맵

게임에서 플레이어에게 여러 경로 선택지를 제공하는 맵 구조를 의미합니다.

간단하게 다음과 같은 구조로 이루어져 있습니다.

B --- D -------- X
A < E ------- X
C --<
F ------- END

따라서, 분기맵은 다음과 같은 구조적 특징을 가집니다.

하나의 시작점에서 출발해 여러 갈래 길로 나뉨
각 분기점마다 2개 이상의 경로 선택 가능
여러 경로가 다시 하나로 합쳐질 수도 있음
최종 목적지는 하나 또는 여러 개일 수 있음
플레이어의 선택에 따라 다른 경험을 할 수 있음

장 점	단 점
플레이어에게 전략적 선택권	일부 경로의 콘텐츠는 사용률 낮음 등의 문제
재플레이시 재미가 높음	다른 경로 콘텐츠를 위해 재플레이 해야하는 피로
다양한 게임 경험 제공	-
플레이어의 의사결정이 게임 진행에 영향을 줌	-

다음과 같은 특징을 가지며, 대표적인 게임은 다음과 같습니다.

Slay the Spire와 Frostpunk

오픈월드 맵

플레이어가 광범위한 가상 세계를 자유롭게 탐험하고 상호작용 할 수 있는 게임 형식입니다.

주요 특징으로는 다음과 같습니다.

자유로운 이동: 플레이어가 원하는 방향으로 자유롭게 이동 가능
비선형적 진행: 메인 스토리나 사이드 퀘스트를 원하는 순서로 진행
상호작용: 환경, NPC, 오브젝트 등과 다양한 상호작용 가능
광활한 맵: 다양한 지형과 환경이 하나로 연결된 거대한 맵

환 경 적 요 소	게 임 플 레 이 요 소
도시, 마을, 숲, 산, 바다 등 다양한 지형	자유로운 탐험
낮 / 밤 주기, 날씨 변화	다양한 이동 수단
자연스러운 생태계	다양한 활동 (전투, 수집, 제작 등)
-	다수의 서브 콘텐츠

플레이어가 상당히 자유롭게 가상 세계를 경험하며 플레이 할 수 있는 형식이며,

대표적인 게임은 다음과 같습니다.

GTA 5, The Elder Scrolls V: Skyrim

참고할 맵

Slay the Spire

Arcana는 로그라이크 덱 빌딩 게임입니다.

따라서, 장르의 개척자인 Slay the Spire의 맵 시스템과 비슷한 맵 시스템을 구축하기로 하였습니다.

Slay the Spire 맵

Slay the Spire의 맵 특징을 참고하여,

Arcana의 맵을 구성할 것이며, 큰 특징은 다음과 같습니다.

수직적 진행 구조 (아래에서 위로)
각 층마다 3-4개의 선택 가능한 경로
랜덤하게 생성되는 노드 배치
시각적으로 명확한 경로 표시

맵 구조

ARCANA MAP

아르카나의 맵은 위에서 말한 특징을 가지고,

다음과 같은 노드들로 이루어 질 것입니다.

이 미 지	노 드	설 명
	전투 (일반)	하위 종족부터 상위 종족까지 인류의 밑에서 민주주의에 대해 배울 것입니다.
	이벤트	온갖 음해와 모함 혹은 행운이 찾아옵니다.
	휴식	고난한 행군 중에도 휴식이 필요하니까요.
	상점	폭리를 취하는 인성 나쁜 사장과의 거래입니다.
	전투 (용, 보스)	최종 라운드, 용을 제거하고 ARCANA 행성에 민주주의를 전파하십시오!

다음과 같은 노드들로 이루어져있으며, 각 노드들은 각 역할에 맡는 씬으로의 이동을 담당하게 될 것입니다.

자유를 향한 길

전체적인 맵 시스템은

노드 - 각 씬으로 이동하여 스토리를 진행할 수 있게 함
경로 - 각 노드별 연결된 경로이며, 해당 경로에서 벗어난 노드들은 선택이 불가능하게 제한함.

으로 구성되어 있습니다.

위와 같은 맵 구조로 다양한 재미를 느끼실 수 있을 겁니다.

개발사항

우선, Slay the Spire의 맵 구조와 비슷한 시스템을 구성하신 분의 자료를 참고하여, 시작합니다.

전체적으로 중요한 부분은

맵의 생성 - 노드 및 경로의 제약 규칙 및 생성

플레이어 움직임 추적 - 플레이어가 경로를 벗어난 노드를 클릭했는지, 정상적인 경로의 노드라면 씬을 이동하는 등

맵의 관리 - 맵의 생성 시점 및 저장, 로드 등

다음의 사항이 핵심이 될 것 같습니다.

이 부분들을 중심으로 자료를 참고하여, 맵 시스템의 개발이 이루어질 것 같습니다.

ARCANA의 맵 시스템에 대해 소개해드렸습니다.

맵은 게임의 뼈대를 이루는 핵심 요소이며, 플레이어의 경험을 좌우하는 중요한 구성 요소입니다.

게임의 컨셉과 목적에 따라 다양한 맵 시스템이 선택될 수 있지만,

가장 중요한 것은 플레이어에게 최고의 게임 경험을 제공하는 것입니다.

앞으로도 ARCANA는 플레이어 여러분께 더 나은 게임 경험을 제공하기 위해 노력하겠습니다.

참조

Slay the Spire Map : https://www.youtube.com/watch?v=P9ogBkLWmPQ

[ARCANA] ARCANA 개발일지 EP.0

Farmmachine — Fri, 3 Jan 2025 17:11:25 +0900

덱 빌딩 로그라이크 게임 [ARCANA]를 개발하며

맡은 파트를 정리하는 용도로 작성하는 글입니다.

[ARCANA] ARCANA 개발일지 EP.0

목차

1. ARCANA?

2. 개발환경

3. Part

4. Team

결론

ARCANA?

시작화면

ARCANA

ARCANA의 개요에 대해서 간단하게 설명하겠습니다.

분 류	내 용
장르	덱 빌딩, 로그라이크
플랫폼	PC
엔진	Unity
가격	Free

스토리

먼 미래, 환경오염으로 더 이상 지구에서 머물 수 없던 인류는,

새 고향을 찾아 멀고도 험한 여정을 시작합니다.

그러다, 용이 지배하는 ARCANA(아르카나) 행성에 도달하게 되었고,

용에게 자비를 바라며, 행성의 변방에 난민으로 정착하게 됩니다.

인류는 ARCANA에서 용족에게 자비를 부탁합니다.

하지만, 종족별로 차등하게 대우하는 것에, 인류는 불만이 쌓이게 되고,

가슴 속 뜨거운 불씨가 점점 불을 키우게 됩니다!

인류는 평등의 가치에 대해 논하고자 합니다. 가장 인류다운 방식으로 말이죠!

더 이상, 참을 수 없던 인류는!!

평등의 가치를 가장 인류다운 방식으로 알리고자 합니다.

평등의 가치를 위해 일어선 자랑스런 인류의 전사들!

일어선 인류는 잊고 살았던 본성을 깨닫습니다.

자신들이 한 행성의 개척자이자 혁명가이며,

그리고 "지배자" 였다는 것을요!

과연?? 인류는 철권통치의 용족들에게 억압받는 ARCANA에 자유를 찾아 줄 수 있을까요?

드디어, 인류는 ARCANA의 지배자이자 철권통치를 하는 용족에게,

당당히, 맞서게 됩니다.

과연, 인류는 용족에게 억압받는 ARCANA에 자유와 평등을 찾아 줄 수 있을까요?

여러분은 인류의 지도자로서 자유의 빛을 ARCANA에 찾아주어야 하는 임무를 수행해야 합니다.

게임 시스템

ARCANA는 덱 빌딩, 로그라이크 게임입니다.

게임 시스템 구성은 다음과 같습니다.

메인페이지 & 시작페이지

메인 페이지 & 시작페이지

맵

전투

실키와의 전투, 해방을 위한 희생..?

상점

까칠한 주인장.. 경제 사범으로 처벌해야..

이벤트

검은 거래를 원하는가..?

휴식

잘 쉬는 것도 중요하겠죠..?

다음과 같은 구성으로 게임은 진행이 될 예정입니다.

맵은 랜덤으로 노드의 배치가 바뀌게되어 매번 회차마다, 다양한 경로를 탐험하게 될 것입니다.

전투는 덱에 있는 카드를 기반으로 랜덤으로 플레이어의 손(카드를 낼 수 있는 부분)에 들어오게 되고, 게임을 진행하게 됩니다.

개발환경

개발환경은 다음과 같습니다.

분 류	내 용
플랫폼	PC
엔진	Unity

Part

제가 맡은 파트는

- 맵 시스템 구현

- Save & Load 구현

- Game Data 관련 로직

- Computer Player의 AI 패턴

다음과 같은 파트를 맡게 되었습니다.

앞으로도, 다음 파트에 관한 내용이 주가 될 것 같습니다.

Team

게임에 미쳐있는 열정적인 팀원들과 함께하게 되었습니다.

정말 재미있고 멋있는 팀과 하게되어, 기분이 아주 좋습니다!!!

Team	Part
헛햇훗	Leader, Unity
놔요	Unity, Marketing
김세진	Unity
가야수	Unity
마늘기사	Unity
FarmMachine	Unity

총 6명의 팀원들과 즐거운 게임을 만들어 보겠습니다.

결론

이렇게, 개발을 시작하는 저희 게임을 소개하게 되어 반갑습니다!

종종 방문하셔서, 저희의 여정을 지켜봐 주십시오!

앞으로도, 종종 소식을 올리겠습니다!!

[Unity] Object Pooling, 오브젝트 풀링

Farmmachine — Fri, 27 Dec 2024 15:49:03 +0900

최적화 기법 중 하나인, 오브젝트 풀링(Object Pooling)에 대해, 정확하지는 않지만, 정리를 해보고자 합니다.

[Unity] 오브젝트 풀링 (Object Pooling)

목차

1. 개요

2. 오브젝트 풀링?

3. Unity 공식 오브젝트 풀링

4. 예제

5. 성능분석

6. 결론

개요

게임 개발에서 오브젝트의 생성과 파괴는 매우 빈번하게 발생하는 작업입니다. 총알을 발사하거나, 적을 생성하거나, 이펙트를 표시하는 등의 상황에서 새로운 오브젝트를 생성하고 불필요해지면 제거하는 작업이 계속됩니다. 하지만 이러한 작업들은 상당한 시스템 리소스를 소모하며, 특히 모바일 환경에서는 심각한 성능 저하를 초래할 수 있습니다.

오브젝트 풀링은 이러한 문제를 해결하기 위한 최적화 기법으로, Unity 2021부터는 엔진 차원에서 공식적으로 지원되고 있습니다.

오브젝프 풀링?

오브젝트 풀링

오브젝트 풀링은 게임 오브젝트들을 미리 생성하여 풀(pool)에 보관해두고, 필요할 때마다 이를 재사용하는 메모리 관리 기법입니다. 이는 다음과 같은 상황에서 특히 유용합니다:

총알이나 투사체 발사
파티클 효과나 시각적 효과
적 캐릭터 스폰
아이템 드롭
UI 요소의 동적 생성

그러면, 기존의 방식인 생성과 파괴와는 어떻게 다를까요?

(좌) 기존의 생성/파괴 방식, (우) 오브젝트 풀링 방식

기존의 Instantiate/Destroy 방식은 다음과 같은 문제를 가지고 있습니다:

높은 CPU 부하
- 새로운 오브젝트 생성 시 메모리 할당 필요 (Instantiate)
- 사용 후 메모리 해제 (Destroy)
- 컴포넌트 초기화에 따른 오버헤드
- 파괴 시 가비지 컬렉터 유발
- 리소스 비용이 높음
메모리 단편화
- 잦은 생성과 파괴로 인한 메모리 단편화 발생
- 장시간 실행 시 성능 저하 누적
프레임 드랍
- 다수의 오브젝트 동시 생성 시 프레임 저하
- 가비지 컬렉션으로 인한 끊김 현상

반면에, 오브젝트 풀링 (Object Pooling)은 다음과 같은 장점을 가집니다.

성능 최적화
- 오브젝트 생성/파괴 비용 감소
- 미리 생성된 객체들의 풀
- 활성/비활성 상태 전환으로 재사용
- 메모리 할당/해제 최소화
- 가비지 컬렉터 감소
안정적인 메모리 사용
- 일정한 메모리 사용량 유지
- 메모리 단편화 방지
- 예측 가능한 리소스 관리
부드러운 게임플레이
- 프레임 드랍 감소
- 일관된 성능 제공
- 더 나은 사용자 경험

Unity 공식 오브젝트 풀링

여기서부터는 Unity 2021 부터 제공하는 오브젝트 풀링 (Object Pooling)에 대해서 설명하겠습니다.

Unity 공식 오브젝트 풀링 시스템은 다음과 같은 특징을 제공합니다:

통합된 인터페이스
- IObjectPool<T> 인터페이스 제공
- Unity 컴포넌트 시스템과의 원활한 통합
- 타입 안정성 보장
효율적인 메모리 관리
- 자동 크기 조절
- 최대 용량 제한 기능
- 스레드 안전성
유연한 확장성
- 커스텀 풀 구현 가능
- 다양한 오브젝트 타입 지원
- 이벤트 콜백 제공

예제

다음으로 간단한 예제를 통해 알아보겠습니다.

[총알 오브젝트 풀]

using UnityEngine;
using UnityEngine.Pool;

// 총알 오브젝트 풀을 관리하는 매니저 클래스
// 오브젝트 풀링을 통해 총알의 생성/파괴를 최적화합니다.
public class BulletPoolManager : MonoBehaviour
{
    // 풀에서 생성할 총알 프리팹
    [Tooltip("풀에서 관리할 총알 프리팹을 할당하세요")]
    public GameObject bulletPrefab;
    
    // 총알 오브젝트들을 관리할 풀 인스턴스
    // IObjectPool 인터페이스를 통해 Get/Release 등의 기능 사용
    private IObjectPool<GameObject> bulletPool;

    // 컴포넌트 초기화 시 오브젝트 풀을 생성합니다.
    private void Start()
    {
        // createFunc: 새 오브젝트 생성 시 호출될 함수
        // actionOnGet: 풀에서 오브젝트를 가져올 때 호출될 함수
        // actionOnRelease: 풀에 오브젝트를 반환할 때 호출될 함수
        // actionOnDestroy: 풀에서 오브젝트가 제거될 때 호출될 함수
        // defaultCapacity: 풀의 초기 크기 (미리 생성할 오브젝트 수)
        // maxSize: 풀이 보유할 수 있는 최대 오브젝트 수
       
       bulletPool = new ObjectPool<GameObject>(
            createFunc: CreateBullet,        // 새 총알 생성
            actionOnGet: OnGetBullet,        // 총알 활성화
            actionOnRelease: OnReleaseBullet, // 총알 비활성화
            actionOnDestroy: OnDestroyBullet, // 총알 파괴
            defaultCapacity: 20,              // 초기에 20개 생성
            maxSize: 100                      // 최대 100개까지 허용
        );
    }

    // 새로운 총알 오브젝트를 생성하고 초기화하는 함수
    // return은 생성된 총알 게임오브젝트
    private GameObject CreateBullet()
    {
        // 프리팹으로부터 새 총알 인스턴스 생성
        GameObject bullet = Instantiate(bulletPrefab);
        // 총알 컨트롤러 컴포넌트 가져오기
        BulletController controller = bullet.GetComponent<BulletController>();
        // 컨트롤러에 풀 참조 전달 (나중에 반환할 때 사용)
        controller.SetPool(bulletPool);
        return bullet;
    }

    // 풀에서 총알을 가져올 때 실행되는 함수
    // bullet은 활성화할 총알 오브젝트
    private void OnGetBullet(GameObject bullet)
    {
        // 총알 오브젝트 활성화
        bullet.SetActive(true);
    }

    // 총알을 풀에 반환할 때 실행되는 함수
    private void OnReleaseBullet(GameObject bullet)
    {
        // 총알 오브젝트 비활성화
        bullet.SetActive(false);
    }

    // 풀에서 총알이 완전히 제거될 때 실행되는 함수
    // maxSize 초과 시 호출될 수 있음
    private void OnDestroyBullet(GameObject bullet)
    {
        // 실제로 총알 오브젝트 파괴
        Destroy(bullet);
    }

    // 지정된 위치와 방향으로 총알을 발사하는 함수
    // position 발사 시작 위치
    // direction 발사 방향
    public void FireBullet(Vector3 position, Vector3 direction)
    {
        // 풀에서 총알 가져오기
        GameObject bullet = bulletPool.Get();
        // 총알 위치 설정
        bullet.transform.position = position;
        // 총알 초기화 (방향 설정 등)
        bullet.GetComponent<BulletController>().Initialize(direction);
    }
}

[총알 제어 컨트롤러]

// 개별 총알의 동작을 제어하는 컴포넌트
public class BulletController : MonoBehaviour
{
    // 이 총알이 속한 오브젝트 풀 참조
    private IObjectPool<GameObject> pool;
    // 총알 이동 속도
    private float speed = 10f;
    // 총알 활성화 시간
    private float lifetime = 3f;
    // 총알 이동 방향
    private Vector3 direction;

    // 총알에 풀 참조를 설정하는 함수
    // bulletPool 총알이 속한 오브젝트 풀
    public void SetPool(IObjectPool<GameObject> bulletPool)
    {
        pool = bulletPool;
    }

    // 총알 발사 시 초기화하는 함수
    // newDirection 총알의 진행 방향
    public void Initialize(Vector3 newDirection)
    {
        // 방향 정규화
        direction = newDirection.normalized;
        // 총알 활성화 시간 코루틴 시작
        StartCoroutine(LifetimeRoutine());
    }

    // 매 프레임 총알을 이동시키는 함수
    private void Update()
    {
        // 설정된 방향과 속도로 총알 이동
        transform.Translate(direction * speed * Time.deltaTime);
    }

    // 총알 활성화 시간을 관리하는 코루틴
    private IEnumerator LifetimeRoutine()
    {
        // 지정된 시간만큼 대기
        yield return new WaitForSeconds(lifetime);
        // 시간이 다 되면 풀로 반환
        ReturnToPool();
    }

    // 충돌 발생 시 처리하는 함수
    // collision 충돌 정보
    private void OnCollision(Collision collision)
    {
        // 충돌 시 풀로 반환
        ReturnToPool();
    }

    // 총알을 풀로 반환하는 함수
    private void ReturnToPool()
    {
        // 풀이 존재하는 경우에만 반환
        if (pool != null)
        {
            pool.Release(gameObject);
        }
    }
}

다음과 같이 간단하게 구현해 볼 수 있습니다.

성능분석

일반적인 생성/파괴 방식과 비교했을 때의 성능 차이는 다음과 같다고 합니다.

CPU 사용량
- Instantiate/Destroy: 평균 8-15ms
- Object Pooling: 평균 0.1-0.5ms
- 개선율: 약 95%
메모리 할당
- 생성/파괴 방식: 매 생성 시 새로운 메모리 할당
- 풀링 방식: 초기 할당 후 추가 할당 최소화
- 가비지 컬렉터 호출 감소: 약 90%
프레임 안정성
- 프레임 드랍 발생 빈도 감소
- 평균 프레임 시간 편차 감소

일반적으로 이 정도의 성능차이가 난다고 합니다.

결론

사용 권장

빈번한 생성/파괴가 필요한 게임 요소
모바일 게임 최적화
대규모 파티클 시스템
탄막 슈팅 게임
다수의 적 캐릭터 생성

Unity의 공식 오브젝트 풀링 시스템을 활용하면 게임의 성능을 크게 향상시킬 수 있습니다. 특히 모바일 게임이나 많은 오브젝트를 다루는 게임에서는 필수적인 최적화 기법이라 할 수 있습니다. 적절한 설계와 구현을 통해 안정적이고 효율적인 게임 개발이 가능합니다.

오늘은, 오브젝트 풀링에 대해 부정확하고, 잘 알지는 못하지만 알고 있는 것을 정리해보았습니다.

부족한 정보나마 키워드라도 얻어 가셨으면 합니다. 감사합니다.

FrostPunk 리뷰

Farmmachine — Tue, 17 Dec 2024 11:33:06 +0900

FrostPunk 리뷰를 간단하게 작성해보겠습니다.

FrostPunk 리뷰.

목차

1. 게임소개

2. 재미 포인트

3. 후기

들어가며

스팀펑크 풍의 시티빌더 생존 게임.

갑작스럽게 다가온 빙하기에서 생존하며, 발전기를 중심으로, 인류 최후의 도시를 만드는 재미있는 게임입니다.

(플레이 타임 : 145시간)

게임 소개

개요

Frostpunk 공식 트레일러

게임명	Frostpunk
개발사	11Bit Studio
장르	생존, 시티빌더
플랫폼	PC, PS4, Xbox One
출시일	2018년 4월 24
가격	32,000 KRW
엔진	자체 엔진

스토리

19세기 말, 화산 폭발과 기후 변화로 인한 극한의 한파가 전 세계를 덮치며 인류 문명이 붕괴된다. 영국의 생존자들은 마지막 희망을 안고 거대한 증기 발전기가 설치된 북쪽 정착지를 향해 떠난다. 플레이어는 이 정착지의 지도자가 되어 혹한 속에서 마지막 생존자들을 이끌어가야 한다.

재미 포인트

생존

불만 - 시민들의 희생이 강요될때 누적이 되고, 최악의 경우에는 최후통첩을 받게 된다. 해소하지 못한다면 게임오버.

희망 - 시민들의 요구사항이 들어주면 올라간다. 0이 되면, 불만과 마찬가지로 게임 오버.

발전기

이 도시의 핵심이다.

연구소에서 기술 개발을 통해, 업그레이드를 할 수 있으며,

단계가 올라갈수록 난방구역과 수준을 설정할 수 있다.

이 발전기가 꺼진다면, 도시는 무너진다.

도시 건설

발전기를 중심으로 한 도시 전경

도시는 난방의 핵심인 발전기를 중심으로 원형으로 건설이 된다.

난방 및 전력 공급을 위해 도로를 연결해야 하며,

시민(주거 & 복지), 보건, 식량, 자원, 기술, 목적 건물 (질서, 신앙)이 있다.

일부 건물들을 제외하고는, 모두 시민들의 노동력이 필요하고, 거리도 중요하니 배치 및 건설에 주의할 필요가 있다.

법률과 정책

법률

크게 적응과 목적(신앙 or 질서) 두 가지로 이루어져 있다.

각, 법률은 건물 해금, 희망 및 불만 조절 등 게임에 필요한 정책들을 담고 있다.

적응

게임이 시작하자마자 사용이 가능한 법률서로, 기초적인 법령들로 이루어져 있다.

도시 노동력 구성, 식단, 의료시설 및 환자 처리 등 가장 기본적이고 중요한 법률로 생존 및 도시관리에 적합.

목적

희망과 불만을 관리하는데 적합한 법률로,

도시의 통치 방향을 정한다고 보면 된다.

크게 질서(독재), 신앙(종교)으로 이루어져 있다.

목적법의 최종 법안들은 상당히 무시무시하다. 하지만, 새로운 세상도 열어줄 것이다.

후기

어려운 점

초반 진입장벽이 높음
실수에 대한 패널티가 강함
일부 시나리오의 난이도 격차

하지만 이러한 어려움을 극복하고 나면 매력적인 게임성이 기다리고 있다.

극한의 환경에서 살아남기 위해 내리는 선택들, 그리고 그 선택들이 가져오는 결과들을 지켜보는 것은 독특한 재미를 준다.

마지막으로 이 게임은 우리에게 '생존을 위해서라면 어디까지 갈 수 있는가'라는 질문을 던진다.

단순한 게임을 넘어서 하나의 예술 작품으로서도 충분한 가치가 있다고 평가하고 싶다.

FARM MACHINE ON

Farmmachine — Tue, 10 Dec 2024 13:48:27 +0900

Game Farm Online.