📦패키지 언리얼 오브젝트 패키지 단일 언리얼 오브젝트가 가진 정보는 저장할 수 있지만, 오브젝트들이 조합되어 있다면? 저장된 언리얼 오브젝트 데이터를 효과적으로 찾고 관리하는 방법은? 복잡한 계층 구조를 가진 언리얼 오브젝트를 효과적으로 저장과 불러들이는 방법을 통일해야함 언리얼 엔진은 이를 위해 패키지(UPackage)단위로 언리얼 오브젝트를 관리함. 패키지의 중의적 개념 언리얼 엔진은 다양한 곳에서 단어 "패키지" 를 사용하고 있음 언리얼 오브젝트를 감싼 포장 오브젝트를 의미함. (이번 강의의 주제) 또한 개발된 최종 컨텐츠를 정리해 프로그램으로 만드는 작업을 의미함 → 예) 게임 패키징 DLC와 같이 향후 확장 컨텐츠에 사용되는 별도의 데이터 묶음을 의미하기도 함 → 예) pkg파일 구분을 위해 언..

언리얼 엔진의 직렬화 직렬화(Serialization)란? 오브젝트나 연결된 오브젝트의 묶음(오브젝트 그래프)을 바이트 스트림으로 변환하는 과정 복잡한 데이터를 일렬로 세우기 때문에 직렬화 거꾸로 복구시키는 과정도 포함해서 의미 Serialization : {오브젝트 그래프 → 바이트 스트림}으로 Deserialization : {바이트 스트림 → 오브젝트 그래프}로 직렬화가 가지는 장점 현재 프로그램의 상태를 저장하고 필요한 때 복원할 수 있다. (게임의 저장) 현재 객체의 정보를 클립보드에 복사해서 다른 프로그램에 전송할 수 있다. 네트워크를 통해 현재 프로그램의 상태를 다른 컴퓨터에 복원할 수 있다. (멀티플레이어 게임) 데이터 압축, 암호화를 통해 데이터를 효율적이고 안전하게 보관할 수도 있음. ..

언리얼 엔진의 자동 메모리 관리 C++ 언어 메모리 관리의 문제점 C++은 저수준으로 메모리 주소에 직접 접근하는 포인터를 사용해 오브젝트를 관리한다. 그러다보니 프로그래머가 직접 할당(new)과 해지(delete) 짝 맞추기를 해야 한다. 이를 잘 지키지 못하는 경우 다양한 문제가 발생할 수 있음 잘못된 포인터 사용 예시 메모리 누수(Leak) ⇒ new를 했는데 delete 짝을 맞추지 못함 → 힙에 메모리가 그대로 남아있음 허상(Dangling)포인터 ⇒ (다른곳에서) 이미 해제해 무효화된 오브젝트의 주소를 가리키는 포인터 와일드(wild)포인터 ⇒ 값이 초기화되지 않아 엉뚱한 주소를 가리키는 포인터 잘못된 포인터 값은 다양한 문제를 일으키며, 한 번의 실수는 프로그램을 종료시킴 게임 규모가 커지고..

[!note] 실습은 지난번 프로젝트인 UnrealContainer에 이어서 작성 언리얼 구조체 🔗공식 문서 → 강의와 똑같은 문서는 사라진것 같음 구조체 게임플레이 클래스용 구조체 생성 및 구현 관련 레퍼런스입니다. https://docs.unrealengine.com/5.1/ko/structs-in-unreal-engine/ 구조체 사용시 알아둘 정보 구조체는 단순한 데이터 타입에 적합하므로 UObjects와는 다름 프로젝트 내부에서 보다 복잡한 인터랙션을 하기 위해서는 UObject 또는 AActor 서브클래스를 만드는것이 좋음 UStruct는 리플리케이션용으로 간주되지 않음 UProperty변수는 리플리케이션응으로 간주됨 언리얼 구조체 UStruct 데이터 저장/전송에 특화된 가벼운 객체 대부분 ..

개요 언리얼 컨테이너 라이브러리 언리얼 엔진이 자체 제작해 제공하는 자료구조 라이브러리 줄여서 UCL(Unreal Container Library) 라고도 함. 언리얼 오브젝트를 안정적으로 지원하며 다수 오브젝트 처리에 유용하게 사용됨. 언리얼 C++는 다양한 자료구조 라이버르리를 직접 만들어 제공하고 있음. 실제 게임 제작에 유용하게 사용되는 라이브러리로 세 가지를 추천함. ⇒ TArray, TMap, TSet C++ STL과 언리얼 컨테이너 라이브러리의 차이점 C++ STL은 범용적으로 설계되어 있다. C++ STL은 표준이기 때문에 호환성이 높다. C++ STL에는 많은 기능이 엮여 있어 컴파일 시간이 오래걸림. 언리얼 컨테이너 라이브러리는 언리얼 엔진에 특화돼 있음. 언리얼 컨테이너 라이브러리는 ..

느슨한 결합(Loose Coupling) 강한 결합과 느슨한 결합 강한 결합(Tight Coupling) 클래스들이 서로 의존성을 가지는 경우를 의미한다. 아래 예시에서 Card가 없는 경우 Person이 만들어질 수 없다. 이 때 Person은 Card에 대한 의존성을 가진다고 한다. 핸드폰에서도 인증할 수 있는 새로운 카드가 도입된다면? 느슨한 결합(Loose Coupling) 실물에 의존하지 말고 추상적 설계에 의존하라. (DIP 원칙) 왜 Person은 Card가 필요한가? → 출입을 확인해야 하기 때문 출입에 관련된 추상적인 설계에 의존하자. ICheck를 상속받은 새로운 카드 인터페이스를 선언해 해결 이러한 느슨한 결합 구조는 유지 보수를 손쉽게 만들어 줌. 기존 코드 class Card { ..