치킨 날다

https://dev.epicgames.com/documentation/ko-kr/unreal-engine/asynchronous-asset-loading-in-unreal-engine

FSoftObjectPaths

• Asset의 전체 이름으로 된 String이 들어있는 구조체
  • Property를 만들 시 UObject*로 나타냄
• Cooking과 REdirector가 처리되기 때문에 Device에서 정상 동작을 보장한다.

FSoftObjPtr

• FSoftObjectPaths를 감싸고 있는 TWeakObjPtr
• Editor UI에서 특정 Class만 선택되도록 할 수 있다.
• 실제 대상 Asset은 Get 함수로 Raw Object를 반환
• 일반적으로는 Artist나 Designer가 수동으로 Setup 하는 것이 베스트
  • 다만 다음 조건에서는 Asset Registry나 Object Library를 사용하는 것이 좋다.
    • 특정 조건을 만족하는 질의를 모든 Asset Load 없이 시행하려는 경우

Asset Registry

• Asset에 대한 MetaData를 저장하고 검색, 질의를 가능케 하는 System
• 보통 Editor의 Contents Browser에서 정보를 표기하기 위해 사용됨.
  • 하지만 GamePlay 코드 상에서도 Load되지 않은 Asset에 대한 MetaData 질의를 하는데 사용 할 수 있다.
• MetaData 질의에 사용하기 위해서는 해당 Data의 PROPERTY()에 AssetRegistrySearchable Tag를 추가해줘야 함.
• 질의 결과는 FAssetData Object로 반환
  • Object 정보 뿐 아니라 Mark 된 Property가 들어있는 Key-Value Map도 포함되어 있다.

Object Library

