Trapper 소개 영상 보러가기

2024년 4월부터 시작해 11월 중순까지 열심히 달렸고, 지스타와 게임인재원 졸업전시까지 끝낸 시점이 왔다. (뭐했다구 또 나이를 먹네요..) 언리얼 엔진의 언자도 모르고 시작한게 엊그제 같은데.. 어쨌든 인재원 덕분에 정말 값진 경험을 얻은 것 같다. 내가 만든 게임을 불특정 다수의 사람들이 플레이하고, 그에 대한 피드백을 받을 수 있는 기회는 정말 흔치 않으니까.

10월 한달간은 폴리싱하고, 코드 갈아엎고 버그 잡는다고 정말 정신이 없었고, 10-11월에 걸쳐서는 포트폴리오를 제작하고 자소서도 몇개 써본다고 글을 포스팅 할 여력이 없었다. 지스타랑 졸업전시 마무리하고, 방학동안 야무지게(?) 쉬고 왔다. 으.. 이제 새삼 진짜 취준 시작이구나 싶다.

어쨌든, 아무것도 모르는 상태로 시작한 블로그라 많이 부족한 글들만 잔뜩 써왔지만, 시작했으니 마무리는 해야겠다는 생각으로 시리즈의 마지막 글을 작성하러 왔다. 아마 프로젝트와 관련된 기록만 남기진 않을 것 같다. 취업을 앞둔 시점에서, 생각을 정리하려고 작성하는 글이기도 하니까.

제일 어려웠던 것

프로젝트를 진행하면서 제일 어려웠던 것은, 역시 아무래도 언리얼 엔진을 배우고 쓰는거였다. 제공해주는 기능이 많은 만큼, 내부 코드를 모르고 쓰면 그만큼 위험성이 높다는 것을 제대로 깨달았다. 그리고 엔진 딴에서는 다 구현되어있는 기능인데, 몰라서 헤맨 것도 많았음.

이전에 인재원에서 배웠던 과정들은 전부 자체엔진 프로젝트였었는데, 아무래도 우리가 0부터 100까지 엔진의 기능을 모두 만들어서 사용하다보니 문제가 생기면 대부분 우리 선에서 해결이 됐었다. 팀원이 만든 기능이라면 물어물어 해결할 수 있었고 내가 만든 기능이라면 문제점을 찾고 고쳐서 쓰면 됐었으니까.

아무튼 나는 언리얼 엔진을 처음 배울 때 그 스케일에 압도당했던 것 같다. 문서와 블로그를 찾아가며 엔진의 기능을 사용하는 방법을 배워야했고, 내부적으로 견고하게 쌓여져있는 코드는 읽기에도, 이해하기에도 정말 막막했다. 하나하나 이해해가며 쓰면 너무 좋겠지만, 모든 기능을 다 알고 쓰려고하면 밑도끝도 없이 파고들어야 하다보니 정신도 없었다.

지금 팀원들이랑 얘기하는거지만, 만약 우리 게임을 더 발전시켜야 하는 상황이 온다면, 갈아엎자는 의견이 99%다. 나도 100% 동의한다 ㅎㅎ. 그럼에도 불구하고, 지금 완성된 게임은 결국 그동안 노력해온 결과물이니까. 새삼 대견하기도 하고, 더 잘할 수 있었을 텐데 하는 후회도 남고 여러 감정이 든다.

절망의 계곡

프로젝트랑 별개로 이제 공부를 한지 2년 다 되어가는데, 절망의 계곡에 여전히 박혀있는 중이다. (언제 나갈 수 있는거지...?) 사실 한살만 어려졌으면 좋겠다. 일년 더 공부하면 지금보다 낫지 않을까, 이런 생각도 많이 한다. 스무살때부터 컴공을 전공한 친구들이 부러웠고, 내가 못하는 것을 너무나도 멋지게 해내는 친구들을 보면 힘들기도 했다. 나도 잘하고 싶은데, 어떻게 해야 더 잘할 수 있을까 매일 고민했으니까.

근데 뭐, 별 수 없다. 그냥 지금처럼 계속 해나가는 수밖에 없는 것 같다. 공부하는동안 몇번이고 넘어졌지만, 나는 결국 오늘까지도 포기하지 않았고, 앞으로도 그럴 것 같다. 그냥 이 과정이 즐거우니까, 즐기기로 했다. 뭐, 이대로 계속 하다보면 언젠가는 잘 하는 사람이 되지 않겠어요?

드디어 지스타!

아직도 사진을 보면 믿기지가 않는다. 우와.. 내가 지스타에서 전시를 했다니..! 결국 해내고 말았다..!!!! 디자인을 배웠을 때부터 느낀거지만, 내가 만들고 창작한 무언가가 누군가에게 영향을 끼친다는건 정말 멋진 일이다.

목/금에 상주했던 친구들이 받아온 명함들을 보고 꽤나 놀랐다. 기업의 멋진 분들이 우리가 만든 게임에 관심을 가져주시고, 좋게 평가해주셔서 너무 신기하고 신이났다.

내가 개발했던 많은 것들중 제일 만족했던 부분은 역시나 제일 고생했던 자성이동 기능이었다. 멀쩡하게 잘 돌아가는걸 보면서 얼마나 기뻤는지.. 다들 자성이동만 해도 재밌다고 해줘서 너무너무 좋았다 ㅜㅜ

애기들이 플레이 해줬던 것이 기억에 남는다. 애기들이 이해하기엔 불친절하고 어려울 수도 있는 게임이었을텐데, 작은 손가락으로 키보드를 하나하나 눌러가며 게임을 조작하고, 재밌게 해주는걸 보니까 괜히 기분이 이상했다. 오래 해주고 간걸 보면, 그래도 꽤 재미있었나보다.

상주하면서 사람들이 플레이하는걸 뒤에서 지켜보면, 되게 조마조마하다. 게임이 언제 터질지 모르고, 사람들이 생각지도 못한 방식으로 플레이하는걸 보면.. 그냥 시중에 나온 게임들이 얼마나 대단한지 새삼 느끼게 된다. 안정적인 플레이 경험을 위해 얼마나 많은 테스트를 거치고, 얼마나 많이 코드를 갈아엎었을까.

사람들에게 더 좋은 경험을 주지 못한 것이 아쉬우면서도, 재밌게 플레이 해주고 칭찬도 해주시는 많은 분들을 만나면서 힘들지만 참 행복했던 것 같다.

나름 디자인 전공을 살려 프로그래밍 팀의 포트폴리오도 만들어봤다. 팀원들에게 원고를 받고, 이미지와 글을 편집해서 한권의 책으로 만들어 함께 전시했다. 모두의 고생과 업적을 작게나마 남기고 싶어서 바쁜 와중에 시간을 쪼개 만든거였는데, 교수님들이 꽤나 관심을 주셨고, 탐내주시는 분들도 많았다. 팀원들도 너무너무 좋아해줬다!! 좀 더 많이 뽑을걸..ㅎㅎ 뿌듯했다. 배워둔 지식은, 결국 어떤 방식으로든 쓸 일이 생긴다는 것을 느꼈다.

기억에 남는 디버깅

부산 내려가는 SRT에서 언리얼 가비지 컬렉션에 대한 공부를 했다. 왠지 모르겠는데 그냥 이부분을 하나도 몰라서 해놓고 싶었음. 어쨌든 이때를 시작으로 지스타 끝나고도 조금씩 공부를 하고 있었는데, 이것 덕분에 내가 디버깅에 꽤나 기여를 했다. 사실 그래서 남기는 자랑 글이다 ^_^

지스타 끝나고 최종 빌드를 다시 뽑아야 하는 일이 있었는데, 자꾸 의도치 못한 상황에서 계속 크래시가 났었다. 지스타에서도 계속 같은 일이 있었는데, 의심하던 부분이 아닌 다른쪽에서 크래시가 나는 바람에 다들 원인을 찾지 못하고 있었다.

그냥 최근에 공부하고 있기도 했고, 확인해보면 좋을 것 같아서 디버깅하고 있는 팀원에게 변수 선언부쪽을 한번 보여달라고 했는데, 크래시나는 그 변수가 생포인터로 선언되어 있었다. 가비지컬렉션 되고 있을거라는 확신이 들어서 혹시 모르니까 UPROPERTY 붙혀보라고 했고, 빌드를 뽑아서 테스트 해보자고 얘기했다. 순식간에 일어난 일이었는데, 진짜 그 문제가 맞았고....!!!!!! 해결이 되버린 것..!!!! 내가 구현한 부분도 아니었는데 마침 공부하고 있던 부분이었고, 급한 상황이었는데 어쩌다보니 해결되버려서 너무 웃기고 뿌듯했던 경험이었다 ㅋㅋㅋ

프로젝트 디버깅하면서 항상 신기했던 부분이, 보통 게임에서 크래시가 나면 코드도 안봤는데 갑자기 한명이 어... 헐 미안.. 을 외치면서 수정하러 간다 ㅋㅋㅋ 나도 마찬가지구.. 그럴때마다 너무 신기하구 웃기다.

함께여서 더 즐거웠던!

정말 감사하게도, 나는 예전부터 인복이 참 좋다. 이번 프로젝트를 진행하면서 너무 멋진 팀원들과 함께할 수 있어 행복했고, 많은 것을 배우고 공유할 수 있었다. 함께 고민해주는 팀원들이 있어 프로젝트를 진행하는게 두렵지 않았고, 매 순간이 즐거웠던 것 같다. 서로를 믿고 의지할 수 있는 팀원들을 만나 완성까지 힘낼 수 있었다. 이제는 다들 각자만의 길을 찾아가야겠지만, 모두 능력있고 좋은 사람들이라 자기만의 길을 잘 찾아서 갈거라고 확신한다! 또 같이 일할 수 있다면 너무너무 좋을 것 같다 :D 꼭 다시 만나자!

마무리하며

사실 생각보다 별 내용 없고 두서없는 후기였지만.. 그래도 이렇게 남겨놓음에 의의를 두고 이번 글을 마무리하려고 한다. 쓰고싶은게 생기면 슬쩍 또 추가해 둬야지 ㅎㅎ. 고생많았다 2024년의 나! 취업도 화이팅해보자!!!!

실제로 두 컴퓨터에 랜선을 연결하고 로컬로 테스트 플레이를 진행해보니 똑같이 버벅이는 현상이 있었고, 이게 최적화의 문제인지 내 코드의 문제인지를 판단해야 했다. 이틀정도 언리얼 인사이트를 공부하고, 최적화에 관련된 것들을 찾아보았다. 결과적으로 CPU에서 병목이 생기는 것을 알았고, 어디를 최적화해야할 지에 대한 감은 잡혔는데..

최적화 문제가 아닐 것이라는 확신이 들기 시작했다. 우선, 문제가 '클라이언트' 에서만 발생한다는 것. 애초에 프레임이 떨어진다면 서버나 클라이언트 둘 다 버벅이는게 맞잖아..? 내가 새로 만들어서 달아준 무브먼트 컴포넌트, 솔루나 시프트 동기화 로직이 의심이 가기 시작했고, 실제로 게임모드를 바꿔 언리얼 Third Person 캐릭터를 사용하도록 빌드하여 플레이해보니 모든 문제가 해결되었다ㅎㅎ

이제 어디가 문제인건지 찾고 고쳐야한다. (내가 해결할 수 있을까..)

이동 문제 해결하기

자성이동과 이동 모두 같은 문제일거라 생각했는데, 일단 이동과 점프에서 순간이동 하는 문제는 해결된 것 같다. 도대체 이게 왜 켜져있는지 모르겠는데, 캡슐 컴포넌트의 리플리케이트 옵션이 켜져있었다.. 꺼주니까 부드럽게 잘 이동한다.

솔루나 시프트 문제 해결

이전 게시글 보며 문제 찾아보기

자성이동 때문에 이미 충분히 삽질을 했었던 것 같은데 또 하게 될 줄이야.. PIE에서는 정상적으로 동작하지만 빌드만 뽑으면 클라이언트에서 이상하게 동작한다ㅠ (도대체 왜그러는거야.. 왜!!!!!)

일단, 예전에 작성했던 솔루나 시프트 삽질 기록을 다시 읽고 어떻게 해결해볼지 고민해보았다.

• 클라이언트측에서 로컬로 움직이고, RPC를 이용해 서버쪽의 프록시도 움직여 주었을 때 : 클라이언트쪽에서 지터링이 발생한다 => 서버의 수정 사항이 반영되어서 생긴 문제로 추측

• 무브먼트 컴포넌트 오버라이드를 통한 예측 기능 추가 : 지터링은 사라졌지만, 목적지에 도착하기 전에 착지해버림 => 서버가 이동하고 있는 도중, 클라이언트쪽에서 자성이동을 종료하면서 플래그가 동기화되면서 생기는 문제로 추측

• AddMovementInput을 이용한 로직 : 에디터 내에선 잘 동작했으나, 빌드 후 비정상적으로 동작함을 확인. 이때 게시글에선 빌드를 뽑아보지 않았기도 하고, 이것저것 여러 코드가 추가되었기 때문에 어떤게 문제인지 확인 불가능.

이 외에도 서버에서만 델타타임을 계산하도록 하고, 누적시킨 델타타임을 리플리케이트 하여 그 값을 보간해 이동하게끔 하는 로직도 사용해봤는데, 지금까지 해봤던 모든 방법보단 나았지만 지연이 있는 상황이 발생했을 시 가만히 멈추는 문제가 발생했다. 사용성이 너무 좋지 않아서 이것도 폐기.

해결을 위한 2주간의 대장정

윗부분을 작성하고, 지금 내용을 작성하기까지 약 2주정도의 시간이 흘렀다. 아무리 생각해도 무브먼트 컴포넌트에 대한 더 심도깊은 이해가 필요하다고 확신했고, 유튜브와 구글, GPT 등 사용할 수 있는 모든 수단을 이용해 무브먼트 컴포넌트에 대한 공부를 했다. 물론 이마저도 시간이 얼마 없었기에 제대로 하진 못했지만, 대충 어떻게 굴러가는구나~ 정도는 이해한 것 같다. 그리고 나서야 확신한건데, 제대로 동작할리가 없는 코드를 사용하고 있었다. 무브먼트 컴포넌트와 클라이언트측 예측에 대한 이해가 없었기에 일어났던 예고된 참사였음..

이전에 작성했던 코드에 대한 리뷰

void ATrapperPlayer::Interact(const FInputActionValue& Value)
{
    float Data = Value.Get<float>();

    if (!Movement->CanMagneticMoving() || !Data)
        return;

    if (HasAuthority()) MulticastRPCMagneticMoveStart();
    else if (IsLocallyControlled()) ServerRPCMagneticMoveStart();
}

사실상 여기만 보면 될 것 같은데, 자성 이동을 시작하는 쪽의 코드다. 자성이동 로직에서 교수님이 알려주신 AddMovementInput 함수를 사용한 것 까지는 좋았다. 근데.. 무브먼트 컴포넌트를 통해 알아서 처리되고 있기 때문에, 우리는 클라이언트에서 인풋을 입력할때 RPC 함수를 쓰지 않는다.

근데 나는 양쪽의 캐릭터에 모두 인풋을 넣고 있었던 것이다(..이게 말이 되는 코드일까?..) 에디터 내에서는 정상 작동하는 것처럼 보일 수밖에 없었을 것 같다. 패킷 손실이나 지연이 0에 수렴해서 동시에 움직이고, 그럼 서버가 보정을 할 필요가 없었을 테니까.

서버에게 타겟 위치는 전달했지만, 서버가 이동하던 도중 타겟이 바뀌어버린 케이스도 있었을 것이고, 심지어 자성이동 로직에 서버만 Max Speed로 바꾸는 코드도 있다. 점프를 두군데서 호출한 것도 문제였을 것 같고.. (아무튼 총체적 난국이다)

무브먼트 컴포넌트가 이동을 어떻게 처리해야하는지 이해하고 인풋 함수를 사용했다면, 문제 없이 잘 구현됐을 것 같은데 하는 아쉬움이 많이 남았다. 추후에 프로젝트가 끝난 뒤, 더 자세한 공부와 함께 여러 사례들을 테스트해보며 이전 문제에 대해 다시 리뷰해볼 생각이다.

해결 후의 의문점들

결국 강의에서 사용한 코드의 구조를 보고 공부하며 최대한 비슷하게 구현해보려고 노력했고, 결론적으로 클라이언트측 예측을 사용해 (아직 찝찝하지만) 해결에 성공하긴 했다.

다만 여기서 로직을 엄청 자세하게 설명하진 않을 예정이고, 위에서 말했듯 프로젝트가 끝난 후에 다른 프로젝트를 하나 파서 다시 구현해볼 것이다. 그때 제대로 정리해서 조금이나마 제대로 된 정보로 포스팅을 작성하려고 한다.

Trigger

void ATrapperPlayer::Interact(const FInputActionValue& Value)
{
    float Data = Value.Get<float>();

    if (Movement->CanMagneticMoving() && !Movement->GetMagneticMovingState())
    {
        if (Movement->IsFalling())
        {
            // Start Magnetic Move
            if (HasAuthority() && IsLocallyControlled())
            {
                MulticastWantsToMagneticMove();
            }
            if (!HasAuthority() && IsLocallyControlled())
            {
                WantsToMagneticMove();
                ServerWantsToMagneticMove();
            }
        }
        else
        {
            // Cast Animation
            if (HasAuthority() && IsLocallyControlled())
            {
                MulticastPlayCastAnimation();
            }
            if (!HasAuthority() && IsLocallyControlled())
            {
                PlayCastAnimation();
                ServerPlayCastAnimation();
            }
        }
    }

    return;
}

void ATrapperPlayer::WantsToMagneticMove()
{
    Movement->bWantsToMagneticMove = true;
    Movement->bWantsToMagneticCast = true;
}

void ATrapperPlayer::PlayCastAnimation()
{
    Movement->bWantsToMagneticCast = true;

    UAnimInstance* AnimInstance = GetMesh()->GetAnimInstance();
    if (!IsValid(AnimInstance) && !IsValid(MagneticMoveMontage))
    {
        return;
    }

    AnimInstance->Montage_Play(MagneticMoveMontage, 1.0);
    FOnMontageEnded EndDelegate;
    EndDelegate.BindUObject(this, &ATrapperPlayer::CastEnd);
    AnimInstance->Montage_SetEndDelegate(EndDelegate, MagneticMoveMontage);
}

void ATrapperPlayer::CastEnd(UAnimMontage* Montage, bool bInterrupted)
{
    Movement->bWantsToMagneticMove = true;
}

플레이어가 자성이동 트리거 키를 입력했을 때 사용하는 코드이다. 사실 처음에는 로컬 무브먼트 컴포넌트 내의 압축 플래그를 뒤집어주는 식으로만 작성했는데, 각자의 컴퓨터에서 복제되는 캐릭터(서버에서 보는 클라이언트, 클라이언트에서 보는 서버의 복제본)에서 애니메이션이 출력되지 않는 문제가 발생해서 RPC 함수를 통해 플래그를 뒤집어주었다. 이 과정에서 캐스트 애니메이션을 몽타주로 변경해주었다(원래는 애니메이션 상태였음).

내가 공부하고 이해한 바로는, 압축 플래그를 사용하면 몽타주 애니메이션 재생을 제외하고는 RPC 함수 없이도 플래그값과 무브먼트가 서버에도 반영되어 애니메이션이 잘 반영되어야 하는데, 이게 잘 안되어서 의문이었다. 그래서 어떻게든 플래그 상태를 반영하기 위해 RPC 릴라이어블 함수로 변경해주었고, 결론적으로는 잘 된다.. 사실 이게 클라이언트측 예측을 위한 코드로 변경해준 후에 제대로 동작하지 않았던 것들을 해결한 방법의 거의 전부이다. 변수를 리플리케이티드 처리하던가, RPC 함수를 통해 상태를 동기화 하거나.

점프, 낙하 등의 상태일 때는 자성이동 시전 없이 곧바로 bWantsToMagneticMove의 플래그를 뒤집어 자성이동을 실행시키고, 땅에 닿아있는 상태일 때는 캐스트 몽타주 애니메이션을 실행한 후에 자성이동을 실행시킨다.

Target

void UTrapperPlayerMovementComponent::EnterMagneticMove(EMovementMode PrevMode, ECustomMovementMode PrevCustomMode)
{
    PlayerRef->StartManeticMovingSetting();

    // Set Target RPC
    if (PlayerRef->HasAuthority() && PlayerRef->IsLocallyControlled())
    {
        ClientSetTargetPos(TargetPosition);
    }
    else if (!PlayerRef->HasAuthority() && PlayerRef->IsLocallyControlled())
    {
        ServerSetTargetPos(TargetPosition);
    }

    // Rotation in Target Direction
    FVector Direction = (TargetPosition - UpdatedComponent->GetComponentLocation()).GetSafeNormal();
    Direction.Z = 0.0f;
    FQuat Rot = Direction.ToOrientationQuat();
    FHitResult Hit;
    SafeMoveUpdatedComponent(FVector::ZeroVector, Rot, false, Hit);
}

void UTrapperPlayerMovementComponent::ServerSetTargetPos_Implementation(const FVector& TargetPos)
{
    TargetPosition = TargetPos;
    bCanChangeTarget = false;
}

void UTrapperPlayerMovementComponent::ClientSetTargetPos_Implementation(const FVector& TargetPos)
{
    TargetPosition = TargetPos;
}

타겟의 경우 자성 이동에서 사용하는 유일한 외부변수이다. 서버에서 클라이언트의 위치를 보정하고, 클라이언트의 보류된 움직임을 재생성할 때 이 변수가 변경되어 있으면 치명적일 수 있다. 하지만 특정 방향으로 자동 이동하기 위해 꼭 필요한 변수이므로, 서버에 타겟을 세팅해 줄 때 bCanChangeTarget 를 false로 바꿔준 후(리플리케이트 되는 변수). 서버에서 해당 이동을 종료할 때 true로 바꿔주어서 안전하게 처리하려고 노력했다.

그리고 이 경우에 두 컴퓨터로 테스트하는 경우, 클라이언트쪽에 서버가 보낸 리플리케이트 패킷이 손실되는건지 한번씩 클라이언트가 타겟을 설정할 수 없는 경우가 생겼다.

void UTrapperPlayerMovementComponent::ExitMagneticMove()
{
    PlayerRef->FinishMagneticMovingSetting();

    // Jump After Arrived & Gravity Set
    GravityScale *= ArrivedJumpGravity;
    bProxyGravityChange = ~bProxyGravityChange;
    Velocity = JumpImpulse * (FVector::UpVector * 0.1f);

    // Set Movement & Flag 
    bWantsToMagneticMove = false;
    bWantsToMagneticCast = false;

    // Change to enable Target Setting
    if (PlayerRef->HasAuthority() && !PlayerRef->IsLocallyControlled())
    {
        bCanChangeTarget = true;

        // 클라이언트에게 자성이동 종료 명시
        GetWorld()->GetTimerManager().SetTimer(MagneticMoveEndCheckHandle, this,
            &UTrapperPlayerMovementComponent::MagneticMoveEndCheck, 1.f, false, 0.1f);
    }
}

void UTrapperPlayerMovementComponent::ClientMagneticMoveEndCheck_Implementation()
{
    bCanChangeTarget = true;

    if (bWantsToMagneticMove || bWantsToMagneticCast)
    {
        bWantsToMagneticMove = false;
        bWantsToMagneticCast = false;
    }

    PlayerRef->FinishMagneticMovingSetting();
}

타이머를 이용해 0.1초뒤에 한번 더 체크하도록 클라이언트 RPC를 보내주었고, 지금까지 테스트해본 바로는 아직까지 클라이언트가 타겟을 설정할 수 없는 문제는 없는 것 같다.

Proxy

애니메이션도 잘 나오고, 이동도 잘 하는데도 불구하고 있었던 마지막 문제가 있었다. 클라이언트측에서 보는 서버의 프록시가 자성이동을 끝내고 내려올 때 미친듯이 지터링하고 그 후에 하는 점프에서도 지터링하는 현상이 발생했다.

서버의 중력은 변경됐는데 클라이언트쪽의 서버 프록시에서는 변경되지 않아 생긴 문제인 것 같았고, 서버의 중력이 변경될 때마다 리플리케이티드 되는 변수를 하나 만든 뒤 서버의 프록시쪽에서 변수가 복제될 때마다 함수를 호출해 중력 값을 변경해주는 식으로 처리했더니 문제가 해결됐다. 마찬가지로 혹시 몰라 타겟 위치도 복제하도록 변경했다.

서버의 프록시는 서버의 움직임 값만 받아서 보간하는식으로 처리하는 걸로 알고있는데 왜 이런 문제가 발생하는건지 이해를 할 수가 없다.. 프로젝트가 끝난 뒤에 정말 확실하게 알아봐야겠다.

결과

두 컴퓨터에서 테스트 한 영상이다. 지스타에서도 거의 같은 환경에서 플레이를 진행할 예정이기 때문에, 크게 문제가 생기진 않을 것으로 보인다.

<서버의 로컬 캐릭터가 자성 이동을 사용하는 모습>

<클라이언트에 있는 서버의 프록시가 자성 이동을 사용하는 모습>

<클라이언트의 로컬 캐릭터가 자성 이동을 사용하는 모습>

<서버에 있는 클라이언트가 자성 이동을 사용하는 모습>

드디어 자성 이동의 네트워크 이슈가 사라졌으니, 자성이동 이펙트, 카메라 등 완성도를 위한 작업들을 진행할 수 있게 됐다. 드디어 폴리싱 작업에 합류할 수 있다 ㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠ 이거 해결한다고 컨텐츠쪽을 거의 못하고 있었는데, 듬직한 팀원들이 많이 도와줬다 정말 너무 고맙다....ㅠㅠ 너무 고생한 나에게도 박수를.. 그래도 팀장님이 주신 데드라인에 맞춰 딱 해결되어 너무 다행이구.. 공부도 정말 많이 됐다. 시간적 여유만 있었으면 더 즐겁게 공부하고 해결할 수 있었을텐데 그게 아쉽지만, 뭐 회사를 가도 시간적 여유는 없을테니까..?! 암튼 솔루나 시프트 로직 진짜 진짜로 끝...!

NDC의 "〈카트라이더〉 0.001초 차이의 승부" 강의를 듣고 정리한 글입니다. https://youtu.be/r4ZaolMQOzE?si=xiOBldRnOnUktjRf

Dedicated Server 동기화 모델

일반적인 데디케이티드 동기화 모델?

클라이언트가 서버에게 먼저 이벤트를 요청(Server RPC), 서버가 이벤트를 받고 연산 후 클라이언트에게 되돌려준다(Multicast RPC).

미사일 아이템은 다음과 같은 4가지 상태를 갖는다.

공격자가 서버에게 미사일을 발사하도록 요청, 서버가 여러가지 조건을 확인하고 미사일을 발사한다.

무브먼트 컴포넌트에서는 사진처럼 딜레이가 발생할 수 있기 때문에, 이런 방식으로 사용하기가 쉽지 않다.

무브먼트는 인풋을 통해서 캐릭터를 움직일 수 있다. 전진 키를 눌렀을 때 카트가 앞으로 나아가는 식이다. 나아간 결과값을 클라이언트에게 전파해줄 수 있다.

내 입력을 서버에 알리고, 결과값만 받으면 서버에서 나온 결과값만 보게 되니까 모두 같은 화면을 보게 된다. 모두 같은 화면을 보는 것은 굉장한 이점이 될 수 있지만, 그 방법에는 한계점이 있다.

인풋을 서버에서 처리하게 되면 (한국에서 서버에 유저가 들어오는 속도를 보통 20ms로 가정하고 있다) 서버에 핑퐁됐을 시 40ms 정도의 딜레이가 발생할 수 있다. 해외에서 플레이하는 유저라면 10frame 이상의 차이도 발생할 수 있게 된다. 드리프트 등의 세밀한 조작은 1frame 차이로 결과가 크게 다르게 나온다.

Client Simulated model

따라서 모든 것을 서버에서 처리할 수는 없고, 일부는 클라이언트에서 처리를 해주어야 한다. Client Simulated model은, 클라이언트가 먼저 계산을 한 후에 계산된 결과를 초당 16번 서버에 보낸다. 서버는 그 결과값을 Validation 하여, 값을 검증한다.

P2P의 경우, 클라이언트가 클라이언트에게 시뮬레이트된 결과를 보내면 Validation이 없기 때문에 검증되지 않은 정보를 다른 클라이언트에게 보내게 될 수 있다.

Client Simulated model은 시뮬레이트된 결과를 서버에 보내고, 서버는 검증 후 다른 클라이언트에게 시뮬레이트된 결과를 보내주게 된다.

Extrapolation

서버가 처리하는 방식과 클라이언트가 처리하는 방식의 다른점은, 클라이언트가 처리를 하기 때문에 클라이언트가 패킷을 보내기 전에 딜레이가 발생할 수 있다. 대표적인 버그로, 클라이언트 1의 화면에는 1의 카트가 2의 카트보다 빠르다고 되어 있는데, 클라이언트 2의 화면에는 클라이언트 1보다 2의 카트가 빠르다고 보일 수가 있다. (실제로는 비슷한 위치에 있었음에도 불구하고)

하지만 0.001초로 승부가 갈리는 게임에서, 이렇게 동기화가 이루어지면 안된다.

https://youtu.be/r4ZaolMQOzE?si=a9aWEUZjfiOnATgC&t=479

상하로 클라이언트 1과 2를 나눈 샘플 프로젝트를 준비했다. 동시에 출발함에도, 서로 다른 위치에 존재하는 것처럼 보이는 것을 알 수 있다. 따라서, Extrapolation 이라는 기술을 사용해야 한다.

Extrapolation은 interpolation의 반대말로, 0과 1이 있을 때 2혹은 3과 같은 미래의 값을 유추하는 과정이다.

Extrapolation을 하기 위해서는 4가지 정보가 필요하며, 클라이언트는 서버에게 해당 정보를 보내주게 된다.

• Time Stamp : 클라이언트가 패킷을 보낸 시간
• Transform : 카트의 위치
• Linear Velocity : 카트의 선형 속도
• Angular Velocity : 카트의 각속도

