Game Develop

액터 컴포넌트(Actor Component) 재사용가능한 기능을 정의하는 컴포넌트에 대한 베이스 클래스로 충돌, 메시, 월드 이동, 소리 재생, 빛과 명암 등의 다양한 기능을 지원. 씬 컴포넌트 (Scene Component) 트랜스폼을 가진 액터 컴포넌트 프리미티브 컴포넌트 (Primitive Component) 렌더링 가능한 액터 컴포넌트

필요없는 잡소리를 듣고싶지 않다면 https://forums.unrealengine.com/t/when-is-the-constructor-called/480067 When is the Constructor called? Hey guys, first of all, i am sorry for my English. So i need to say that i am in the beginning of GameDev. I know the basics of c++, and so on, and therefore i wanted to look into Unreal Engine. My Problem is something like this: why is it not possible to forums.unrealengine..

UPROPERTY를 당연히 쓰긴 써왔지만, 사실 각프로퍼티에 대해 좀 헷갈렸었다. 설명은 많지만 아키타입이 뭔지도 헷갈리고, 그냥 적용범위가 넓은 프로퍼티를 써서 되게만 해왔던 것 같다. 하지만 const처럼, 읽기전용으로 할것을 굳이 Edit관련 프로퍼티를 넣을필요가 없기에 한번 싹 정리를 했다. 공식문서등에 나오는 아키타입이란 것은, 우리가 어떤 액터를 만들고 해당 액터를 상속받는 블루프린트클래스파일을 만들경우 이 블루프린트파일이 아키타입이라 생각하면 된다. 유니티의 프리팹이랑 매우 비슷한 개념이라고 하며, UPROPERTY에서 아키타입에 관해 Edit이라던가 Visible관한 설명이 나오면 이 블루프린트파일내에서 디테일패널에 표시할건지, 수정까지할건지 등에 대한 속성을 결정하는거라 보면 된다. 위의..

다른부분에 대해서 구글링하다가, 우연히 접하게 되었다. 이름에서 알 수 있듯이, C++의 inline과 비슷한데 좀 더 강력한 강제성을 지녔다고 한다. 애초에 c++에서의 inline같은 경우는 명시하더라도 컴파일러가 임의로 인라인화를 안시킬수도 있으며 inline을 명시 안했더라도 인라인화를 시켜버리기도 한다. 예를들어 헤더에서 함수정의까지 할 경우 인라인화를 시키는 경우가 있다. 그에반해 언리얼 FORCEINLINE은 좀 더 강제성을 띈다고 한다. 다만 당연히 무조건 좋은건 아니고 공식문서에도 좀 더 보수적으로 사용하라고 되어있다. 어떤곳에 사용하지않는게 좋은지는 알아갈때마다 이 글에 추가해봐야겠다. 일단 현재는 Getter 함수에다가는 전부 선언해줬다.

const는 결국 사람의 실수를 막기 위한 것이다. 없어도 동작은 당연히 한다. 말했다시피 당연히 실수를 방지하기 위함이다. 실수를 미리 방지할 수 있으면 개발시간도 단축될 수 있는 가능성이 있기 때문에 생산성에까지 영향을 끼친다 볼 수 있다. 미리 함수파라미터에 const로 해놓으면, 함수내부로직을 작성할 때 무의식적으로 해당 매개변수값을 변경하려 하면, 에러를 띄워주니 말이다. 만약 const로 안해놨으면 좀더 나중에서야 알아차리겠지. 그래서 이펙티브 c++ 책이라던가 다른 개발자분들께서도 코딩스탠다드에 c++를 적극 사용하라는 말들이 있다. 레퍼런스는 불필요한 복사를 방지하기 위함이다. 게임개발을 하다보면 위치값이나 회전값같이 벡터값을 넘겨야하는 경우가 많은데, 그냥 초보자강의용이라던지 그런 영상 ..

ActorPool로 관리할 액터들에게 PoolableActor라는 인터페이스를 상속시켰었다. 해당 인터페이스에는 m_bIsActive, 즉 활성화여부를 따지는 bool변수 딱 하나만 있었다. 아무생각없이 그렇게 하다가, 인터페이스 관련 글을 보다보니 원래 객체지향설계에서 인터페이스에는 멤버변수가 없는게 정설이라고들 하더라... 원시타입인 bool 하나라서 괜찮지 않을까? 싶다가도, 후에 특정 액터클래스에도 같은 변수명이 있을수도 있는, 즉 겹칠수도 있는 상황이 있을수도 있단다. 생각해보니 말이 된다. 물론, 현제 내가 아는 영역에서는 활성화여부란 액터풀에 관련된 활성화여부밖에 없지만, 그건 취준생의 생각일 뿐이다. 그래서 언리얼 인터페이스가 아니라 그냥 추상클래스로 바꾸려고 여러 시도를 했다. 거의 인터..

튜토리얼?이라던가 그런것들 보면 보통 생성자에서 부착해서 쓰고들 한다. 그래서 생성자에서만 호출 가능한 로드함수들을 사용하고는 한다. CreateDefaultSubobject라던가 ConstructorHelpers::FClassFinder (혹은 FObjectFinder 등) 같은 걸 쓴다. 일단 기존의 생성자에서 호출하는 코드. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 UWidgetComponent* widgetComponent = CreateDefaultSubobject(*assetPath); widgetComponent->SetupAttachment(mesh); widgetComponent->SetRelativeLocation(relativeLocation); wi..

언리얼 유효성검사하다보면, 막 배우는 사람들입장에서는 헷갈리는 부분들이 있다. 뭔 로우포인터쓰면 nullptr이 대입안되서 위험하고.. UPROPERTY쓰면 어쩌고 저쩌고.... 다른 기준으로 좀 이해하기 편하게 쓰자면, 어떠한 액터의 Destroy()를 호출했을때를 기준으로 생각하는것도 괜찮다. 일단 UPROPERTY()가 명시된 액터의 경우, Destroy를 호출한 다음 GC가 호출되기 이전, 이후는 다음과 같다. 이전 : 여전히 기존의 메모리를 가르킴. 이후 : 변수에 nullptr대입 즉, 만약 Destroy 호출 후에 GC가 호출되기 이전에 그저 해당 유효성검사를 nullptr로 한다면 개발자가 의도하지않은 동작이 일어날 수 있다는 의미이다. 어쨌든 Destroy를 호출했다는 것은 해당 호출 이..