• Load된 Object와 그렇지 않은 Object를 합친 리스트가 FAssetData에 있는 경우로, 공유 Base Class를 상속한다.
• 검색할 경로를 입력해 Load하면, 그 경로에 있는 모든 Asset이 Object Library에 추가된다.
• Contents 폴더 일부분을 각기 다른 유형으로 지정하고 사용하면
  Artist/Designer가 Master List를 건들지 않고 Asset을 추가할 수 있다.
  • 이 때, Master List는 Asset을 로드하고 있는 게임 내 고유한(Singleton) List를 지칭한다.
  • 더보기

     

    	if (!ObjectLibrary)
    	{
    		   ObjectLibrary = UObjectLibrary::CreateLibrary(BaseClass, false, GIsEditor);
    		   ObjectLibrary->AddToRoot();
    	}
    	ObjectLibrary->LoadAssetDataFromPath(TEXT("/Game/PathWithAllObjectsOfSameType");
    	if (bFullyLoad)
    	{
    		   ObjectLibrary->LoadAssetsFromAssetData();
    	}

• 위 코드는 새 Object Library를 생성하고, BaseClass를 할당하여 주어진 경로의 모든 Asset Data를 로드한다.
  • Option을 통해 실제 Asset Load도 가능.

• Asset이 작은 경우에는 통째로 Load한다.
  • Asset이 Cooking 중인 경우에는 모두 Cooking이 된 후에 Load도 가능하다.
  • Cooking 도중 Asset Registry 질의를 하고 반환된 Asset을 Load하는 한,
    Object Library는 개발 환경에서나 라이브 환경에서나 동일하게 동작한다.
• Object Library에 Asset Data가 들어가 있는 상태라면, 질의를 통해 특정 Asset만 선택적으로 Load 할 수도 있다.
• 더보기

  	TArray<FAssetData> AssetDatas;
  	ObjectLibrary->GetAssetDataList(AssetDatas);
   
  	for (int32 i = 0; i < AssetDatas.Num(); ++i)
  	{
  		   FAssetData& AssetData = AssetDatas[i];
   
  		   const FString* FoundTypeNameString = AssetData.TagsAndValues.Find(GET_MEMBER_NAME_CHECKED(UAssetObject,TypeName));
   
  		   if (FoundTypeNameString && FoundTypeNameString->Contains(TEXT("FooType")))
  		   {
  				  return AssetData;
  		   }
  	}

  • 위 코드는 TypeName에 "FooType"이 들어있는 것들을 검색하고, 그 중 첫번째 것을 반환한다.
    • AssetData가 생긴 후,
      ToStringReference()를 호출하고 FSoftObjectPath로 변환하면 Async Load가 가능하다.

StreambleManager

• 가장 간단한 Async Load
  • 이 외의 방법으로는 Async Load Package, BulkData가 있다.
• 게임 전역으로 유일한 Singleton Object에 생성하는 것이 좋다.
  • DefaultEngine.ini나 자체적인 SingletonClass 등
    • 더보기

       

      [/Script/Engine.StreamableManager]
      ; 스트리밍 풀의 최대 크기를 메가바이트 단위로 설정합니다.
      s.Streaming.PoolSize=2000
      
      ; 애셋을 스트리밍할 때 사용할 수 있는 동시 스트리밍 요청의 최대 개수를 설정합니다.
      s.AsyncLoadingThreadCount=8
      
      ; 스트리밍 대기 시간을 초 단위로 설정합니다. 이는 에셋이 스트리밍 될 때까지의 지연 시간을 조정합니다.
      s.Streaming.HLODStrategy=2
      
      ; 스트리밍 세그먼트 크기를 설정합니다. 더 큰 크기는 스트리밍 프로세스를 최적화할 수 있지만 메모리 사용량이 증가할 수 있습니다.
      s.Streaming.SegmentedStreamingThreshold=20​

       

      #include "Engine/StreamableManager.h"
      #include "Engine/AssetManager.h"
      
      void MyFunction()
      {
          FStreamableManager& StreamableManager = UAssetManager::GetStreamableManager();
      
          // 비동기 로드를 위한 에셋 경로
          FString AssetPath = TEXT("Path/To/Your/Asset");
      
          // 에셋 로드
          StreamableManager.RequestAsyncLoad(AssetPath, FStreamableDelegate::CreateLambda([]()
          {
              // 에셋 로드 완료 후 수행할 작업
              UE_LOG(LogTemp, Log, TEXT("Asset Loaded Successfully!"));
          }));
      }​

• FSoftObjPath를 전달하면 Load가 시작 함.
  • 작은 Object는 SynchronousLoad로도 충분 함.
  • 하지만 큰 Object는 Main Thread를 오래 점유하므로 RequestAsyncLoad를 사용해서 호출해야 한다.
    • RequestAsyncLoad는 완료 시 Delegate를 호출하도록 세팅 할 수 있다.
  • 더보기

    		void UGameCheatManager::GrantItems()
    	{
    		   TArray<FSoftObjectPath> ItemsToStream;
    		   FStreamableManager& Streamable = UGameGlobals::Get().StreamableManager;
    		   for(int32 i = 0; i < ItemList.Num(); ++i)
    		   {
    				  ItemsToStream.AddUnique(ItemList[i].ToStringReference());
    		   }
    		   Streamable.RequestAsyncLoad(ItemsToStream, FStreamableDelegate::CreateUObject(this, &UGameCheatManager::GrantItemsDeferred));
    	}
     
    	void UGameCheatManager::GrantItemsDeferred()
    	{
    		   for(int32 i = 0; i < ItemList.Num(); ++i)
    		   {
    				  UGameItemData* ItemData = ItemList[i].Get();
    				  if(ItemData)
    				  {
    						 MyPC->GrantItem(ItemData);
    				  }
    		   }
    	}

  • 예시에서 ItemList는 TArray<TSoftObjectPtr<UGameItem>>이며, Editor에서 Designer에 의해 수정되었다.
    • 위 코드는 ItemList를 순회하여 StringReferences로 변환시키고, 다음 Load를 위해 대기열에 등록한다.
    • ItemList가 모두 Load되거나 Load에 실패하면 전달 된 Delegate를 호출한다.
    • 그러면 Delegate는보통 Load 된 ItemList를 다시 순회하여 역참조를 구하고, 플레이어에게 전달해준다.
• StreamableManager는 Dlegate가 호출될 때까지 Load하는 Asset에 대한 Reference를 유지한다.
  • 이는 Delegate 호출 전에 Garbage Collecting이 되는 일 없도록 방지하기 위함이다.
  • Delegate가 호출된 후에는 Reference가 해제되므로 반드시 어딘가에 Hard Reference를 해줘야 한다.

*Async Load 방식들에 대한 비교

StreamableManager

• Runtime 중 Dynamic Asset Loading이나 Memory Resource가 제한된 환경에 적합하다.
  • 모바일이나 VR 환경
  • 주로 스킨, 무기, 추가 레벨 등에서 사용.
• 반대로 초기 Game/Level Loading 등 한번만 Load하면 되지만 그 용량이 큰 경우에는 부적합하다.

Async Load Package

• 전체 Game Level이나 World를 Async Load 할 때 적합
  • 보통 Map 전환 시 Loading Screen과 함께 사용하면 Load 지연을 인지하지 못하게 할 수 있다.
• 또는 Game이나 Level 시작 시 필요한 Asset들을 Load할 때에도 적합하다.
• 반대로 소규모, 또는 개별로 발생하는 Load에는 부적합하다.
  • Animation Clip, Texture 등

BulkData

• 큰 Texture, Sound, Video와 같은 대용량 Resource 사용에 적합하다.
  • GamePlay 중 Memory에 직접 Load되어 성능 최적화에 기여 한다.
• Media Player 또는 Video Streaming Service에서 async로 대용량 미디어 파일을 Load하고 재생할 때 유효
• 모든 경우의 Synchronous Data 처리에 부적합하다.
  • Load 속도가 비교적 느리기 때문

NIKKE를 재밌게 하다가 비슷한 작업이 Unreal에서 가능한지 확인하기 위해 해본 RnD입니다.

제가 알기로 NIKKE는 Spine을 쓰고, Spine은 뼈대에 2D 파츠 이미지를 붙이고 뼈대의 Animation을 통해 동작하는 방식으로 알고 있습니다.

흡시 언리얼 엔진에서 MeshMerge로 각 파츠 Mesh를 하나의 Mesh로 만들고, 안에 Skeletal을 넣은 뒤 Animation이 Skeletal에 동작하는 것과 같이요.

목표는 이와 같이 파츠 별 이미지를 따로 관리하는 것.

그리고 각 애니메이션 작업을 뼈대를 기반으로 하는 것입니다.

RnD 해봤던 플러그인은 총 3개입니다.

PaperZD

알아볼 때 가장 그럴듯해 보이던 플러그인이었습니다.

신규 버전에 대한 지원도 잘 되고 기존 언리얼의 Paper2D 기능을 확장하였기에 가장 기대가 컸습니다.

실제로 UE5 5.3 버전에서 잘 동작 하였습니다만 한가지 문제가 발생했습니다.

Paper가 붙었듯, Flip Book 형식으로 2D Animation이 재생된다는 점이었습니다.

이런 식으로 말이죠.

이 말은 각 프레임마다 이미지가 여러 장이 필요하고, 각 이미지는 대상의 모든 파츠를 다 담고 있어야 한다는 의미입니다.

아님 파츠별로 FlipBook을 따로 만들고 이걸 같은 좌표에 중첩해서 출력하거나.

혹은, PaperZD 기능을 확장하여 각 파츠 이미지에 해당하는 Sprite를 여러개 들고 있으며, 각 프레임마다 그 위치와 각도를 컨트롤 할 수 있는 Custom Paper Flip을 제작하는 것입니다.

앞의 2가지 방법은 코스트가 너무 높아져서 부적합하고, 세번째는 당장은 할 수 없는 작업이라 판단하였습니다.

렌더링 코드를 잘 아는 것도 아니고....

Creature2D Skeletal and Mesh Tool

Creature2D는 조사했을 때 제가 원하는 기능에 가장 근접한 Plugin이었습니다.

퀄리티도 꽤 높아서 기대를 많이 했는데, 지원 버전이 4.24에 멈춰있었습니다.

자체적으로 5.0 지원을 준비 하는 것 같기는 해서 설치 후 빌드 에러를 수정하고 작업하려 했으나,

지원 기능이 많은 만큼 렌더링 코드에서 많은 크래시가 발생하여 RnD를 중지하였습니다.

Spine Plugin

Spine과 같은 기능을 UE5에서 할 수 있는지 알아보다가 "Spine은 UE5에서 못쓰나?"라는 의문으로 시도했습니다.

알아본 결과 상당히 지원이 잘 되어 있는 것을 확인할 수 있었습니다.

https://ko.esotericsoftware.com/spine-ue4

이렇게 주의사항도 문서 갱신이 잘 되어 있기도 하구요.

이 부분만 주의를 한다면 테스트케이스 작업 자체는 매우 간단하게 마무리가 됩니다.

모듈 선언 해주고 값 넣고 세팅만 하면 되더군요.

다만 몇가지 주의할 점이 있습니다.

첫째, Spine 정보를 .skel과 .json 2가지로 전달할 수 있는데 .skel은 인식은 하지만 동작하지 않습니다.

그러니 Unreal Engine 5에서 Spine Plugin을 쓸 때 정보는 .json을 사용하는 편이 좋습니다.

둘째, 위 사진에 언급 한 것처럼 한 Spine에 대한 파일들이 확장자와 무관하게 이름이 모두 달라야 합니다.

조사해보니 5.3으로 올라가면서 json, uasset, spine 등의 이름 구분이 안정적으로 지원되지 않게 되었다고 하네요.

결과적으로 사실상 PaperZD, Creature2D, Spine 중에서는 Spine이 압도적인 승리를 거둔 셈입니다.

그냥 Spine을 쓰면 되니까요.

다만 애로사항도 있습니다.

첫번째로 Spine은 별도의 에디터가 있어서 그 에디터로 작업을 해야 한다는 점.

Unreal Engine은 조립만 해야 합니다.

두번째로, 이 때문에 애니메이션 쪽 작업의 디버깅이 불가하다는 점.

순전히 아트의 작업으로 넘어가게 됩니다.

어떻게 보면 좋은건가?

일단 튜토리얼 문서에 아직 못 본 항목도 있어서 조금 더 봐야 알 것 같습니다.

이름은 좀 다르겠지만 2편이 생기겠네요

우선 출시 직후에 가장 많은 혹평 요소는 "분량"과 "최적화"이었습니다.

그 다음에 나온 얘기가 "호러 게임인데 액션 요소가 더 크다"였는데요.

전 윈도우 리소스 패치가 이미 나온 후라서 최적화 부분은 크게 얘기 할 요소는 없습니다.

그 외의 요소들을 중점적으로 적어보고자 합니다.

1. 분량

제 기억상의 데드스페이스 1하고 큰 차이는 없는 것 같습니다.

다만 서브 스토리나 설정 배경 등을 다른 지역에 분리하는데 그 지역을 거치지 않고 진행이 되는 점.

동일한 맵 리소스를 재활용 하려는 모습 등 유저들이 시각적으로 비슷한 부분이 반복되는 현상이 있습니다.

2. 액션 요소

전 키보드-마우스로 해서 패드의 획기적인 방향키 혼합 매핑을 직접 경험하지는 못했습니다.

일단 방향키로 회피하는게 복싱에서 위빙 하는 느낌이라서 다른 액션 게임에서도 채용하면 많이 좋을 것 같았습니다.

다만 전반적으로는 더 좋은 기능이 있음에도 호러 게임의 가장 큰 특성인 "제약"가 맞물려서 더 안좋은 기능들을 제공하되, 그 편의성을 개선 했다는 인식이 강합니다.

반대로 말하면 호러 게임이 아니라면 이런 방식이 통할까? 라는 생각이 좀 큽니다.

3. 호러

저는 솔직히 전반적으로 호러 게임이라는 느낌이 거의 들지 않았습니다.

사운드나 연출 기법이 전형적인 호러 게임의 정석임에도, 호러는 겉껍데기라는 느낌이 강합니다.

다른 호러 게임에서는 적이 많이 나오지는 않지만 한명한명이 버겁거나 극한의 상황으로 몰아넣는 느낌이 강했다면,

칼리스토 프로토콜은 굉장히 만만한 적들이 순차적으로 나오거나 일정 지역에 배치 되어 있어서 전투가 간결합니다.

콤보 중에도 피격이 거의 없기 때문에 한번에 앞뒤로 여러명이 튀어나오지 않는 한 큰 문제는 없습니다.

그래서 이걸 계속 반복적으로 공략하고 대응하는 과정에서 액션이라는 느낌이 강합니다.

4. 밸런스

이게 좀 기묘한 부분인데 일반 맵에서는 근접무기가 거의 기본사양입니다.

총기류는 탄약을 많이 들고 다닐 수 없기도 하고, 데미지가 근접무기가 훨씬 효율이 좋기 때문입니다.

하지만 중간 보스 급인 트윈헤드, 최종보스는 근접으로 대처가 거의 불가합니다.

트윈헤드만 해도 3방 맞으면 빈사고, 최종 보스는 한방컷이 가능합니다.

물론 깨는 사람도 있겠지만, 여타 적들에 비해 난이도가 매우매우 높습니다.

그래서 이런 적들은 기본적으로 총기로 상대를 해야 합니다.

트윈헤드는 총기로 빈사시키고 근접으로 때리면 정확히 2페이즈만에 끝납니다.

최종 보스는 근접은 생각도 말고 그냥 빙글빙글 돌면서 탄환을 머리에다가 박아넣어야 합니다.

최종 보스 전에는 심지어 상당한 양의 탄약을 주기도 합니다.

결국 게임이 시스템 단위에서 게임을 할수록 근접무기에서 총기류를 중심으로 사용하도록 하는 것입니다.

앞에서는 열심히 위빙 치고 뚝배기 깨다가 정조준 사격 하더니 나중에는 근접을 시도하기 너무 빡세서 불만 사항이 큰 것 같습니다.

5. 스토리

개연성이 많이 부족합니다.

전반부에서 마찰이 발생하는데 그 이유가 최후반부 직전에야 나옵니다.

그래서 앞에서 플레이 할 때에는 "저거 완전 사이코패스 아니야?" 하고 플레이를 하다가 뒤에서 "짜잔! 사실은 이렇습니다" 하는거죠.

이 텀이 매우 길고 떡밥이 거의 없어서 공감도 잘 안가는데 내용적으로도 이 부분이 매끄럽지 않습니다.

이게 다른 타이틀이라 그렇지 만약 데드 스페이스 타이틀로 후속작이 이렇게 나왔다?

바로 더 라스트 오브 어스 2 꼴이 되어도 할 말이 없다고 생각합니다.

총평을 해보자면 "오염된 호러 장인"일 것 같습니다.

호러에 대한 공식을 착실하게 따랐지만, 코어 플레이가 액션성이 너무 짙은 탓에 주객전도가 심하게 되었습니다.

비유하자면 30년 해장국 장인이 양식집에서 먹은 크림스프 맛에 반해서 본인 가게 해장국 신메뉴에 크림을 넣은 격이겠네요.

연말에 갑자기 일이 생겨서 생각보다 자유롭게 개발을 못했습니다.

오늘은 InputActionComponent의 Type을 변수로 받아서 실시간으로 Component를 코드 상으로 생성하고, 에디터에서도 표시가 되는 방법을 찾아보았습니다.

결과적으로 생성되는 것까지는 했으나, 에디터에서 표시가 되지 않아 뭔가 사용하기 좀 더 어려워진 느낌이었습니다.

그래서 Component는 수동으로 입력해주는 이전 방식으로 복구해놓고, 컴포넌트 부분은 따로 처리해보기로 했습니다.

두번째로 애셋들이 경로 정리 하면서 깨져서 다시 Migration해주었습니다.

이 과정에서 Migration 전용 프로젝트에서 경로가 꼬인 것들을 정리하고, 신규로 경로 정리를 했습니다.

작업은 10일부터 했는데 미완인 상태에서 계속 개선하고 건드려 보다가 오늘 완성이 되어서 일지를 적어봅니다.

Enhanced Input Component를 이용해 입력을 받도록 하되, 이왕 입력이 간단하게 정리가 되는 김에 좀 더 모듈화를 하고 싶었습니다.

그럴려면 가장 큰 문제는 입력 반응에 호출될 함수들이 Character 내부에 있는게 아니라 별도의 Object에 있고, Character에서 그걸 가져다가 쓸 수 있었어야 했습니다.

금요일에 Character 내부에서 입력 작업을 마무리 하고, UObject에다가 함수를 분리한 뒤 시도를 해보았는데 빌드 오류를 잡지 못해서 revert를 했습니다.

그리고 오늘 졸린데 자기 직전 니케 재화 빼기 위해 뭘 할까 하다가 다시 잡았는데, 코드를 좀 더 찾아보니 Bind Function을 Object와 FunctionName 두가지로 검색하는 것을 발견했습니다.

그래서 "혹시 항상 this를 넣어 주었던 Object 부분에 UObject를 넣어주면 되는거 아닐까?" 해서 시도를 해보았고, 이것이 들어맞게 되었습니다.

이 과정에서 몇 차례 크러시가 났었는데, 처음에는 Interface로 함수들을 선언해주고 이걸 UObject가 상속을 받게 했습니다.

하지만 Interface에서 파생된 함수는 Bind가 동작하면서 Object가 안전하지 못한 것인지 받아들이지 못했고, 그래서 Interface를 폐기하고 Object로 통일했습니다.

이 부분이 해결되니 그 이후는 비교적 간편했습니다.

Character 내부의 동작 함수를 각각의 Object에 이식을 하고, 이를 Bind 함수 내부에서 일괄적으로 Bind를 해주었습니다.

이후 작업은 Animation이 될 예정입니다.

기본 서있기나 이동 기능은 기본이고, 몇가지 사항은 애니메이션 제공 상황을 봐서 추가 적용할 생각입니다.

첫번째는 제자리에서 화면을 좌우로 전환 시 고개가 따라 움직이는 기능.

두번째는 고개가 일정 이상 회전 시 그 방향으로 몸이 완전히 돌아가는 기능.

세번째로 걷다가 방향을 전환할 시 회전 애니메이션을 넣는 기능.

이렇게 애니메이션을 우선 적용할 예정입니다.

여기까지가 연말에서 구정 전까지 작업 할 사항입니다.

위 작업이 마무리가 되면 뛰기, 점프, 앉기 등 혼자서 할 수 있는 기능들을 구현할 생각입니다.

그 다음에는 공격, 상호작용 등을 작업하여 솔로 플레이에서 퀄리티 있는 로코모션 기능을 구현하고, 간단한 오픈월드를 만들어서 IK를 적용할 생각입니다.

여기까지가 내년 3월 중으로 마무리 할 예정인 부분입니다.

이 다음은 Dedicate Server를 생성해서 멀티플레이에서 기능 테스트를 할 예정이고, 이 작업에서는 예전에 NDC에서 보았던 "서버와 클라이언트에서의 컴포넌트 부착을 조작하여 최적화"하는 것을 고려할 예정입니다.

예를 들어 Animation에 필요한 상세한 정보나 이벤트 호출 부분을 서버에서는 동작하지 않고, 결과만 받아서 쏴주는 등의 방식을 이용해볼까 합니다.

여기까지가 내년 상반기까지의 목표입니다.

이 부분까지 된다면 AWS에 서버를 올리고, 본격적인 기획사항을 구현해갈 예정입니다.

오늘은 아래 영상을 참고하여 Enhanced Input Mapping을 이용해 기본적인 기능(이동/마우스 커서 회전)을 구현해봤습니다.

https://www.youtube.com/watch?v=XSz5l5Rfxbw 

작업했을 때 매우 간단하기는 했으나 이동 부분에 버그가 있어서 이 부분을 추가로 수정해줘야 할 것 같습니다.

그리고 영상의 방식을 따라 한다면 애니메이션의 배치 등을 모두 BP로 해야 하는데 이 방식이 효율적인지 고민입니다.

기능이 몇 없다면 문제가 없겠지만 스킬들을 넣는 등 여러 가지를 배치 한다면 어느정도 자동화를 하는게 좋겠는데,
이벤트 발생하는 시기를 특정지을 수 없어서 형태를 고민 중에 있습니다.

지금 드는 생각은 대략 이런 방식입니다.

1) 모션 발생 시 실행 될 함수를 인터페이스로 제공한다