동기화를 위해 가장 중요한 것은, 서로의 시간을 맞추는 것이다. 클라이언트 1이 2에게 패킷을 보내는데, 만약 2시에 보냈고 2시 2분에 받았을 때 2분의 차이가 날 것 같지만 둘의 시계가 같다는 보장이 없다. 따라서, 서버의 시간을 받아 서버의 시간으로 비교하는 것이 중요하다.

언리얼 엔진4에서는 GameStateBase 클래스를 통해 서버가 각 클라이언트들에게 ReplicateWorldTimeSeconds를 초당 10frame으로 리플리케이션 해주고, 각자의 시계와 서버의 시계를 비교해 델타를 구하고 서버의 시간을 유추하고 있다.

그렇게 유추된 서버의 시간을 클라이언트 1은 Time Stamp를 찍어서 서버에 보내고, 클라이언트 2는 그 패킷을 받아 클라이언트 1과 2가 시간 차이가 얼마나 나는지 계산한다.

Current는 이전 프레임에 계산된 위치이다. 패킷을 받으면 Rep_Position이라는 패킷의 위치가 나올 것인데, 두 클라이언트의 레이턴시가 200ms라고 한다면 200ms 전의 위치일 것이다. 200ms 후인 현재의 위치를 알고 싶은 것이기 때문에, 패킷으로 받은 Linear Velocity와 아까 계산된 ExtrapolationDeltaSeconds를 곱해 타겟 포지션을 구한다. 타겟 포지션을 완전히 믿을 수 없기 때문에, 포지션 interpolation을 통해 New Location을 유추해내고 있다. 조절 파람의 경우, 카트의 속도가 얼마나 빠르고 정확도가 어느정도인지에 따라 조절해줄 수 있다.

Rotation, Velocity Extrapolation도 마찬가지이다. Position과 동일한 방식으로 유추한다.

이렇게 유추한 결과를 적용하면, 0.2초 전에 보낸 패킷도 같이 달리는 것처럼 볼 수 있게 된다.

UE4 네트워크 콘솔 명령어

언리얼 엔진4의 콘솔 명령어이다. 이걸 사용해 스트레스 테스트 진행이 가능하다.

HardSnap

200ms 정도 레이턴시가 있다면, Extrapolation이 미래를 예측하는 것이기 때문에 오차가 발생할 수 있다.

플레이어가 0.2초 후에 왼쪽 키를 누를지, 오른쪽 키를 누를지 알 수가 없기 때문이다. 혹은 UDP 통신이기 때문에 패킷 손실이 발생하여 Extrapolation이 종종 실패하기도 한다. 실제 값과 예측된 값이 오차가 크거나, 오류가 누적되었을 때 보간 없이 HardSnap을 발생시킨다.(텔레포트) 기존의 연산 값들을 버리고, 새로 연산된 값들을 바로 적용시킨다.

파라미터 튜닝

멀리 있는 유저는 더 과거의 모습을 보여주어도 크게 문제가 되지 않기 때문에 예측을 조금 덜 하고, 가까운 유저는 하드 스냅을 더 빈번하게 발생시켜 정확한 위치를 표현해주어야 한다. 카트라이더 내에서 하드 스냅의 조건의 경우, 캐릭터의 속도에 따라 다르게 주어진다.

Character Movement Component In-Depth 강의 시리즈를 공부하면서 한글로 정리한 포스트입니다. 의역과 오역이 난무하니 주의해주세요! https://youtu.be/j45CUV9lWTA?si=nsePEHZSnSmg8hMK

Prone Implementation

UENUM(BlueprintType)
enum ECustomMovementMode
{
    CMOVE_None        UMETA(Hidden),
    CMOVE_Slide        UMETA(DisplayName = "Slide"),
    CMOVE_Prone        UMETA(DisplayName = "Prone"),
    CMOVE_MAX        UMETA(Hidden),
};

새로운 Custom Movement Mode를 추가해주고,

    /// Prone
    UPROPERTY(EditDefaultsOnly) float ProneEnterHoldDuration = .2f;
    UPROPERTY(EditDefaultsOnly) float ProneSlideEnterImpulse = 300.f;
    UPROPERTY(EditDefaultsOnly) float MaxProneSpeed = 300.f;
    UPROPERTY(EditDefaultsOnly) float BrakingDecelerationProning = 2500.f;

    // Prone
private:
    void EnterProne(EMovementMode PrevMode, ECustomMovementMode PrevCustomMode);
    void ExitProne();
    bool CanProne() const;
    void PhysProne(float deltaTime, int32 Iterations);

Prone과 관련된 변수와 함수를 선언해주자.

PhysProne()

전체 구현부는 저자의 깃허브에서 확인하실 수 있습니다! https://github.com/delgoodie/Zippy

PhysProne 의 경우, PhysWalking 의 코드와 굉장히 유사하게 구현했다. Walking과 Prone은 기본적으로 이동 속도의 변화일 뿐이고, 동작 자체가 매우 유사하다. 이번 튜토리얼에서는 서브 스테핑이 어떻게 작동하는지에 중점을 둘 예정이다.

우리는 서브 스테핑을 할 것이며, 서브 스테핑이 의미하는 것은 한 프레임에서 여러번 반복하는 것이다. 따라서 프레임이 주어지고, 프레임은 특정 델타 타임으로 구성되어 있다. 한 프레임 안에서 여러번 반복하며, 더 정확하고 움직임에 대해 더 높은 해상도의 시뮬레이션을 할 수 있다.

float remainingTime = deltaTime;

while문에 들어가기 전, remainingTime에 deltaTime을 넣어준다.

while ((remainingTime >= MIN_TICK_TIME) && 
      (Iterations < MaxSimulationIterations) &&
      CharacterOwner && (CharacterOwner->Controller || bRunPhysicsWithNoController || (CharacterOwner->GetLocalRole() == ROLE_SimulatedProxy)))

서브 스테핑에 들어가기 위한 조건문이다. 최소 틱 시간보다 남은 시간이 더 많은지 확인하고, 반복이 최대 시뮬레이션 반복보다 적을때(무한 루프에 들어가는 것을 방지하기 위함), 그리고 밑의 조건들을 만족할 때 서브 스테핑을 실행한다.

Iterations++;
bJustTeleported = false;
const float timeTick = GetSimulationTimeStep(remainingTime, Iterations);
remainingTime -= timeTick;

텔레포트를 사용하지 않기 때문에 bJustTeleported 를 false로 설정하고, GetSimulationTimeStep 함수를 이용해 틱 시간을 얻는다.

// Save current values
UPrimitiveComponent * const OldBase = GetMovementBase();
const FVector PreviousBaseLocation = (OldBase != NULL) ? OldBase->GetComponentLocation() : FVector::ZeroVector;
const FVector OldLocation = UpdatedComponent->GetComponentLocation();
const FFindFloorResult OldFloor = CurrentFloor;

모든 현재 값에 대해 저장된 값을 만들어준다. 이렇게 하는 이유는, 방금 계산한 이동을 되돌려야 할 수도 있기 때문이다.

// Ensure velocity is horizontal.
MaintainHorizontalGroundVelocity();
const FVector OldVelocity = Velocity;
Acceleration.Z = 0.f;

// Apply acceleration
CalcVelocity(timeTick, GroundFriction, false, GetMaxBrakingDeceleration());

MaintainHorizontalGroundVelocity 는 속도를 수평으로 유지하는 데 매우 유용한 함수이다. 우리는 지면에 있을 수도 있고, 경사면에 있을 수도, 평평하지 않은 평면에 있을 수도 있지만 속도는 평면에 수평으로 유지된다. 주로 지상 이동 모드에서 도움이 되는 함수이다. Acceleration 은 입력 벡터라는 것을 잊지 말자. 아무튼, Z값을 0으로 변경하여 위 또는 아래로 가속할 수 없게 한다.

마찰은 항상 캡슐에 적용되므로, 캡슐이 움직일 때 마찰이 가해지며 속도가 느려진다. 그렇기 때문에 무한히 가속할 수 없다. 우리는 캐릭터가 걸어다니다가 키를 놓았을 때 곧바로 멈추기를 원한다. 하지만, 이것을 위해 마찰을 높이게 되면 캐릭터의 이동속도가 정말 느려질 것이고, 슬라이드와 같은 이동 모드가 제대로 구현되지 않을 수 있다. 따라서 존재하는 것이 BrakingDeceleration 인데, 이것은 키를 놓았을때와 같이 어떤 움직임도 적용하지 않을 때 적용되는 값이다. 이 값을 이용해 빠르게 멈출 수 있다.

커스텀 무브먼트 모드의 경우 GetMaxBrakingDeceleration() 함수를 사용하면 0을 반환하므로, 함수를 오버라이드 하여 해당 이동 모드의 감속도를 반환해주어야 한다.

// Compute move parameters
const FVector MoveVelocity = Velocity;
const FVector Delta = timeTick * MoveVelocity; // dx = v * dt
const bool bZeroDelta = Delta.IsNearlyZero();
FStepDownResult StepDownResult;

if ( bZeroDelta )
{
    remainingTime = 0.f;
}
else
{
    MoveAlongFloor(MoveVelocity, timeTick, &StepDownResult);

    if ( IsFalling() )
    {
        // pawn decided to jump up
        const float DesiredDist = Delta.Size();
        if (DesiredDist > KINDA_SMALL_NUMBER)
        {
            const float ActualDist = (UpdatedComponent->GetComponentLocation() - OldLocation).Size2D();
            remainingTime += timeTick * (1.f - FMath::Min(1.f,ActualDist/DesiredDist));
        }
        StartNewPhysics(remainingTime,Iterations);
        return;
    }
    else if ( IsSwimming() ) //just entered water
    {
        StartSwimming(OldLocation, OldVelocity, timeTick, remainingTime, Iterations);
        return;
    }
}

만약 속도가 0이면 캡슐이 어디로도 움직이지 않으므로 서브스테핑이 필요하지 않게된다. 따라서 시뮬레이션을 서두르기 위해 남은 시간을 즉시 0으로 설정한다.

속도가 0이 아니라면, MoveAlongFloor 함수를 이용해 바닥을 따라 이동한다. 이 함수 또한 매우 유용한 헬퍼 함수인데, 이 함수는 컴포넌트를 안전하게 움직여준다. 이름에서 알 수 있듯 바닥을 따라 움직이며, 이것은 정말 도움이 된다. 다양한 각도의 경사면에서 움직일 수 있고, 각각의 속도와 시간 틱을 가질 수 있으며, StepDownResult 이라는 결과값이 반환되기 때문이다. 현재 있는 표면과 이동중인 표면을 아는 것은 정말 중요하다. 캡슐이 계단과 같은 표면에서 움직인다고 상상해보자. 그 표면은 항상 변하기 때문에, 우리는 그에 따라 처리해주어야 한다. StepDownResult를 통해 변화된 표면을 알 수 있다.

이 줄 자체가 실제로 움직임이 일어나는 곳이며, 나머지는 움직임을 정리하는 코드들이다. 첫번째는 움직이다가 떨어졌을 때의 경우이다. 움직이고 있다가 바닥이 없는 곳으로 떨어지면, 우리는 기본적으로 falling 모드에 들어가게 될 것이다. 여기서 볼 수 있는 멋진 것 중 하나는, 남은 시간과 반복을 사용하여 StartNewPhysics 를 실행한다는 것이다. 새로운 물리 시뮬레이션을 전체 델타 타임이 아니라 우리가 가지고 있는 남은 델타 타임을 사용하여 시뮬레이션 중간에 이동 모드를 전환할 수 있게 된다. StartSwimming 의 경우에도, 같은 경우를 설정한다. 이러한 코드들을 사용해, 걷다가 다른 이동 모드로 전환되는 경우를 처리할 수 있게 된다.

// Update floor.
// StepUp might have already done it for us.
if (StepDownResult.bComputedFloor)
{
    CurrentFloor = StepDownResult.FloorResult;
}
else
{
    FindFloor(UpdatedComponent->GetComponentLocation(), CurrentFloor, bZeroDelta, NULL);
}

StepDownResult.bComputedFloor 가 true라면, 캐릭터가 아래로 이동할 때 이미 바닥 정보를 계산했다는 뜻이므로 CurrentFloor 에 현재 바닥 정보를 대입해주고, false 라면 새로운 바닥 정보를 계산한다.

// check for ledges here
const bool bCheckLedges = !CanWalkOffLedges();
if ( bCheckLedges && !CurrentFloor.IsWalkableFloor() )
{
    // calculate possible alternate movement
    const FVector GravDir = FVector(0.f,0.f,-1.f);
    const FVector NewDelta = bTriedLedgeMove ? FVector::ZeroVector : GetLedgeMove(OldLocation, Delta, GravDir);
    if ( !NewDelta.IsZero() )
    {
        // first revert this move
        RevertMove(OldLocation, OldBase, PreviousBaseLocation, OldFloor, false);

        // avoid repeated ledge moves if the first one fails
        bTriedLedgeMove = true;

        // Try new movement direction
        Velocity = NewDelta/timeTick; // v = dx/dt
        remainingTime += timeTick;
        continue;
    }
    else
    {
        // see if it is OK to jump
        // @todo collision : only thing that can be problem is that oldbase has world collision on
        bool bMustJump = bZeroDelta || (OldBase == NULL || (!OldBase->IsQueryCollisionEnabled() && MovementBaseUtility::IsDynamicBase(OldBase)));
        if ( (bMustJump || !bCheckedFall) && CheckFall(OldFloor, CurrentFloor.HitResult, Delta, OldLocation, remainingTime, timeTick, Iterations, bMustJump) )
        {
            return;
        }
        bCheckedFall = true;

        // revert this move
        RevertMove(OldLocation, OldBase, PreviousBaseLocation, OldFloor, true);
        remainingTime = 0.f;
        break;
    }
}
else
{
    // Validate the floor check
    if (CurrentFloor.IsWalkableFloor())
    {
        AdjustFloorHeight();
        SetBase(CurrentFloor.HitResult.Component.Get(), CurrentFloor.HitResult.BoneName);
    }
    else if (CurrentFloor.HitResult.bStartPenetrating && remainingTime <= 0.f)
    {
        // The floor check failed because it started in penetration
        // We do not want to try to move downward because the downward sweep failed, rather we'd like to try to pop out of the floor.
        FHitResult Hit(CurrentFloor.HitResult);
        Hit.TraceEnd = Hit.TraceStart + FVector(0.f, 0.f, MAX_FLOOR_DIST);
        const FVector RequestedAdjustment = GetPenetrationAdjustment(Hit);
        ResolvePenetration(RequestedAdjustment, Hit, UpdatedComponent->GetComponentQuat());
        bForceNextFloorCheck = true;
    }

    // check if just entered water
    if ( IsSwimming() )
    {
        StartSwimming(OldLocation, Velocity, timeTick, remainingTime, Iterations);
        return;
    }

    // See if we need to start falling.
    if (!CurrentFloor.IsWalkableFloor() && !CurrentFloor.HitResult.bStartPenetrating)
    {
        const bool bMustJump = bJustTeleported || bZeroDelta || (OldBase == NULL || (!OldBase->IsQueryCollisionEnabled() && MovementBaseUtility::IsDynamicBase(OldBase)));
        if ((bMustJump || !bCheckedFall) && CheckFall(OldFloor, CurrentFloor.HitResult, Delta, OldLocation, remainingTime, timeTick, Iterations, bMustJump) )
        {
            return;
        }
        bCheckedFall = true;
    }
}

[*TODO] 32:41 - 42:02 Ledges와 관련된 구현 로직은 추후에 정리하겠습니다 :)

여기서 가장 중요한 부분은 서브 스테핑이다. 더 작은 델타 타임으로 반복을 수행하면 더 정확한 시뮬레이션을 얻을 수 있다는 것을 기억하자.

CanProne()

bool UNyongMovementComponent::CanProne() const
{
    return IsCustomMovementMode(CMOVE_Slide) || IsMovementMode(MOVE_Walking) && IsCrouching();
}

슬라이드하고 있거나, 웅크리고 있을 때 Prone 모드에 들어갈 수 있다.

EnterProne()

void UNyongMovementComponent::EnterProne(EMovementMode PrevMode, ECustomMovementMode PrevCustomMode)
{
    bWantsToCrouch = true;

    if (PrevMode == MOVE_Custom && PrevCustomMode == CMOVE_Slide)
    {
        Velocity += Velocity.GetSafeNormal2D() * ProneSlideEnterImpulse;
    }

    FindFloor(UpdatedComponent->GetComponentLocation(), CurrentFloor, true, NULL);
}

여기서 FindFloor 를 호출하는 이유는 Enter 함수 이후에 MoveAlongFloor 함수가 바로 호출되기 때문이다. MoveAlongFloor 의 가장 첫 줄을 보면, 현재 바닥이 걸을 수 있는지의 여부를 확인하고 그렇지 않다면 return 해버린다. 만약 갱신하지 않고 무브먼트 모드를 변경한다면, 첫번째 서브 스테핑 단계에서 이동이 실패하고 바닥이 갱신되므로, 첫번째 서브스테핑을 성공시키기 위해 함수를 호출한 것이다.

Link

bool UNyongMovementComponent::IsMovingOnGround() const
{
    return Super::IsMovingOnGround() || IsCustomMovementMode(CMOVE_Slide) || IsCustomMovementMode(CMOVE_Prone);
}

Prone도 지상에서 움직이는 이동 모드이므로, IsMovingOnGround() 함수에 추가해준다.

void UNyongMovementComponent::PhysCustom(float deltaTime, int32 Iterations)
{
    Super::PhysCustom(deltaTime, deltaTime);

    switch (CustomMovementMode)
    {
    case CMOVE_Slide:
        PhysSlide(deltaTime, Iterations);
        break;
    case CMOVE_Prone:
        PhysProne(deltaTime, Iterations);
        break;
    default:
        UE_LOG(LogTemp, Fatal, TEXT("Invalid Movement Mode"));
    }
}

PhysCustom 함수에 PhysProne 을 호출해주는 케이스문을 추가해준다.

virtual void OnMovementModeChanged(EMovementMode PreviousMovementMode, uint8 PreviousCustomMode) override;

void UNyongMovementComponent::OnMovementModeChanged(EMovementMode PreviousMovementMode, uint8 PreviousCustomMode)
{
    Super::OnMovementModeChanged(PreviousMovementMode, PreviousCustomMode);

    if (PreviousMovementMode == MOVE_Custom && PreviousCustomMode == CMOVE_Slide) ExitSlide();
    if (PreviousMovementMode == MOVE_Custom && PreviousCustomMode == CMOVE_Prone) ExitProne();

    if (IsCustomMovementMode(CMOVE_Slide)) EnterSlide(PreviousMovementMode, (ECustomMovementMode)PreviousCustomMode);
    if (IsCustomMovementMode(CMOVE_Prone)) EnterProne(PreviousMovementMode, (ECustomMovementMode)PreviousCustomMode);
}

OnMovementModeChanged 함수를 오버라이드하고 구현해준다. 이부분은 강의 이후 수정된 내용이므로, 뒷부분에서 설명한다.

virtual float GetMaxSpeed() const override;
virtual float GetMaxBrakingDeceleration() const override;

float UNyongMovementComponent::GetMaxSpeed() const
{
    if (IsMovementMode(MOVE_Walking) && Safe_bWantsToSprint && !IsCrouching()) return MaxSprintSpeed;

    if (MovementMode != MOVE_Custom) return Super::GetMaxSpeed();

    switch (CustomMovementMode)
    {
    case CMOVE_Slide:
        return MaxSlideSpeed;
    case CMOVE_Prone:
        return MaxProneSpeed;
    default:
        UE_LOG(LogTemp, Fatal, TEXT("Invalid Movement Mode"))
        return -1.f;
    }
}

float UNyongMovementComponent::GetMaxBrakingDeceleration() const
{
    if (MovementMode != MOVE_Custom) return Super::GetMaxBrakingDeceleration();

    switch (CustomMovementMode)
    {
    case CMOVE_Slide:
        return BrakingDecelerationSliding;
    case CMOVE_Prone:
        return BrakingDecelerationProning;
    default:
        UE_LOG(LogTemp, Fatal, TEXT("Invalid Movement Mode"))
            return -1.f;
    }
}

두 개의 함수를 오버라이드 해주자.

Trigger

이전 강의에서는 compressed flag를 사용했지만, prone의 경우는 sprint와 다르게 일회성 이벤트이기 때문에 prone을 하고 있는지 여부를 서버에 매 프레임마다 알릴 필요가 없기 때문에 사용할 필요가 없다. 이번 강의에서는 RPC를 이용해 트리거할 예정이다.

uint8 Saved_bWantsToProne : 1;
bool Safe_bWantsToProne;

커스텀 SavedMove 구조체에 Saved 변수를 선언해주고, 무브먼트 컴포넌트 안에 Safe 변수를 선언해주자.

void UNyongMovementComponent::FSavedMove_Nyong::SetMoveFor(ACharacter* C, float InDeltaTime, FVector const& NewAccel, FNetworkPredictionData_Client_Character& ClientData)
{
    FSavedMove_Character::SetMoveFor(C, InDeltaTime, NewAccel, ClientData);

    UNyongMovementComponent* CharacterMovement = Cast<UNyongMovementComponent>(C->GetCharacterMovement());
    Saved_bWantsToSprints = CharacterMovement->Safe_bWantsToSprint;
    Saved_bPrevWantsToCrouch = CharacterMovement->Safe_bPrevWantsToCrouch;
    Saved_bWantsToProne = CharacterMovement->Safe_bWantsToProne;
}

void UNyongMovementComponent::FSavedMove_Nyong::PrepMoveFor(ACharacter* C)
{
    Super::PrepMoveFor(C);
    UNyongMovementComponent* CharacterMovement = Cast<UNyongMovementComponent>(C->GetCharacterMovement());
    CharacterMovement->Safe_bWantsToSprint = Saved_bWantsToSprints;
    CharacterMovement->Safe_bPrevWantsToCrouch = Saved_bPrevWantsToCrouch;
    CharacterMovement->Safe_bWantsToProne = Saved_bWantsToProne;
}

SetMoveFor, PrepMoveFor 함수를 구현해주고,

void TryEnterProne() { Safe_bWantsToProne = true; }
UFUNCTION(Server, Reliable) void Server_EnterProne();

void UNyongMovementComponent::Server_EnterProne()
{
    Safe_bWantsToProne = true;
}

두 함수를 선언 및 구현해준다. 두 함수 모두 Safe_bWantsToProne 변수를 true 처리하는 것 뿐이라는걸 알 수 있다.

Server RPC의 경우, 호출될 때 항상 현재 프레임 movement RPC가 도착하기 전에 도착한다. 따라서 이런 RPC가 호출될 때, 서버의 프레임이 클라이언트의 프레임보다 항상 먼저 실행될 수 있다.

클라이언트가 프레임 100에서 움직임 관련 작업을 수행하고 RPC를 서버에 보내면, 서버는 클라이언트가 보낸 RPC를 처리한 후 프레임 100을 실행한다. 따라서 서버는 프레임을 실행하기 전에 클라이언트가 보낸 움직임 정보로 상태 변수를 미리 업데이트하는 것이 중요하다.

FTimerHandle TimerHandle_EnterProne;

void UNyongMovementComponent::CrouchPressed()
{
    bWantsToCrouch = ~bWantsToCrouch;
    GetWorld()->GetTimerManager().SetTimer(TimerHandle_EnterProne, this, &UNyongMovementComponent::TryEnterProne, ProneEnterHoldDuration);
}

void UNyongMovementComponent::CrouchReleased()
{
    GetWorld()->GetTimerManager().ClearTimer(TimerHandle_EnterProne);
}

특정 시간 동안 C키를 누른 후 prone을 시작하므로, 타이머 핸들이 필요하다. 타이머 핸들은 서버와 클라이언트에서 다른 속도로 실행되기 때문에 movement safe하지 않다. 하지만 클라이언트만이 Enter Prone을 호출할 것이기 때문에 괜찮다. 클라이언트만이 C키를 실제로 누르고 뗀걸 알 수 있기 때문이다.

void UNyongMovementComponent::UpdateCharacterStateBeforeMovement(float DeltaSeconds)
{
    // 생략

    if (Safe_bWantsToProne)
    {
        if (CanProne())
        {
            SetMovementMode(MOVE_Custom, CMOVE_Prone);
            if(!CharacterOwner->HasAuthority()) Server_EnterProne();
        }
        Safe_bWantsToProne = false;
    }

    if (IsCustomMovementMode(CMOVE_Prone) && !bWantsToCrouch)
    {
        SetMovementMode(MOVE_Walking);
    }

    Super::UpdateCharacterStateBeforeMovement(DeltaSeconds);
}

Prone으로 들어갈 때, 서버가 아닌 경우 Server RPC를 호출한다.

Amendments

Sprint

void UNyongMovementComponent::OnMovementUpdated(float DeltaSeconds, const FVector& OldLocation, const FVector& OldVelocity)
{
    Super::OnMovementUpdated(DeltaSeconds, OldLocation, OldVelocity);

    if (MovementMode == MOVE_Walking)
    {
        if (Safe_bWantsToSprint)
        {
            MaxWalkSpeed = Sprint_MaxWalkSpeed;
        }
        else
        {
            MaxWalkSpeed = Walk_MaxWalkSpeed;
        }
    }

    Safe_bPrevWantsToCrouch = bWantsToCrouch;
}

원래는 OnMovementUpdated 함수 내에서 Max Walk Speed를 변경하고 있었다. 이부분을 지우고,

float UNyongMovementComponent::GetMaxSpeed() const
{
    if (IsMovementMode(MOVE_Walking) && Safe_bWantsToSprint && !IsCrouching()) return MaxSprintSpeed;

    // 생략
}

이 코드를 작성해준다. 무브먼트 모드가 Walking이고, Sprint를 원하고, Crouch 상태가 아니라면 MaxSprintSpeed 를 반환해주자. 만약 Safe_bWantsToSprint 상태가 아니라면 Super 함수에서 MaxWalkSpeed를 반환할 것이다. 동일한 이동 모드이지만 다른 최대 속도를 갖을 뿐이기 때문에, 좀 더 깔끔하게 구현할 수 있다.

Slide

먼저 슬라이드 구현 로직이 일부 변경 및 추가되었다. 자세한 코드는 깃허브를 참고하자.

void UNyongMovementComponent::EnterSlide()
{
    UE_LOG(LogTemp, Warning, TEXT("Enter Slide"));

    bWantsToCrouch = true;
    Velocity += Velocity.GetSafeNormal2D() * Slide_EnterImpulse;
    SetMovementMode(MOVE_Custom, CMOVE_Slide);
}

원래 EnterSlide() 함수 내에서 무브먼트 모드가 변경됐지만, 이제는 OnMovementModeChanged() 함수에서 변경된다.

void UNyongMovementComponent::OnMovementModeChanged(EMovementMode PreviousMovementMode, uint8 PreviousCustomMode)
{
    Super::OnMovementModeChanged(PreviousMovementMode, PreviousCustomMode);

    if (PreviousMovementMode == MOVE_Custom && PreviousCustomMode == CMOVE_Slide) ExitSlide();
    if (PreviousMovementMode == MOVE_Custom && PreviousCustomMode == CMOVE_Prone) ExitProne();

    if (IsCustomMovementMode(CMOVE_Slide)) EnterSlide(PreviousMovementMode, (ECustomMovementMode)PreviousCustomMode);
    if (IsCustomMovementMode(CMOVE_Prone)) EnterProne(PreviousMovementMode, (ECustomMovementMode)PreviousCustomMode);
}

이 방법으로 구현하면, 이미 기본 함수인 Set Movement Mode 함수만 호출하면 된다. 따로 EnterSlide 함수를 호출할 필요가 없다. 이유는 두 가지가 있는데, 하나는 우선 깔끔하다. 블루프린트에서 Set Movement mode를 호출할 때 Enter 과 Exit 함수가 자동으로 호출되므로, 두 함수를 블루프린트에 노출하지 않아도 자동으로 불러질 것이다. 두번째로, 슬라이드를 종료하고 falling 모드나 Walking, Swimming 모드에 들어갈 수도 있으므로 Exit Slide 함수가 Movement Mode를 설정하는 것을 원하지 않기 때문이다.

enum CompressedFlags
{
    FLAG_Sprint        = 0x10,
    FLAG_Custom_1    = 0x20,
    FLAG_Custom_2    = 0x40,
    FLAG_Custom_3    = 0x80,
};

커스텀 Saved Move 구조체 안에 CompressedFlags 만들어 커스텀 플래그를 만들어주었다. 기존 커스텀 플래그와 값이 같다는 것에 주의하자.

void UNyongMovementComponent::UpdateFromCompressedFlags(uint8 Flags)
{
    Super::UpdateFromCompressedFlags(Flags);

    Safe_bWantsToSprint = (Flags & FSavedMove_Nyong::FLAG_Sprint) != 0;
}

이런식으로 사용할 수 있다. 가독성 말고는 크게 좋은 점은 없지만, 완성도를 높이기 위해 이렇게 했다.

Character Movement Component In-Depth 강의 시리즈를 공부하면서 한글로 정리한 포스트입니다. 의역과 오역이 난무하니 주의해주세요! https://youtu.be/-iaw-ifiUok?si=raM_aBeABXfqFQ98

Setup

UENUM(BluprintType)
enum ECustomMovementMode
{
    CMOVE_None        UMETA(Hidden),
    CMOVE_Slide        UMETA(DisplayName = "Slide"),
    CMOVE_MAX        UMETA(Hidden),
};

물리 기반 슬라이드를 구현하기 전, 약간의 준비를 해야한다. 가장 먼저, Custom Movement Mode Enum을 추가하자. 이것은 우리의 커스텀 무브먼트 모드를 추적하고 다양한 무브먼트 모드 사이를 전환하는 데 사용하게 될 것이다.

UPROPERTY(Transient) class ANyongCharacter* NyongCharacterOwner;

protected:
    virtual void InitializeComponent() override;

void UNyongMovementComponent::InitializeComponent()
{
    Super::InitializeComponent();

    NyongCharacterOwner = Cast<ANyongCharacter>(GetOwner());
}

다음은 캐릭터를 가져와야 한다. InitializeComponent() 함수를 오버라이드 하여 가져와주자.

public:
    UFUNCTION(BlueprintPure) bool IsCustomMovementMode(ECustomMovementMode InCustomMovementMode) const;

