치킨 날다

어제 코딩 테스트 보느라 오랜만에 커피를 마셨는데 그 때문인지 새벽에 한숨도 자지 못했습니다.

누워서 멀뚱멀뚱 거리기 애매해 새벽부터 운동 가고 조금 일찍 개발을 시작했는데,

아침 먹고 나니까 거짓말처럼 눈이 감겨서 2시간 정도 눈을 붙인 것 같습니다.

전반적으로 집중력이 좀 떨어지는 하루였습니다.

Exit Climb 부분의 Animation이 제대로 재생되지 않는 문제를 건드려보았습니다.

Animation 조건문이나 State 이동 조건 등을 만져보았는데 별 다른 소득을 얻지 못했습니다.

아무리 생각해도 조건이 틀린 것 같다는 생각이 들지 않습니다.

그래서 혹 무언가 잘못 생각한 것이 있는가 싶어 Overlap Trigger 값을 로그로 찍어보려 하는데,

Client에서만 출력을 해서 정확히 알아보고 싶은데 조건을 잘못잡고 있습니다.

또한 이전에 RPC 부분에서 실제 값과 로그가 찍히는 값의 순서 차이로 인해

명확한 값을 잡지 못하는 것도 발목을 잡는 요소 중 하나입니다.

우선 다음에는 조건문을 정확히 파악해서 제대로 된 로그를 찍어보고자 합니다.

그 뒤에 State 이동 조건이 정확한지 확인해볼 예정입니다.

만약에 조건문이 잘못 짜여졌다면 다행이지만,

조건문이 정상이라면 완전히 암흑으로 문제가 빠졌다는 것이기에 걱정이 좀 됩니다.

다음에는 좀 더 컨디션 조절을 해서 더 집중하고자 합니다.

오늘은 Climb 상태에서 적절하게 재생되지 않는 Animation이 재생되도록 수정을 하였습니다.

이전에 새 구조를 구상 했는데 이미 구현된 구조랑 동일 했다고 한번 언급 했을 것입니다.

사실 두 구조에는 한가지 차이가 있습니다.

이미 구현된 구조체는 FullBodyMotion이 모두 하나의 FSM으로 구현되어 있습니다.

즉, 각 행동들은 State로 구분되고, Climb는 Conduit으로 구분되어 내부적으로 FSM을 다시 갖습니다.

하지만 새 구현체는 바로 Blend by IdleType으로 바로 Sub-FSM으로 구분됩니다.

이렇게 구현한 이유는 Climb는 Enter만 지나면 각자 다른 형태로라도 Idle 상태가 유지되기 때문입니다.

그래서 이전과 동일하지만, 조금 다른 구조를 적용하자 Enter Climb Animation이 작동하였습니다.

비록 아직은 Lower Enter만 확인했지만, 어차피 Upper 부분은

Ledge와 Enter/Exit 시 위치 보정을 해줘야 하기 때문에 당장 확인을 못합니다.

그러니 현재로써는 이정도가 성공적인 구현 수준인 것 같습니다.

여세를 몰아 Movement도 구현하였고, 이 또한 성공적으로 작동하였습니다.

Animation에 비해 이동 속도가 빠르지만, 이는 나중에 조절하면 됩니다.

다만 Exit 부분이 제대로 작동하지 않습니다.

조건문이 문제가 되는데 이 부분만 좀 더 노력해서 처리하면 그 다음은 다른 Climb Object들의 Animation.

그리고 Ledge 처리 하면서 Climb Enter/Exit Upper Side에서의 위치 보정을 하면 될 것 같습니다.

이 과정이 짧아도 2주는 걸릴 것 같고, 이게 되면 비로소야 Climb 기능이 완성이 됩니다.

그 뒤에는 Puzzle, Trap의 버그 수정 및 MultiPlay기능 적용, 그 뒤에는 Teleport Trap 개선과 VanishTrap 구현.

그리고 게임 편의성 및 더 그럴듯한 Character Movement 및 Animation 적용을 할 것입니다.

Climb 기능 완성을 6월 중으로 마무리 하고, Puzzle과 Trap쪽을 7월까지 마무리 하는 것이 목표입니다.

물론 그 전에 게임 회사에 입사하면 계획이 달라질것이지만.

