Game Develop

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

예를들어 캐릭터의 전투여부에 따라 Idle모션이 바뀐다고 가정. 애님인스턴스 c++파일에서는 캐릭터클래스를 TryGetPawnOwner로 받아와서 애님인스턴스클래스자체에서도 bool IsCombat을 계속 업데이트하게 해놨다. 입문자를 위한 책예제에서는 전부 블루프린트에서 하게 해놨는데, 일단 블루프린트와 C++성능 차이가 꽤 있다는 것을 인지하고 있었기 때문에 틱마다 수행하는 이런 간단한 값업데이트정도는 C++로 하는게 맞다고 판단했다. 사실 일단은 규모가 작기 때문에 현재를 기준으로 치면 블루프린트로 처리하든 C++코드로 처리하든 별 의미는 없다. 다만, 어차피 결국 커지기 마련이고 최대한 코드로 처리할 수 있는 부분은 코드로 처리하는게 맞는 것 같다. 실제로 이렇게하니까 아래와 같이 에디터자체에서도..

프로젝트에 사용할 캐릭은 에픽게임즈스토어에 무료로 풀린 파라곤 에셋 캐릭터들 중 하나를 구입해서 사용했다. 애니메이션같은 경우는 에픽게임즈스토어에서 애니메이션팩을 유료로 구입했다. 즉, 서로 다른 스켈레톤이기 때문에 리타겟팅을 해줘야 했다. 일단 Walk 애니메이션시퀸스를 먼저 리타겟팅을 해 봤다. 이 Walk 애니메이션시퀸스는 기본적으로 루트모션이 아니고, 조금씩 전진하는 파일이다. 그대로 캐릭터에 적용할 경우 그냥 가만히 냅둬도 조금씩 전진한다음 다시 처음으로 돌아오게되고 이걸 계속 반복한다. 그렇기 때문에 반드시 루트모션을 적용해줘야 한다. 좀 더 이유에 대해 첨언하자면, 조금씩 전진할 때 루트캡슐컴포넌트는 같이 전진하지않고 시작위치에 그대로 있기 때문에 의도치 않은 버그들을 유발할 수 있다. 캐릭..

본인이 직접 작성한 코드에 대한 포인터는 UPROPERTY 매크로를 붙여서 관리하게 하자. -> 잘못하면 런타임때 죽어버릴 수 있다. 월드상에 배치되는 액터라면 IsValid()함수로 유효성 체크를 한다. 언리얼오브젝트는 Destroy를 호출한다고 바로 삭제되는게 아니라, 일단 Pending Kill 상태로 마크만 표시한 후, 다음 가비지컬렉터가 작동할 때 되서야 실제로 삭제된다. 네이티브 c++ 개발할 때처럼 nullptr로만 체크를 하는것을 권장하지 않는다. UPROPERTY가 런타임때 죽는다면, 가비지컬렉터가 UObject에서 상속되는 클래스를 지워서 그렇다. 스마트포인터로 관리하거나, AddReference로 GC에 참조카운트를 올려서 관리받게 유도한다. Actor클래스의 경우 SpawnActor..