bool UNyongMovementComponent::IsCustomMovementMode(ECustomMovementMode InCustomMovementMode) const
{
    return MovementMode == MOVE_Custom && CustomMovementMode == InCustomMovementMode;
}

우리가 커스텀 무브먼트에 있는지 확인하기 위한 함수를 선언해준다. 먼저 우리가 Custom Movement 상태인지 확인하고, InCustomMovementMode 가 Custom Movement 인지 한번 더 체크한다.

Slide Implementation

private:
    void EnterSlide();
    void ExitSlide();
    void PhysSlide(float deltaTime, int32 Iterations);
    bool GetSlideSurface(FHitResult& Hit) const;

슬라이드 구현을 위해 이렇게 네개의 함수를 구현해야 한다. 나머지는 슬라이드 구현을 위한 보조 함수이지만, PhysSlide 함수의 경우 모든 movement에 필요한 시스템의 실제 부분이다. 모든 movement mode는 해당 movement의 작동 방식을 정의하는 물리 함수가 필요하다. 모든 Phys* 변수는 deltaTime과 Iterations을 매개변수로 갖는다.

GetSlideSurface

FCollisionQueryParams GetIgnoreCharacterParams();

FCollisionQueryParams ANyongCharacter::GetIgnoreCharacterParams()
{
    FCollisionQueryParams Params;

    TArray<AActor*> CharacterChildren;
    GetAllChildActors(CharacterChildren);
    Params.AddIgnoredActors(CharacterChildren);
    Params.AddIgnoredActor(this);

    return Params;
}

먼저 캐릭터에 캐릭터와 캐릭터의 모든 자식을 무시하는 충돌 쿼리 파라미터를 만들어주는 함수를 만들어준다. (Line Trace가 캐릭터에 닿지 않도록 하기 위해 필요함)

bool UNyongMovementComponent::GetSlideSurface(FHitResult& Hit) const
{
    FVector Start = UpdatedComponent->GetComponentLocation();
    FVector End = Start + CharacterOwner->GetCapsuleComponent()->GetScaledCapsuleHalfHeight() * 2.f * FVector::DownVector;
    FName ProfileName = TEXT("BlockAll");
    return GetWorld()->LineTraceSingleByProfile(Hit, Start, End, ProfileName, NyongCharacterOwner->GetIgnoreCharacterParams());
}

슬라이드 할 면을 찾아주는 GetSlideSurface 함수를 만들어준다. 아래로 Line Trace를 쏘고 결과를 반환한다.

PhysSlide

UPROPERTY(EditDefaultsOnly) float Slide_MinSpeed = 350.f;
UPROPERTY(EditDefaultsOnly) float Slide_EnterImpulse = 500.f;
UPROPERTY(EditDefaultsOnly) float Slide_GravityForce = 5000.f;
UPROPERTY(EditDefaultsOnly) float Slide_Friction = 1.3f;

네 가지 파라미터를 추가해주자. 먼저 Slide_MinSpeed 의 경우, 슬라이드의 최소 속도를 나타낸다. 해당 속도보다 낮다면 미끄러질 수 없으며, 슬라이드를 유지할 수도 없다. Slide_EnterImpulse 의 경우, 슬라이드에 들어가자마자 얻을 수 있는 속도의 부스트이다. Slide_GravityForce 는 플레이어가 지면에 서있게 하기 위해 적용되는 힘의 양이며, 또한 슬로프를 따라 미끄러질 때 얼마나 빠르게 속도를 변경하는 지에 대해 영향을 미친다. Slide_Friction 은 슬로프에서 미끄러질 때 얼마나 느리게, 얼마나 빠르게 속도를 떨어지게 할 지 결정한다.

여기서부턴 PhysSlide 의 구현 코드이다.

if(deltaTime < MIN_TICK_TIME)
{
    return;
}

deltaTime이 MIN_TICK_TIME보다 작지 않은지 확인한다. Default CMC에 적용되어 있는 코드인데, 언리얼은 최소 틱 시간보다 큰 델타 타임을 갖고있지 않으면 물리를 계산하는걸 원하지 않는다. 이 강의의 저자가 추측하건대, 보일러 플레이트인 것 같다고 한다. (boiler plate : 반복적으로 사용하는 코드나 텍스트 조각을 의미한다. 특정 프레임워크를 사용할 때 필수적으로 포함되어야 하는 설정 코드)

RestorePreAdditiveRootMotionVelocity();

루트모션은 캐릭터 애니메이션 데이터로부터 캐릭터의 위치 및 속도를 제어하는 방식을 의미한다. 슬라이드는 매우 구체적인 움직임이므로 루트 모션이 발생하면 안된다. RestorePreAdditiveRootMotionVelocity(); 함수는 루트 모션이 끝난 후, 애니메이션이 적용되기 전의 원래 속도와 방향으로 복원해주는 함수이다.

FHitResult SurfaceHit;
if (!GetSlideSurface(SurfaceHit) || Velocity.SizeSquared() < pow(Slide_MinSpeed, 2))
{
    ExitSlide();
    StartNewPhysics(deltaTime, Iterations);
    return;
}

먼저, 슬라이드 표면이 없다면 슬라이드에서 빠져나와야 하므로 GetSlideSurface 를 통해 슬라이드 표면이 없는지 확인한다. 또한, 슬라이드 속도가 최소 슬라이드 속도 미만인 경우 슬라이드에서 빠져나와야 하므로, 둘 중 하나라도 해당되면 ExitSlide() 을 호출해 슬라이드를 종료하고 StartNewPhysics() 를 호출한다. StartNewPhysics() 의 경우, 동일한 프레임에서 새로운 물리 함수를 실행하게 된다.

// Surface Gravity
Velocity += Slide_GravityForce * FVector::DownVector * deltaTime; // v += a * dt

가장 먼저 할 일은, surface gravity를 적용해 속도를 시간에 따라 점진적으로 업데이트 해주는 것이다. 직접적으로 Velocity에 힘을 더해주는건 아니다.

// Strafe
if (FMath::Abs(FVector::DotProduct(Acceleration.GetSafeNormal(), UpdatedComponent->GetRightVector())) > 0.5f)
{
    Acceleration = Acceleration.ProjectOnTo(UpdatedComponent->GetRightVector());
}
else
{
    Acceleration = FVector::ZeroVector;
}

슬라이드할 때 스트레이프를 허용한다. Acceleration 는 기본적으로 입력 벡터를 의미한다. 캐릭터의 입력이 Strafe(좌우 이동)인지 확인하고, 그 값이 0.5f 이상의 충분히 큰 값일 때만 작동하도록 한다.

// Calc Velocity
if (!HasAnimRootMotion() && !CurrentRootMotion.HasOverrideVelocity())
{
    CalcVelocity(deltaTime, Slide_Friction, false, GetMaxBrakingDeceleration());
}
ApplyRootMotionToVelocity(deltaTime);

보일러 플레이트 구문이다. 루트 모션이 없으면 실행시키는데, CalcVelocity 는 보일러 플레이트보단 도우미 함수에 가깝다. Default CMC 안에는 Phys* 함수에서 호출할 수 있는 일반적인 작업을 수행하는 헬퍼 함수가 많이 있다.

bFluid 변수가 true로 되어있는 것을 볼 수 있는데, 기술적으로 유체 안에 있지 않으면 마찰이 적용되지 않기 때문이다.

그런 다음, ApplyRootMotionToVelocity 함수를 사용해 Velocity에 루트 모션을 적용한다. 이 함수도 마찬가지로, 루트모션을 사용하지 않는다면 의미는 없는 구문이다. (완성도를 위한 코드)

// Perform Move
Iterations++;
bJustTeleported = false;

FVector OldLocation = UpdatedComponent->GetComponentLocation();
FQuat OldRotation = UpdatedComponent->GetComponentRotation().Quaternion();
FHitResult Hit(1.f);
FVector Adjusted = Velocity * deltaTime;
FVector VelPlaneDir = FVector::VectorPlaneProject(Velocity, SurfaceHit.Normal).GetSafeNormal();
FQuat NewRotation = FRotationMatrix::MakeFromXZ(VelPlaneDir, SurfaceHit.Normal).ToQuat();
SafeMoveUpdatedComponent(Adjusted, NewRotation, true, Hit);

bool SafeMoveUpdatedComponent(
    const FVector& Delta,         // 이동시키려는 변위 (델타 벡터)
    const FQuat& NewRotation,     // 이동시키려는 새로운 회전 (쿼터니언)
    bool bSweep,                  // 충돌 검사를 수행할지 여부
    FHitResult* OutHit = nullptr  // 충돌 결과를 저장할 수 있는 히트 결과 포인터
);

SafeMoveUpdatedComponent 함수는, 실제로 캐릭터를 움직이기 위해 호출하는 함수이다. 캡슐의 위치를 직접 변경하는 것이 아니라 이 구문을 호출해야 한다.

타겟 위치까지의 이동 경로 상에 무언가와 부딪힌다면, 이동을 멈추거나 다른 처리를 한다. OutHit의 경우, 우리가 스윕했을 때 무언가를 Hit할 경우의 결과가 들어갈 것이다.

FVector Adjusted = Velocity * deltaTime;

Velocity는 속도, deltaTime은 프레임 간격이므로 속도 x 시간 = 이동거리 공식에 따라 이동할 거리를 구할 수 있다.

FVector VelPlaneDir = FVector::VectorPlaneProject(Velocity, SurfaceHit.Normal).GetSafeNormal();

VectorPlaneProject 함수는 Velocity 벡터를 SurfaceHit.Normal 벡터에 수직인 평면으로 투영하는 함수이다. 이걸 통해 현재 표면을 따라 이동할 방향 벡터를 얻을 수 있다.

FQuat NewRotation = FRotationMatrix::MakeFromXZ(VelPlaneDir, SurfaceHit.Normal).ToQuat();

VelPlaneDir 을 X축으로 하고, SurfaceHit.Normal을 Z축으로 하는 회전 행렬을 생성한다. 이 회전 행렬을 ToQuat 함수를 사용하여 쿼터니언 형태로 변환한다.

if (Hit.Time < 1.f)
{
    HandleImpact(Hit, deltaTime, Adjusted);
    SlideAlongSurface(Adjusted, (1.f - Hit.Time), Hit.Normal, Hit, true);
}

위 로직에서 문제가 생겼는지 확인하고 처리하는 로직이다. HandleImpact 는 마찬가지로 보일러 플레이트로, 안전한 이동 업데이트의 영향을 처리하기 위해 호출한다.

SlideAlongSurface 는 정말 유용한 헬퍼 함수이다. 안전한 이동 업데이트를 할 때 무언가에 부딪힐 때까지 움직이는데, 표면에 따라 미끄러지고 있을 때 무엇인가에 부딪히자마자 트랙에서 멈추게 된다. SlideAlongSurface 함수는, 타격을 받고 나서도 벽같은 부딪힌 곳에 평행하게 계속해서 이동하게끔 한다. 벽과 바닥처럼 부딪힌 모든 곳에 해당된다. 표면을 따라 미끄러지는 방법일뿐이며, 어떤 물리 함수에서도 호출할 수 있다. 완전히 움직임에 안전하고 바로 작동한다.

FHitResult NewSurfaceHit;
if (!GetSlideSurface(NewSurfaceHit) || Velocity.SizeSquared() < pow(Slide_MinSpeed, 2))
{
    ExitSlide();
}

슬라이드 조건이 충족되는지를 다시 확인한다.

// Update Outgoing Velocity & Acceleration
if (!bJustTeleported && !HasAnimRootMotion() && !CurrentRootMotion.HasOverrideVelocity())
{
    Velocity = (UpdatedComponent->GetComponentLocation() - OldLocation / deltaTime);
}

캐릭터의 속도와 가속도를 업데이트 한다. 현재 위치와 이전 위치의 차이를 deltaTime 으로 나누어, 캐릭터가 지난 프레임 동안 얼마나 이동했는지를 기반으로 속도를 계산한다.

EnterSlide

void UNyongMovementComponent::EnterSlide()
{
    bWantsToCrouch = true;
    Velocity += Velocity.GetSafeNormal2D() * Slide_EnterImpulse;
    SetMovementMode(MOVE_Custom, CMOVE_Slide);
}

슬라이드를 시작할 때, Crouch 상태를 참으로 한다. 슬라이드를 할 때 여전히 웅크리고 있을 것이기 때문이다. 다음으로 Velocity.GetSafeNormal2D() 를 통해 속도의 수평 요소를 얻고, Slide_EnterImpulse 값을 곱해 속도를 설정해준다. 마지막으로, Movement Mode를 우리가 생성한 CMOVE_Slide로 설정해주면 된다.

ExitSlide

void UNyongMovementComponent::ExitSlide()
{
    bWantsToCrouch = false;

    FQuat NewRotation = FRotationMatrix::MakeFromXZ(UpdatedComponent->GetForwardVector().GetSafeNormal2D(), FVector::UpVector).ToQuat();
    FHitResult Hit;
    SafeMoveUpdatedComponent(FVector::ZeroVector, NewRotation, true, Hit);

    SetMovementMode(MOVE_Walking);
}

ExitSlide 도 비슷하다. bWantsToCrouch 를 false로 설정하고, 중간의 세 줄은 회전을 교정한다. 슬라이드가 끝나면, 캡슐을 다시 수직으로 만들어야 하기 때문이다. 마지막으로, 무브먼트 모드를 Walking으로 변경해준다. SafeMoveUpdatedComponent 함수는 safe move movement context에서만 호출해야 한다.

Linking Slide to System

이제 지금까지 구현한 슬라이드를 시스템에 연결하는 일이 남았다.

class FSavedMove_Nyong : public FSavedMove_Character
{
    typedef FSavedMove_Character Super;

    uint8 Saved_bWantsToSprints : 1;
    uint8 Saved_bPrevWantsToCrouch : 1;

    virtual bool CanCombineWith(const FSavedMovePtr& NewMove, ACharacter* InCharacter, float MaxDelta) const override;
    virtual void Clear() override;
    virtual uint8 GetCompressedFlags() const override;
    virtual void SetMoveFor(ACharacter* C, float InDeltaTime, FVector const& NewAccel, class FNetworkPredictionData_Client_Character& ClientData) override;
    virtual void PrepMoveFor(ACharacter* C) override;
};

먼저 SavedMove 클래스 안에 Saved_bPrevWantsToCrouch 를 선언해준다. 이동 로직의 상태에 중요하기 때문이다. 이전 값을 저장하는 이유는, Crouch를 원하는 경우 플래그가 이전에 false고 현재 true인지 또는 그 반대인지를 감지하기 위함이다.

왜 CrouchPressed 함수가 실행됐다는 것을 알기 위해 bWantsToCrouch 가 있음에도 새로운 변수를 만드냐면, 클라이언트가 c키를 누를 때 서버에서 호출되지 않기 때문이다. 다른 시뮬레이트 프록시에서도 호출되지 않는다. 모든 클라이언트와 서버에서 이 동작을 재현할 수 있도록 이전 값을 저장해야 하는 것이다.

safe saved 종류의 아키텍처에 익숙하다면, 저장된 모든 변수에 대해 안전한 변수가 필요하다는 것을 알게 될 것이다.

bool Safe_bPrevWantsToCrouch;

우리의 실제 CMC 로직에서는 Safe_bPrevWantsToCrouch 변수를 사용하고, 나중에 해당 이동을 생성할 수 있었던 상태를 다시 생성하기 위해 Saved_bPrevWantsToCrouch 에 이 상태를 저장할 것이다.

void UNyongMovementComponent::FSavedMove_Nyong::SetMoveFor(ACharacter* C, float InDeltaTime, FVector const& NewAccel, FNetworkPredictionData_Client_Character& ClientData)
{
    FSavedMove_Character::SetMoveFor(C, InDeltaTime, NewAccel, ClientData);

    UNyongMovementComponent* CharacterMovement = Cast<UNyongMovementComponent>(C->GetCharacterMovement());
    Saved_bWantsToSprints = CharacterMovement->Safe_bWantsToSprint;
    Saved_bPrevWantsToCrouch = CharacterMovement->Safe_bPrevWantsToCrouch;
}

void UNyongMovementComponent::FSavedMove_Nyong::PrepMoveFor(ACharacter* C)
{
    Super::PrepMoveFor(C);
    UNyongMovementComponent* CharacterMovement = Cast<UNyongMovementComponent>(C->GetCharacterMovement());
    CharacterMovement->Safe_bWantsToSprint = Saved_bWantsToSprints;
    CharacterMovement->Safe_bPrevWantsToCrouch = Saved_bPrevWantsToCrouch;
}

변수를 동기화되도록 하려면 우리는 이것을 SetMoverFor, PrepMoveFor 함수에 추가해야 한다. SetMoveFor 함수에서 값을 저장하고, PrepMoveFor 함수에서 이를 꺼내온다.

void UNyongMovementComponent::OnMovementUpdated(float DeltaSeconds, const FVector& OldLocation, const FVector& OldVelocity)
{
    Super::OnMovementUpdated(DeltaSeconds, OldLocation, OldVelocity);

    if (MovementMode == MOVE_Walking)
    {
        if (Safe_bWantsToSprint)
        {
            MaxWalkSpeed = Sprint_MaxWalkSpeed;
        }
        else
        {
            MaxWalkSpeed = Walk_MaxWalkSpeed;
        }
    }

    Safe_bPrevWantsToCrouch = bWantsToCrouch;
}

OnMovementUpdated 함수는 모든 움직임이 업데이트된 후이기 때문에 변수를 안전하게 설정할 수 있고, 다음 프레임에 적용될 수 있다. 그러므로, 여기서 Safe_bPrevWantsToCrouch 변수에 bWantsToCrouch를 설정해주면 된다.

virtual void UpdateCharacterStateBeforeMovement(float DeltaSeconds) override;

이제 이 함수를 오버라이드 해주자. 이 함수 내에서 edge detection을 수행하고, 슬라이드 이동 모드로 들어갈 수 있게 된다. 이 함수에서 수행하는 이유는, 여기가 Crouch 매커니즘이 처리되는 곳이므로, Crouch 매커니즘이 업데이트 되기 전에 업데이트 하려면 이 함수에서 업데이트 해야 한다.

void UNyongMovementComponent::UpdateCharacterStateBeforeMovement(float DeltaSeconds)
{
    if (MovementMode == MOVE_Walking && !bWantsToCrouch && Safe_bPrevWantsToCrouch)
    {
        FHitResult PotentialSlideSurface;
        if (Velocity.SizeSquared() > pow(Slide_MinSpeed, 2) && GetSlideSurface(PotentialSlideSurface))
        {
            EnterSlide();
        }
    }

    if (IsCustomMovementMode(CMOVE_Slide) && !bWantsToCrouch)
    {
        ExitSlide();
    }

    Super::UpdateCharacterStateBeforeMovement(DeltaSeconds);
}

현재 걷는 중이고, 웅크리기를 원하고 이전에 웅크리고 있던 상태라면(C를 두번 클릭했을 경우) 슬라이드로 들어간다. EnterSlide 안에서 bWantsToCrouch 를 true로 바꿔주므로, 여전히 bWantsToCrouch 의 상태가 된다. 매커니즘이 캡슐 높이를 다시 원래 높이로 올리기 전에 True로 설정한 것이 된다.

커스텀 무브먼트 모드가 슬라이드이고 bWantsToCrouch가 false라면 슬라이드를 종료한다.

void UCharacterMovementComponent::UpdateCharacterStateBeforeMovement(float DeltaSeconds)
{
    // Proxies get replicated crouch state.
    if (CharacterOwner->GetLocalRole() != ROLE_SimulatedProxy)
    {
        // Check for a change in crouch state. Players toggle crouch by changing bWantsToCrouch.
        const bool bIsCrouching = IsCrouching();
        if (bIsCrouching && (!bWantsToCrouch || !CanCrouchInCurrentState()))
        {
            UnCrouch(false);
        }
        else if (!bIsCrouching && bWantsToCrouch && CanCrouchInCurrentState())
        {
            Crouch(false);
        }
    }
}

이 모든 것은, Super 이전에 동작해야 한다. Super 함수의 내부 구현을 보면, 여기서 Crouch 매커니즘이 구현된 곳인 것을 알 수 있다.

virtual void PhysCustom(float deltaTime, int32 Iterations) override;

void UNyongMovementComponent::PhysCustom(float deltaTime, int32 Iterations)
{
    Super::PhysCustom(deltaTime, deltaTime);

    switch (CustomMovementMode)
    {
    case CMOVE_Slide:
        PhysSlide(deltaTime, Iterations);
        break;
    default:
        UE_LOG(LogTemp, Fatal, TEXT("Invalid Movement Mode"));
    }
}

이렇게 커스텀 무브먼트 모드에 대한 모든 물리를 다루는 PhysCustom 함수를 오버라이드 해야한다.

virtual bool IsMovingOnGround() const override;
virtual bool CanCrouchInCurrentState() const override;

bool UNyongMovementComponent::IsMovingOnGround() const
{
    return Super::IsMovingOnGround() || IsCustomMovementMode(CMOVE_Slide);
}

bool UNyongMovementComponent::CanCrouchInCurrentState() const
{
    return Super::CanCrouchInCurrentState() && IsMovingOnGround();
}

마지막으로, 두 함수를 오버라이드하여 만들면 된다. 슬라이딩은 지상에서 유효하지만,IsMovingOnGround() 의 Super 함수는 그걸 알 수 없기 때문에 슬라이딩 할때도 IsMovingOnGround() 함수가 true를 반환하도록 해준다.

웅크린 상태의 경우, 공중에서 웅크리기를 원치 않기 때문에 IsMovingOnGround() 도 함께 true일 때만 true를 반환하도록 해준다.

Debugging

코드를 똑같이 따라 친 것 같은데 동작이 잘 안된다.

1. 우선 바닥면 프로파일을 모두 "BlockAll" 로 바꿔줬다.

2. 로그를 찍어보니 Crouch 되는 순간 속도가 줄어들어서, 슬라이드로 진입이 어렵다는 것을 알게 됐다. (Crouch의 Max Speed = 300.f / 슬라이드 진입의 Min Speed = 350.f) Crouch의 Max Speed를 400.f로 올려주었다.

슬라이드에 진입하고 나니, 이렇게 바로 벽에 박혀버리는 현상이 발생했다.

if (!bJustTeleported && !HasAnimRootMotion() && !CurrentRootMotion.HasOverrideVelocity())
{
    Velocity = (UpdatedComponent->GetComponentLocation() - OldLocation) / deltaTime;
}

요 코드에서 괄호의 위치를 잘못 작성했었다..ㅎㅎ

이제 슬라이드가 동작하고 동기화도 잘 되는 것을 볼 수 있다!

Character Movement Component In-Depth 강의 시리즈를 공부하면서 한글로 정리한 포스트입니다. 의역과 오역이 난무하니 주의해주세요! https://youtu.be/vw4sPZ8xhFk?si=h_zshCaMpfvAI4pc

웅크리기 기능은 언리얼에서 제공하는 기능이다. CMC에 내장되어 있으므로 이 기능을 노출하고 프로젝트에서 사용하는 방법을 알려 줄 예정이다. 또한, 카메라 전환을 원할하게 만드는 방법도 보여준다.

Crouch Implementation

enum CompressedFlags
{
    FLAG_JumpPressed    = 0x01,    // Jump pressed
    FLAG_WantsToCrouch    = 0x02,    // Wants to crouch
    FLAG_Reserved_1        = 0x04,    // Reserved for future use
    FLAG_Reserved_2        = 0x08,    // Reserved for future use

    // Remaining bit masks are available for custom flags.
    FLAG_Custom_0        = 0x10,
    FLAG_Custom_1        = 0x20,
    FLAG_Custom_2        = 0x40,
    FLAG_Custom_3        = 0x80,
};

지난번에 살펴보았던 플래그들이다. 엔진에 예약되어 있는 것이 있고, 우리가 사용할 수 있는 것이 있다. FLAG_WantsToCrouch 를 보면 웅크리기가 이미 있다는 것을 알 수 있다. 만약 이 플래그를 변경하려고 한다면, 자동으로 서버에 복제되고 모든 동작이 동기화되며, CMC가 이 플래그의 실제 구현을 자동으로 다루게 된다. 엔진이 이것을 처리하므로, 우리가 직접 다룰 수는 없다. GetCompressedFlags() 의 Super 함수로 들어가보면 Crouch 플래그를 설정하고 있다는 것을 볼 수 있다.

따라서 bWantsToCrouch 변수를 변경하면, 플래그가 자동으로 설정, 읽혀지고 자동으로 구현된다.

Crouch를 처리할 수 있는 두 가지 방법이 있다. toggle 과 hold. toggle은 Crouch 버튼을 누를 때마다 상태를 변경하는 것을 의미한다. 웅크리고 있을때는 서 있는 상태가 되고, 서 있는 상태에서는 웅크린다는 뜻이다. hold 는 Crouch 버튼을 누르고 있으면 웅크린 상태가 되고, 손을 떼자마자 서 있는 상태로 변경되는 것을 말한다.

UFUNCTION(BlueprintCallable) void CrouchPressed();

void UNyongMovementComponent::CrouchPressed()
{
    bWantsToCrouch = !bWantsToCrouch;
}

변수를 토글해주고,

UNyongMovementComponent::UNyongMovementComponent()
{
    NavAgentProps.bCanCrouch = true;
}

생성자에서 Crouch를 사용한다고 명시해준다. 이것이 Crouch 매커니즘을 사용하는 데 필요한 전부이다.

마찬가지로 C키를 누르면 플래그를 변경해주는 함수를 호출하고, 디버깅을 위해 캡슐의 Hidden in Game 옵션을 꺼주었다.

캡슐의 높이가 줄어들고 속도가 느려지는 것을 확인할 수 있다. 여기서 Crouch를 시작하면 카메라가 즉시 내려간다는 것을 알 수 있는데, 캡슐이 Crouch를 실행하는 순간 절반 높이로 즉시 줄어들어서 발생하는 현상이다.

캡슐의 높이를 천천히 줄이는 방법이 있지만, 이는 많은 비동기화를 유발시킬 수 있다. 서버에서는 충돌이 일어났지만 클라이언트에서는 일어나지 않을 수도 있음. 캡슐의 높이가 둘 중 하나라면 이러한 오류가 발생할 여지가 적다. 이렇기 때문에 캡슐이 스냅되도록 두는 것이 더 나을 것이다.

이러한 로직은 그대로 두고, 일종의 전환이 있는 것처럼 보이도록 카메라와 애니메이션을 통해 부드러운 전환을 처리한다.

PlayerCameraManager Implementation

#pragma once

#include "CoreMinimal.h"
#include "Camera/PlayerCameraManager.h"
#include "NyongCameraManager.generated.h"

UCLASS()
class NYONG_API ANyongCameraManager : public APlayerCameraManager
{
    GENERATED_BODY()

public:
    ANyongCameraManager();
};

#include "NyongCameraManager.h"
#include "NyongCharacter.h"
#include "NyongMovementComponent.h"
#include "Components/CapsuleComponent.h"

ANyongCameraManager::ANyongCameraManager()
{
    PrimaryActorTick.bCanEverTick = true;
}

PlayerCameraManager 를 상속받은 새 캐릭터를 만들어주자.

UPROPERTY(EditDefaultsOnly) float CrouchBlendDurtation = 0.5f;
float CrouchBlendTime;

virtual void UpdateViewTarget(FTViewTarget& OutVT, float DeltaTime) override;

두 개의 변수를 선언해주고, UpdateViewTarget 함수를 오버라이드 한다.

void ANyongCameraManager::UpdateViewTarget(FTViewTarget& OutVT, float DeltaTime)
{
    Super::UpdateViewTarget(OutVT, DeltaTime);

    if (ANyongCharacter* NyongCharacter = Cast<ANyongCharacter>(GetOwningPlayerController()->GetPawn()))
    {
        UNyongMovementComponent* NMC = NyongCharacter->GetNyongCharacterMovement();
        FVector TargetCrouchOffset = FVector(0.f, 0.f, 
            NMC->GetCrouchedHalfHeight() - NyongCharacter->GetClass()->GetDefaultObject<ACharacter>()->GetCapsuleComponent()->GetScaledCapsuleHalfHeight());
        FVector Offset = FMath::Lerp(FVector::ZeroVector, TargetCrouchOffset, 
            FMath::Clamp(CrouchBlendTime / CrouchBlendDuration, 0.f, 1.f));

        if (NMC->IsCrouching())
        {
            CrouchBlendTime = FMath::Clamp(CrouchBlendTime + DeltaTime, 0.f, CrouchBlendDuration);
            Offset -= TargetCrouchOffset;
        }
        else
        {
            CrouchBlendTime = FMath::Clamp(CrouchBlendTime - DeltaTime, 0.f, CrouchBlendDuration);
        }

        if (NMC->IsMovingOnGround())
        {
            OutVT.POV.Location += Offset;
        }
    }

NyongCharacter->GetClass()->GetDefaultObject<ACharacter>()->GetCapsuleComponent()->GetScaledCapsuleHalfHeight());

여기서 캐릭터의 기본 객체를 사용하는 이유는 현재 인스턴스의 상태(웅크리기)와 무관하게 캐릭터가 처음 정의된 상태(기본적으로 서 있는 상태)의 캡슐 컴포넌트 높이를 얻기 위함이다. TargetCrouchOffset 을 계산할 때 웅크린 상태와 서 있는 상태의 기본 높이 차이를 알아야 하므로, 항상 기준이 되는 Default Object 값을 사용하여 변화를 비교한다.

자연스럽게 블렌딩 되는 카메라를 볼 수 있다.

Character Movement Component In-Depth 강의 시리즈를 공부하면서 한글로 정리한 포스트입니다. 의역과 오역이 난무하니 주의해주세요! https://youtu.be/17D4SzewYZ0?si=aBG-uYJkNECFkftK

Create Custom CMC

#pragma once

#include "CoreMinimal.h"
#include "GameFramework/CharacterMovementComponent.h"
#include "NyongCharacterMovementComponent.generated.h"

/**
 * 
 */
UCLASS()
class MOVEMENTSTUDY_API UNyongCharacterMovementComponent : public UCharacterMovementComponent
{
    GENERATED_BODY()

};

