언리얼 코딩 일기 (5)

美夜·2025년 9월 7일

언리얼 코딩 일기

목록 보기
5/9

인벤토리


인벤토리를 어떻게 구현할 것인가. RPG게임 뿐만 아니라 굉장히 많은 게임에서 필요한 기능이고, 게임 장르마다 구현 방식이 많이 달라지는 기능이고, 게임의 디테일에 달라서도 굉장히 많이 달라지는 기능이고, 개발 과정에서 엄청나게 많은 변형이 일어나는 기능이다.
지금 만드는 건, 가장 단순한 기능인 아이템 사용, 획득, 버리기 정도만 고려하고 있기 때문에 그렇게까지 복잡하진 않지만 인벤토리는 아주 중요하고 엄청 방대한 스펙이 될 확률이 높은 기능이라는 걸 알 필요가 있다. 그래서 우선 어떤 식으로 구현할지 큰 골자를 잡았다.

  1. 인벤토리용 클래스를 분리한다.
    매우 방대한 코드가 추후에 들어가야할 부분이다. 당장의 기능을 생각하면 그냥 TArray에 아이템을 순서대로 넣어도 될 것 같지만, 진짜 게임을 만들게 되면 100%후회할 선택이라 클래스 분리를 진행했다.

  2. 인벤토리 클래스는 ActorComponent를 상속한다.
    인벤토리는 많은 경우 캐릭터에 종속되는 개념이고, Actor나 Actor와 관련된 클래스의 기능들은 Component들로 구분해서 구현한다. 그리고 언리얼의 컴포넌트 문서에서도 ActorComponent의 예시 중 하나로 인벤토리를 들고있다.

  3. 인벤토리 클래스는 AActor 아래에 둔다.
    정확히는 AActor를 상속한 ACharacter를 상속한, 내가 만든 AMainPlayer 클래스의 Component중 하나로 두었다. 여기서 고민한 건 AActor에 속하는 게 좋을 지, APlayerController에 두는 게 좋을지, APlayerState에 두는게 좋을 지 고민했다. 이상적으로는 APlayerState에 두는게 더 좋을 수도 있겠다고 생각했으나, 당장은 필요가 없고, APlayerState의 상속 클래스는 만들어 둔 게 없으며, 이 정도 구현은 쉽게 옮길 수 있다고 판단했다.

  4. Widget <-> Component간 상호작용은 Controller를 경유한다.
    입력을 담당하는 곳이 Controller이기에, Controller가 각종 캐스팅 등을 거쳐서 이루어지는 지저분한 로직을 담당하고 위젯과 컴포넌트는 최대한 깔끔하게 유지하는 게 좋다고 생각했다.

여기까지 정하고 아래와 같이 대략적인 구조를 잡았다.

AMainPlayer
↳UInventoryComponent
   ↳UItem
       ↳FItemData
       ↳int(StackCount)

UInventoryWidget
   ↳UItemSlotWidget
       ↳FItemData
       ↳int(StackCount)

이렇게 설계를 하고, 현재 코드 작업을 진행 중이다. (또 다시) UI 작업과, 테스트를 위한 데이터 세팅과, 게임 저장/불러오기에 인벤토리 연동 등등 딸려오는 작업들이 역시나 많아서 코드 작업이 길어지고 있다. 제발 버그가 거의 안 나오고 테스트와 디버깅이 빠르게 끝나기를...

0개의 댓글