WIL [2025.02.10 ~ 2025.02.14]

지난 주의 일

• C++ 기반으로 만드는 언리얼5 강의를 듣고 게임 만들기.
• 인터페이스를 활용한 아이템 클래스 설계, 아이템 스폰 및 레벨 데이터 관리, 관리 시스템 구현, 게임 루프 설계를 통한 게임 흐름 제어를 배웠다.
• UI를 사용해 

인터페이스

클래스가 반드시 구현해야 할 함수 목록만을 미리 정의해 두고, 실제 함수의 동작(구현 내용)은 해당 클래스를 상속받거나 구현하는 쪽에서 자유롭게 작성할 수 있도록 하는 일종의 계약서입니다.

C++에서는 UInterface를 상속받아 IItemInterface 같은 인터페이스를 만들 수 있으며, 언리얼 블루프린트에서도 "블루프린트 인터페이스"를 통해 비슷한 개념 구현 가능.

 

상속과의 차이점

상속 

• 부모 클래스의 모든 속성과 기능을 자식 클래스가 물려 받는 구조.
• 부모 클래스에 구현된 로직을 자식 클래스가 그대로 사용할 수 있으며, 필요하다면 자식 클래스에서 재정의(오버라이딩)할 수 있다.

인터페이스

• 이 함수를 반드시 만들어야 한다라는 함수 원형 (함수 시그니처) 만을 정의
• 실제 함수가 어떻게 동작할지는 각 자식 (또는 구현 클래스)에서 자유롭게 작성할 수 있다.

상속은 부모의 실제 구현을 가져다 쓰는 반면, 인터페이스는 함수의 틀만 빌려 쓰고, 그 안에 담길 코드는 직접 만들어야 한다.

 

인터페이스를 사용하면 좋은 점

• 결합도 감소
  • 클래스 간 구체적인 구현 내용을 공유하지 않고, 필요한 함수 목록만 약속하므로 클래스 간의 의존도가 낮음.
  • 다른 클래스 내부에 어떻게 돌아가는 지 몰라도 "이 함수를 이렇게 호출하면 된다" 정도만 알면 됨.
• 확장성 향상
  • 새로운 아이템 클래스를 만들 때, 이미 정의된 인터페이스를 구현하기만 하면 기존 시스템에 쉽게 편입 가능.
• 다형성 극대화
  • TArray<IItemInterface*> Items; 와 같은 인터페이스 포인터 배열로 관리하면, 아이템 종류가 무엇이든 같은 함수를 호출하여 다룰 수 있다.

 

GameMode

• 게임의 규칙을 정의하고 관리
• 어떤 캐릭터를 스폰할지, 플레이어가 사망했을 때 어떻게 처리할지 결정.
• 멀티 플레이에서는 서버 전용으로 동작

 

GameState

• 게임 플레이 전반에서 "공유되어야하는 전역 상태"를 저장
• GameState는 기본적으로 레벨당 1개 존재, 엔진 내부에서 데이터 동기화를 고려해 설계되었기에 전역 데이터 관리로 적합
• 대표적으로 점수, 남은 시간, 현재 게임 단계(Phase), 스폰된 오브젝트의 총 개수 등 저장
• 멀티플레이에서는 서버가 관리하고, 클라이언트는 이를 자동으로 동기화 받아볼 수 있다.

GameInstance

• 레벨 전환 시에 GameState, GameMode 같은 기본 클래스를 비롯해 맵 내에서 생성된 대부분의 객체가 처음부터 다시 생성됨.
• 하지만 이전 레벨에서 획득한 점수나 플레이어 상태 등을 모든 레벨에 걸쳐 유지하고 싶을 때 두가지 방법 사용.

1. Game Instance

• 프로젝트가 시작될 때 (에디터에서 게임 실행을 누른 시점)부터 애플리케이션이 완전히 종료될 때까지 유일하게 계속 살아있는 객체
• 맵이 전환되어도 파괴되지 않아, 여기서 전역 데이터 유지 가능

1. Seamless Travel

• 멀티플레이 환경에서 주로 사용되는 레벨 전환 방식, GameState / PlayerController등을 파괴하지 않고 그대로 다음 맵으로 넘어가는 기능
• seamless Travel을 사용하면 대부분의 객체를 유지하지만 설정과 로직이 조금 더 복잡해 싱글 플레이 전용 간단 프로젝트라면 GameInstance를 사용하기 쉽다.