먼저 캐릭터 무브먼트 컴포넌트를 상속받은 커스텀 무브먼트를 만들어주자. 그 다음, bool Safe_bWantsToSprint 라는 변수를 선언한다. 클라이언트가 Shift 키를 누를 때마다 플래그가 설정될 것이다. 클라이언트 업데이트가 호출되면 모든 것이 복제되고 적절하게 준비된다. (rubber 현상같은 것이 일어나지 않을 것이라는 뜻) 이제 우리가 만들어야 하는 두 개의 도우미 클래스가 있다.

Saved Move Class

UCLASS()
class MOVEMENTSTUDY_API UNyongCharacterMovementComponent : public UCharacterMovementComponent
{
    GENERATED_BODY()

    class FSavedMove_Nyong : public FSavedMove_Character
    {
        typedef FSavedMove_Character Super;

        uint8 Saved_bWantsToSprints : 1;

        virtual bool CanCombineWith(const FSavedMovePtr& NewMove, ACharacter* InCharacter, float MaxDelta) const override;
        virtual void Clear() override;
        virtual uint8 GetCompressedFlags() const override;
        virtual void SetMoveFor(ACharacter* C, float InDeltaTime, FVector const& NewAccel, class FNetworkPredictionData_Client_Character& ClientData) override;
        virtual void PrepMoveFor(ACharacter* C) override;
    };

    bool Safe_bWantsToSprint;
};

첫번째 클래스는 Saved Move이다. 무브먼트 컴포넌트의 모든 상태 데이터 스냅샷을 저장한다. 이 스냅샷은 단일 프레임에 대한 이동을 생성하는데 필요하다. 그런 다음, 서버가 정확한 동작을 수행할 수 있도록 압축된 버전을 서버에 복제한다.

Safe_bWantsToSprint 변수는 우리가 스프린트를 원하는지의 여부를 나타낸다. 이 변수는 중요하기 때문에 saved move에 저장해야 한다. 기본 클래스를 재정의해야 하며, 여기에 추가해야 할 것은 저장 될 단일 변수 뿐이다.

Safe_bWantsToSprint 는 작동 변수이다. 우리가 설정하고 확인할 것이며, 이 변수의 값을 기반으로 논리를 적용할 것이다.

Saved_bWantsToSprints 는 Safe_bWantsToSprint 값으로 자동으로 업데이트 된다. new saved move를 생성하고, safe move를 실행해야 할 때마다 변수가 복사된다.

이제 오버라이드한 함수를 구현하면서, 어떻게 동작하는지 살펴보자.

CanCombineWith

bool UNyongCharacterMovementComponent::FSavedMove_Nyong::CanCombineWith(const FSavedMovePtr& NewMove, ACharacter* InCharacter, float MaxDelta) const
{
    FSavedMove_Nyong* NewNyongMove = static_cast<FSavedMove_Nyong*>(NewMove.Get());

    if (Saved_bWantsToSprints != NewNyongMove->Saved_bWantsToSprints)
    {
        return false;
    }

    return FSavedMove_Character::CanCombineWith(NewMove, InCharacter, MaxDelta);
}

기본적으로 두 개의 동작을 확인하는 함수이다. 현재의 움직임과 새로운 움직임을 확인하고, 결합할 수 있는지 확인한다. 대역폭을 절약하기 위해서이다.

이 방법의 기본 아이디어는 saved move의 모든 데이터가 거의 동일한지의 여부를 기반으로, 동일하다면 true를 반환한다. 두 번의 움직임을 보낼 필요 없이, 서버에게 두번 실행하라고 요청한다.

먼저 NewMove를 캐스팅하여 커스텀 클래스에 저장한 다음, 현재 Saved_bWantsToSprints 변수가 NewMove 안의 변수와 동일하지 않은지 확인한다. 만약 다르다면, 동작은 정확히 동일하지 않으며 결합할 수 없으므로 false를 리턴한다. 두 값이 동일하다면, Super 함수에서 결합할 수 있는지를 확인하도록 한다.

Clear

void UNyongCharacterMovementComponent::FSavedMove_Nyong::Clear()
{
    FSavedMove_Character::Clear();

    Saved_bWantsToSprints = 0;
}

Clear() 함수에서는 Super 함수를 먼저 실행해 기존 값들을 초기화해주고, 추가해준 변수도 초기화해주자.

GetCompressedFlags

uint8 UNyongCharacterMovementComponent::FSavedMove_Nyong::GetCompressedFlags() const
{
    uint8 Result = Super::GetCompressedFlags();

    if (Saved_bWantsToSprints)
    {
        Result |= FLAG_Custom_0;
    }

    return Result;
}

압축 플래그는 실제로 클라이언트가 이동 데이터를 복제하는 방법이다. 디폴트 SavedMove 안에는 수많은 변수가 있는데, 매번 이 모든 것을 서버에 복제하는 것은 분명히 비쌀 것이다. 우리는 매 프레임마다 이동을 수행하므로, 모두 보내는 대신 매우 최소한으로 압축된 버전을 보내게 된다.

압축된 플래그는 기본적으로 8개이므로 uint8을 반환하고, 압축된 플래그를 사용하여 원하는 모든 것을 할 수 있지만, 일반적으로 각 플래그는 키 누름과 관련되어 있다. 실제로 기본 값을 보면, 점프 키를 누르면 점프 플래그를 플립하는 식이다.

enum CompressedFlags
{
    FLAG_JumpPressed    = 0x01,    // Jump pressed
    FLAG_WantsToCrouch    = 0x02,    // Wants to crouch
    FLAG_Reserved_1        = 0x04,    // Reserved for future use
    FLAG_Reserved_2        = 0x08,    // Reserved for future use

    // Remaining bit masks are available for custom flags.
    FLAG_Custom_0        = 0x10,
    FLAG_Custom_1        = 0x20,
    FLAG_Custom_2        = 0x40,
    FLAG_Custom_3        = 0x80,
};

우리는 Custom 이라고 적힌 4가지의 플래그를 이용할 수 있다. 압축된 플래그는 클라이언트에서 서버로 전송된다.

SetMoveFor

void UNyongCharacterMovementComponent::FSavedMove_Nyong::SetMoveFor(ACharacter* C, float InDeltaTime, FVector const& NewAccel, FNetworkPredictionData_Client_Character& ClientData)
{
    FSavedMove_Character::SetMoveFor(C, InDeltaTime, NewAccel, ClientData);

    UNyongCharacterMovementComponent* CharacterMovement = Cast<UNyongCharacterMovementComponent>(C->GetCharacterMovement());
    Saved_bWantsToSprints = CharacterMovement->Safe_bWantsToSprint;
}

CMC의 현재 스냅샷에 저장된 이동을 설정한다. Super 함수를 실행하고, 현재 캐릭터의 무브먼트 컴포넌트를 가져온 뒤, Saved_bWantsToSprints 변수를 Safe_bWantsToSprint 값과 동일하게 설정해준다.

PrepMoveFor

void UNyongCharacterMovementComponent::FSavedMove_Nyong::PrepMoveFor(ACharacter* C)
{
    Super::PrepMoveFor(C);
    UNyongCharacterMovementComponent* CharacterMovement = Cast<UNyongCharacterMovementComponent>(C->GetCharacterMovement());
    CharacterMovement->Safe_bWantsToSprint = Saved_bWantsToSprints;
}

PrepMove는 방금 한 것의 정확히 반대 기능을 한다. Saved Move의 데이터를 가져와 CMC의 현재 상태에 적용한다.

Client Predicition Data

class FNyongNetworkPredictionData_Client : public FNetworkPredictionData_Client_Character
{
    typedef FNetworkPredictionData_Client_Character Super;
public:
    FNyongNetworkPredictionData_Client(const UCharacterMovementComponent& ClientMovement);
    virtual FSavedMovePtr AllocateNewMove() override;
};

이제 Default Character Move를 사용하지 않을 것임을 캐릭터 컴포넌트에 알려야 한다. 커스텀 Save move를 사용하고 이를 수행하는 방법은 network prediction data client 라는 다른 클래스를 통해 이루어지며 이전과 마찬가지로 커스텀 버전으로 만들어야 한다.

UNyongCharacterMovementComponent::FNyongNetworkPredictionData_Client::FNyongNetworkPredictionData_Client(const UCharacterMovementComponent& ClientMovement)
    : Super(ClientMovement)
{
}

FSavedMovePtr UNyongCharacterMovementComponent::FNyongNetworkPredictionData_Client::AllocateNewMove()
{
    return FSavedMovePtr(new FSavedMove_Nyong());
}

생성자에서는 Super 함수를 호출하기만 하면 되고, AllocateNewMove() 안에서는 새로 만든 Saved Move를 할당하면 된다.

이제 CMC에서 방금 만든 클래스를 사용하고 싶다는 것을 알리기 위해 실제 캐릭터 무브먼트 컴포넌트에 몇 가지 함수를 구현해야 한다.

virtual FNetworkPredictionData_Client* GetPredictionData_Client() const override;

FNetworkPredictionData_Client* UNyongCharacterMovementComponent::GetPredictionData_Client() const
{
    check(PawnOwner != nullptr)

    if (ClientPredictionData == nullptr)
    {
        UNyongCharacterMovementComponent* MutableThis = const_cast<UNyongCharacterMovementComponent*>(this);

        MutableThis->ClientPredictionData = new FNyongNetworkPredictionData_Client(*this);
        MutableThis->ClientPredictionData->MaxSmoothNetUpdateDist = 92.f;
        MutableThis->ClientPredictionData->NoSmoothNetUpdateDist = 140.f;
    }

    return ClientPredictionData;
}

먼저 ClientPredictionData 가 null인지 확인하고, 없다면 만들어서 반환하고 있다면 이미 가지고 있는 것을 반환한다. 이 값은 클라이언트 예측의 캐시된 값이다. GetPredictionData_Client() 함수는 기본적으로 Getter 이기 때문에 const 함수이다. 하지만 클라이언트 예측 데이터가 null 이라면 우리는 그것을 만들어야 하므로, const_cast를 해준다. 새로운 FNyongNetworkPredictionData_Client 를 만들어 주자. 밑의 두 줄은, 클라이언트 예측 데이터에 대한 두 개의 매개변수일 뿐이다.

protected:
    virtual void UpdateFromCompressedFlags(uint8 Flags) override;

void UNyongCharacterMovementComponent::UpdateFromCompressedFlags(uint8 Flags)
{
    Super::UpdateFromCompressedFlags(Flags);

    Safe_bWantsToSprint = (Flags & FSavedMove_Character::FLAG_Custom_0) != 0;
}

해당 플래그를 기반으로 CMC의 상태를 설정한다.

Recap

이 모든 설정들이 movement safe한 변수를 생성하고 활용하는 데 필요한 모든 종류의 인프라이므로, 앞으로 일어날 일에 대한 파이프라인을 살펴보자.

먼저, 틱에서 모든 이동 로직을 실행하는 Perform Move를 호출하고, Safe_bWantsToSprint 변수를 활용한다는 내용을 읽고, 안전한 saved move를 생성한 뒤, Set Move를 통해 변수를 읽어낸 후, 이를 Saved_bWantsToSprints 에 저장한다. 그 다음, CanCombineWith 함수를 사용하여 서버로 전송될 대기 중인 이동이 있는지 확인하고 필요하면 결합한 다음, GetCompressedFlags 를 호출하여 저장된 이동을 서버에 보낼 수 있는 작은 네트워크 가능 패킷으로 줄인 다음 서버에게 전송한다.

서버가 이를 수신하면, UpdateFromCompressedFlags 를 호출하여 값을 읽어와 Safe_bWantsToSprint 변수 값을 갱신한 후, 클라이언트가 수행한 이동을 수행한다.

Sprint Implementation

public:
    UFUNCTION(BlueprintCallable) void SprintPressed();
    UFUNCTION(BlueprintCallable) void SprintReleased();

스프린팅을 구현하기 위해 정의한 이 두가지 함수는, safe move flag를 토글하기만 한다. 무브먼트 컴포넌트의 non-safe 한 컨텍스트에서 호출되고 있는데, 이게 안전한 이동의 속성을 손상시키지 않을까? 여기서 핵심은 클라이언트에서만 이러한 함수를 호출할 수 있다는 것이다. 클라이언트의 non-safe movement 함수에서 safe 변수를 바꿀 수 있다는 것이 혼란스러울 수 있다. non-safe movement 함수에서 safe 변수를 절대 활용할 수 없으며, 서버에서 safe 변수를 변경하는 non-safe movement 함수를 호출할 수 없다.

이제 완전히 움직임에 안전하며, 클라이언트는 스프린트 pressed 또는 release를 호출하여 이 변수의 값을 토글할 수 있다.

virtual void OnMovementUpdated(float DeltaSeconds, const FVector& OldLocation, const FVector& OldVelocity) override;

OnMovementUpdated 함수는 모든 이동 수행이 끝날 때 자동으로 호출되는 편리한 함수이며, 어떤 이동 모드에 관계 없이 실행되는 일부 이동 로직을 작성할 수 있게 한다.

UPROPERTY(EditDefaultsOnly) float Sprint_MaxWalkSpeed;
UPROPERTY(EditDefaultsOnly) float Walk_MaxWalkSpeed;

블루프린트에서 편집할 수 있는 두가지 변수를 선언해주자. 스프린트를 사용했을 때 캐릭터가 얼마나 빨리 움직이는지를 결정한다.

void UNyongCharacterMovementComponent::OnMovementUpdated(float DeltaSeconds, const FVector& OldLocation, const FVector& OldVelocity)
{
    Super::OnMovementUpdated(DeltaSeconds, OldLocation, OldVelocity);

    if (MovementMode == MOVE_Walking)
    {
        if (Safe_bWantsToSprint)
        {
            MaxWalkSpeed = Sprint_MaxWalkSpeed;
        }
        else
        {
            MaxWalkSpeed = Walk_MaxWalkSpeed;
        }
    }
}

이렇게 OnMovementUpdated 함수를 구현해주면, 우리가 MOVE_Walking 에 있는지 확인하고, Safe_bWantsToSprint 변수의 값에 따라 최대값을 설정하는 역할을 한다.

Setup Character for new CMC

protected:
    UPROPERTY(EditDefaultsOnly, BlueprintReadOnly, Category = Movement)
    class UNyongCharacterMovementComponent* NyongMovement;

public:
    AMovementStudyCharacter(const FObjectInitializer& ObejctInitializer);

이제 캐릭터 클래스에 커스텀 무브먼트 변수를 추가해주고, 기본 생성자를 변경해주자. FObjectInitializer 를 사용하면, 커스텀 CMC를 재정의 할 수 있다.

AMovementStudyCharacter::AMovementStudyCharacter(const FObjectInitializer& ObejctInitializer)
    : Super(ObejctInitializer.SetDefaultSubobjectClass<UNyongCharacterMovementComponent>(ACharacter::CharacterMovementComponentName))
{
    NyongMovement = Cast<UNyongCharacterMovementComponent>(GetCharacterMovement());

// 생략

그리고 이렇게 구현해주면 된다.

Testing

캐릭터 블루프린트로 이동해 이렇게 구현해주고, 스프린트 스피드를 설정해주고 테스트해보자.

PktLag 를 사용하여 극단적인 지연을 테스트해볼 수 있다.

Character Movement Component In-Depth 강의 시리즈를 공부하면서 한글로 정리한 포스트입니다. 의역과 오역이 난무하니 주의해주세요! https://youtu.be/dOkuIvKCvpg?si=yRzIaylvUKSvZIze

Three Networked Cases

이해해야 하는 세 가지 네트워크 사례가 있다. 이는 게임의 모든 복제된 개체에 해당된다. 이 원리는 우리가 CMC를 필요로 하는 이유이기 때문에, 반드시 이해해야 한다.

게임에는 동일한 캐릭터의 사본 3개가 존재한다. (소유 클라이언트 / 서버 / 해당 캐릭터를 보기만 하고 제어하지 않는 모든 원격 클라이언트에 대해 하나씩)

소유 클라이언트가 실제로 입력을 받는 클라이언트가 되고, 이동을 수행한 다음, 확인을 위해 서버에 데이터를 보내고 가져오며, 서버에 의해 수정된다.

서버는 클라이언트 데이터를 수신하고, 이 데이터로 이동을 수행하며, 이를 다른 클라이언트로 보내고 필요한 경우 소유 클라이언트를 수정한다.

원격 클라이언트는 서버로부터 상태를 수신하고 해당 위치와 회전을 보간하기만 하면 된다. 하지만, 우리는 원격 클라이언트에 대해서는 신경 쓸 필요가 없다. CMC에 의해 완전히 처리되기 때문이다.

우리는 소유 클라이언트와 서버와의 관계에 대해서만 신경쓰면 되기 때문에, 이 강의에서 언급하는 클라이언트는 그 캐릭터의 소유 클라이언트만을 의미한다.

Client-Side Prediction

클라이언트측 예측은 본질적으로 캐릭터 이동 구성 요소의 주요 기능이며, 커스텀 CMC를 사용하는 이유이다.

이것은 네트워크 그래프이다. 수직의 선은 시간을 의미하고, 틱 단위로 표현되고 있다. 각 틱은 10밀리초라고 생각하면 된다. (t5 = 50ms / t10 = 100ms) 왼쪽에는 클라이언트가 있고, 오른쪽에는 서버가 있다. 이 그래프는 캐릭터 위치에 대한 클라이언트와 서버의 뷰이다.

t0에서 클라이언트와 서버 모두 0에서 시작하고, 클라이언트는 자신이 원하는 동작을 가지고 있다. 앞으로 한 칸 이동하기 위해 키보드에서 w를 눌러 이 데이터를 서버로 전송하는데, 이 선이 대각선이라는 것을 볼 수 있다. 레이턴시나 핑이 0이 아니기 때문에, t5에서 서버가 이 이동 요청을 받고 이를 적용한다. 클라이언트 캐릭터는 자신의 위치에 대한 권한이 없기 때문에 아직 위치가 업데이트 되지 않은 것을 확인하자. 그 후, 서버는 클라이언트에게 클라이언트가 있어야 할 새로운 위치를 보내고, 클라이언트는 t10에서 받아 이 위치로 이동한다. 따라서, 클라이언트가 키보드에서 w를 누르고, 실제로 캐릭터의 움직임을 볼 수 있는 것은 100ms 지연이 발생한 이후가 된다. 입력에 레이턴시가 있으면 게임이 정말 느리다고 느껴지며, 요즘 게임에서는 이런 현상을 거의 볼 수 없다.

어떻게 해야 올바른 방식으로 이동을 수행할 수 있을까? 클라이언트측 예측이 그걸 가능하게 한다. 클라이언트는 서버에 이동 요청을 하고, 즉시 예측한 이동을 적용시킨다. 하지만, 이것은 단지 예측된 값이기 때문에 권한이 없는 이동이다. 여전히 서버는 0의 위치에 있다.

아무튼, 클라이언트가 이동하고, 이 이동은 서버가 실제로 이동을 적용할 때 일어나는 일과 일치하므로 서버가 이동을 적용하고 정확한 위치를 다시 보냈을 때, 클라이언트와 서버의 위치는 동일하다. 이는 서버가 요청에 따라 수행할 움직임을 성공적으로 클라이언트가 예측했음을 의미한다.

// 번역 확인 필요..

이 그림에서 볼 수 있는 것은 2D 캐릭터를 제어할때의 모습과 같다. 클라이언트가 실제로 서버보다 앞서 있다는 것이다. 클라이언트가 매 틱마다 이동을 보내고 있었을 수도 있다는 것도 볼 수 있다. 이러한 움직임은 간헐적으로 발생하는 상태로, 서버에서 아직 확인되지 않은 보류중인 움직임이므로 서버가 이러한 움직임 중 하나를 받고 위치와 모든 작업이 완료되면 클라이언트의 움직임을 승인하고 이를 수행한다.

캐릭터가 움직일 때마다 움직임을 만드는데, 이것을 Saved Move라고 한다. 기본적으로, 클라이언트는 정확히 같은 움직임을 재현한 모든 상태 데이터를 저장하고 서버가 정확히 동일한 움직임을 다시 생성할 수 있도록 압축된 버전을 서버에 전송한다. Saved Move는 이동을 복제하는데 필요한 모든 데이터가 포함되어 있으며, 여기서 타임스탬프는 움직임의 ID를 식별한다.

클라이언트가 서버가 수행할 이동을 성공적으로 예측하려면, 서버와 클라이언트가 동일하게 호출하는 함수는 정확히 같은 데이터로 호출되어야 하고, 명확해야 한다. 따라서 그 안에 난수나 외부 상태 데이터를 가질 수 없다. 만약 이동 함수가 랜덤 벡터를 호출하고, 클라이언트가 랜덤 벡터로 이동을 수행하지만 서버는 다른 랜덤 벡터를 얻게 되면 서버와 클라이언트가 같은 위치에 있을 수 없다는 것을 알 수 있다. 이로 인해 서버가 클라이언트를 수정해야 하고, 예측이 실패하게 된다.

Client Pipeline

Tick Component

캐릭터가 매 프레임마다 움직여야 하므로, 가장 최근의 입력 벡터를 소비한다. 기본적으로, 모든 키 입력은 클라이언트가 해당 프레임에서 누른 모든 키를 의미한다. 그리고, 캐릭터의 이동 함수 해당 인풋 벡터를 보낸다.

Controlled Character Move

해당 벡터를 가져와 가속도에 적용한다.

Perform Move

Controlled Character Move 는 Perform Move 를 호출하고, Perform Move 는 모든 일이 일어나는 곳이다. 캐릭터의 루트 구성 요소에 이동을 적용하는 함수이다. Force와 Impulse를 적용하고, 루트 모션을 업데이트 한다.

Start New Physics

다양한 이동 모드에 따라 캐릭터를 움직인다.

Replicate Move To Server

Controlled Character Move - Perform Move - Start New Physics 에 걸쳐 한 체인이 끝이 나면, 소유 클라이언트는 이 작업을 서버에 전송한다. 여기서 중요한점은 Saved Move 를 만드는 것이다. 이동의 입력과 출력의 결과를 바탕으로 압축된 버전의 데이터 구조(FCharacterNetworkMoveData)를 만들어 서버 RPC 로 보내게 된다.

Server Move

서버는 데이터를 전송받고, 클라이언트가 수행한 이동을 재현하게 된다.

우리는 Replicate Move To Server / Server Move 에 관련해서는 신경을 쓰지 않아도 된다. Saved Move만 올바르게 설정해주면, 내부적으로 거의 완벽하게 처리될 것이다.

따라서, 우리는 Perform Move, Start New Physics 함수와 같은 움직임 로직만 집중하면 된다. 하지만, 우리가 이것들을 작성하는 방법과 이 모든 것을 서버에서 동기화하기 위해서는 무슨 일들이 일어나는지 이해해야만 한다.

Server Pipeline

Server Move

클라이언트로부터 RPC로 호출된 Server Move는 들어오는 이동에 대해 준비하는 상태이다. 클라이언트가 작업했던 것과 동일한 입력 매개변수로 작동하도록 서버를 준비시켜야 한다. 동일한 입력에 대해 작업한 것과 동일한 결과를 얻는 것이 매우 중요하다.

Move Autonomous

더 많은 준비를 수행하고, 상태를 완전히 준비한 후에는 Perform Move 를 호출한다.

Perform Move

클라이언트가 한 것처럼 이동 수행을 호출하기만 하면, 동일한 결과를 얻을 수 있다.

Server Move Handle Client Error

Server Move에서 클라이언트가 보내는 데이터에는, 클라이언트가 Perform move를 호출한 후에 얻은 결과도 들어있다. 여기서는 각각 Perform move를 수행한 후, 서버가 얻은 결과와 클라이언트가 얻은 결과가 동일한지 확인하고, 그렇지 않다면 Client Adjust Position 을 수행하게 된다.

Client Adjust Position

클라이언트의 예측이 틀렸다고 말한 뒤, 실제로 권한이 있는 상태를 보낼 것이다. 모든 것은 서버가 권한을 가지고 있고, 클라이언트는 서버가 보낸 조정 위치를 적용해야 한다.

Client Adjust Position (on Client)

캐릭터를 서버의 상태로 재설정하고, 보류 중인 움직임들을 다시 시뮬레이션 한다. (추후에 다시 언급)

Movement Modes

Start New Physics 가 호출되었을 때, switch문을 사용하여 무브먼트 모드에 따라 함수를 호출하게 된다. 언리얼은 기본적으로 몇 가지 무브먼트 모드를 제공하며, advanced 한 움직임을 원하지 않을때 사용하거나, 커스텀 무브먼트 모드를 사용할 때의 좋은 예시로써 사용된다. 각 모드에는 입력 매개변수를 사용하여 이동을 계산하는 각각의 물리 함수가 존재한다. 또한 우리는 스위치 문에서 들어갈 수 있는 커스텀 무브먼트와 물리 함수를 직접 구현할 수 있다.

Phys Function

1. DeltaTime : 모든 이동은 델타 타임에 걸쳐 동작하며, 델타 타임을 기반으로 일정한 거리만큼 플레이어를 증가시킨다.
2. Acceleration : 가속도는 본질적으로 입력 벡터이다.
3. State Data / Compressed Flags : 대시나 그와 비슷한 것을 트리거 한 다음, 압축된 플래그로 설정한다.

이것들은 모두 물리 함수가 작동하기 위해 필요하다. 그리고 이것들은 위치, 회전, 속도를 변경하고 CMC의 상태 데이터를 변경시킨다. 또한 언리얼 엔진이 제공하는 도우미 함수도 있다.

델타타임은 tick component에서 나온다. 하지만 이것은 프레임 종속적이며, 동일한 게임을 실행하는 컴퓨터에 따라 다르다. 우리는 이 델타 타임을 더 작은 시뮬레이션 시간 단계로 나눠야 하고, 이것을 서브 스테핑이라고 부른다.

중요한 것은, 시뮬레이션 중간에 이동 모드를 변경할 수 있다는 것이다. 캐릭터가 걷고있다고 해보자. 이 시뮬레이션 중간에 물 볼륨으로 건너가고, 수영을 시작해야 한다. 우리는 이 물리함수 중간에 새로운 물리를 시작(StartNewPhysics)할 수 있다. 이 함수에 원래 델타 시간 절반에 해당하는 남은 시간을 주면, 이터레이션이 증가한다. 이렇게 하면 정밀한 서브 스테핑을 알 수 있고, 훨씬 더 정확한 시뮬레이션을 얻을 수 있다. 그런 다음 남은 델타시간 동안 우리는 수영 물리 모드를 시뮬레이션 하고, 이터레이션을 증가시킬 것이다.

ClientAdjustPosition()

클라이언트측 예측에 대해 다시 이야기 해야 한다. 이것이 작동하려면 두가지 일이 일어나야 한다. 클라이언트는 움직임을 예측해야 하지만, 클라이언트가 실수를 하면 움직임을 수정해야 한다. 서버는 클라이언트가 서버와 일치하는 움직임으로 수정하기 위해 필요한 데이터를 모두 포함한 큰 종류의 봉투를 보내게 된다. 타임 스탬프는 어떤 움직임이 벗어났는지를 식별한다. 여기서는 12.5초가 잘못되었다고 하고 있으므로, 이 위치와 속도를 사용해야 하며, 다른 사항도 알고있어야 한다. 이것이 정확한 움직임이므로, 클라이언트에는 승인되지 않은 보류중인 Saved Move가 있다. 마지막 Saved Move가 14.05초라는 것을 알 수 있는데, 이것은 과장된 것이므로 실제로는 그렇게 큰 차이가 나지는 않을 것이다. 어쨌든, 먼저 발생하는 것은 서버 상태를 캐릭터에 직접 적용하는 것이다.

클라이언트는 서버에 의해 수정될 때마다 서버의 위치로 다시 돌아간다. 알다싶이 14.05초의 시간 단계에서 우리는 잘못된 예측을 했고, 초록색의 원 위치에 있어야 했지만 현재 노란색의 위치에 있다. 하지만 서버가 업데이트된 위치를 보낼 때 우리는 이미 미래에 대해 시뮬레이션 했으며, 14.42 단계인 빨간색 원의 위치에 있다. 우리가 잘못된 예측을 했을 때보다 약 400ms 앞서 있다는 것을 알 수 있다. 클라이언트를 다시 초록색 원의 위치로 보내야 하므로, 꽤 거슬리는 행동이 될 것이다. 빨간색 원과 노란색 원의 사이에 있는 분홍색 원들은 보류 중인 동작을 나타내는데, 이 보류 중인 동작들은 잘못되지 않았다. 단지 노란색 원의 동작이 잘못됐을 뿐이다.

그래서 그 대신에, 잘못된 상태를 초록색 원의 상태로 옮긴 다음에, 보류중인 움직임을 우리가 있어야 할 위치로 다시 시뮬레이션 할 것이다. 이렇게 하면 위의 사례보다 훨씬 덜하게 차이가 발생한다는 것을 알 수 있으며, 차이가 특정된 허용범위 내에 있으면 언리얼 엔진이 클라이언트를 새로운 위치에 블렌딩하기에 스냅 현상이 일어나지 않는다.

다시 돌아가서, 우리는 상태를 먼저 적용하고, 보류된 움직임에 대해 다시 적용하고 다시 Perform Move를 호출하면 우리를 수정된 새로운 위치로 데려가게 된다.

Statefulness & Movement Safety

상태 보존과 안전한 이동에 대해 얘기할 것인데, 이 주제는 좀 어려울 수 있어서 코딩을 시작하고 나서야 이해하기가 훨씬 쉬울 것이다.

클라이언트에서 perform move가 호출되는 곳은 두곳이 있다. 실제로 캐릭터를 이동할 때 틱 컴포넌트의 일반적인 이동이 있고, 서버가 클라이언트를 수정할 때 모든 Saved Move에 대한 이동이 있다. 이전에 말했던 것처럼, 이것이 작동하려면 우리는 동일한 입력 상태에서 작동하도록 해야한다. 입력이 동일하게 유지되면, 동일한 결과를 생성할 것이다.

하지만, 상태 데이터가 있으면 까다로워진다. 예를 들면 대시가 될 수 있다. 대시에 쿨다운이 있고, 플레이어가 빨간색 원의 방향으로 돌진했고, 플레이어가 빨간색의 위치에 있다고 해보자. 물리 함수에서 대시 쿨다운에 델타 시간을 추가하고 대시 쿨다운이 대시 지속 시간을 초과할 때마다 다시 대시할 수 있다.

조정을 마친 후, Saved Moves를 재생해야 한다. 각 동작이 Perform move를 다시 호출하고, 물리 함수를 다시 호출한 뒤 다시 대시 쿨다운을 증가시킨다.

겉보기에는 문제가 없어보이지만, 위의 단계에선 실시간으로 여러 프레임에 걸쳐 발생하는데 반면 여기서는 저장된 모든 동작을 하나의 프레임에서 다시 시뮬레이션 한다. 이것이 끔찍한 비동기화의 이유이다. 이 문제를 어떻게 해결해야 할까?

공식적인 용어는 아니지만, 여기서는 Movement Safety 라는 용어를 사용한다. 이것은 어떤 변수를 사용할 수 있고 없는지에 대한 아이디어와 물리 함수가 비상태 데이터에 대해 오작동하는 것을 피할 수 있는 방법을 제공한다.

Saved Move는 오버라이드가 가능하고, 여기에 대시 쿨다운을 추가할 수 있는 상태 데이터를 추가할 수 있다. 이렇게 하면 Perform move에 대한 입력이 준비되어 처음으로 perform move를 호출했을 때와 정확히 동일해진다.

Saved Move에 상태를 적절하게 저장하지 않으면 이동이 안전하지 않다. 또한 클라이언트와 서버가 동기화되지 않는 비동기화 현상이 발생하며 수많은 서버의 보정이 적용된다는 것을 알 수 있다.

Character Movement Component In-Depth 강의 시리즈를 공부하면서 한글로 정리한 포스트입니다. 의역과 오역이 난무하니 주의해주세요! https://youtu.be/urkLwpnAjO0?si=ZzIrCFjw58bE8Yy9

In this video...

• 캐릭터 무브먼트 컴포넌트란 무엇인가?
• 캐릭터 무브먼트 컴포넌트를 확장해야 하는 이유?
• 캐릭터 무브먼트 컴포넌트가 제공하는 것은?

What is the Character Movement Component?

캐릭터 무브먼트 컴포넌트(이하 CMC)는 언리얼 엔진의 캐릭터를 상속받은 클래스에 포함된 액터의 구성 요소로, 캐릭터에서 전송되는 입력 벡터를 취하고 이를 사용하여 여러 무브먼트 모드가 포함된 캐릭터의 트랜스폼을 다룬다.

이 클래스를 커스텀 CMC로 확장하면 강력한 기능이 발휘된다. 새로운 무브먼트 모드를 만들고, 전력질주와 같은 상태 변경이나 대시와 같은 이벤트처럼 캐릭터가 이동하는 방식을 변경하는 함수를 CMC에 작성할 수 있다.

CMC를 확장하려면 C++이 요구되므로, 블루프린트 프로그래머는 기본 CMC 기능에 가까운 게임을 만드는 것이 좋다.

Do you need a custom Character Movement Component?

이제 게임에 커스텀 CMC가 필요한지 판단할 수 있는 세 가지 카테고리를 살펴보겠다.

Single Player / Co-op

클라이언트가 권한을 갖고(치트나 핵같은 부분에 신경을 쓰지 않아도 되는 경우) 걷기, 질주, 수영 등과 같은 매우 표준적인 인간형 움직임만 사용하는 경우엔 기본 CMC를 사용하는 것만으로도 충분할 것이다. 이런 경우. CMC에 내장되어 있지 않은 기능은 블루프린트를 약간만 수정하는 것으로도 쉽게 구현할 수 있다. (EX : Max Walk Speed 만 수정하면 되는 스프린팅과 같은 경우)

오프라인 게임에서만 정상적으로 작동한다는 것을 참고하자. 만약 벽 달리기나 행글라이딩과 같은 복잡한 움직임을 사용하고 싶다면, 중력 조절과 같은 기능을 수정하여 가능하게 만들 수는 있지만 벽에 부딪힐 확률이 높으므로 커스텀 CMC를 만드는 것을 추천한다.

General Multiplayer

fps, MMO, 배틀 로얄과 같은 일반적인 멀티 플레이어 게임을 만들고 있다면, 커스텀 CMC를 반드시 사용해야 한다.

다음의 두 가지 경우는 CMC를 확장할 필요가 없을 수도 있다.

1. 게임의 움직임이 매우 간단하고 기본 이동 매커니즘 외에 다른 것이 필요하지 않은 경우(멀티플레이어 포인트 앤 클릭 MMO)
2. CMC에서 처리할 수 없을만큼 복잡한 이동 시스템이 있는 경우(폰의 루트 컴포넌트가 physics-based 여서 완전한 물리 기반 캐릭터일 경우와 같은)

Non-Humanoid

탱크나 새와 같이 인간형이 아닌 플레이어가 있거나 캐릭터가 물리 기반인 경우.

오프라인 게임을 만든다면 CMC나 캐릭터를 사용하지 않고 폰 클래스를 상속받거나 자신만의 무브먼트 클래스를 만드는 것을 추천한다.

하지만 멀티플레이어 게임을 만든다면, 캐릭터를 사용하고 CMC를 확장하는 것을 추천한다. 비록 플레이어가 이 구조에 적합하지 않다고 느껴지더라도, CMC가 제공하는 장점은 매우 중요하다. 캐릭터 기반 클래스를 사용하는 경우의 유일한 단점은, 캡슐 콜라이더 사용이 고정된 것 뿐이다. 만약 새를 사용하는 경우, 캡슐의 절반 높이를 반경과 동일하게 설정하면 스피어 콜라이더로 만들어지므로 이 문제를 해결할 수 있다.

What does the Character Movement Component Provide?

Client Side Prediction - hides latency

CMC의 가장 중요하고 필수적인 기능은 서버에서 신뢰할 수 있고 클라이언트가 예측한다는 것이다. 클라이언트 측 예측과 그것이 필요한 이유에 대해 강의가 올라올 것이다. 멀티플레이 게임을 만들려면, 기본적으로 클라이언트 측 예측이 있어야 한다. 이 기능을 직접 구현하려면 몇 달이 걸릴 수 있다.

오늘은 데미지의 종류에 따라 캐릭터가 다르게 반응하도록 구현하려고 한다. 기획서에 명시되어 있는 데미지의 종류는 다운, 넉백, 스턴, 슬로우, 약공격, 강공격이 있다.

데미지 타입 클래스 만들기

데미지 타입의 클래스를 이용해 구분하므로, DamageType을 상속받은 클래스를 먼저 만들어주었다. '클래스'만 필요하기 때문에, 코드의 선언부와 구현부는 모두 비워놓았다.

약공격과 강공격은 데미지의 세기에 따라 후순위로 분류되므로, 일반 데미지타입이 들어왔을 때 적용하도록 하고 특수한 데미지 타입만 만들어주었다.

TakeDamage() 함수에 데미지 타입 판별 코드 구현

기존에 데미지를 처리하는 멀티캐스트 RPC 함수가 데미지 이벤트를 받도록 수정해주고, 타입을 판별해 로그를 출력하도록 만들었다.

// 데미지 타입별 처리
const UDamageType* DamageType = DamageEvent.DamageTypeClass->GetDefaultObject<UDamageType>();

if (DamageType->IsA<UDamageTypeDown>())
{
    UE_LOG(LogTemp, Warning, TEXT("Damage Type : Down"));
}
else if (DamageType->IsA<UDamageTypeStun>())
{
    UE_LOG(LogTemp, Warning, TEXT("Damage Type : Stun"));
}
else if (DamageType->IsA<UDamageTypeKnockBack>())
{
    UE_LOG(LogTemp, Warning, TEXT("Damage Type : Knock Back"));
}
else if (DamageType->IsA<UDamageTypeSlow>())
{
    UE_LOG(LogTemp, Warning, TEXT("Damage Type : Slow"));
}
else
{
    // 우선 수치는 하드코딩 -> 추후 데이터 테이블로 뺄 것
    if (Damage < 70)
    {
        UE_LOG(LogTemp, Warning, TEXT("Damage Type : Light Attack"));
    }
    else
    {            
        UE_LOG(LogTemp, Warning, TEXT("Damage Type : Heavy Attack"));
    }
}

테스트 환경 만들기

콜리전 박스를 가지고 있는 액터를 하나 만들어주고, 투명한 머테리얼을 가진 메시와 텍스트 렌더러를 달아준 뒤, 데미지 타입을 스트링으로 받도록 변수를 하나 만들어주었다.

게임이 시작되면 텍스트 렌더러에 입력한 스트링으로 바꿔주는 코드를 넣고,

받은 스트링에 따라 데미지를 주도록 노드를 구성했다. 다소 복잡하지만... 각기 다른 클래스를 넣어주어야 해서 어쩔수 없었다...ㅎㅎ

테스트 레벨에 배치해주고 실행하면,

이렇게 설정해준 클래스 타입별로 로그가 잘 찍히는 것을 볼 수 있다.

Slow 데미지 타입이 빠지게 되어 Slow 관련 클래스와 테스트 액터를 삭제해주었다.

몽타주 수정

기획서에 명시되어 있는 애니메이션 에셋을 리타게팅 해준 후, 기존 TakeDamage 몽타주에 섹션을 나누어 넣어주었다.

몽타주 재생

void ATrapperPlayer::MulticastRPCCharacterAlive_Implementation(float Damage, FDamageEvent const& DamageEvent, AActor* DamageCauser)
{
    IsDamaged = true;

    if (IsValid(DamageCauser) && DamageCauser->ActorHasTag("NoCharacterHitAnimationTrap"))
    {
        return;
    }

    GetCharacterMovement()->SetMovementMode(MOVE_None);

    UAnimInstance* AnimInstance = GetMesh()->GetAnimInstance();
    if (!IsValid(AnimInstance) && !IsValid(DamagedAnimationMontage))
    {
        return;
    }

    // 몽타주 재생
    AnimInstance->Montage_Play(DamagedAnimationMontage, 1.0);

    // 데미지 타입별 애니메이션 섹션 이동
    const UDamageType* DamageType = DamageEvent.DamageTypeClass->GetDefaultObject<UDamageType>();

    if (DamageType->IsA<UDamageTypeDown>())
    {
        AnimInstance->Montage_JumpToSection(FName("Down"), DamagedAnimationMontage);
    }
    else if (DamageType->IsA<UDamageTypeStun>())
    {
        AnimInstance->Montage_JumpToSection(FName("StunStart"), DamagedAnimationMontage);
    }
    else if (DamageType->IsA<UDamageTypeKnockBack>())
    {
        AnimInstance->Montage_JumpToSection(FName("KnockBack"), DamagedAnimationMontage);
    }
    else
    {
        if (Damage < 70)
        {
            AnimInstance->Montage_JumpToSection(FName("Light"), DamagedAnimationMontage);
        }
        else
        {
            AnimInstance->Montage_JumpToSection(FName("Heavy"), DamagedAnimationMontage);
        }
    }

    // 몽타주 끝났을 때 델리게이트 바인딩
    FOnMontageEnded EndDelegate;
    EndDelegate.BindUObject(this, &ATrapperPlayer::DamagedEnd);
    AnimInstance->Montage_SetEndDelegate(EndDelegate, DamagedAnimationMontage);
}

몽타주를 재생한 뒤, 데미지 타입별로 애니메이션 섹션을 바꿔주는 식으로 코드를 구현하였다.

이제 데미지 타입별로 몽타주가 재생되는 것을 볼 수 있다 :)

