Replicated

오브젝트나 연결된 오브젝트의 묶음(오브젝트 그래프)을 바이트 스트림으로 변환하는 과정- 복잡한 데이터를 일렬로  -> 직렬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{함수정보}델리게이트 유형 (구독자의 수가 많으면 멀티)- DECLARE_DELEGATE - 1:1형태로 C++만 지원함- DECLARE_MULTICAST - 1:N 형..

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

인터페이스- 객체가 반드시 구현해야 할 행동을 지정하는데 활용- 다형성의 구현, 의존성이 분리된 설계에 유용 언리얼 c++인터페이스인터페이스 생성 시 두 개의 클래스 생성..- U로 시작하는 타입 클래스 (클래스 타입 정보 제공)- I로 시작하는 인터페이스 클래스 객체 설계 => I 인터페이스 클래스 사용- U타입 클래스에서 작업 안함* C++기반이라, 클래스로 인터페이스 구현해서 인터페이스에도 구현이 가능함 // Fill out your copyright notice in the Description page of Project Settings.#pragma once#include "CoreMinimal.h"#include "UObject/Interface.h"#include "LessonInterfa..

리플렉션 : 프로그램이 실행 시간에 자기 자신을 조사하는 기능다양한 기능이 리플렉션을 토대로 제공언리얼이 자체적으로 제공함 옵션으로 필요할 때 사용 가능리플렉션 시스템에 보이도록 했으면 하는 거에 주석을 달아주면언리얼 헤더 툴이 컴파일 시 해당 정보를 수집 헤더에 리플렉션이 있는 유형으로 마킹 시 -> generated.h 인클루드 필요그 다음 객체에 UENUM(), UCLASS(), USTRUCT(), UFUNCTION(), UPROPERTY()를 앞에다 넣어주면자동으로 처리해줌 멤버 변수 -> UPEROERTY()함수 -> UFUNCTION()매크로 추가 시 관련 코드를 INTERMEDIATE 폴더에 자동으로 생성해줌이때 메타데이터 넣을 수도 있음 리플렉션된게 아니면 가비지 컬렉터 작동 안함-> 알아..