요 며칠 컨디션이 안좋었는데 아무래도 수면 부족이었나봅니다.
아침서부터 편두통과 무력감, 우울감에 찌들어서 개발에 하나도 집중을 하지 못했습니다.
개발을 게을리 하지 않기 위해 낮잠을 자제하는 편인데 너무 힘들고 머리에 뭐가 들어오지 않아
될대로 되라지 싶은 심정으로 그냥 잤습니다.
자고 일어나니까 컨디션이 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시 애니메이션이 재생되도록 할 예정입니다.