이왕이면 언리얼이나 C++을 사용하는 회사에 입사를 했으면 합니다.

3주 연속으로 일주일 중 유일하게 쉬는 날인 주말 일요일에 입사지원을 하느라 많이 지쳤습니다.

또한 오랫동안 고민한 이슈를 해결하였기에 하루 정도 휴가를 주고자 합니다.

체력도 보충하고 집중력도 충전하는 시간을 갖도록 하겠습니다.

이전 문제가 해결된 이후로 2주 가까이 지났습니다.

오늘에서야 문제를 해결할 수 있었습니다.

저번에 적었듯이, MovingDirection이 Climb 중 Moving Input이 들어오는 상태에서 해제 될 시 값이 고정되는 문제가 있었습니다.

처음에는 Climb 중 이동을 맡는 MoveForward 함수 내부를 수정할까 고민을 했는데,

내부에서 무언가를 추가/제거 하는 것으로 문제가 해결 될 것 같지가 않았습니다.

그 이후 생각이 나는 해결책은 Tick에서 상태를 조절해주는 것인데,

기껏 Tick에서 기능들을 빼고 다시 넣는 것도 웃기는 것 같았습니다.

그러다가 이전에 Tick에 있던 기능들을 제거 할 때 CharacterMovementComponent의 OnMovementModeChanged 등과 같은 Event를 이용했던 것을 떠올렸습니다.

이번에도 문제가 발생하기 직전에 OnClimbEndOverlap Event가 호출이 되기에, 그 안에서 MovingDirection을 초기화 했습니다.

그러자 아무 일도 없다는듯이 문제가 해결되었습니다.

처음에는 Climb 상태가 아닐 때에도 Move Input이 들어오면 MovingDirection 값이 변하는데 왜 고정이 되는지 야속했습니다.

하지만 조금 더 생각을 해보니, Animation에 대해 열 댓개의 트리거들을 사용하고 있는데 작은 예외라도 처리를 해주는게 옳지 않았나 싶은 생각이 들었습니다.

그렇게 저를 괴롭히던 Climb 기능은 기능적인 측면에서는 모두 완성되었습니다.

남은 것은 각 기능 별 적절한 Animation이 재생이 되는 것인데,

Animation Blueprint를 수정해본 결과 State Machine에 구조적 결함이 있는 것을 발견했습니다.

그래서 FullBodyMotion쪽 State Machine들을 전면 개선해야 Animation이 정상 재생 될 것 같습니다.

이 과정에서 Ledge, Slide 등의 Animation도 같이 수정되기에 이 두 기능들 적용이 병행되어야 할 것 같습니다.

오늘도 이 문제 부분을 고치기 위해 이것저것 시도를 했고, 실패했습니다.

얻은 결과가 몇가지 있다면, MovingDirection이 Climb 상태에서 해제된 이후로도 변하지 않는다는 점.

이 값이 변해야 하는 부분의 다른 함수는 잘 작동하고 있다는 점입니다.

다음에는 

1. 프로젝트 rebuilding 해보기

2. 해당 함수가 실행되어야 할 부분에 로그를 찍어서 제대로 동작하는지 확인해보기

이정도 먼저 해보려 합니다.

3달정도 자르는 것을 미루던 머리를 깎느라 개발 시간이 조금 줄어들었습니다.

오늘은 Climb의 위와 아래에 다다라서 상태에 벗어난 이후 Animation이 재생되지 않는 문제를 체크해 보았습니다.

우선 문제를 조금 더 상세히 분류했습니다.

탈출 시 이동 키를 누르고 있으면 문제가 발생하는데, 그렇지 않으면 정상적으로 작동했습니다.

심지어 애니메이션도 정상 작동했습니다.

문제가 일어날 가능성이 있는 부분이 Overlap 함수에서 Movement 함수까지 넓어졌습니다.

Movement 함수를 살펴보니, Climb 상태에서 이동하는 동안에 MovementType이 계속 Climb로 덮어씌워지고 있었습니다.

이 부분을 제거해 보았더니, Climb 상태에서 이동 중 Climb Animation이 재생되지 않았습니다.

그래서 Animatiton에 Stand Idle만 있던 것을 여러 종류의 Idle 값에 따른 Animation을 붙여주었고,