2) 프로젝트에서 사용하는 공용 InputAction을 만들고 이 InputAction이 1)의 인터페이스 타입을 들고 있는다

3) Character 내부에서 2)의 InputAction에서 1)의 인터페이스 타입을 받아와 Character를 Cast 해서 Valid 한 경우에 이벤트를 Bind

개인적으로 아쉬운건 3)의 부분을 Template로 처리할 수 없어서 수동으로 작업해줘야 한다는 점입니다.

하지만 이를 완전히 자동화 해서 BP에서 숨김처리하는 것보다 기계적인 반복 처리가 필요하더라도 노출하는게 향후 신규 작업 추가 시에 더 좋지 않을까 하는 생각도 들어서 이 방법을 좀 더 탐구해보고 발전해볼 생각입니다.

금요일에 Unreal Dev Community에서 Programming, Animation 관련 항목들을 읽고 개인적으로 필요하다 싶은 튜토리얼들을 정리해보았습니다.

https://docs.google.com/document/d/1DPCe4WUm4l5Sm4o00t2Kf14m-KGCB1Bg8JXcFKw699U/edit?usp=sharing 

이를 기반으로 Locomotion 개발은 Enhanced Input으로 진행하기로 하였습니다.

다만 오늘은 이 부분을 제대로 손보지는 못했고, Mode나 Character 등 기본 Class와 BP들을 선언하고 연결하였습니다.