SubTitle : 난 데이터 테이블 누락인줄 알았어

static ConstructorHelpers::FObjectFinder<UDataTable> CharacterTable(TEXT("/Script/Engine.DataTable'/Game/Blueprints/Data/DT_CharacterData.DT_CharacterData'"));
if (CharacterTable.Succeeded() && CharacterTable.Object)
{
    CharacterData = CharacterTable.Object;
}

캐릭터 데이터 테이블을 생성자에서 FObjectFinder를 사용해 불러오고, BeginPlay() 함수에서 캐릭터 스탯의 초기화에 사용하고 있는데, 에디터에서는 정상적으로 작동하지만 빌드만 뽑으면 자꾸 Fatal Error가 뜨면서 시작하자마자 게임이 꺼지는 현상이 있었다.

[2024.08.21-05.18.18:011][638]LogWindows: Error: === Critical error: ===
[2024.08.21-05.18.18:011][638]LogWindows: Error: 
[2024.08.21-05.18.18:011][638]LogWindows: Error: Unhandled Exception: EXCEPTION_ACCESS_VIOLATION writing address 0x00000000000008b0
[2024.08.21-05.18.18:011][638]LogWindows: Error: 
[2024.08.21-05.18.18:011][638]LogWindows: Error: [Callstack] 0x00007ff632815df1 TrapperProject.exe!ATrapperPlayer::ApplyCharacterData() [E:\GA5thFinalProject_Trapper\5_Project\TrapperProject\Source\TrapperProject\Character\TrapperPlayer.cpp:710]

ApplyCharacterData() 여기서 자꾸 예외가 뜨길래 데이터 테이블이 패키징에 포함되지 않는 것 같았다.

분명 Additional Asset Directories to Cook 에 디렉토리 경로를 잘 넣어주고 있는데... 그래서 패키징된 파일에 데이터 테이블이 잘 들어가있는지 확인이 필요했다. 그 확인하는 과정을 남겨두면 좋을 것 같아서 기록하는 포스팅.

UnrealPak 사용하는법

먼저 명령 프롬포트를 킨 뒤, UnrealPak이 설치된 폴더로 이동하자.

C:\Program Files\Epic Games\UE_5.3\Engine\Binaries\Win64

그리고 패키징된 파일이 있는 곳으로 이동해서 Pak 폴더를 찾아준다.

(생략)\Windows\TrapperProject\Content\Paks

내 경우엔 여기에 위치한다.

UE5 기준으로 이렇게 세개의 파일을 찾을 수 있었다.

만약 포함된 에셋의 리스트만 출력하고 싶다면, 명령 프롬포트에

UnrealPak.exe "출력해야 하는 Pak 파일 경로" -List

이렇게 써주면 된다.

C:\Program Files\Epic Games\UE_5.3\Engine\Binaries\Win64>UnrealPak.exe "E:(생략)\Windows\TrapperProject\Content\Paks\TrapperProject-Windows.pak" -List

(예시 커맨드)

그럼 이렇게 쭉쭉 출력된다.

만약 압축을 풀어서 폴더로 확인하고 싶다면,

UnrealPak.exe "출력해야 하는 Pak 파일 경로" -Extract "압축 풀 경로"

이렇게 넣어주면 된다.

C:\Program Files\Epic Games\UE_5.3\Engine\Binaries\Win64>UnrealPak.exe "E:(생략)\Windows\TrapperProject\Content\Paks\TrapperProject-Windows.ucas" -Extract "C:\Users\user\Desktop\PakTest"

(예시 커맨드)

나는 pak 확장자가 아닌 ucas 확장자를 압축해제 해줬는데, pak을 풀어봤을 때 에셋이 포함되어 있지 않았기 때문.. Content 폰트만 들어있었어서, 용량이 더 큰 ucas를 풀어보니 거기에 에셋이 다 있었다.

이렇게.. Extract 한 폴더에 들어가보면 쭉쭉 뜨기 때문에, 에셋이 누락되었는지 다른 문제인건지 확인할 수 있게된다.

아무튼 사진을 보면 알 수 있듯, 나는... 다른 문제였다.. 데이터 테이블 너무 예쁘게 들어가있구.. 애먼 데이터 테이블만 탓하고 있었음 :) 뭐 그래도 덕분에 UnrealPak 사용법도 알게되고 럭키비키자나...!

시퀀스들의 정보를 가지고 있고, 시퀀스마다 타입을 붙혀준 뒤 그 타입을 인자로 받아 재생시켜주는 시퀀스 매니저를 만들어주었다.

UENUM(BlueprintType)
enum class ESequenceType : uint8
{
    Opening                            UMETA(DisplayName = "Opening"),
    TutorialCameraMove                UMETA(DisplayName = "TutorialCameraMove"),
    FirstWave                        UMETA(DisplayName = "FirstWave"),
    BonusWave                        UMETA(DisplayName = "BonusWave"),
    Ending                            UMETA(DisplayName = "Ending"),
};

enum class를 사용해 각각의 시퀀스마다 이름을 붙혀주었다.

UPROPERTY(EditDefaultsOnly, BlueprintReadWrite)
TMap<ESequenceType, class ULevelSequence*> SequenceMap;

맵을 만들어주고, 블루프린트에서 직접 시퀀스를 설정할 수 있도록 해줬다.

UFUNCTION(NetMulticast, Reliable)
void MulticastRPCPlaySequence(ESequenceType Type);

void ASequenceManager::MulticastRPCPlaySequence_Implementation(ESequenceType Type)
{
    ULevelSequence** Sequence = SequenceMap.Find(Type);
    if (Sequence && *Sequence)
    {
        if (HasAuthority())
        {
            ATrapperGameState* TrapperGameState = GetWorld()->GetGameState<ATrapperGameState>();
            TrapperGameState->OnEventExecute.Broadcast(99);
        }

        FMovieSceneSequencePlaybackSettings PlaybackSettings;
        LevelSequencePlayer = ULevelSequencePlayer::CreateLevelSequencePlayer(GetWorld(), *Sequence, PlaybackSettings, LevelSequenceActor);

        if (LevelSequencePlayer && LevelSequenceActor)
        {
            // 종료 함수 바인딩
            if (HasAuthority())
            {
                FName* EndFunctionName = EndFunctionMap.Find(Type);
                if (EndFunctionName)
                {
                    LevelSequencePlayer->OnFinished.AddDynamic(this, &ASequenceManager::OnSequenceFinished);
                }
            }

            LevelSequencePlayer->Play();
        }
    }
}

멀티캐스트 RPC 함수를 사용해 시퀀스 타입을 인자로 받아 시퀀스를 재생시켜주는 함수이다. 시퀀스 맵에서 타입에 따라 맞는 시퀀스를 불러와주고, 종료 함수를 바인딩한 뒤 시퀀스를 플레이한다. 서버일 경우 이벤트 코드 99번을 송신하는데, 플레이어 HUD를 숨김처리해주는 코드이다.

void ASequenceManager::OnSequenceFinished()
{
    for (const TPair<ESequenceType, FName>& Pair : EndFunctionMap)
    {
        if (LevelSequencePlayer->GetSequence() == SequenceMap[Pair.Key])
        {
            // 함수 이름을 통해 호출
            FName FunctionName = Pair.Value;
            UFunction* Function = FindFunction(FunctionName);
            if (Function)
            {
                ProcessEvent(Function, nullptr);

                ATrapperGameState* TrapperGameState = GetWorld()->GetGameState<ATrapperGameState>();
                TrapperGameState->OnEventExecute.Broadcast(98);
            }
        }
    }
}

시퀀스가 종료되었을 때 호출되는 함수이다. ProcessEvent 함수를 통해 실행된 시퀀스에 따라 시퀀스가 끝났을 때 각기 다르게 처리해준다.

// ASequenceManager.h

TMap<ESequenceType, FName> EndFunctionMap;
UFUNCTION() void OpeningSequenceFinished();
UFUNCTION() void TutorialCameraMoveFinished();
UFUNCTION() void FirstWaveFinished();
UFUNCTION() void BonusWaveFinished();

// ASequenceManager.cpp

void ASequenceManager::Initialize()
{
    EndFunctionMap.Add(ESequenceType::Opening, TEXT("OpeningSequenceFinished"));
    EndFunctionMap.Add(ESequenceType::TutorialCameraMove, TEXT("TutorialCameraMoveFinished"));
    EndFunctionMap.Add(ESequenceType::FirstWave, TEXT("FirstWaveFinished"));
    EndFunctionMap.Add(ESequenceType::BonusWave, TEXT("BonusWaveFinished"));
}

Initialize() 함수 안에서 EndFunctionMap에 호출해야 할 함수명들을 저장해둔다. 사실 모든 함수에서 이벤트 코드만 호출하기 때문에 이렇게 복잡하게 짤 필요는 없었지만, 다른 방식으로도 한번 설계해 보았다. 이벤트 코드로 호출하는 것과는 다르게, 시퀀스마다 이름을 지정해주었기 때문에 호출할때 헷갈리지 않아서 좋은 것 같다 :)

다시 위로 올라가서 시퀀스가 종료되어 OnSequenceFinished() 함수가 호출되면, 각 시퀀스에 맞는 종료 함수를 실행해주고, 98번 이벤트 코드를 전송해 플레이어 HUD를 다시 되돌려놓는다.

다이얼로그 매니저 구현

TObjectPtr<class UDataTable> DialogData;

ADialogManager::ADialogManager()
{
    // Set this actor to call Tick() every frame.  You can turn this off to improve performance if you don't need it.
    PrimaryActorTick.bCanEverTick = true;

    static ConstructorHelpers::FObjectFinder<UDataTable> DialogTable(TEXT("/Script/Engine.DataTable'/Game/Blueprints/Data/DT_DialogData.DT_DialogData'"));
    if (DialogTable.Succeeded() && DialogTable.Object)
    {
        DialogData = DialogTable.Object;
    }
}

먼저, 생성 시점에 다이얼로그 데이터 테이블을 불러와줬다.

    /// --------------------------------
    ///                Dialog 
    /// --------------------------------

    if (EventCode >= 500 && EventCode < 600)
    {
        DialogManager->MulticastRPCPlayDialog(EventCode);
    }

게임모드에서 500번대 이벤트 코드를 받으면 MulticastRPCPlayDialog() 함수를 호출한다.

void ADialogManager::MulticastRPCPlayDialog_Implementation(int32 DialogCode)
{
    if (!PlayerController)
    {
        return;
    }

    PlayDialog(DialogCode);
}

플레이어 컨트롤러가 있는 경우에만(BeginPlay 함수에서 받아온다) PlayDialog() 함수를 호출한다.

void ADialogManager::PlayDialog(int32 DialogCode)
{
    // 플레이어 대사 UI 활성화
    PlayerController->ShowPlayerDialog(true);
    bIsPlaying = true;

    DialogIndex++;

    // 다이얼로그 데이터를 불러오기 위한 이름 계산
    FString DialogDataName = FString::FromInt(DialogCode) + TEXT("_") + FString::FromInt(DialogIndex);
    FDialogInfo* Dialog = DialogData->FindRow<FDialogInfo>(*DialogDataName, FString());
    LastDialogCode = DialogCode;

    // 데이터가 있다면,
    if (Dialog)
    {
        // Text UI를 설정해준다.
        PlayerController->SetPlayerText(GetCharacterName(Dialog->Character), Dialog->Dialog);

        // 다이얼로그에 이벤트 코드가 있을 경우 실행
        if (Dialog->EventCode.Num() != 0 && HasAuthority())
        {
            for (auto Code : Dialog->EventCode)
            {
                GetWorld()->GetGameState<ATrapperGameState>()->OnEventExecute.Broadcast(Code);
            }
        }

        // 마지막 대사의 경우 타이머를 설정한 뒤 다이얼로그 재생을 끝낸다
        if (Dialog->bIsEnd)
        {
            FTimerHandle EndHandle;
            GetWorldTimerManager().SetTimer(EndHandle, FTimerDelegate::CreateLambda([&]
                {    
                    // 대사 UI 비활성화, 인덱스 초기화
                    PlayerController->ShowPlayerDialog(false);
                    DialogIndex = 0;
                    bIsPlaying = false;
                }
            ), 1.0f, false, Dialog->Time);
        }
        // 마지막 대사가 아닐 경우, 다음 대사 진행
        else
        {
            FTimerHandle Handle;
            GetWorldTimerManager().SetTimer(Handle, FTimerDelegate::CreateLambda([&]
                {
                    PlayDialog(LastDialogCode);
                }
            ), 1.0f, false, Dialog->Time);
        }
    }
}

이것도 이쁘게 주석으로 정리해보았다..! 다이얼로그 매니저는 호출 당했을 때 저장하고 있는 대사만 출력해주면 되므로 간단하게 끝난다 :)

이벤트 작동 테스트

처음 설계대로 게임모드가 시퀀스 매니저와 퀘스트 매니저, 다이얼로그 매니저에서 보내준 이벤트 코드를 받아 전역으로 처리해주며 게임의 루프가 굴러가고 있다.

튜토리얼~첫번째 웨이브까지의 이벤트코드 수신 목록이다. 코드를 받는대로 잘 작동하는걸 확인할 수 있었다 :) 이제 틀은 모두 만들어졌으니, 이런식으로 쭉쭉 살을 붙혀나가면 메타루프도 금방 끝날 것 같다.

데이터 시트 설명서 제작

기획자분들이 웨이브 / 퀘스트 / 다이얼로그 관련해 수정할 수 있도록 설명서를 제작했다(드디어!).

예시와 함께 최대한 쉽게 설명하려고 노력해서 작성했다..!!

그리고 내 개인 노트에 정리해두었던 퀘스트 / 이벤트 코드 관련된 것들도 같이 작성해두었다. 겸사겸사 현재 적용 여부도 기획분들이 확인하실 수 있게끔 함께 정리해두었음 :)

[Trapper] 웨이브 & 퀘스트 & 다이얼로그 코드 정리 및 설명서

궁금하실분을 위해 준비했습니다..(뾰롱)

(뜬금)일기

갈수록 정리의 개념으로 글을 쓰고있게 되는 것 같다. 빨리 굴러가게 구현해야하니까 글 쓸 시간이.. 과정을 남기는게 목표긴 했는데, 그래도 이렇게라도 남겨두는게 어디냐!!! 앞으로도 열심히 써야지 :)

프로젝트를 진행할 수록, 회사에서의 프로젝트 진행이 너무너무 궁금하다.. 얼마나 체계적일까? 내가 설계하는게 효율적인지 비효율적인지 판단해줄 선배들이 잔뜩 계시는걸까..?! 기존 게임들은 도대체 어떻게 게임의 흐름을 관리하고, 기획자와 협업하고, 시스템을 만들고 그러는걸까.. 너무너무너무 궁금하다 XD 빨리 배우고싶어!!!!!!!!(시끄러움)

우선, 이런식으로 내가 기획문서를 읽고 작동시켜야 할 이벤트들을 정리해보았다. 아직 기획서가 완벽하게 정해지진 않은거라 다 채우진 못했음!

퀘스트 데이터 테이블에서 bMoveToMaintenance 변수를 제거하고, EventCode 변수를 추가해주었다. 추후에 스크립트 테이블에도 이 Event Code를 넣어줄 것이다.

// GameState.h

DECLARE_MULTICAST_DELEGATE_OneParam(FOnEventExecute, int32)
FOnEventExecute OnEventExecute;

// GameMode.cpp

void ATrapperGameMode::BeginPlay()
{
    Super::BeginPlay();

    TrapperGameState = Cast<ATrapperGameState>(GetWorld()->GetGameState());
    TrapperGameState->OnEventExecute.AddUObject(this, &ATrapperGameMode::EventHandle);

    // 생략..
}

게임 스테이트에 델리게이트 변수를 선언해주고, 게임모드에서 이걸 처리해줄 함수를 선언하고 바인딩 해주었다.

void AQuestManager::QuestComplete()
{
 // 생략..

    // 정비시간으로 이동
    if (GetCurrentQuest().bMoveToMaintenance)
    {
        ATrapperGameMode* GameMode = GetWorld()->GetAuthGameMode<ATrapperGameMode>();
        GameMode->SetGameProgress(EGameProgress::Maintenance);
        GameMode->SetSkipIcon(true);
        GameMode->InitialItemSetting();

        UE_LOG(LogQuest, Warning, TEXT("Go Maintenance"));
    }

 // 생략..
 }

이부분의 코드를, 아래처럼 퀘스트를 완료했을 시에 발생시켜야 하는 이벤트 코드를 보내는 쪽으로 바꾸어주었다.

void AQuestManager::QuestComplete()
{
 // 생략..

    if (GetCurrentQuest().EventCode.Num() != 0)
    {
        ATrapperGameState* GameState = GetWorld()->GetGameState<ATrapperGameState>();
        for (auto Code : GetCurrentQuest().EventCode)
        {
            // 이벤트 코드 브로드캐스트
            GameState->OnEventExecute.Broadcast(Code);
        }
    }

 // 생략..
 }

void ATrapperGameMode::EventHandle(int32 EventCode)
{
    switch (EventCode)
    {

    /// --------------------------------
    ///                Event 
    /// --------------------------------

#pragma region Event
    case 1:
    {
        SetGameProgress(EGameProgress::Maintenance);
        SetSkipIcon(true);
        InitialItemSetting();
    }
    break;
#pragma endregion Event

    /// --------------------------------
    ///                Sequence 
    /// --------------------------------

#pragma region Sequence

#pragma endregion Sequence

    /// --------------------------------
    ///                Dialog 
    /// --------------------------------

#pragma region Dialog

#pragma endregion Dialog

    default: 
        break;
    }
}

이벤트를 재생시킬 함수는 그냥 switch-case 문으로 빠르게 처리했다. 어차피 이벤트가 그렇게 많은 게임이 아니기 때문에, 이정도로 해두는게 가독성도 좋고 유지보수가 쉬울 것이라고 판단했기 때문이다.

이렇게 만들어두고! 내일은 스크립트 매니저와 시퀀스 매니저를 만든 뒤에 본격적으로 메타루프에 살을 붙혀보려고 한다 :)

계속 퀘스트 매니저가 모든 것들을 제어하는 식으로 고민해왔는데, 모든 곳에서 게임 흐름을 제어하는 이벤트가 발생한다는 것을 생각하니, 별도의 관리자가 있는게 훨씬 나을 것 같다는 판단이 섰다. 각각의 매니저들은 각각의 기능만 관리하도록 하고, 한 곳에서 이벤트 코드를 받아 제어하도록 하는게 좋겠다 싶었다. 어차피 게임 흐름은 서버에서 관여할 것이고, 굳이 게임 매니저를 따로 만들지 않고 게임 모드를 사용하는게 가장 적합할 것 같다는 결론이 섰음.

정비 시간 & 웨이브 상태변수 게임 스테이트로 이동