그 결과 함수를 제거해도 Animation이 예전처럼 적용되었습니다.

애니메이션은 여전히 작동하지 않았습니다.

슬슬 Anim Instance에서도 문제가 있는건가 의심이 되기 시작했습니다.

갈피가 잘 안잡히는게 이번 달 안에 끝낼 수 있을지 의문이 들기 시작합니다.

늦잠 + 입사지원 겹쳐서 개발을 늦게 시작했지만, 의외로 집중이 잘 되어서 이것저것 잘 한 것 같습니다.

오늘은 Climb 중 위아래로 이동 중 갑자기 Climb 상태가 해제되는 현상을 수정했습니다.

정확히는 수정 당했습니다.

문제 상황을 좀 더 명확하게 체크하기 위해 로그를 좀 더 찍어보았습니다.

그 결과 이동 중 갑자기 TriggerEndOverlap 이벤트가 발생하면서 문제가 발생하는 것을 확인했습니다.

이게 조건으로 걸러질수 있는가 하면, Climb의 맨 위와 아래에서 동일한 이벤트로 탈출하기에 불가능합니다.

그러다가 Climb의 Component를 Actor 크기와 최대한 비슷하게 맞춰보았더니 문제가 해결되었습니다.

다만 이 상황이 이해가 되지 않는게, 이벤트 발생 조건이 Component가 아니라 Actor입니다.

프로젝트에서 포괄적으로 사용하는 THActorBase에 Component가 있긴 하지만, Climb에는 사용되지 않습니다.

그래서 좀 기묘하고  해결 당했다는 것입니다.

이 뒤로는 Climb 위와 아래에 다다라서 상태가 해제된 이후에
Locomotion Animation이 재생되지 않는 현상을 수정해보려 했습니다.

이것도 기묘한 것이, 동일한 함수가 호출되는 Jump나 Re-Interaction에 의한 상태 해제 시에는 정상 작동합니다.

하지만 EndOverlap에 의한 것들만 작동하지 않습니다.

이 함수들을 Enter/ExitClimb로 묶어서 선언해도 마찬가지입니다.

아무래도 뭔가 다른 문제가 있는 것 같습니다.

이 문제가 Client에서만 발생한 것으로 보아 통신 쪽 문제라 생각됩니다.

다음에도 이 부분을 중점적으로 고쳐보고자 합니다.

오늘은 그저께 다시 작성한 Climb 기능의 State Machine을 하나하나 구현을 해보았습니다.

우선은 Rope를 먼저 수정하고, Rope에서 문제 없이 잘 작동하면 Wall과 Ladder에도 수정을 할 예정입니다.

결론적으로, 반의 반쪽만 완성하였습니다.

Climb시 Climb-Idle 상태로는 변합니다.

하지만 Enter Climb, Exit Climb와 Climb up, Climb down이 전혀 작동하지 않습니다.

또한 Climb move 중 갑자기 MvoementMode가 변하면서 Climb 상태가 해제되는 경우가 있습니다.

이 경우, Locomotion Animation도 정상 작동되지 않습니다.

간혹 정상적으로 Climb State에서 해제 되어도 Locomotion Animation이 정상 작동하지 않기도 합니다.

날이 따뜻해서  노곤노곤해지는 날입니다.

월요일에 이 문제를 좀 더 수정해보겠습니다.

오늘은 Climb 기능에 대해 적절한 Animation이 재생되도록 개선을 히도했습니다.

우선 성과가 있는 점부터 적겠습니다.

Climb 시 Animation이 재생되지 않는 이유는 Climb Animation이 속해있는

FullBodyMotion을 관할하는 trigger 값이 적절한 값을 가지지 않았기 때문입니다.

이를 적용하자, Animation이 어느정도 재생이 되기 시작했습니다.

이후 Climb를 한번이라도 하면 Climbing 상태로 움직이는 문제가 있었으나,

위와 마찬가지로 Climb 해제 시 FullBodyMotion 값이 적절치 못해서였습니다.

남은 시간은 Animation을 기능과 맞추기 위해 시간을 꽤 투자하였으나,

미묘하게 Animation 재생이 어긋나 있었습니다.

일관적이라면 무언가 잘못 입력된 것이겠지만, 규칙성을 찾지 못했습니다.

