전체 글58 [UE5 C++] MVVM 패턴 기반의 인벤토리 UI 데이터 바인딩 및 뷰모델 구현 📘 [UE5 C++] 인벤토리 학습 노트 - 5단계: UI 연동 뷰모델 [UFTInventoryViewModel] 인벤토리 데이터를 실제 화면(View)인 UMG 위젯과 연결해 주는 인벤토리 뷰모델의 구현 원리와 MVVM 패턴을 학습하고,뷰모델이 데이터의 상태 변화를 어떻게 위젯에 감지시켜 자동 갱신하는지, 카테고리 탭 필터링, 무게 게이지 바의 동적 색상 제어, 그리고 삭제 데이터의 인덱스 예외 처리를 자세히 공부한다. 1. MVVM 아키텍처 개요 및 필요성 왜 UI 위젯이 인벤토리 컴포넌트에 직접 접근하지 않을까?전형적인 UMG 위젯 구현 방식은 다음과 같은 단점이 있다. 1. 디자이너와 개발자의 작업 간섭: 위젯 그래프나 블루프린트 내부에 비즈니스 로직이 녹아들어가 있으면, UI 레이아웃을 고치던.. 2026. 7. 10. [UE5 C++] WorldSubsystem과 GameplayMessage를 활용한 드롭 아이템 스폰 및 오브젝트 풀링(Pooling) 최적화 📘 [UE5 C++] 인벤토리 학습 노트 - 4단계: 글로벌 스폰 및 풀링 시스템 [UFTItemPoolSubsystem]월드 상에 드롭되는 아이템 액터들을 중앙에서 일괄 제어하고 최적화하는 아이템 풀서브시스템의 동작 원리를 이해하고, 전역 매니저로서 왜 UWorldSubsystem을 채택했는지, 라인트레이스 지형 탐색, 그리고 가비지 컬렉터 부하를 최소화하는 오브젝트 풀링의 실제 구현부와 트러블 슈팅을 다룬다. 1. 월드 서브시스템 도입 이유왜 싱글톤이나 전역 매니저 액터를 배치하지 않았는가?월드 상의 스폼을 관리할 매니저를 개발할 때 흔히 사용되는 대안과 그 한계는 다음과 같다. 1. 정적 싱글톤 패턴:엔진 라이프사이클과 맞물려 있어 레벨이 언로드되거나 월드가 전환될 때 데이터가 좀비처럼 남아 메모.. 2026. 7. 9. [UE5 C++] 인터페이스를 활용한 필드 아이템 상호작용 및 물리 설정 📘 [UE5 C++] 인벤토리 학습 노트 - 3단계: 필드 상호작용 액터월드 상에 실제로 베치되거나 버려져 플레이어와 부딪히고, 눈에 보이며, 상호작용할 수 있는 아이템 액터의 설계와 구현 원리를 정리하고, 상호작용 인터페이스 구현, 물리 및 콜리전 설정, 그리고 소멸 라이프사이클을 서브시스템으로 양도하는 느슨한 결합 아키텍처를 공부할 예정이다.1. 상호작용 인터페이스 구현왜 상호작용을 상속이 아닌 인터페이스로 구현했을까?플레이어가 아이템 외에도 다양한 환경 물체와 상호작용해야 한다고 가정해 보자.만약 이들을 상속으로 해결하려 한다면, 이 모든 상호작용 객체들의 공통 부모인 클래스를 만들어야 하며, 이는 클래스 계층 구조를 지나치게 복잡하게 만들고, 불필요한 기능까지 상속받게 되는 원인이 된다.반면 인.. 2026. 7. 8. [UE5 C++] 컴포넌트 패턴으로 구현하는 인벤토리 핵심 기능과 데이터 동기화 📘 [UE5 C++] 인벤토리 학습 노트 - 2단계: 인벤토리 컴포넌트 인벤토리 시스템의 비지니스 로직과 데이터 처리를 담당하는 인벤토리 컴포넌트의 구현 원리를 탐구하고, 왜 액터가 아닌 컴포넌트로 만들었는지, 자료구조는 왜 배열을 선택했는지, 무게 관리 시스템, 그리고 다중 아이템 삭제 시 발생하는 인덱스 밀림 문제와 퀵슬롯 동기화의 비포/애프터 트러블 슈팅 코드를 설명하고자 한다.1. 컴포넌트 패턴 (ActorComponent)을 채택한 이유와 이점 왜 인벤토리를 액터가 아닌 컴포넌트(UActorComponent)로 만들었을까? 인벤토리를 플레이어 캐릭터 액터 클래스 내부에 변수와 함수로 직접 구현하게 되면 다음 두 가지 큰 한계가 생긴다. 1. 단일 책임 원칙(SRP) 위배: 캐릭터 클래스가 이.. 2026. 7. 7. [UE5 C++] 데이터 기반 아이템 시스템 구축: UDataAsset과 AssetManager 활용법 📘 [UE5 C++] 인벤토리 학습 노트 - 1단계: 아이템 데이터 모델링아이템 시스템의 근간이 되는 데이터 모델링의 원리와 상세 코드를 분석하여 "왜 이렇게 구현했는지"에 대한 정리를 해보려 한다.1. 데이터와 행동의 분리 (데이터 주도적 설계: Data-Driven Design)왜 액터에 아이템 데이터를 직접 넣지 않을까?과거의 개발 방식에서는 AAppleActor, ASwordActor처럼 아이템 종류마다 개별 액터 클래스를 만들고, 그 내부에 이름, 공격력, 무게 등의 변수를 하드코딩했다고 한다. 하지만 이 방식은 두 가지 심각한 문제를 발생시킨다.1. 메모리 낭비: 월드에 사과 액터 100개가 스폰되면, 100개의 액터가 각각 동일한 이름 문자열과 텍스트를 메모리에 복제하여 소지하게 된다.2... 2026. 7. 6. [TIL: 2026.07.03] 생성자·소멸자의 생명주기와 접근 제어자 및 프로그래머스 - 최댓값과 최솟값 문제 풀이 오늘의 학습 내용에이타니 + 코드카타 + 학습에이타니: 생성자·소멸자의 생명주기와 접근 제어자 객체의 탄생부터 소멸에 이르는 생명주기를 관리하는 생성자·소멸자, 그리고 객체의 외벽을 세우는 접근 제어자는 안정적인 소프트웨어 아키텍처를 구축하기 위한 필수 지식이다. 복습 노트를 바탕으로 정리하고자 한다. 생성자(Constructor)와 소멸자(Destructor)의 작동 원리 기본 개념생성자: 객체가 메모리에 할당되는 순간 자동으로 호출되어 멤버 변수의 초기화나 리소스 할당을 담당한다.소멸자: 객체가 메모리에서 해제되는 순간 자동으로 호출되어 시스템 자원 반환, 동적 할당 메모리 해제 등의 정리 작업을 수행한다. 추가로 알아야 할 핵심 포인트: RAII 패턴과 가상 소멸자 RAII (Resource Ac.. 2026. 7. 3. 이전 1 2 3 4 ··· 10 다음