일주일동안 GamePlay Ability System(이하 GAS)과 애니메이션 사용에 대해 공부를 했습니다.

결국 GAS는 게임 내에서 float 등으로 표시되는 스탯들을 관리하는 시스템이었습니다.

예를 들어 달리기를 한다면 모션 자체는 예전의 Animation과 구현이 동일하지만, 달리기 속도 등 외부 요인으로 변경될 수 있는 스탯들은 GAS로 관리를 해주는게 좋을 것 같습니다.

결국 GAS 자체는 기본 Locomotion이 구현되고 나면 그 뒤에 덧붙이는 편이 좋을 것 같습니다.

더불어 Sub Animation Graph 등 여러가지 기법들을 확인해서 이를 이용해 연말까지 Locomotion 구현을 진행해보고자 합니다.

오늘은 프로젝트 세팅을 마무리하고 첫 작업을 해보았습니다.

GamePlay Abilities를 사용해보았는데, 튜토리얼을 따라해도 문제가 많아서 우선 모두 revert를 하였습니다.

다음에는 이 기능이 정확히 어떻게 동작하고, 어떤 경우에 쓰면 좋은지 파악해서 필요 기능 별로 구현 방식을 대략적으로 정리하고자 합니다.

이후 모두 GAS로 처리가 되면 GAS 개발을, 아니라면 GAS가 아닌 기능들을 우선 개발하고자 합니다.