우선, 게임모드가 가지고 있던 게임의 상태를 게임 스테이트로 이관하기로 했다. 작업하는 틈틈히 옮겨놓긴 해서 그렇게 많진 않았다.

정비 시간

#pragma region Maintenance

// ATrapperGameState.h

// 몇번째 정비시간인지 체크
UPROPERTY(Replicated)
uint8 MaintenanceCount = 0;

UPROPERTY(ReplicatedUsing = OnRep_ChangeMaintenanceTimeLeft)
uint32 MaintenanceTimeLeft;

void AddMaintenanceTime(uint32 Value);

UFUNCTION()
void OnRep_ChangeMaintenanceTimeLeft();

UPROPERTY(ReplicatedUsing = OnRep_ChangeMaintenanceState)
uint32 bMaintenanceInProgress : 1;

UFUNCTION()
void OnRep_ChangeMaintenanceState();

#pragma endregion Maintenance

클라이언트의 UI를 설정하는데 필요한 남은 정비 시간과 정비 시간임을 알 수 있는 변수를 옮겨주고, 게임모드 내에서 사용하고 있는 기존 변수들을 게임 스테이트에서 꺼내쓰도록 바꿔주었다. 또한, 게임모드에서 RPC를 통해 동기화시켜주고 있는 UI를 게임스테이트 내에서 로컬로 처리하도록 변경했다.

정상적으로 UI가 동기화되는 모습.

웨이브

#pragma region Wave

public:

    UPROPERTY(ReplicatedUsing = OnRep_ChangeWaveTimeLeft)
    uint32 WaveTimeLeft;

    void SetWaveTime(float Value);

    UFUNCTION()
    void OnRep_ChangeWaveTimeLeft();

    UPROPERTY(Replicated)
    uint32 bWaveInProgress : 1;

    UPROPERTY(Replicated)
    uint32 Wave = 0;

    UPROPERTY(Replicated)
    uint32 SubWave = 1;

    UPROPERTY(Replicated)
    uint32 MaxWave = 20;

#pragma endregion Wave

웨이브도 정비 시간과 마찬가지로 똑같이 처리해주었다.

웨이브 로직 수정

기존 10웨이브가 20웨이브로 늘어났고, 커다란 웨이브 한 묶음이 끝나고 몬스터를 '모두' 잡아야 정비시간으로 넘어가게끔 바뀌었기 때문에 수정해 주어야 하고, 서브 웨이브 단계를 기획분들이 밸런싱하기 쉽게 변경하기로 했다(기존에도 고려하여 설계했지만, 조금 더 이해하기 쉽도록 수정).

USTRUCT()
struct FWaveInfo : public FTableRowBase
{
    GENERATED_USTRUCT_BODY()

public:
    UPROPERTY(EditAnywhere, BlueprintReadWrite) uint8 bLastSubWave;
    UPROPERTY(EditAnywhere, BlueprintReadWrite) uint8 bLastLargeWave;
    UPROPERTY(EditAnywhere, BlueprintReadWrite) int32 Skeleton;
    UPROPERTY(EditAnywhere, BlueprintReadWrite) int32 Mummy;
    UPROPERTY(EditAnywhere, BlueprintReadWrite) int32 Zombie;
    UPROPERTY(EditAnywhere, BlueprintReadWrite) int32 Debuffer;
    UPROPERTY(EditAnywhere, BlueprintReadWrite) float NextWaveLeftTime;
    UPROPERTY(EditAnywhere, BlueprintReadWrite) FText Memo;
};

기존 웨이브 테이블의 bUseThisWave 변수를 삭제하고, 서브웨이브의 마지막과 웨이브의 한 묶음(1~4웨이브)의 마지막을 알 수 있는 변수들을 추가해주었다.

void ATrapperGameMode::WaveStart()
{
    UE_LOG(LogQuest, Warning, TEXT("Wave %d-%d"), TrapperGameState->Wave, TrapperGameState->SubWave);

    ALevelScriptActor* LevelScriptActor = GetWorld()->GetLevelScriptActor();
    ATrapperScriptActor* MyLevelScriptActor = Cast<ATrapperScriptActor>(LevelScriptActor);
    if (MyLevelScriptActor)
    {
        MyLevelScriptActor->MulticastRPCPlaySystemSound(ESystemSound::WaveStart);
    }

    FWaveInfo CurrentWaveData;
    if (GetWaveData(CurrentWaveData))
    {
        SpawnMonster(CurrentWaveData);
    }
    else
    {
        UE_LOG(LogQuest, Warning, TEXT("Wave Data Error"));
    }

    TrapperGameState->bWaveInProgress = true;
    TrapperGameState->SetWaveTime(CurrentWaveData.NextWaveLeftTime);
    TrapperGameState->SetWaveInfo();

    if (CurrentWaveData.bLastLargeWave == true)
    {
        TrapperGameState->SubWave = 1;
        TrapperGameState->bWaveInProgress = false;
        TrapperGameState->SetWaveTime(0.f);
        //SetGameProgress(EGameProgress::Maintenance);
        //SetSkipIcon(true);
        return;
    }

    if (CurrentWaveData.bLastSubWave == true)
    {
        // 다음 웨이브로 넘어감
        TrapperGameState->Wave++;
        TrapperGameState->SubWave = 1;
        SetGameProgress(EGameProgress::Wave);
        return;
    }

    FTimerHandle WaveTimerHandle;
    GetWorldTimerManager().SetTimer(WaveTimerHandle, FTimerDelegate::CreateLambda([&]
        {
            // 서브 웨이브 계속 진행
            TrapperGameState->SubWave++;
            WaveStart();
        }
    ), 1.0f, false, CurrentWaveData.NextWaveLeftTime);
}

초반부분은 기존 코드와 거의 동일하다. 만약 이전에 진행한 웨이브가 Large Wave 였다면 더이상 웨이브를 진행하지 않고 리턴하도록 했다. 마지막 Sub Wave일 경우 Wave를 증가시키고 Sub Wave를 1로 초기화한다. 모두 아닌 경우 타이머를 설정하고 Sub Wave를 증가시키고 재귀하도록 했다. 확실히 이전 로직보다는 깔끔한 느낌이다.

void ATrapperGameMode::GetThisWaveRemainingMonsterCount()
{
    bool ThisLargeWaveEnd = false;

    while(!ThisLargeWaveEnd)
    {
        for (uint32 k = 1; k < 6; k++)
        {
            FString WaveText = TEXT("Wave") + FString::FromInt(RemainingMonsterCountWave) + TEXT("_") + FString::FromInt(k);
            FWaveInfo* Data = WaveData->FindRow<FWaveInfo>(*WaveText, FString());
            if (!Data) continue;

            uint32 TotalMonster = 0;

            TotalMonster += Data->Skeleton;
            TotalMonster += Data->Mummy;
            TotalMonster += Data->Zombie;
            TotalMonster += Data->Debuffer;
            TotalMonster += Data->Boss;

            TrapperGameState->ChangeRemainingMonsterCount(TotalMonster);
            //UE_LOG(LogQuest, Warning, TEXT("This Wave %d-%d, Total Spawn Monster %d"), RemainingMonsterCountWave, k, TotalMonster);

            if (Data->bLastLargeWave)
            {
                ThisLargeWaveEnd = true;
            }
        }

        RemainingMonsterCountWave++;
    }
}

개인적으로는 데이터 구성을 바꿈으로써 변경된 이 함수가 마음에 들었다. 기존에는 다섯개 웨이브 단위로 하드코딩 되어있어서 혹시라도 웨이브 단위가 바뀌면 변경해주어야 했는데, Large Wave가 끝나면 계산을 끝내도록 해주었기 때문에 웨이브 단위가 모두 달라져도 상관이 없어졌다.

정상적으로 진행되고 있는 웨이브 테스트 스크린샷 :)

몬스터가 모두 잡히면 정비 시간으로 넘어가도록 하기

정비 단계와 웨이브 단계 모두 퀘스트가 있다. 정비단계 시간이 끝나거나 스킵했을 때 / 모든 몬스터 처치가 끝나면 퀘스트 매니저로 각각의 완료 퀘스트 코드를 넘긴 뒤, 퀘스트 매니저에서 다시 이벤트 코드를 게임모드로 보내는 식으로 변경해주려고 한다.

정비단계 퀘스트 완료

void ATrapperGameMode::MaintenanceStart()
{
    // 정비 시간 설정
    TrapperGameState->SetMaintenanceTime(MaintenanceTime);
    TrapperGameState->bMaintenanceInProgress = true;
    TrapperGameState->MaintenanceCount++;
    TrapperGameState->OnRep_ChangeMaintenanceState();

    // 웨이브에 출현할 몬스터 계산
    GetThisWaveRemainingMonsterCount();

    FTimerHandle MaintenanceTimerHandle;
    GetWorldTimerManager().SetTimer(MaintenanceTimerHandle, FTimerDelegate::CreateLambda([&]
        {
            // 정비시간을 스킵했을 경우 리턴
            if (bSkipMaintenance) return;

            SetSkipIcon(false);

            TrapperGameState->OnQuestExecute.Broadcast(99, true);

            // 다음 웨이브 시작
            TrapperGameState->Wave++;
            TrapperGameState->bMaintenanceInProgress = false;
            SetGameProgress(EGameProgress::Wave);
        }
    ), 1.0f, false, MaintenanceTime);
}

TrapperGameState->OnQuestExecute.Broadcast(99, true); 델리게이트에 99번 완료 코드를 보내주면, 정비 퀘스트가 완료된다.

void ATrapperGameMode::SkipMaintenance()
{
    bSkipMaintenance = true;
    TrapperGameState->bMaintenanceInProgress = false;

    TrapperGameState->OnQuestExecute.Broadcast(99, true);
    SetSkipIcon(false);

    TrapperGameState->Wave++;
    SetGameProgress(EGameProgress::Wave);
}

SkipMaintenance() 함수에서도 호출하도록 넣어주었다.

웨이브 퀘스트 완료

게임 스테이트에 있는 CurrentMonsterCount(현재 스폰된 몬스터 수) , RemainingMonsterCount(Large Wave동안 스폰될 남은 몬스터 수) 수가 모두 0이 되어야 정비 시간으로 넘어간다.

void ATrapperGameState::ChangeMonsterCount(int32 Count)
{
    if (HasAuthority())
    {
        CurrentMonsterCount += Count;
        OnRep_ChangeCurrentMonster();

        if (CurrentMonsterCount == 0)
        {
            CheckAllWaveMonsterDie();
        }
    }
}

void ATrapperGameState::CheckAllWaveMonsterDie()
{
    if (CurrentMonsterCount == 0 && RemainingMonsterCount == 0)
    {
        OnQuestExecute.Broadcast(98, true);
    }
}

굳이 Tick에서 계속 검사할 필요 없이 남아있는 몬스터 수가 0이 될때마다 두 변수를 모두 체크해서 이벤트를 발생시켜주면 될 것 같으므로, 이렇게 구현해보았다.

아직 Skip UI는 정상적으로 뜨지 않지만, 모든 몬스터가 죽었을 때 퀘스트가 정상적으로 완료되고 정비 단계로 이동하는 것을 볼 수 있다.

퀘스트 완료 함수에 스킵 UI를 띄워주는 코드를 임시로 넣어주었다. 이제 커밋해두고, 게임모드에 이벤트 코드를 받아 처리하는 함수를 만들어 줄 것이다. 그럼 퀘스트 완료 시에 이벤트 코드를 게임모드쪽으로 전송하고, 이벤트 코드에 따라 게임모드는 게임의 진행도를 관리해주면 된다. (이론은 완벽해..)

흐어어엉엉,, 역시는 역시 한번에 잘 풀릴리가 없다.. 네트워크 지원이야 안된다는걸 알고 사용한거긴 하지만 따로 액터를 생성해서 RPC를 날려서 서브시스템의 함수를 호출해도 클라이언트는 받질 못하고.. 동기화도 안되고.............. 잘 모르고 편해보인다고 쓰면 이렇게 되는거다.... 반나절을 넘게 헤맸지만 아직도 왜 안되는건지 잘 모르겠다.. 다시 액터로 교체 들어갑니다,,, 그냥 레벨에 배치해서 써야겠다 ^-^..ㅎ..

(+ 교수님께 여쭤봤더니 서브시스템은 동기화가 안되는거라고 한다.. 서버 관련된건 여기서 안 쓰는게 맞다함) (+ 뒤늦게 생각해봤는데.. 만들어준 액터에 Owner 설정을 안해줬던 것이 문제였던 것 같다..)

퀘스트 매니저 리뷰

갑자기 왜 리뷰로 넘어왔냐면(..) 퀘스트 매니저를 액터로 바꾸면서 정신없이 구현하는 바람에... 과정을 설명하기가 애매해져버렸다. 우선 지금까지의 진행상황이라도 정리하기로 했다.

생성자 & BeginPlay

AQuestManager::AQuestManager()
{
    // Set this actor to call Tick() every frame.  You can turn this off to improve performance if you don't need it.
    PrimaryActorTick.bCanEverTick = true;

    static ConstructorHelpers::FObjectFinder<UDataTable> QuestTable(TEXT("/Script/Engine.DataTable'/Game/Blueprints/Data/DT_QuestData.DT_QuestData'"));
    if (QuestTable.Succeeded() && QuestTable.Object)
    {
        QuestData = QuestTable.Object;
    }

    static ConstructorHelpers::FObjectFinder<UDataTable> QuestActorTable(TEXT("/Script/Engine.DataTable'/Game/Blueprints/Data/DT_QuestActorData.DT_QuestActorData'"));
    if (QuestActorTable.Succeeded() && QuestActorTable.Object)
    {
        QuestActorData = QuestActorTable.Object;
    }

    static ConstructorHelpers::FObjectFinder<UDataTable> TutorialMonsterTable(TEXT("/Script/Engine.DataTable'/Game/Blueprints/Data/DT_TutorialMonster.DT_TutorialMonster'"));
    if (TutorialMonsterTable.Succeeded() && TutorialMonsterTable.Object)
    {
        TutorialMonsterData = TutorialMonsterTable.Object;
    }
}

생성자에서는 데이터 테이블을 읽어들인다. 튜토리얼의 몬스터 배치때문에 튜토리얼 몬스터 데이터 테이블(배치해야하는 몬스터의 Position / Rotation 값)을 추가해주었다.

void ATrapperPlayerController::BeginPlay()
{
    Super::BeginPlay();

    UEnhancedInputLocalPlayerSubsystem* SubSystem =
        ULocalPlayer::GetSubsystem<UEnhancedInputLocalPlayerSubsystem>(GetLocalPlayer());
    if (SubSystem && DefaultIMC)
    {
        SubSystem->AddMappingContext(DefaultIMC, 0);
    }

    if (!HasAuthority())
    {
        ServerRPCUpdatebIsClientStart(true);
    }

    InitializeHUD();

    for (AQuestManager* QuestManager : TActorRange<AQuestManager>(GetWorld()))
    {
        QuestManager->SetOwner(this);
        QuestManager->SetQuestUI();
    }
}

플레이어 컨트롤러의 BeginPlay에서 퀘스트 매니저의 Owner를 자신으로 설정해주고, SetUI를 호출해준다. 왜 여기서 UI를 세팅하도록 호출해주었냐면, SetUI 함수 내에서 플레이어 컨트롤러를 호출해 UI를 설정해주고 있기 때문이다. 추후 시퀀스 매니저가 생기면, 오프닝 시퀀스 재생이 끝난 후 거기서 호출해줄 생각이다.

void AQuestManager::BeginPlay()
{
    Super::BeginPlay();

    ATrapperGameState* GameState = GetWorld()->GetGameState<ATrapperGameState>();
    GameState->OnQuestExecute.AddUObject(this, &AQuestManager::QuestCheck);

    if (QuestData)
    {
        // 리스트에 퀘스트 추가
        AddQuest();
    }

    if (QuestActorData)
    {
        // 퀘스트 액터 생성
        CreateQuestActor();
    }

    // 튜토리얼 몬스터 세팅
    if (HasAuthority())
    {
        FTimerHandle Handle;
        GetWorldTimerManager().SetTimer(Handle, this, &AQuestManager::TutorialMonsterSetting, 1.f, false);
    }

    // 이펙트 생성
    QuestEffect = GetWorld()->SpawnActor<AQuestEffect>();
    SetQuestEffect();
}

퀘스트 매니저의 BeginPlay 함수가 호출되면, 퀘스트 리스트에 퀘스트를 추가하고, 현재 퀘스트에 관련된 액터를 생성해준다.

튜토리얼 몬스터 세팅의 경우 몬스터를 만든 친구의 로직(Begin Play가 끝난 이후에 호출되어야 함)때문에 일단 임시로 타이머를 호출해놨다.

퀘스트를 추가하는 부분을 제외한 나머지도 마찬가지로 오프닝 시퀀스가 끝난 후 설정하도록 변경할 것이다.

AddQuest()

void AQuestManager::AddQuest()
{
    LastQuestIndex = QuestData->GetRowMap().Num() - 1;

    for (int i = 1; i <= QuestData->GetRowMap().Num(); i++)
    {
        FQuestInfo* Data = QuestData->FindRow<FQuestInfo>(*FString::FromInt(i), FString());

        FQuest Quest;
        Quest.Initialize(Data->QuestCode, Data->Title, Data->Description,
            Data->GoalCount1P, Data->GoalCount2P, Data->EffectPosition, Data->QuestActorCode);

        if (Data->bIsAlwaysChecking)
        {
            Quest.bIsAlwaysChecking = true;
        }

        if (Data->bChangeMainQuest)
        {
            Quest.bChangeMainQuest = true;
        }

        if (Data->bMoveToMaintenance)
        {
            Quest.bMoveToMaintenance = true;
        }

        if (Data->ExceptionCode != 0)
        {
            Quest.ExceptionCode = Data->ExceptionCode;
        }

        if (Data->bTutorialEnd)
        {
            TutorialEndIndex = i;
        }

        QuestList.Add(Quest);
    }
}

퀘스트 추가 함수에 예외문이 많이 생겼다. 항상 체크해야하는 퀘스트를 체크하기 위한 불변수, 메인 퀘스트가 바뀌는 경우를 체크하기 위한 불변수(추후에 메인 애니메이션마다 UI 애니메이션을 넣어주어야 하기 때문), 정비시간으로 이동해야하는 경우를 체크하기 위한 불변수, 추가적으로 예외처리를 해줘야 하는 상황을 위한 예외코드, 튜토리얼 스킵에 사용해야 해서 필요한 튜토리얼의 인덱스.. 아마 추가적으로 기획자분들이 얘기하는 것들에 따라 더 생길수도 있는데, 일단은 이정도로 마무리해두었다.

QuestCheck()

void AQuestManager::QuestCheck(int32 InQuestCode, bool bIs1P)
{
    // 항상 체크하는 퀘스트 확인
    AlwaysCheckQuestCheck(InQuestCode, bIs1P);

    FQuest& CurrentQuest = GetCurrentQuest();

    // 퀘스트 코드 안맞으면 Exit
    if (CurrentQuest.QuestCode != InQuestCode)
    {
        return;
    }

    // Count 증가
    if (bIs1P)
    {
        CurrentQuest.Count1P++;
    }
    else
    {
        CurrentQuest.Count2P++;
    }

    if (IsQuestClear())
    {
        UE_LOG(LogQuest, Warning, TEXT("-- Complete --"));

        // 퀘스트 완료 처리
        if (HasAuthority())
        {
            QuestComplete();
        }
        else
        {
            ServerRPCQuestComplete();
        }
    }
    else
    {
        UE_LOG(LogQuest, Warning, TEXT("-- Keep Going --"));

        if (HasAuthority())
        {
            ClientRPCAddCount(CurrentQuestIndex, CurrentQuest.Count1P);
        }
        else
        {
            ServerRPCAddCount(CurrentQuestIndex, CurrentQuest.Count2P);
        }
    }

    // 이펙트 설정
    if (HasAuthority())
    {
        if (GetCurrentQuest().Count1P >= GetCurrentQuest().GoalCount1P)
        {
            QuestEffect->QuestPingEffect->Deactivate();
        }
    }
    else
    {
        if (GetCurrentQuest().Count2P >= GetCurrentQuest().GoalCount2P)
        {
            QuestEffect->QuestPingEffect->Deactivate();
        }
    }

    // UI 변경
    SetQuestUI();

    UE_LOG(LogQuest, Warning, TEXT("[%s] Count 1P : %d / 2P : %d - Current Index %d"),
        *GetCurrentQuest().Title, GetCurrentQuest().Count1P, GetCurrentQuest().Count2P, CurrentQuestIndex);
}

게임 스테이트의 델리게이트에 바인딩되어있는 함수이다. 클라이언트와 서버 모두 호출되고 있고, 들어오는 퀘스트 코드에 따라 진행도만 증가시키거나 퀘스트 완료를 판정해준다.

void AQuestManager::AlwaysCheckQuestCheck(int32 InQuestCode, bool bIs1P)
{
    for (int i = 0; i < QuestList.Num(); i++)
    {
        checkf(QuestList.IsValidIndex(i), TEXT("Always Check List Index Error"));
        FQuest& AlwaysCheckQuest = QuestList[i];

        if (!AlwaysCheckQuest.bIsAlwaysChecking ||
            AlwaysCheckQuest.QuestCode != InQuestCode ||
            i == CurrentQuestIndex)
        {
            continue;
        }

        //---------------------------------------------------------------

        // Count 증가
        if (bIs1P)
        {
            AlwaysCheckQuest.Count1P++;
            ClientRPCAddCount(i, AlwaysCheckQuest.Count1P);
        }
        else if (!bIs1P)
        {
            AlwaysCheckQuest.Count2P++;
            ServerRPCAddCount(i, AlwaysCheckQuest.Count2P);
        }

        UE_LOG(LogQuest, Warning, TEXT("-- Always Check Quest -- Count 1P : %d / 2P : %d"),
            AlwaysCheckQuest.Count1P, AlwaysCheckQuest.Count2P);
    }
}

항상 체크해야 하는 퀘스트를 확인하는 함수. 조건문 처리를 해 해당되지 않는 퀘스트들은 바로바로 continue 시키고, 맞다면 진행도를 증가시킨다.

void AQuestManager::ServerRPCQuestComplete_Implementation()
{
    UE_LOG(LogQuest, Warning, TEXT("Server RPC Quest Complete"));

    QuestComplete();
}

void AQuestManager::ServerRPCAddCount_Implementation(int32 Index, int32 Count)
{
    QuestList[Index].Count2P = Count;
    SetQuestUI();
}

void AQuestManager::ClientRPCAddCount_Implementation(int32 Index, int32 Count)
{
    QuestList[Index].Count1P = Count;
    SetQuestUI();
}

AddCount() 함수는 상대방의 카운트를 받아 동기화해주는 작업을 한다.

QuestComplete()

void AQuestManager::QuestComplete()
{
    UE_LOG(LogQuest, Warning, TEXT("[%s] Quest Complete"), *GetCurrentQuest().Title);

    PlayQuestCompleteSound();

    // 정비시간으로 이동
    if (GetCurrentQuest().bMoveToMaintenance)
    {
        ATrapperGameMode* GameMode = GetWorld()->GetAuthGameMode<ATrapperGameMode>();
        GameMode->SetGameProgress(EGameProgress::Maintenance);
        GameMode->InitialItemSetting();

        UE_LOG(LogQuest, Warning, TEXT("Go Maintenance"));
    }

    // 마지막 퀘스트 클리어일 경우, 게임 클리어 판정
    if (CurrentQuestIndex == LastQuestIndex)
    {
        //MyOwner->SetGameProgress(EGameProgress::GameClear);
        UE_LOG(LogQuest, Warning, TEXT("Go GameClear"));
        return;
    }

    CurrentQuestIndex++;

    // 이미 클리어 했을 시 2초 뒤에 QuestComplete 호출
    if (IsQuestClear())
    {
        FTimerHandle TimerHandle;
        GetWorld()->GetTimerManager().SetTimer(TimerHandle, FTimerDelegate::CreateLambda([&]
            {
                GetCurrentQuest().bIsAlwaysChecking = false;
                QuestComplete();
            }
        ), 1.0f, false, 2.0f);
    }

    // 현재 퀘스트 액터 정리
    DestroyQuestActor();

    // 다음 퀘스트 액터 준비
    CreateQuestActor();

    // 둘다 서버만 변경함
    // 클라이언트 이펙트는 CurrentIndex의 OnRep 함수에서 변경
    SetQuestUI();
    SetQuestEffect();
}

void AQuestManager::OnRep_ChangeCurrentIndex()
{
    SetQuestEffect();
    SetQuestUI();
}

퀘스트가 완료되었을 때 서버에서 호출하는 함수. 퀘스트 완료음을 재생하고, 조건에 따라 게임 진행 상태를 진척시킨다. CurrentQuestIndex 를 리플리케이트 설정하여 인덱스가 바뀌었을 경우 클라이언트쪽에서 UI와 이펙트를 설정하도록 해주었다.

void AQuestManager::HandleQuestExceptions()
{
    switch (GetCurrentQuest().ExceptionCode)
    {
        // 찰코함정 활성화
        case 1 :
        {
            for (ABearTrap* BearTrap : TActorRange<ABearTrap>(GetWorld()))
            {
                BearTrap->MagneticTriggerControl(true);
            }
            break;
        }
        default:
        {
            break;
        }
    }

}

CreateQuestActor() 함수 마지막에 넣어준 예외처리 함수이다. 퀘스트 데이터를 읽어올 때 받아온 예외 코드를 스위치문으로 만들어 필요한 처리를 해줄 수 있도록 만들어두었다.

SkipTutorial()

void AQuestManager::SkipTutorial()
{
    CurrentQuestIndex = TutorialEndIndex;

    SetQuestUI();
    SetQuestEffect();

    DestroyQuestActor();

    for (ATutorialMonster* TutorialMonster : TActorRange<ATutorialMonster>(GetWorld()))
    {
        TutorialMonster->Teleport(TutorialMonster->StartPoint);
    }

    for (ABearTrap* BearTrap : TActorRange<ABearTrap>(GetWorld()))
    {
        BearTrap->DestroyHandle();
    }

    CreateQuestActor();
}

튜토리얼 스킵 함수를 호출했을 때, 현재 퀘스트 인덱스를 튜토리얼의 다음 퀘스트로 바꾸어준 뒤, 튜토리얼 퀘스트와 관련된 액터들을 정리해준다.

Set Effect & UI

void AQuestManager::SetQuestEffect()
{
    if (QuestEffect)
    {
        bool IsActive = false;
        if (GetCurrentQuest().EffectPosition != FVector::Zero())
        {
            IsActive = true;
        }

        QuestEffect->SetQuestEffect(IsActive, GetCurrentQuest().EffectPosition);
    }
}

void AQuestManager::SetQuestUI()
{
    FQuest CurrentQuest = GetCurrentQuest();
    FString Description = CurrentQuest.Description;

    if (CurrentQuest.TotalGoalCount > 1)
    {
        uint8 TotalGoal = CurrentQuest.Count1P + CurrentQuest.Count2P;
        Description += TEXT("(") + FString::FromInt(TotalGoal) + TEXT(" / ") +
            FString::FromInt(CurrentQuest.TotalGoalCount) + TEXT(")");
    }

    for (ATrapperPlayerController* PlayerController : TActorRange<ATrapperPlayerController>(GetWorld()))
    {
        PlayerController->SetQuestInfo(CurrentQuest.Title, Description);
    }
}

이펙트와 UI를 설정해주는 코드이다. 기존의 코드를 거의 그대로 사용한다 :)

이제 둘이서 클리어해야 하는 퀘스트더라도, 각각 완료된 상황을 파악해 이펙트를 꺼주거나 하는 등의 처리가 가능해졌다. 예외처리도 할 수 있게 되었고, 네트워크를 통하지 않고 UI와 이펙트를 로컬로 처리하게 되었다(가장 큰 목표..). 얼마나 효율적으로 코드를 개선했는지는 확실치 않지만, 확장에는 조금 더 유연한 구조가 되었길 기도해본다.

이제 시퀀스 매니저와 스크립트 매니저를 만들고, 게임 모드 - 게임 스테이트 - 퀘스트 매니저 - 시퀀스 매니저 - 스크립트 매니저간에 서로 얽히어 있는 이벤트들을 처리하며 메타루프를 완성해나가기로 했다.

지금 게임의 진행 단계 & 퀘스트 & 스크립트 & 시네마틱이 맞물려 돌아가고 있어서 너무 서로에 대한 의존도가 높다. 이걸 어떻게 관리해야 할까..

게임의 단계, 시네마틱 영상, 스크립트, 카메라 무빙 등 퀘스트의 진행 단계에 따라 트리거되는 것들이 많다. 따라서, 가장 먼저 퀘스트 시스템을 개편하려고 한다.

지금은 퀘스트 매니저가 게임모드에서 생성되고 있는데, 서브시스템으로 만들어 퀘스트를 관리하도록 해보려고 한다. 이 친구는 각 퀘스트에 맞게끔 액터를 생성해주는 역할도 할 것이고, 시네마틱이나 카메라 연출을 재생시켜주기도 할 것이다.

코드를 짜봐야 알겠지만, 대충 이런 느낌의 구조가 나올 것 같다. 시네마틱과 스크립트, 카메라 이벤트들은 퀘스트 매니저와 게임 모드의 명령을 받고 재생만 하고, 게임 모드와 퀘스트 매니저는 서로의 함수를 호출해야 할 듯.

퀘스트 서브시스템 생성

먼저, 레벨과 같은 생명주기로 돌아가는 UWorldSubsystem 을 상속받아 QuestSubSystem 클래스를 만들어주었다.

DECLARE_MULTICAST_DELEGATE_OneParam(FOnQuestExecute, int32)

UCLASS()
class TRAPPERPROJECT_API UQuestSubsystem : public UWorldSubsystem
{
    GENERATED_BODY()

public:
    UQuestSubsystem();

public:
    virtual void OnWorldBeginPlay(UWorld& InWorld) override;

    TObjectPtr<class UDataTable> QuestData;
    void AddQuest();

    TArray<FQuest> QuestList;
    int32 CurrentQuestIndex = 0;
    FQuest GetCurrentQuest();

    FOnQuestExecute OnQuestExecute;
    void QuestCheck(int32 InQuestCode);
    void QuestComplete();