때문에 저는 Animation과 기능의 조건을 잘못 나눈 것이 아닌가 하는 의구심이 들었고,

관련 State Machine을 재정리 하였습니다.

이를 기반으로 다시 조건을 부여하여 Animation이 적절히 재생되도록 할 예정입니다.

요 며칠 컨디션이 안좋었는데 아무래도 수면 부족이었나봅니다.

아침서부터 편두통과 무력감, 우울감에 찌들어서 개발에 하나도 집중을 하지 못했습니다.

개발을 게을리 하지 않기 위해 낮잠을 자제하는 편인데 너무 힘들고 머리에 뭐가 들어오지 않아

될대로 되라지 싶은 심정으로 그냥 잤습니다.

자고 일어나니까 컨디션이 100%까지는 아니더라도 70% 정도까지는 올라온 것 같습니다.

그 덕에 시간은 적었지만, 해결하고자 하는 문제는 해결하였습니다.

오늘 해결한 문제는 Client에서 작업 여부와 관계 없이 MovementMode가 반대로 움직이는 현상을 수정하는 것입니다.

코드가 잘 돌아가는데 값이 반대로 작동하는건 수 개월 전에 기억도 가물가물해지는 시기에 겪고 처음입니다.

그래서 굉장히 오래 걸릴것 같아 오늘 하루 이 문제만 해결하도록 계획을 잡았습니다.

그런데 문제가, 문제가 아니었습니다.

우선 어느 시점에서 값이 바뀌는지 알기 위해 MovementMode의 로그를 출력하는 함수를 더 추가했습니다.

원래는 Interaction 작업을 한 직후(B)에만 출력을 하였는데, RPC 함수에서 NetMulticast 함수 내부에 MovementMode 값을 직접 수정하는 코드의 앞, 뒤(A)로도 추가하였습니다.

이후 로그를 찍어보니까 생각치도 못하게 나왔습니다.

우선 코드 순서 상 A를 호출하는 함수가 B보다 더 앞입니다. 

Host(Server)에서는 A 다음 B 순서로 잘 찍혔고, 값도 멀쩡했습니다.

하지만 Client에서는 B가 찍힌 후에 A가 찍히고, B 값은 원래 값과 반대로 움직이는 반면
A 값은 정상적으로 변경 전과 변경 후가 의도한대로 변경되었습니다.

A 값이 정상적으로 움직인다는 것은 MovementMode의 값은 어느 Client에서도 정상이라고 예상할 수 있습니다.

그렇다면 로그가 찍히는 순서가 다른 것에서 어떤 의미가 있는 것인지를 알아야 했습니다.

이는 조금만 생각해도 금방 알 수 있었습니다.

A 코드는 B 코드보다 먼저 실행된다 하더라도 RPC 함수입니다.

때문에 같은 procedure에서 실행되지 않을 것입니다.

Client에서 실행하는 경우, 한번 Host(Server)의 함수를 호출하도록 통신을 하고, 

Host(Server)는 자기 자신을 포함한 모든 Client에서 값을 바꾸도록 다시 한번 함수를 호출할 것입니다.

즉 A는 실행이 될 때까지 두번의 네트워크 통신이 발생합니다.

그에 반해 B는 A 부분에서 RPC 함수 통신이 끝나면 그 즉시 바로 호출됩니다.

또한 A와 다른 Procedure 상에서 작동되기 때문에 반드시 A가 B보다 먼저 끝난다는 보장도 없습니다.

때문에 Client에서는 A 호출을 위한 두번의 통신 과정이 B 호출보다 더 늦게 완료 된다고 예상했습니다.

그 뒤로는 예상이 맞는지 검증을 하는 과정입니다.

검증은 간단했습니다. Tick에서 값을 로그에 출력해보는 것입니다.

출력 결과, 값 자체는 정상적으로 움직이는 것으로 나왔습니다.

결국 이 문제는 기능상, 구현상 문제가 아니라, RPC 함수의 특성에 대한 이해 부족이 문제였습니다.

이를 통해 멀티플레이 게임에서의 디버그 때에는 로그에 지나치게 의존해서는 한된다는 교훈을 얻었습니다.

내일에는 Animation 블루프린트의 트리거 값을 조절하여 Climb시 애니메이션이 재생되도록 할 예정입니다.