일주일 넘게 걸렸습니다.

대략 열흘동안 주중에는 이슈가 좀 많아서 손을 못대고, 주말에는 프로젝트 세팅 하다가 오늘 어떻게 마무리가 되었습니다.

목표는 Unreal Project를 Content 폴더와 그 외의 것으로 분리해서 따로 VCS를 돌리는 것이었습니다.

처음에는 Content 폴더는 바이너리 파일들만 있기 때문에 Perforce로, 전체 프로젝트는 코드와 설정들이 주류라 Git으로 하고자 했습니다.

다만, 이 둘을 모두 EC2에 올려서 서버 구축 방법을 알아보고자 했습니다.

그런데 다른건 몰라도 EC2 접속 오류가 곧 죽어도 안 잡히더라구요.

그래서 타협을 해서 Git 대신 CodeCommit에 전체 프로젝트를 올려두고, Content만 따로 추가로 잡아보았습니다.

그게 거진 화요일? 수요일이었습니다.

그리고 오늘까지 작업한 결과 결국 답이 없더라구요.

EC2 접속 잡는건 여전히 잘 안되어서 결국 Perforce와 EC2를 포기하고 CodeCommit을 하나 더 만들어서 Content를 올려두었습니다.

썩 좋은 방법은 아닌 것 같은데 더 잡으면 더 쳐질 것만 같더라구요.

이 외에 업무시간 외에 휴식시간이나 대기시간에 짬짬히 GAS(Game Ability System)을 공부했습니다.

뭔가 감이 잡힐듯 안잡힐듯 한데 우선은 당장 애니메이션과 모션 쪽에서 어느정도 사용은 가능할 것 같아서 우선도를 높게 잡고 찾아보고자 합니다.

최우선은 컨트롤 방식을 좀 정해놓고, 정리한 뒤 이를 구현하는 것입니다.

상하좌우, 화면 돌리기를 먼저 잡고 그 사이에 GAS를 살펴본 뒤, 점프나 공격 등을 GAS를 사용하면서 해볼 생각입니다.