    TArray<TObjectPtr<class AInteract>> QuestActorBox;
    void ActiveQuestActor(int32 QuestID);

    TObjectPtr<class AQuestEffect> QuestEffect;
    void SetQuestUI(FString Title, FString Contents);
};

기존 게임모드, 퀘스트 매니저에서 관리하던 퀘스트와 관련된 변수와 함수의 선언부를 옮겨주었다. 구현부는 변경해야 하므로, 조금 이따가 이어서 진행하도록 하겠다!

퀘스트 구조체 개선

기존의 퀘스트는 서버가 모두 관리했고, 클라이언트는 퀘스트의 정보를 갖고있지 않은채로 서버에서 데이터를 받아 UI만 갱신하는 식으로 관리했었다. 따라서 한명이 퀘스트를 완료해도 누가 완료했는지 알 수 없는 문제가 있었다. 클라이언트쪽에서 퀘스트를 완료했다면 클라이언트쪽에서 UI나 이펙트 등으로 표시해주기로 했는데, 그러기 위해서는 먼저 퀘스트 구조체를 변경해야 한다.

겸사겸사 아이템 획득처럼 현재 퀘스트가 진행중이 아니더라도 체크해야 하는 것들도 하드코딩 해놨던 것들을 자동화 시켜보기로 했다. 또한, 퀘스트를 진행할 때 퀘스트와 관련된 액터들을 미리 배치해두는 것이 아니라 필요할 때마다 생성하도록 바꾸기 위해 퀘스트 액터 데이터 테이블을 만들고, 그 데이터 테이블을 참조하여 액터를 생성하도록 퀘스트 구조체가 생성해야 할 데이터 테이블의 번호를 갖고있도록 바꿔줄 것이다.

// 변경한 퀘스트 구조체

USTRUCT()
struct FQuest
{
    GENERATED_USTRUCT_BODY()

public:
    FQuest() {}
    void Initialize(EQuestType InQuestType, FString InTitle, FString InDescription, int32 InQuestCode, int32 InGoalCount, FVector InPingPosition);

    // 퀘스트 종류
    EQuestType QuestType;

    // 퀘스트 코드
    int32 QuestCode;

    // 제목 & 설명
    FString Title;
    FString Description;

    // 해야하는 행동의 횟수
    int32 Count = 0;
    int32 GoalCount = 0;

    // 퀘스트를 진행중이 아닐때도 체크해야할 때
    uint8 bIsAlwaysChecking : 1 = false;

    // 퀘스트 완료 확인
    uint8 bUserComplete : 1 = false;
    uint8 bTeamComplete : 1 = false;

    // 활성화해야 할 액터 코드
    TArray<int32> QuestActorCode;

    // 퀘스트 이펙트 위치
    FVector EffectPosition = FVector();
};

// 데이터 테이블용 구조체

USTRUCT()
struct FQuestInfo : public FTableRowBase
{
    GENERATED_USTRUCT_BODY()

public:
    UPROPERTY(EditAnywhere, BlueprintReadWrite) EQuestType QuestType;

    UPROPERTY(EditAnywhere, BlueprintReadWrite) FString Title;
    UPROPERTY(EditAnywhere, BlueprintReadWrite) FString Description;

    UPROPERTY(EditAnywhere, BlueprintReadWrite) int32 GoalCount;
    UPROPERTY(EditAnywhere, BlueprintReadWrite) uint8 bIsAlwaysChecking : 1;

    UPROPERTY(EditAnywhere, BlueprintReadWrite) TArray<int32> QuestActorCode;
    UPROPERTY(EditAnywhere, BlueprintReadWrite) FVector EffectPosition;

    UPROPERTY(EditAnywhere, BlueprintReadWrite) FString Memo;
};

퀘스트 액터 데이터 테이블 생성

USTRUCT()
struct FQuestActorInfo : public FTableRowBase
{
    GENERATED_USTRUCT_BODY()

public:
    UPROPERTY(EditAnywhere, BlueprintReadWrite)
    TSubclassOf<class AActor> QuestActor;

    UPROPERTY(EditAnywhere, BlueprintReadWrite)
    FVector Position;

    UPROPERTY(EditAnywhere, BlueprintReadWrite)
    FRotator Rotation;

    UPROPERTY(EditAnywhere, BlueprintReadWrite)
    FVector Scale;
};

생성할 액터를 넣어두는 테이블을 만들어 준 뒤, 기존 퀘스트에 필요했던 액터들을 테이블에 데이터로 옮겨주었다.

퀘스트에 해당하는 액터 생성

void UQuestSubsystem::Initialize(FSubsystemCollectionBase& Collection)
{
    Super::Initialize(Collection);

    FString QuestTablePath = TEXT("/Script/Engine.DataTable'/Game/Blueprints/Data/DT_QuestData.DT_QuestData'");
    UDataTable* QuestTable = LoadObject<UDataTable>(nullptr, *QuestTablePath);
    if (QuestTable)
    {
        QuestData = QuestTable;
    }

    UDataTable* QuestActorTable = LoadObject<UDataTable>(nullptr, TEXT("/Script/Engine.DataTable'/Game/Blueprints/Data/DT_QuestActorData.DT_QuestActorData'"));
    if (QuestActorTable)
    {
        QuestActorData = QuestActorTable;
    }
}

서브시스템의 Initialize 함수를 오버라이드 한 뒤, 퀘스트 테이블과 퀘스트 액터 테이블을 받아왔다.

void UQuestSubsystem::OnWorldBeginPlay(UWorld& InWorld)
{
    OnQuestExecute.AddUObject(this, &UQuestSubsystem::QuestCheck);

    if (QuestData)
    {
        // 리스트에 퀘스트 추가
        AddQuest();
    }

    // 테스트용 -----------------------------------
    if (QuestActorData)
    {
        // 퀘스트 액터 생성
        CreateQuestActor();
    }

}

void UQuestSubsystem::AddQuest()
{
    for (int i = 1; i <= QuestData->GetRowMap().Num(); i++)
    {
        FQuestInfo* Data = QuestData->FindRow<FQuestInfo>(*FString::FromInt(i), FString());

        FQuest Quest;
        Quest.Initialize(Data->QuestType, Data->Title, Data->Description, Data->QuestActorCode, Data->GoalCount, Data->EffectPosition);
        QuestList.Add(Quest);

        if (Data->bIsAlwaysChecking)
        {
            AlwaysCheckQuestList.Add(&QuestList.Last());
        }
    }
}

AddQuest 함수는 바뀐 퀘스트의 구조체에 맞게 초기화하도록 바꿔주었고, bIsAlwaysChecking 변수가 true일 경우 AlwaysCheckQuestList 에 추가로 저장해주었다. AlwaysCheckQuestList 는, QuestList 안에 들어가 있는 퀘스트 구조체의 주소를 저장하는 배열이다.

void UQuestSubsystem::CreateQuestActor()
{
    // 서버가 아니면 return
    ENetMode NetMode = GetWorld()->GetNetMode();
    if (NetMode != NM_ListenServer)
    {
        return;
    }

    // 현재 액터에서 생성해야 할 액터 코드
    TArray<int32> CurrentQuestActorCode = GetCurrentQuest().QuestActorCode;

    // 액터 생성
    for (auto Code : CurrentQuestActorCode)
    {
        FQuestActorInfo* Data = QuestActorData->FindRow<FQuestActorInfo>(*FString::FromInt(Code), FString());

        FTransform QuestActorTransform;
        QuestActorTransform.SetLocation(Data->Position);
        QuestActorTransform.SetRotation(FQuat::MakeFromRotator(Data->Rotation));
        QuestActorTransform.SetScale3D(Data->Scale);

        QuestActorBox.Add(GetWorldRef().SpawnActor(Data->QuestActor, &QuestActorTransform));
    }

    //UE_LOG(LogTemp, Warning, TEXT("Create Quest Actor"));
}

액터는 서버에서만 생성하도록 해주었다. 현재 퀘스트 데이터의 생성해야 할 액터 코드를 가져온 뒤, 퀘스트 액터 데이터 테이블에서 클래스를 받아와 생성해주는 코드이다. 생성한 뒤에는 따로 선언해준 QuestActorBox에 넣어준다.

테스트를 위해 투명벽에 텍스트 렌더러를 따로 넣어주었다. 서버와 클라이언트 모두 첫번째 퀘스트에서 생성해주어야 하는 1, 2, 7번째 투명벽들을 잘 생성해준 모습을 볼 수 있다.

퀘스트 체크 및 판정처리

서브시스템은 RPC나 리플리케이트가 안되는 것 같다. 따라서, 기존의 퀘스트 매니저를 서브시스템에서 생성해 가지고 있도록 하고, 퀘스트 매니저를 이용해 네트워킹을 진행해보려고 한다.

어차피 게임 인스턴스를 통해 서브시스템을 찾아서 쓰기 때문에, 기존에 사용하던 델리게이트는 삭제해주었다.

void UQuestSubsystem::QuestCheck(int32 InQuestCode)
{
    // 항상 체크하는 퀘스트들
    for (auto AlwaysCheckQuest : AlwaysCheckQuestList)
    {
        // 이미 완료한 상태라면 Exit
        if (AlwaysCheckQuest->bUserComplete)
        {
            break;
        }

        // 퀘스트 코드가 같다면 Count 증가
        if (AlwaysCheckQuest->QuestCode == InQuestCode)
        {
            AlwaysCheckQuest->Count++;
        }

        // 목표 Count보다 높거나 같아졌다면
        if (AlwaysCheckQuest->Count >= AlwaysCheckQuest->GoalCount)
        {
            AlwaysCheckQuest->bUserComplete = true;

            // 퀘스트 완료 서버 처리
        }
    }

    FQuest& CurrentQuest = GetCurrentQuest();

    // 현재 퀘스트를 완료한 상태가 아니고 퀘스트 코드가 같다면 Count 증가
    if (!CurrentQuest.bUserComplete && CurrentQuest.QuestCode == InQuestCode)
    {
        CurrentQuest.Count++;
    }

    // 목표 Count보다 높거나 같아졌다면
    if (CurrentQuest.Count >= CurrentQuest.GoalCount)
    {
        CurrentQuest.bUserComplete = true;

        // 퀘스트 완료 처리
        ENetMode NetMode = GetWorld()->GetNetMode();

        // 서버이고, 팀도 클리어 했을 경우 퀘스트 완료판정
        if (NetMode == NM_ListenServer)
        {
            if (CurrentQuest.bTeamComplete)
            {
                QuestComplete();
            }
            else
            {
                // 클라이언트에게 완료 알리기
            }
        }
        else
        {
            // 서버에게 완료 알리기
        }
    }

    // UI 변경
    SetQuestUI();
}

void UQuestSubsystem::QuestComplete()
{
    PlayQuestCompleteSound();

    // 정비시간으로 이동
    if (CurrentQuestIndex == MoveMaintenanceQuestIndex)
    {
        //MyOwner->SetGameProgress(EGameProgress::Maintenance);
        //MyOwner->InitialItemSetting();
        // 서버와 클라이언트 모두 UI / 이펙트 OFF
        return;
    }

    CurrentQuestIndex++;

    // 마지막 퀘스트 클리어일 경우, 게임 클리어 판정
    if (CurrentQuestIndex == LastQuestIndex)
    {
        //MyOwner->SetGameProgress(EGameProgress::GameClear);
        return;
    }

    FQuest& NewQuest = GetCurrentQuest();

    // 이미 클리어 했을 시 2초 뒤에 QuestComplete 호출
    if (NewQuest.bUserComplete && NewQuest.bTeamComplete)
    {
        FTimerHandle TimerHandle;
        GetWorld()->GetTimerManager().SetTimer(TimerHandle, FTimerDelegate::CreateLambda([&]
            {
                QuestComplete();
            }
        ), 1.0f, false, 2.0f);
    }

    // 현재 퀘스트 액터 정리
    DestroyQuestActor();

    // 다음 퀘스트 액터 준비
    CreateQuestActor();

    // 서버와 클라이언트 모두 UI / 이펙트 변경 처리
}

주석으로 예쁘게 설명했으므로 설명은 생략(...) 중간중간 주석이 대체하고 있는 것들은 다른 것들 먼저 구현해놓고 하나씩 채워나갈 예정이다. 옮기다보니 치명적인 버그가 있던걸 확인했는데.... 지금까지 빌드에서는 너무 의도대로 잘 작동해서 몰랐다. 이렇게라도 발견해서 너무 다행이야,, ㅜㅜ

퀘스트 액터 수정

이제 새로 짠 로직에 맞게 기존에 만들어두었던 AInteract 관련 액터들을 수정해주어야 한다.

원래는 Interact 액터에서 두 캐릭터 모두 상호작용을 완료했는지 판정하고 퀘스트 완료처리를 해주었다. 이제는 퀘스트 액터들이 로컬 플레이어의 퀘스트 완료 여부만 처리하고, 퀘스트 서브시스템에서 두 플레이어가 모두 완료했는지 확인 후 퀘스트 완료판정을 내리도록 바꿔줄 것이다.

AInteract

UCLASS()
class TRAPPERPROJECT_API AInteract : public AActor
{
    GENERATED_BODY()

public:    
    // Sets default values for this actor's properties
    AInteract();

protected:
    // Called when the game starts or when spawned
    virtual void BeginPlay() override;

public:    
    // Called every frame
    virtual void Tick(float DeltaTime) override;
    virtual void CheckActivate(int32 Value);

protected:
    uint8 bPlayerActive : 1;
};

void AInteract::CheckActivate(int32 Value)
{
    if(bPlayerActive) return;

    UQuestSubsystem* QuestSubSystem = GetWorld()->GetSubsystem<UQuestSubsystem>();
    QuestSubSystem->QuestCheck(Value);
    bPlayerActive = true;
}

CheckActivate 함수와 bPlayerActive 변수를 제외하고 모두 삭제했다.

void ATrapperPlayer::FClickStarted(const FInputActionValue& Value)
{
    if (!IsLocallyControlled()) return;

    // 라인 트레이싱 부분 생략...

    if (HasHit)
    {
        AInteract* InteractActor = Cast<AInteract>(HitResult.GetActor());
        if (!InteractActor) return;

        if (HasAuthority())
        {
            MulticastRPCPlayInstallAnim();
        }
        else
        {
            InteractActor->CheckActivate(30);
            ServerRPCPlayInstallAnim();
        }
    }
}

플레이어에서 해당 액터에 상호작용 했을 때, 서버일 경우 애니메이션만 재생해주고 클라이언트에서 퀘스트 완료 판정 처리를 해줬다.

AMoveQuestTriggerBox

UPROPERTY(EditDefaultsOnly, BlueprintReadOnly)
uint8 bCheckMagneticMoving : 1;

void AMoveQuestTriggerBox::NotifyActorBeginOverlap(AActor* OtherActor)
{
    Super::NotifyActorBeginOverlap(OtherActor);

    ATrapperPlayer* Player = Cast<ATrapperPlayer>(OtherActor);
    if (!Player || !Player->IsLocallyControlled()) return;

    if (!bPlayerInTriggerTutorial)
    {
        // 트리거 발동 확인 코드
        CheckActivate(1);
    }
    else
    {
        // 자성 이동 확인해서 트리거 발동
        if (Player->Movement->GetMagneticMovingState())
        {
            CheckActivate(2);
        }
    }
}

bCheckMagneticMoving 변수만 남겨놓았다. 이 변수를 사용해 자성이동 트리거와 일반 접근 트리거로 나누어줬다.

퀘스트 액터 블루프린트 생성

기존에는 Tower가 AInteractive를 상속받아 동작하도록 했지만, 이제 타워 위에 상호작용 박스를 생성하여 상호작용이 동작하도록 만들어줄 것이다. 자성이동용 트리거 박스도 만들어주어야 한다.

Interact 콜리전 채널만 Block해준 상호작용 박스를 만들고,

기존 이동 트리거 박스를 복제해 자성이동을 체크하도록 만들어주었다.

다 만든뒤 데이터 테이블에 수정된 것들을 모두 반영해줬다.

이틀동안은 구조를 고민하고, 큰 그림을 그려두었다. 아직 많이 부족하긴 하지만, 내일부터는 네트워크부터 해서 점차적으로 디테일한 부분들을 바꿔나가야겠다.

트래퍼에는 이렇게 땅, 물, 콘크리트 세 종류의 바닥 재질이 있다. 재질별로 발소리를 다르게 해줘야 했다. 밑의 유튜브에서 설명이 잘 되어 있어서, 따라가며 작업했다. 나중에 또 필요할 때를 대비해 여기에 정리해두겠다 :)

https://youtu.be/TzGqRIioBbY?si=KrwM0WA1dYWcbWyO

먼저 해당하는 사운드 큐를 만들어줘야한다.

모든 사운드 큐는 내부적으로 여러개의 사운드를 랜덤으로 재생한다.

사용할 사운드 큐를 모두 만들었다면, 프로젝트 세팅의 Engine - Physics - Physics Surface 로 이동해 이름을 지어주면 된다. 나는 세개를 사용할 것이므로, Ground / Water / Concrete 이렇게 사용해주었다.

이제 피직스 머테리얼을 만들어주자. 각각 머테리얼마다 아까 만들어준 Surface Type을 설정해주면 된다.

레벨에 배치된 캐릭터가 걸어다닐 액터들을 선택하고 방금 만들어준 피직스 머테리얼을 설정해주었다.

발소리는 몽타주 내에서 이벤트로 처리해줄 것이기 때문에, AnimNotify를 상속받은 블루프린트를 만들어주자.

Override - Received Notify를 선택해주면, 이제 노드를 구현할 차례이다.

먼저 Mesh Comp에서 Owner를 받아와준 뒤, 액터의 로케이션을 가져와 새로운 벡터를 만들어 줘야한다. Z값에 캐릭터로부터 캐릭터가 밟고있는 지면까지 레이를 쏠 수 있도록 적당한 값을 빼주면 되는데, 나는 캐릭터의 캡슐 컴포넌트를 가져와 빼주고 추가로 작은 값을 더 빼주었다. 만약 소리가 나지 않는다면 디버그 라인을 사용해 지면에 레이가 정확히 히트되는지 파악해보는걸 추천 :)

라인 트레이스의 Start에 액터의 위치를 넣어주고, End에는 방금 만들어준 벡터를 연결해주자. 여기서 캐릭터를 Actors to Ignore에 추가해주는게 중요하다. 이걸 해주지 않으면,

라인 트레이스에서 캐릭터를 판정해버려 그냥 디폴트로 설정한 소리가 나게 된다.

Actors to Ignore 배열을 정확히 지정해주면 이렇게 바닥에 잘 히트되는 것을 볼 수 있음!

이제 Branch를 통해 히트한 결과가 있다면 사운드 재생, 없다면 리턴해주면 된다.

Out Hit에서 Surface Type을 받아와 Select 노드의 인덱스로 넣어주고, 종류에 따라 사운드를 처리해주면 된다. Spawn Attached 노드의 Location에는 히트한 위치를 넣어주고, Sound에는 방금 Select에서 리턴된 값을 넣어주면 된다.

사실 로직 자체가 간단해서 C++로 구현해볼까 했지만.. 귀찮았다..ㅎㅎ 언젠가 시간이 있으면 바꿔보는걸로..

이제 애니메이션 시퀀스나 몽타주에 내가 만든 블루프린트를 노티파이로 추가해주면 끝!

물 발소리가 나지 않는 현상 해결

왜인지 모르겠지만.. 나는 다 적용하고 나서도 캐릭터가 걸을 때 물 발자국 소리가 나질 않고, 땅 발자국 소리만 계속 났다. 라인으로 디버그를 찍어봐도 물쪽에 Hit 처리가 안되는걸 보니 콜리전 채널이 문제인가 싶었는데, 라인트레이스 채널을 Block으로 바꿔줘도 같은 현상이 일어났었다. 이것저것 옵션을 바꿔봐도 해결이 안되어서, 일단은 피직스 볼륨을 사용해 예외적으로 처리해주었다.

피직스 볼륨을 물이 있는 쪽에 넓게 깔아주면 정상적으로 트레이스되며 물 발소리가 재생된다. 땅 재질보다 살짝 낮게 깔아두어서 땅 위로 올라가면 정상적으로 땅 발소리가 재생된다!

배경음악 재생하기

우리 게임은 레벨마다 배경음악이 다르므로, 레벨이 배경음악 재생을 맡도록 했다.

C++ 코드에서 배경음악 재생을 명령할 것이므로, LevelScriptActor를 상속받은 TrapperScriptActor를 하나 만들어주었다.

UCLASS()
class TRAPPERPROJECT_API ATrapperScriptActor : public ALevelScriptActor
{
    GENERATED_BODY()

public:
    UFUNCTION(BlueprintImplementableEvent)
    void ChangeBackgroundSound(float FadeOutTime);

    virtual void BeginPlay() override;
};

void ATrapperScriptActor::BeginPlay()
{
    Super::BeginPlay();

    ChangeBackgroundSound(0.f);
}

BlueprintImplementableEvent 로 함수를 하나 만들어주었고, BeginPlay 함수에서는 맨 처음 배경음악을 재생하기 위해 해당 함수를 호출해주었다.

트래퍼 레벨의 Parent Class를 방금 만든 TrapperScriptActor로 지정해주고,

받은 FadeOutTime 값에 따라 Fade Out을 진행,

레벨에서 재생을 담당할 오디오 컴포넌트를 가진 BGM Manager 액터를 하나 만들어 준 뒤 타겟으로 넣어주었다.

지정한 시간이 끝난 뒤에 Change BGM 함수를 실행한다.

게임 스테이트를 캐스팅한 후, 현재 Game Progress를 가져와 해당 모드에 따라 BGM을 골라서 재생하도록 만들어주었다. (이거때문에 게임모드에 있던 Current Game Progress 변수를 Game State로 옮기는 과정도 거쳤다. 언제 다 옮기지.. 번거로우니까 포스팅에서는 생략하겠다)

void ATrapperGameMode::SetGameProgress(EGameProgress Progress)
{
    EGameProgress PreviousProgress = TrapperGameState->CurrentGameProgress;

    if (PreviousProgress != Progress)
    {
        TrapperGameState->CurrentGameProgress = Progress;
        TrapperGameState->OnRep_GameProgressSetting();
    }

// 생략...

void ATrapperGameState::OnRep_GameProgressSetting()
{
    UE_LOG(LogTemp, Warning, TEXT("Change Background"));

    ALevelScriptActor* LevelScriptActor = GetWorld()->GetLevelScriptActor();
    ATrapperScriptActor* MyLevelScriptActor = Cast<ATrapperScriptActor>(LevelScriptActor);
    if (MyLevelScriptActor)
    {
        MyLevelScriptActor->ChangeBackgroundSound(3.f);
    }
}

CurrentGameProgress가 바뀔때마다 ChangeBackgroundSound 함수를 호출하도록 해주었다. OnRep 함수로 지정했기 때문에, 클라이언트에서도 잘 적용된다.

효과음 적용

캐릭터와 관련된 효과음들은 애니메이션 시퀀스나 몽타주에서 간단하게 설정할 수 있으므로, 캐릭터의 목소리, 점프, 솔루나 시프트 등 여러가지를 적용해주었다.

기존 자성 기둥에 아웃라인 효과가 있으므로 똑같이 적용만 하면 될거라고 생각했지만, 아웃라인 굵기와 색상을 따로 지정해줘야하고 자성기둥과 달리 플레이어는 다른 액터들이 플레이어를 가리더라도 아웃라인이 표시되어야 했다.

아웃라인 굵기, 색상 설정하기

스탠실 값을 사용하여 아웃라인의 설정을 바꿔주기로 했다.

먼저 프로젝트 세팅에서 Enabled with Stencil로 옵션을 바꿔주고, Mesh의 CustomDepth Stencil Value를 설정해주었다.

if (IsLocallyControlled())
{
    GetMesh()->SetRenderCustomDepth(false);
}

플레이어는 2, 자성기둥은 0으로 설정한 뒤, 플레이어의 BeginPlay 함수에서 로컬플레이어만 RenderCustomDepth 설정을 false로 바꿔주자.

커스텀 스텐실 값은 SceneTexture의 CustomStencil을 선택해 R값으로 마스킹하여 가져올 수 있다. Named Reroutes(이름 경유) 노드를 만들어 어디서든 꺼내쓰기 쉽게끔 만들어주자.

기존 아웃라인의 굵기를 설정하는 곳을 If문을 사용해 이렇게 바꿔주었다. 스텐실 값이 1보다 크다면 자성기둥의 굵기 변수를 사용하도록 하고, 1보다 작다면 캐릭터의 굵기 변수를 사용하도록 했다.

마찬가지로 굵기와 같은 로직을 사용하여 자성 기둥에는 빨간색, 캐릭터는 파란색이 보이도록 해주었다. A==B 에 연결된 Scene Texture 노드는 곧 설명하도록 하겠음!

그럼 스텐실 값에 따라 이렇게 다른 색상과 굵기를 가질 수 있게 된다.

물체 뒤에서도 아웃라인 보이게 하기

우리 게임에서 자성 기둥은 다른 물체에 가렸을 때 아웃라인이 보이지 않아야 하지만, 플레이어는 벽 뒤에 있어도 아웃라인이 보여야 한다. 위의 gif를 보면 자성기둥과 같이 앞의 물체에 의해 가려지는 것을 볼 수 있음.

기존에 사용하고 있던 씬 뎁스와 커스텀 뎁스를 사용해 앞에 물체가 있으면 아웃라인을 그리지 않는 부분을 Occulusion이라는 이름 경유 노드로 만들어 준 뒤,

스탠실 값에 따라 처리되도록 만들어주었다.

이렇게 물체 뒤에서도 잘 보이게 됐다.

로컬 플레이어는 아웃라인이 뚫지 못하게 만들기

뭔가 술술 잘 풀린다고 생각했지만.. (내 기준)치명적인 문제가 하나 있었다.

로컬 플레이어를 뚫고 그려버린다는 것.... 몬스터나 물체를 뚫는거야 기획상에서 당연히 해야되는 것이었지만.. 어떤 게임에서 캐릭터를 저렇게 처리할까?

어떤 물체에 가려졌을 때만 뜬다면 굳이 처리할 필요 없겠지만, 아웃라인이 '항상' 떠있도록 요청하셨기에 무조건 잡아야한다고 생각했다.

이것때문에 장장 몇시간을 서칭했는데도 별다른 방법을 찾지 못했다. 이것저것 따라해보고 방법도 고민해보고 하다가, 아까 로컬플레이어를 SetRenderCustomDepth(false) 로 바꿔줬던걸 이것저것 건들여보는김에 이걸 true로 켜봤다.

흠.... 상대방 아웃라인이 안뚫리네?? 그럼 커스텀 뎁스를 켜둔 상태에서 아웃라인을 안그리면 되지 않을까...?

if (IsLocallyControlled())
{
    GetMesh()->SetCustomDepthStencilValue(1);
}

플레이어의 BeginPlay에서 로컬 플레이어만 스텐실 값을 1로 바꿔주고,

스텐실 값이 1일 경우에는 씬 텍스쳐를 그대로 그리도록 넣어줬다.

엇... 이게 되네...??? 생각보다 꽤 잘 되길래 놀랬다.

기획 / 아트분들께 전달

아무래도 이부분은 아트와 기획쪽에서 건들여보고 값을 지정하는게 좋을 것 같아서, 외부에서 접근해 굵기와 색상을 바꿀 수 있도록 해두고 전달드렸다 :)

항상 제일 오래걸리는 위젯 만들기.. 너무너무 어렵다.. 이번에도 어떻게 얼레벌레 만들어냈는데, 나중에 위젯 관련된 강의가 없는지 찾아봐야겠다. 알고 만들고 싶어..

아무튼, 이번에는 기존에 만들어두었던 안내창의 Vertical Layout에 SizeBox를 추가하고 자식으로 Overlay를 추가한 뒤, 이미지와 텍스트, Radial Slider를 사용해 UI를 제작해주었다.

1P에 해당하는 붉은색 바는 Value가 증가하면 시계방향으로 차도록 설정해주었고,

2P에 해당하는 파란색 바는 Value가 감소하면 차도록 설정해주었다. 이렇게 구현한 이유는 별거없다.. 아무리 옵션을 이것저것 만져봐도 반시계 방향으로 차오르는걸 구현할 수가 없어서.. ㅎㅎ

스킵이 가능할 때만 보여져야 하므로, 가장 최상위 패널인 SizeBox와 Value를 조작해야 하는 Radial Slider 두개만 변수로 승격해주었다.

구현

스킵 기능 구현

기존에는 F키가 신전 상호작용에만 한번 누르는 정도로만 사용하고 있었어서, Input Action을 변경해주었다.

Trigger는 Hold And Release로, Hold Time Threshold는 2.0초로 해주자. (Threshold에 지정한 시간이 지나야 Complete 처리가 된다!)

// ATrapperPlayer.h

void FClickStarted(const FInputActionValue& Value);
void FClickOngoing(const FInputActionValue& Value);
void FClickCanceled(const FInputActionValue& Value);
void FClickCompleted(const FInputActionValue& Value);

UPROPERTY(ReplicatedUsing = OnRep_SkipGauge)
float SkipGauge;

float SkipAccumulatelTime;
float SkipTime = 2.f;

UFUNCTION() void OnRep_SkipGauge();

void CalculateSkipGauge();
bool SkipCurrentStage();

UFUNCTION(Server, Unreliable)
void ServerRPCSkipGaugeChange(float Value);

UFUNCTION(Server, Reliable)
void ServerRPCSkip();

스킵 기능을 위해 추가로 구현한 함수와 변수들이다. 막상 이렇게 적어두니 뭔가 엄청 많아보이네(..)

UIC->BindAction(FClickAction, ETriggerEvent::Started, this, &ATrapperPlayer::FClickStarted);
UIC->BindAction(FClickAction, ETriggerEvent::Ongoing, this, &ATrapperPlayer::FClickOngoing);
UIC->BindAction(FClickAction, ETriggerEvent::Canceled, this, &ATrapperPlayer::FClickCanceled);
UIC->BindAction(FClickAction, ETriggerEvent::Completed, this, &ATrapperPlayer::FClickCompleted);

