다양한 기록

언리얼 에디터 (엔진) -> 게임 제작을 위해 에픽 게임즈가 제공하는 저작 도구언리얼 엔진의 구성- 에디터 : 게임 제작을 위해 제공되는 응용 프로그램 (일반적으로 엔진이라 부르는 것)- 게임 빌드 : EXE 파일과 리소스로 이루어진 독립적으로 동작하는 게임 클라이언트 에디터에서 기획 및 개발 => 이후 게임 빌드 언리얼 에디터의 동작프로젝트 폴더의 uproject 확장자 더블 클릭 시 에디터 트리거실행 방식- uproject 확장자는 윈도우 레지스트리에 등록됨 (등록이 안되어 있을 시 런처를 실행해 등록)- UnrealVersionSelector 프로그램으로 프로젝트 정보가 넘겨짐- UnrealVersionSelector는 런처가 저장한 에디터 정보로부터 버전에 맞는 에디터 실행 에디터 버전 정보의 파..

언리얼 오브젝트 패키지복잡한 계층 구조를 가진 언리얼 오브젝트를 효과적으로 저장, 로드하는 방법을 통일해야 함=> UPackage 단위로 언리얼 오브젝트를 관리* 패키지는 여러 뜻을 가짐- 언리얼 오브젝트를 감싼 포장 오브젝트- 개발된 최종 컨텐츠를 정리해 프로그램으로 만드는 작업 (게임 패키징)- 향후 확장 컨텐츠에 사용되는 별도의 데이터 묶음 (pkg 파일) 패키지와 애셋- 언리얼 패키지 오브젝트 : 다수의 언리얼 오브젝트를 포장하는데 사용하는 언리얼 오브젝트- 모든 언리얼 오브젝트는 패키지에 속함 (Transitent Package, 임시 패키)- 언리얼 오브젝트 패키지의 서브 오브젝트를 애셋이라고 하며 에디터에 노출- 패키지는 다수의 언리얼 오브젝트를 소유할 수 있으나 일반적으로는 하나의 애셋만 ..

오브젝트나 연결된 오브젝트의 묶음(오브젝트 그래프)을 바이트 스트림으로 변환하는 과정- 복잡한 데이터를 일렬로  -> 직렬Serialization : 오브젝트 그래프 -> 바이트 스트림Deserialization : 바이트 스트림 -> 오브젝트 그래프 장점- 현재 프로그램 상태를 저장 및 복원 가능 (게임 저장)- 현재 객체 정보를 클립보드에 복사 -> 다른 프로그램에 전송 가능- 네트워크를 통해 현재 프로그램의 상태를 다른 컴퓨터에 복원 가능 (멀티게임)- 데이터 압축, 암호화를 통해 데이터를 효율적이고 안전하게 보관할 수도 있음 직접 구현?- 데이터 레이아웃 (오브젝트가 소유한 다양한 데이터를 변환?)- 이식성 (서로 다른 시스템 간)- 버전 관리 - 성능- 보안- 에러 처리쉽지 않음그냥 언리얼 엔진..

기존 C++ : new, delete 해줘야 함-> 누수, 댕글링 포인터, 초기화되지 않은 포인터 등문제가 많이 발생함 가비지 컬렉션 시스템- 프로그램에서 더 이상 사용하지 않는 오브젝트를 자동 감지하여 회수- 동적으로 생성된 모든 오브젝트 정보를 모아둔 저장소를 사용해 사용되지 않는 메모리 추적- 마크-스윕(Mark-Sweep) 방식의 가비지 컬렉션    - 저장소에서 최초 검색을 시작하는 루트 오브젝트 표기    - 루트 오브젝트가 참조하는 객체를 찾아 마크    - 마크된 객체에서 계속해서 참조하는 객체를 찾아 마크(1로 표시)    - 마크되지 않은 객체(0으로 표시) -> 회수(스윕) 언리얼 엔진에선 주기적으로 알아서 작동기본 값 60초, 부하가 좀 있는 작업인데 병렬 처리 및 클러스터링 기능 ..

구조체USTRUCT 매크로 추가하고 (내부에 BlueprintType같은 키워드 추가 가능)내부 상단에 GENERATED_BODY() 추가 (안해도 되긴 하는데 해야 리플렉션, 직렬화 가능)내무 멤버 변수는 UPROPERTY() 매크로 사용* 언리얼 오브젝트가 아니니 F로 시작 사용 용도가 언리얼 오브젝트와는 완전히 다름단순한 데이터 타입에 적합함F로 시작하니까 일반 객체 -> 리플렉션 시스템이 인식 못함대신 내부의 UPROPERTY로 선언된 변수들은 인식함UFUNCTION()은 안됨 대부분 힙 할당 없이 스택 내 데이터로 사용,NewObject()도 지원 안됨하나의 멤버를 UFiled 클래스가 관리UScriptStruct가 GENERATED_BODY가 들어간 구조체UFinction은 UClass는 가져..

언리얼 엔진 자체 제작 자료구조 라이브러리유용하게 쓰는 거: TArray, TMap, TSet** T는 템플릿을 뜻함 C++ STL은 표준이긴 한데 많은 기능이 있어 컴파일이 오래 걸림언리얼 컨테이너 라이브러리가 더 가볍고 언리얼 엔진에 최적화됨vector -> TArrayset - x > TSetmap - x > TMap용도는 유사한데 셋이랑 맵은 내부 구현이 다름TArray- 가변 배열 자료구조- 데이터가 순차적으로 모여있어서 메모리를 효과적 사용, 캐시 효율이 좋음(공간적 지역성)- 언제나 그렇듯 이런 자료구조는 중간 삭제하는게 느림- 많은 수의 데이터에서 검색이 많이 일어나면 TSet이 나음- 연산: GetData(), Insert(), [] 연산자, Add(), Emplace(), Append(..

클래스 간 느슨한 결합 (Loose Coupling) 구현에 편리함- 추상적 설계에 의존 인터페이스를 쓰는 등의 방법으로 느슨한 결합의 구현이 가능그런데 좀 귀찮을 수 있음 -> 어떤 함수를 오브젝트처럼 관리 .. 델리게이트C#의 델리게이트 생각하면 됨* C의 함수 포인터보다 안전한 버전 느낌콘텐츠 제작자는 생산하고, 자신을 대신하여 발행할 발행자를 생성구독자는 발행자한테 받아서 소비이때 델리게이트를 발행자로 하고, 제작자와 구독자를 엮음* 순환 참조 안하도록 주의 언리얼 델리게이트 선언 매크로DECLEAR_{델리게이트유형}DELEGATE{함수정보}델리게이트 유형 (구독자의 수가 많으면 멀티)- DECLEAR_DELEGATE - 1:1형태로 C++만 지원함- DECLEAR_MULTICAST - 1:N 형..

Has-a 관계(상속은 Is-a 관계) SOLIDSingle Responsibility Principle - 하나의 객체는 하나의 의무만 가지도록Open-Closed Principle - 기존에 구현된 코드를 변경하지 않으면서 새로운 기능 추가 가능하도록Liskov Substitution Principle - 자식 객체를 부모 객체로 변경해도 작동에 문제 없을 정도로 상속을 단순히Interface Segregation Design - 객체가 구현해야 할 기능이 많다면 이들을 여러 개의 단순한 인터페이스로 분리하여 설계Dependency Inversion Principle - 구현된 실물보다 구축해야 할 추상적 개념에 의존하나의 언리얼 오브젝트는 항상 CDO를 가짐언리얼 오브젝트 간의 컴포지션?- CDO에..