먼저, 트리거 이벤트에 맞추어 만든 함수들을 바인딩해주었다. 처음에 눌렀을 때, 누르고 있을 때, 누르다 뗐을 때 성공했을 경우와 실패했을 경우 이렇게 네가지 조건이 필요했다.

void ATrapperPlayer::FClickStarted(const FInputActionValue& Value)
{
    if (!IsLocallyControlled()) return;

    if (SkipGauge >= 1.f)
    {
        if (HasAuthority())
        {
            SkipGauge = 0.f;
            OnRep_SkipGauge();
        }
        else
        {
            ServerRPCSkipGaugeChange(0.f);
        }
    }

    // 생략..
}

F키를 처음 눌렀을 때 실행되는 함수인 FClickStarted 에서는, 스킵판정 처리가 난 후 F키를 한번 더 누르면 초기화해주는 코드를 넣어두었다.

void ATrapperPlayer::ServerRPCSkipGaugeChange_Implementation(float Value)
{
    SkipGauge = Value;
    OnRep_SkipGauge();
}

서버에서 바뀌는건 게이지 값이 리플리케이트되고 있지만, 클라이언트에서 바뀌는 값은 서버에서 알 수 없으므로 Server RPC를 통해 변경해준다.

void ATrapperPlayer::FClickOngoing(const FInputActionValue& Value)
{
    SkipAccumulatelTime += GetWorld()->GetDeltaSeconds();
    float Gauge = SkipAccumulatelTime / SkipTime;
    Gauge = FMath::Clamp(Gauge, Gauge, 1);

    if (HasAuthority())
    {
        SkipGauge = Gauge;
        OnRep_SkipGauge();
    }
    else
    {
        ServerRPCSkipGaugeChange(Gauge);
    }
}

F키가 눌린 상태에서 호출되는 FClickOngoing 함수에서는 SkipAccumulatelTime 변수에 델타타임을 누적해주고, UI 게이지를 계산해 SkipGauge 변수에 넣어준다. SkipTime은 스킵 판정이 이루어지기까지 필요로 하는 시간이며, 지금은 기획자분들이 지정해두신 2.0초를 사용하고 있다. UI에 넣어주어야 하는 값이기 때문에, 누적된 시간 값을 0~1 사이로 노말라이징해 사용하고 있다.

void ATrapperPlayer::FClickCanceled(const FInputActionValue& Value)
{
    SkipAccumulatelTime = 0.f;

    if (HasAuthority())
    {
        SkipGauge = 0.f;
        OnRep_SkipGauge();
    }
    else
    {
        ServerRPCSkipGaugeChange(0.f);
    }
}

버튼을 누르고 2초가 지나지 않고 뗐을 경우 호출되는 함수이다. SkipAccumulatelTime 변수를 초기화해주고, 게이지를 0으로 되돌린다.

void ATrapperPlayer::FClickCompleted(const FInputActionValue& Value)
{
    SkipAccumulatelTime = 0.f;

    if (HasAuthority())
    {
        SkipGauge = 1.f;

        if (SkipCurrentStage())
        {
            SkipGauge = 0.f;
        }

        OnRep_SkipGauge();
    }
    else
    {
        ServerRPCSkip();
    }
}

void ATrapperPlayer::ServerRPCSkip_Implementation()
{
    SkipCurrentStage();
}

2초가 지난 후 버튼을 떼면 스킵이 가능한 상태가 된다. 게이지 값을 1로 고정시킨다.

bool ATrapperPlayer::SkipCurrentStage()
{
    TArray<AActor*> OutActors;
    UGameplayStatics::GetAllActorsOfClass(GetWorld(), ATrapperPlayer::StaticClass(), OutActors);

    ATrapperPlayer* FirstPlayer = nullptr;
    ATrapperPlayer* SecondPlayer = nullptr;

    for (const auto& Pawn : OutActors)
    {
        ATrapperPlayer* TrapperPlayer = Cast<ATrapperPlayer>(Pawn);
        if (!TrapperPlayer) continue;

        if (TrapperPlayer->IsLocallyControlled())
        {
            FirstPlayer = TrapperPlayer;
        }
        else
        {    
            SecondPlayer = TrapperPlayer;
        }
    }

    if(!IsValid(FirstPlayer) || !IsValid(SecondPlayer)) 
    {
        return false;
    }

    if ((FirstPlayer->SkipGauge < 1.f) || (SecondPlayer->SkipGauge < 1.f))
    {
        return false;
        UE_LOG(LogTemp, Warning, TEXT("Skip Failed"));
    }

    FirstPlayer->SkipGauge = 0.f;
    SecondPlayer->SkipGauge = 0.f;

    AGameModeBase* GameMode = UGameplayStatics::GetGameMode(GetWorld());
    ATrapperGameMode* MyGameMode = Cast<ATrapperGameMode>(GameMode);
    if(!MyGameMode) return false;

    EGameProgress CurrentStage = MyGameMode->CurrentGameProgress;
    switch (CurrentStage)
    {
    case EGameProgress::Tutorial:
        MyGameMode->SkipTutorial();
        break;
    case EGameProgress::Maintenance:
        MyGameMode->SkipMaintenanace();
        break;
    default:
        break;
    }

    return true;
}

FClickCompleted 함수 내에서 SkipCurrentStage 이라는 함수를 호출하고 있다. 이 함수는 두 플레이어를 받아와 게이지를 검사한 뒤, 두 플레이어 모두 스킵이 가능한 상태라면 게임모드의 Skip 함수를 호출해준다.

void ATrapperGameMode::SkipTutorial()
{
    InitialItemSetting();
    ActiveQuestActor(QuestManager->TutorialQuestEndNumber);
    QuestManager->QuestEffect->MulticastRPCSetQuestEffect(false, FVector::ZeroVector);
    SetGameProgress(EGameProgress::Maintenance);
}

void ATrapperGameMode::SkipMaintenanace()
{
    bSkipMaintenanace = true;
    bMaintenanceInProgress = false;

    SetSkipIcon(false);

    Wave++;
    SetGameProgress(EGameProgress::Wave);
}

SkipTutorial() 함수 내부에서는 처음에 정비에 필요한 아이템 지급, 퀘스트 액터 비활성화 처리, 퀘스트 이펙트 비활성화, 게임 상태를 정비로 넘겨주는 역할을 한다.

SkipMaintenanace() 함수 내부에서는 정비를 종료하는 플래그를 설정해주고, 웨이브 단계에서는 스킵을 사용하지 않으므로 Skip UI를 안보이게 바꿔준 뒤 웨이브를 진행시킨다.

UI 구현

void ATrapperPlayer::OnRep_SkipGauge()
{
    for (FConstPlayerControllerIterator Iterator = GetWorld()->GetPlayerControllerIterator(); Iterator; ++Iterator)
    {
        ATrapperPlayerController* PC = Cast<ATrapperPlayerController>(Iterator->Get());
        if (PC)
        {
            PC->SetSkipGauge();
        }
    }
}

void ATrapperPlayerController::SetSkipGauge()
{
    if (IsLocalController() && PlayerHudRef)
    {
        PlayerHudRef->SetSkipGauge();
    }
}

OnRep 함수에서는 플레이어 컨트롤러의 함수를 호출해 UI를 변경해주고 있다.

void UPlayerHUD::SetSkipGauge()
{
    FindPlayer();

    if (Player->HasAuthority())
    {
        SkipGaugeFirstPlayer->SetValue(Player->SkipGauge);

        if (TeamPlayer)
        {
            SkipGaugeSecondPlayer->SetValue(1 - TeamPlayer->SkipGauge);
        }
        else
        {
            SkipGaugeSecondPlayer->SetValue(1.f);
        }
    }
    else
    {
        SkipGaugeSecondPlayer->SetValue(1 - Player->SkipGauge);
        SkipGaugeFirstPlayer->SetValue(TeamPlayer->SkipGauge);
    }

}

기존 플레이어들의 체력 값을 받아오는 로직을 그대로 사용했다. FindPlayer() 함수를 사용해 플레이어를 받아오고, 스킵 게이지를 받아와 UI에 설정해준다.

이제 튜토리얼과 정비시간을 스킵할 수 있게됐다 :)

간단하긴 하지만, 테스트에 유용하게 쓰일 것 같아서 테스트하기 쉽도록 간단하게 정리해 기획자, 아트분들께 전달도 해드렸다.

남은 몬스터 수 UI 구현

위젯은 다른 팀원이 만들어주어서, 빠르게 구현만 진행할 수 있었다.

지금까지는 계속 게임모드에 모든 게임의 상태와 데이터를 관리하고 있었는데, 게임 스테이트라는 것을 알게 되었다... 여기에 구현했으면 조금 더 쉬웠을 텐데... 아무튼, 나중에 옮기더라도 구현이 우선이므로, 이거라도 게임 스테이트를 사용해보기로 했다.

게임 스테이트는 서버와 클라이언트 모두가 가지고 있으므로, 동시에 관리해야할 데이터를 가지고 있기 좋은 곳이었다.

// ATrapperGameState.h

public:
    void ChangeMonsterCount(int32 Count);
    void ChangeRemainingMonsterCount(int32 Count);

    UPROPERTY(ReplicatedUsing = OnRep_ChangeCurrentMonster)
    int32 CurrentMonsterCount = 0;

    UFUNCTION()
    void OnRep_ChangeCurrentMonster();

    UPROPERTY(ReplicatedUsing = OnRep_ChangeRemainingMonsterCount)
    int32 RemainingMonsterCount = 0;

    UFUNCTION()
    void OnRep_ChangeRemainingMonsterCount();

void ATrapperGameState::GetLifetimeReplicatedProps(TArray<FLifetimeProperty>& OutLifetimeProps) const
{
    Super::GetLifetimeReplicatedProps(OutLifetimeProps);

    DOREPLIFETIME(ATrapperGameState, CurrentMonsterCount);
    DOREPLIFETIME(ATrapperGameState, RemainingMonsterCount);
}

현재 몬스터 수와, 앞으로 나올 몬스터의 수를 설정해주기 위하여 변수를 선언하고, 리플리케이트를 설정해주었다.

void ATrapperGameState::ChangeMonsterCount(int32 Count)
{
    if (HasAuthority())
    {
        CurrentMonsterCount += Count;
        OnRep_ChangeCurrentMonster();
    }
}

void ATrapperGameState::OnRep_ChangeCurrentMonster()
{
    if (PlayerHUDRef)
    {
        PlayerHUDRef->SetCurrentMonsterCount(CurrentMonsterCount);
    }
}

몬스터가 생성되거나 삭제될 때 호출되는 함수들이다. 몬스터의 생명주기 관련 처리는 팀원 친구가 해놨으므로 패스하고, 웨이브별 남은 몬스터를 띄우는 부분만 정리하겠다.

void ATrapperGameState::ChangeRemainingMonsterCount(int32 Count)
{
    if (HasAuthority())
    {
        RemainingMonsterCount += Count;
        OnRep_ChangeRemainingMonsterCount();
    }
}

void ATrapperGameState::OnRep_ChangeRemainingMonsterCount()
{
    if (PlayerHUDRef)
    {
        PlayerHUDRef->SetRemainingMonsterCount(RemainingMonsterCount);
    }
}

ChangeRemainingMonsterCount 함수를 호출하면 앞으로 나올 몬스터 수에 가감되고 UI에 표시된다.

void ATrapperGameMode::GetThisWaveRemainingMonsterCount()
{
    for (uint32 i = Wave + 1; i < Wave + 6; i++)
    {
        for (uint32 k = 1; k < 6; k++)
        {
            FString WaveText = TEXT("Wave") + FString::FromInt(i) + TEXT("_") + FString::FromInt(k);
            FWaveInfo* Data = WaveData->FindRow<FWaveInfo>(*WaveText, FString());
            if (!Data || !Data->UseThisWave) continue;

            int32 TotalMonster = 0;

            TotalMonster += Data->Skeleton;
            TotalMonster += Data->Mummy;
            TotalMonster += Data->Zombie;
            TotalMonster += Data->Debuffer;

            TrapperGameState->ChangeRemainingMonsterCount(TotalMonster);
            //UE_LOG(LogTemp, Warning, TEXT("This Wave %d-%d, Total Spawn Monster %d"), i, k, TotalMonster);
        }
    }
}

게임모드에 GetThisWaveRemainingMonsterCount 함수를 추가해 정비시간마다 호출해주었다. 이 함수 안에서 앞으로 5웨이브동안 나올 몬스터 수를 계산해준다.

void ATrapperGameMode::SpawnMonster(struct FWaveInfo& OutData)
{
    /// *********** Create Monster ***********
    if (!bSpawnMonster) return;

    UE_LOG(LogGameLoop, Warning, TEXT("Create Monster - Skeleton %d / Mummy %d / Zombie %d / Debuffer %d"),
        OutData.Skeleton, OutData.Mummy, OutData.Zombie, OutData.Debuffer);

    int32 DeleteMonsterCount = 0;
    DeleteMonsterCount += OutData.Skeleton;
    DeleteMonsterCount += OutData.Mummy;
    DeleteMonsterCount += OutData.Zombie;
    DeleteMonsterCount += OutData.Debuffer;
    TrapperGameState->ChangeRemainingMonsterCount(-DeleteMonsterCount);

    if (IsValid(Spanwer))
    {
        Spanwer->SpawnMonsters(OutData.Skeleton, OutData.Mummy, OutData.Zombie, OutData.Debuffer);
        //UE_LOG(LogTemp, Warning, TEXT("Check"));
    }

}

SpawnMonster 함수 내에서는 한 서브웨이브가 진행될 때마다 나오는 몬스터 수를 빼주도록 했다.

우선 내가 개선해야 할 UI들은 사진과 같다. <신전의 HP, 아이템 갯수, 플레이어 HP, 퀘스트 안내창, 남은 몬스터 수> 각각의 위젯마다 어떻게 동작하는지 도식화 해보기로 했다.

아직 남은 몬스터 수와 관련되어 처리해준 것은 없기 때문에 제외하고 분석해보았다. 퀘스트 UI를 제외하고는 모두 개선이 필요하다고 느꼈고, 이번 포스팅에서는 이걸 개선해나가는 과정을 적어보려고 한다.

플레이어 피격판정 개선

UI 관련 코드들을 변경하기 전에 TakeDamage 구현부부터 변경해주기로 했다.

float ATrapperPlayer::TakeDamage(float DamageAmount, FDamageEvent const& DamageEvent, AController* EventInstigator, AActor* DamageCauser)
{
    float Damage = Super::TakeDamage(DamageAmount, DamageEvent, EventInstigator, DamageCauser);
    if (IsDead) return Damage;

    Damage = FMath::Min(CurrentHP, Damage);

    if (HasAuthority())
    {
        CurrentHP -= Damage;
        MulticastCharacterDamaged(DamageCauser);
    }
    else if (IsLocallyControlled())
    {
        ServerRPCCharacterDamaged(DamageCauser, Damage);
    }

    return Damage;
}

void ATrapperPlayer::ServerRPCCharacterDamaged_Implementation(AActor* DamageCauser, float Damage)
{
    CurrentHP -= Damage;
    MulticastCharacterDamaged(DamageCauser);
}

void ATrapperPlayer::MulticastCharacterDamaged_Implementation(AActor* DamageCauser)
{
    OnRep_CurrentHP();

    if (HasAuthority() && CurrentHP <= 0)
    {
        MulticastCharacterDeath();
        return;
    }

    Alive(DamageCauser);
}

기존 코드를 살펴보면, TakeDamage가 호출될 경우 서버에서는 CurrentHP에서 데미지만큼 체력을 깎고 Multicast RPC를 날려준다. 클라이언트일 경우 Server RPC를 날린다. 그러고 난 뒤 또 Multicast RPC를 날려준다.

타고타고 내려와서 Multicast에서 사망 혹은 생존판정을 내리게 되는데, 사망판정은 심지어 또 다른 Multicast RPC를 호출한다. 이 과정이 너무 복잡하다고 느꼈다.

개선 후 코드

float ATrapperPlayer::TakeDamage(float DamageAmount, FDamageEvent const& DamageEvent, AController* EventInstigator, AActor* DamageCauser)
{
    float Damage = Super::TakeDamage(DamageAmount, DamageEvent, EventInstigator, DamageCauser);
    if (IsDead) return Damage;

    Damage = FMath::Min(CurrentHP, Damage);

    if (HasAuthority())
    {
        ServerTakeDamage(DamageCauser, Damage);
    }
    else if (IsLocallyControlled())
    {
        ServerRPCCharacterDamaged(DamageCauser, Damage);
    }

    return Damage;
}

void ATrapperPlayer::ServerTakeDamage(AActor* DamageCauser, float Damage)
{
    CurrentHP -= Damage;
    OnRep_CurrentHP();

    if (CurrentHP <= 0)
    {
        MulticastRPCCharacterDeath();
        return;
    }

    MulticastRPCCharacterAlive(DamageCauser);
}

TakeDamage() 구현부는 이렇게 바꿔주었다. 권한을 가질 경우 ServerTakeDamage 함수를 호출해주고, 아닐 경우 Server RPC를 통해 서버에서 ServerTakeDamage 함수를 호출해준다.

그리고 ServerTakeDamage 함수 내부에서 체력 상태를 확인해 Death, 혹은 Alive Multicast RPC를 날려준다.

플레이어 UI 개선

우선 HP Change 델리게이트와 관련된 코드들을 삭제해주었다. 이제 OnRep_CurrentHP() 함수를 수정해줄 것이다.

void ATrapperPlayer::OnRep_CurrentHP()
{
    for (FConstPlayerControllerIterator Iterator = GetWorld()->GetPlayerControllerIterator(); Iterator; ++Iterator)
    {
        ATrapperPlayerController* PC = Cast<ATrapperPlayerController>(Iterator->Get());
        if (PC)
        {
            PC->SetPlayerHPBar();
        }
    }
}

void ATrapperPlayerController::SetPlayerHPBar()
{
    if (IsLocalController() && PlayerHudRef)
    {
        PlayerHudRef->SetHPBar();
    }
}

월드에 있는 플레이어 컨트롤러를 가져와, 각각의 SetPlayerHPBar(); 함수를 호출하도록 했다. 그럼 정상적으로 HP UI를 바꿔준다 :)

void UPlayerHealthBar::SetHealthUI()
{
    FindPlayer();

    // ------------------------------------------------------------------------
    // Player

    float Health = Player->CurrentHP;
    float MaxHealth = Player->MaxHP;
    HealthText->SetText(FText::FromString(FString::FromInt(Health) + TEXT(" / ") + FString::FromInt(MaxHealth)));

    float HealthPercent = Health / MaxHealth;
    if (HealthPercent <= 0.5)
    {
        HealthText->SetColorAndOpacity(FSlateColor(FColor::Red));
    }
    else
    {
        HealthText->SetColorAndOpacity(FSlateColor(FColor::White));
    }

    HealthBar->SetPercent(HealthPercent - 0.04);

    // ------------------------------------------------------------------------
    // Team Player

    if (!TeamPlayer)
    {
        TeamInfoCanvas->SetVisibility(ESlateVisibility::Collapsed);
        return;
    }

    TeamInfoCanvas->SetVisibility(ESlateVisibility::Visible);

    float TeamHealth = TeamPlayer->CurrentHP;
    float MaxTeamHealth = TeamPlayer->MaxHP;
    TeamHealthText->SetText(FText::FromString(FString::FromInt(TeamHealth) + TEXT(" / ") + FString::FromInt(MaxTeamHealth)));

    float TeamHealthPercent = TeamHealth / MaxTeamHealth;
    if (TeamHealthPercent <= 0.5)
    {
        TeamHealthText->SetColorAndOpacity(FSlateColor(FColor::Red));
    }
    else
    {
        TeamHealthText->SetColorAndOpacity(FSlateColor(FColor::White));
    }

    TeamHealthBar->SetPercent(TeamHealthPercent - 0.04);
}

게임을 시작했을 때 HP의 Max값을 받아와 변경해주기 위해 SetHealthUI() 구현부를 변경해주었다.

초기 설정을 확인하기 위해 기본 텍스트를 999/999로 바꾸어주자 :) 플레이어 컨트롤러의 BeginPlay() 함수 안에 있는 InitializeHUD() 함수에서 초기설정을 진행해주었다.

// MainHUD
if (IsValid(PlayerHudClass))
{
    PlayerHudRef = CreateWidget<UPlayerHUD>(this, PlayerHudClass);
    if (PlayerHudRef)
    {
        PlayerHudRef->AddToViewport();
        PlayerHudRef->SetVisibility(ESlateVisibility::Visible);
        PlayerHudRef->GetItemCountChanged(0);
        PlayerHudRef->SetHPBar();
        ATrapperGameState* gs = Cast<ATrapperGameState>(GetWorld()->GetGameState());
        if (gs)
        {
            gs->SetPlayerHUDRef(PlayerHudRef);
        }
    }
}

클라이언트는 정상적으로 세팅이 완료되었지만, 서버쪽의 팀 플레이어 HP 정보가 반영되지 않은것을 볼 수 있었다. 클라이언트가 접속한 다음 서버쪽에서도 다시 호출해주어야 한다.

UFUNCTION(Server, Reliable)
void ServerRPCAfterJoinClientSetting();

void ATrapperPlayerController::ServerRPCAfterJoinClientSetting_Implementation()
{
    // 클라이언트 접속 이후 서버의 로컬 캐릭터에서 처리해야할 것
    for (FConstPlayerControllerIterator Iterator = GetWorld()->GetPlayerControllerIterator(); Iterator; ++Iterator)
    {
        ATrapperPlayerController* PC = Cast<ATrapperPlayerController>(Iterator->Get());
        if (PC && PC->IsLocalController())
        {
            PC->SetPlayerHPBar();
        }
    }
}

클라이언트의 초기화 이후, 서버쪽에 클라이언트의 정보를 반영해주는 Server RPC를 만들어주었다.

클라이언트가 접속했을 때, 정상적으로 서버쪽에서 클라이언트의 정보가 동기화되어 UI가 생기는 것을 확인할 수 있다.

신전 HP / Wave UI 개선

마찬가지로, 게임모드에 있는 신전의 정보들과 델리게이트 관련 코드들을 모두 삭제해주었다.

// PlayerHUD.h
void SetTowerInfo(float TowerHealth, float MaxTowerHealth, int32 CurrentWave, int32 MaxWave);

void SetTowerHealth(float TowerHealth, float MaxTowerHealth);
void SetWaveInfo(int32 CurrentWave, int32 MaxWave);

void UPlayerHUD::SetTowerHealth(float TowerHealth, float MaxTowerHealth)
{
    FString TowerHealthString = FString::FromInt(TowerHealth) + TEXT(" / ") + FString::FromInt(MaxTowerHealth);
    TowerHealthText->SetText(FText::FromString(TowerHealthString));

    float HealthPercent = TowerHealth / MaxTowerHealth;

    if (HealthPercent < 0.5)
    {
        TowerHealthText->SetColorAndOpacity(FColor::Black);
    }

    TowerHealthBar->SetPercent(HealthPercent - 0.04);
}

void UPlayerHUD::SetWaveInfo(int32 CurrentWave, int32 MaxWave)
{
    FString TowerWaveString = TEXT("Wave ") + FString::FromInt(CurrentWave) + TEXT(" / ") + FString::FromInt(MaxWave);
    TowerWaveText->SetText(FText::FromString(TowerWaveString));
}

원래 신전의 HP 정보를 변경할 때 Wave 정보도 함께 바꿔주었다. 게임모드와 신전 각각에서 접근해 변경할 수 있도록 두개의 함수로 분리해줬다.

// Tower.h

UPROPERTY(ReplicatedUsing = OnRep_HpChanged)
float CurrentHP;

UFUNCTION()
void OnRep_HpChanged();

// Tower.cpp

void ATower::GetLifetimeReplicatedProps(TArray<FLifetimeProperty>& OutLifetimeProps) const
{
    Super::GetLifetimeReplicatedProps(OutLifetimeProps);

    DOREPLIFETIME(ATower, CurrentHP);
}

먼저, Tower의 HP 변수를 리플리케이트 해줬다.

float ATower::TakeDamage(float DamageAmount, FDamageEvent const& DamageEvent, AController* EventInstigator, AActor* DamageCauser)
{
    float Damage = Super::TakeDamage(DamageAmount, DamageEvent, EventInstigator, DamageCauser);
    Damage = FMath::Min(CurrentHP, Damage);

    if (HasAuthority())
    {
        CurrentHP -= Damage;
        OnRep_HpChanged();
        UE_LOG(LogTemp, Warning, TEXT("Tower Health : %f"), CurrentHP);
    }

    return Damage;
}

TakeDamage 함수가 호출되었을 때 서버에서만 현재 HP를 깎아주도록 했고, 서버에서는 OnRep_HpChanged 함수가 호출되지 않으므로 명시적으로 호출해주었다.

void ATower::OnRep_HpChanged()
{
    for (FConstPlayerControllerIterator Iterator = GetWorld()->GetPlayerControllerIterator(); Iterator; ++Iterator)
    {
        ATrapperPlayerController* PlayerController = Cast<ATrapperPlayerController>(Iterator->Get());
        if (PlayerController && PlayerController->IsLocalController())
        {
            PlayerController->SetTowerHPBar(CurrentHP, MaxHP);
        }
    }
}

void ATrapperPlayerController::SetTowerHPBar(float CurrentHP, float MaxHP)
{
    if (IsLocalController() && PlayerHudRef)
    {
        PlayerHudRef->SetTowerHealth(CurrentHP, MaxHP);
    }
}

void UPlayerHUD::SetTowerHealth(float TowerHealth, float MaxTowerHealth)
{
    FString TowerHealthString = FString::FromInt(TowerHealth) + TEXT(" / ") + FString::FromInt(MaxTowerHealth);
    TowerHealthText->SetText(FText::FromString(TowerHealthString));

    float HealthPercent = TowerHealth / MaxTowerHealth;

    if (HealthPercent < 0.5)
    {
        TowerHealthText->SetColorAndOpacity(FColor::Black);
    }

    TowerHealthBar->SetPercent(HealthPercent - 0.04);
}

OnRep_HpChanged() 함수가 실행되면, 레벨에 있는 플레이어 컨트롤러의 SetTowerHPBar 함수를 호출해준다.

void ATrapperPlayerController::InitializeWorldInfoHUD()
{
    // Tower Initialize
    TArray<AActor*> OutActors;
    UGameplayStatics::GetAllActorsOfClass(GetWorld(), ATower::StaticClass(), OutActors);

    for (const auto& Actor : OutActors)
    {
        ATower* Tower = Cast<ATower>(Actor);

        if (Tower)
        {
            SetTowerHPBar(Tower->CurrentHP, Tower->MaxHP);
        }
    }

초기 세팅은 아까와 같이 플레이어 컨트롤러의 InitializeHUD() 함수에서 InitializeWorldInfoHUD() 함수를 호출하고, 그 함수 안에서는 타워 정보를 받아와 최초의 신전 HP를 세팅해준다.

void ATrapperGameMode::SetWaveUI()
{
    for (FConstPlayerControllerIterator Iterator = GetWorld()->GetPlayerControllerIterator(); Iterator; ++Iterator)
    {
        ATrapperPlayerController* PlayerController = Cast<ATrapperPlayerController>(Iterator->Get());
        if (PlayerController)
        {
            PlayerController->MulticastRPCWaveSetting(Wave, MaxWave);
        }
    }
}

현재 웨이브 정보는 퀘스트처럼 게임모드가 관리하므로, 퀘스트의 방법과 비슷하게 코드를 짜기로 했다.

// Quest & Wave Initialize
if (HasAuthority())
{
    SetWorldInfo();
}
else
{
    ServerRPCSetWorldInfo();
}

void ATrapperPlayerController::SetWorldInfo()
{
    ATrapperGameMode* GameMode = Cast<ATrapperGameMode>(UGameplayStatics::GetGameMode(GetWorld()));
    GameMode->QuestManager->RequireSetQuestUI();
    GameMode->SetWaveUI();
}

void ATrapperPlayerController::ServerRPCSetWorldInfo_Implementation()
{
    SetWorldInfo();
}

초기설정도 퀘스트와 마찬가지로, 플레이어 컨트롤러의 InitializeWorldInfoHUD() 함수 안에서 진행한다.

이번에도 확인을 위해 기본 텍스트를 9999/9999로 바꾸어주었다.

Max HP와 웨이브가 동기화 하는 모습, 몬스터에 의해 신전의 체력이 닳는 모습까지 잘 나오는 것을 확인했다 :)

아이템 UI 개선

마찬가지로 아이템과 관련된 델리게이트를 모두 지워주었고, 브로드캐스트 하는 쪽을 PlayerController->SetItemCount(BoneItemBox); 로 모두 바꿔주었다.

void ATrapperPlayerController::SetItemCount(int32 Value)
{
    if (IsLocalController() && PlayerHudRef)
    {
        PlayerHudRef->SetItemCount(Value);
    }
}

void UPlayerHUD::SetItemCount(int32 Count)
{
    ItemText->SetText(FText::FromString(FString::FromInt(Count)));
}

이 순서로 호출되어 UI를 바꿔주고, 초기 세팅은 HP Bar를 세팅하는 쪽에 함께 적어주었다.

    // MainHUD
    if (IsValid(PlayerHudClass))
    {
        PlayerHudRef = CreateWidget<UPlayerHUD>(this, PlayerHudClass);
        if (PlayerHudRef)
        {
            PlayerHudRef->AddToViewport();
            PlayerHudRef->SetVisibility(ESlateVisibility::Visible);

            PlayerHudRef->SetItemCount(0); // 여기

            PlayerHudRef->SetHPBar();
            ATrapperGameState* gs = Cast<ATrapperGameState>(GetWorld()->GetGameState());
            if (gs)
            {
                gs->SetPlayerHUDRef(PlayerHudRef);
            }
        }
    }

아이템도 잘 먹어지는 것을 확인했다 :)

오늘은 계속 마음에 안들었던 UI 구조들을 개편할 수 있는 시간이었다. 여전히 어떤 구조가 좋은 코드인지는 잘 모르겠지만, 중구난방하게 사용되고 있던 코드들을 하나의 규칙을 잡고 정리한 것 같아 꽤나 만족스러운 하루였다.

내일은 아직 구현하지 않은 남은 몬스터 수 UI와 튜토리얼 / 정비시간 스킵 기능을 제작할 예정이다 :)