치킨 날다

오늘 유의미한 개발을 한건지는 잘 모르겠습니다.

어제 확인을 했을 때는 Projectile이 정상적으로 작동하지 않아서 Trap 구현이 안된것이라 판단하고 넘겼기 때문입니다.

오늘 Trap 부분에서 RPC가 제대로 되는지 확인하다가 Spawn Character Trap과 비교하려고
Trap을 실행했더니 이건 또 정상 작동을 합디다.

결국 Spawn Character는 되고 Projectile은 안되는데 그 차이는 Fire 함수 호출이었습니다.

이쯤되면 Fire 함수에서 뭔가 문제가 있겠거니 하겠는데 물론 여기에 문제가 있지만,

다른 곳에서도 문제가 있었습니다.

Projectile들은 Compile 하기 전에 미리 Child Actor로 되어 있고, 조건을 만족하면 가시성, Collision을 활성화 합니다.

이 기능을 하나의 RPC 함수로 묶어서 호출하는데, 이 중 가시성 부분만 정상작동하지 않습니다.

Collision은 정상 작동합니다. 활성화 된 후 보이든 보이지 않든 데미지는 계산이 됩니다.

하지만 가시성만은 정상작동하지 않습니다.

정확히는 Server까지는 어떻게 되는데 Multicast가 Broadcast가 안되는 느낌입니다.

Host가 Trap을 발동시키면 모든 Client가 작동하지만, Client가 Trap을 발동시키면 Host에게만 보입니다.

그렇기에 우선은 이 문제를 해결해보려 합니다.

요즘 컴퓨터가 더 늙었는지 가끔 Host 움직임을 Client가 제대로 반영 못하고 렉먹은 것처럼 움직이는데

이 부분이 원인인지도 봐야 할 것 같습니다.

오늘은 Spawn Trap의 기본적인 SpawnedActor 부분을 처리하고, 두가지 BP Trap을 만들어놓았습니다.

구현을 하면서 잠깐 고민을 한 부분이 있습니다.

일반 Actor를 Spawn 할 때는 Activate만 하면 되지만, Projectile은 Activate가 되면 곧바로 Fire가 호출되어야 합니다.

이 때 Fire 방향을 지정해야 하는데,
이 부분이 기획에 따라 매번 바뀔 수도 있고 아무튼 처리하는데 선택지가 많았습니다.

하지만 발사 때마다 바뀌려면 Activate가 파라미터를 받도록 Overload를 만들어줘야 하고, 

그렇다면 결국 상세한 Type을 받아야 했습니다.

그래서 저는 Fire Direction을 미리 지정하고, 매번 같은 방향으로만 발사되도록 하였습니다.

디테일한 부분보다는 기능 위주로 구현해야 할 것 같다고 최근 생각이 바뀌게 되면서 결정한 사항이었습니다.

일단 정상 작동을 하고 있지는 않은데 그 이유를 알아보는건 내일로 미루었습니다.

실내에 환기 중임에도 기온이 38도를 육박하고, 슬슬 3개의 모니터가 4개로 보이기 시작했습니다.

쉬어야겠습니다...

내일 열심히 하면 이번주 내로 4개의 Trap을 완성할 수 있을 것 같습니다.

그렇다면 뒤이어 Teleport를 시도해보고 가능하면 이번주 안에 Teleport Trap까지 완성을 해보겠습니다.

2개의 Block Trap을 Multiplay상에서 구현을 했습니다.

구현을 하긴 했는데... 솔직히 아직 이 기능의 핵심인 InterpToMovementComponent에 대해 적을 자신이 없습니다.

더 효율적이고 적절한 사용 방식이 있을 것 같긴 한데...

뭔가 이해도가 떨어진다는 느낌이 듭니다.

아무튼 구현을 했는데, 크러시가 난 이유는 ControlPoints를 초기화 하지 않았기 때문이었습니다.

그 다음 문제는 벽이 잘못된 위치에서 소환된 것인데 무엇이 문제고, 무엇이 해결법인지 모르겠습니다.

Reset 위치를 조금 바꾼 것과 rebuild 몇번 했는데 해결되어버렸습니다.

참... 찜찜하지 않을 수 없습니다.

우선 빠른 목표 달성을 위해 일단은 남겨두지만,

언젠간 좀 더 알아보고 InterpToMovementComponent의 사용방법을 정리해보겠습니다.

오늘은 Block Trap을 먼저 구현을 해보았습니다.

개발을 하면서 Projectile 부분이 구현이 미흡하다는 점과,

Trap에서 InRange 관리 부분이 호출이 안되어 있음을 발견하고 이 부분을 수정했습니다.

이렇다 보니 구현된 부분이 정확한지 잘 안그려져 좀 느리게 개발한 것 같습니다.

하지만 기능이 완벽히 구현되지는 못했는데, RepNotify가 작동하지 않고 있습니다.

https://docs.unrealengine.com/ko/Gameplay/Networking/QuickStart/index.html

오류가 나지 않는 것으로 보아 문법은 문제가 없는 것 같은데 이유를 잘 모르겠습니다.

혹시나 하여 RepNotify를 그대로 두고 Overlap마다 호출을 해보았는데

장해물을 이동시키는 함수에서 크래시가 발생합니다.

원래는 휴일도 하고 있었지만 내일은 자기소개서와 포트폴리오를 좀 더 다듬기 위해 모래 개발을 이어갈 것 같습니다.

고민이 좀 되는데 우선 repNotify가 되지 않는다면 그냥 Overlap 이벤트마다 값을 체크해볼 것 같습니다.

그리고 장해물 이동 부분을 수정을 해보려 합니다.

이제는 더도말고 덜도말고 일주일에 2개씩만 구현했으면 좋겠습니다.

Climb 시 Teleport에 대해 여러 방법을 시도를 해보았습니다.

Controller 단위에서 Teleport.

Character 단위에서 Teleport.

Movement Component 단위에서 Teleport.

하지만 무엇 하나 제대로 되지 않았고, 안되는 이유도 찾지 못했습니다.

이러다가 몇일이고 삽질만 하다가 결국 못할 것 같아 바로 Trap으로 넘어갔습니다.

일단은 IObjectActivity와 ITrapActivity에 구현된 기능들을 적용하기 위해 이전 기능들을 삭제하고, 

함수들을 호출만 해놓은 상태입니다.

내일부터 하나씩 Multiplay 상에서 적용되도록 할 예정입니다.

면접 보고 왔습니다.

면접 보고 몇가지 정리 좀 하느라 개발을 하지는 못했습니다.

다만 앞으로 당분간은 확정된 면접 일정은 없으니 빨리 Teleport 문제를 해결하겠습니다.

오늘은 면접을 보고 와서 피곤한 나머지 도저히 진행을 할 수 없었습니다.

옆에 켜놓고 검색하고 있는데 영어로 된 자료가 읽히지가 않아서...

금요일에는 꼭 문제를 해결하겠습니다.

오늘은 Climb 관련 Interface 작업을 진행했습니다.

우선 기능 자체를 보았는데, 이미 기능들이 Multiplay 환경에서 어느정도 완성이 되어 있었습니다.

기능 구현을 하면서 Multiplay를 같이 고려 했던 것을 보고 나서야 기억이 났습니다.

그리고 Interface에서 제공할 기능들을 살펴보는데, 보면 볼수록 Interface가 필요가 없을 것 같다는 생각이 들었습니다.

첫번째로, Climb는 Attach와 달리 비슷한 속성을 가진 다른 Actor가 없습니다.

Climb이 가능한 것들은 기본적으로 Climbs로 분류되고, 아직까지 일반 Actor에 이 속성이 부여될 계획이 없습니다.

그렇기에 그냥 기존처럼 Super Class를 제공해도 된다고 생각했습니다.

두번째로, Attach 기능을 하는 것도 Character계열이고, 그 외에는 관련 기능을 필요로 하지 않기 때문입니다.

사실 억지로라도 구현은 가능하겠지만, Climb 가능한 것들에 대한 Interface의 존재 의의가 흐려졌기 때문에 이 역시 존재 의의를 잃었다고 봅니다.

그래서 Climb 관련 Interface들은 삭제하였습니다.

그러자 모든 문제가 사라지고, 곧바로 기능 문제로 이동했습니다.

여전히 제 Character는 윗쪽에서 진입 시 Character가 원하는 방향(Z축 기준 180도 회전)으로 움직이지 않습니다.

TeleportTo, SetActorRelativeRotation 모두 정상적으로 작동하지 않습니다.

Character다 보니까 CharacterMovementComponent를 이용해야 하나 싶기도 한데

아직 갈피를 못잡아서 커뮤니티에 질문글을 올리고 마무리를 하였습니다.

내일부터 수요일까지 면접이라 목요일까지 좀 알아보고, 체력이나 멘탈 여부를 보고 마저 진행할지를 고민하려합니다.

오늘은 열 하루만에 드디어 Multiplay 상의 Attach 기능을 구현하였습니다.

코드를 보고 싶어하는 회사에도 메일을 보냈습니다.

구현하면서 시간이 오래 걸린 부분은 Latch와의 상호작용이었습니다.

단순히 Piece와의 관계는 Replicate와 Character 내부에서의 코드만 만지면 되기에 비교적 쉽게 구현할 수 있었습니다.

하지만 Latch는 여기에 Latch가 섞이면서 3개를 동시에 관리를 해야 했습니다.

게다가 이 중 몇몇 코드는 Piece와 Character간의 상호작용 코드와 90% 이상 동일했기에

둘 사이를 관리하는 함수를 재 사용 하는데, 이 때 사소한 문제가 시간을 오래 잡아먹었습니다.

그리고 Attach 뿐만 아니라 Collision을 관리 하는 것에서도 시간을 잡아먹었습니다.

Piece의 Attach Detach가 직접적으로 이루어지지 않기 때문에 중간중간에 가만히 있는 시기가 존재하는데.

이 때 Character와 Collision이 발생해서 예상치 못하게 트리거 값들이 변하는 문제가 치명적이었습니다.

게다가 무슨 이유인지 Debug를 해도 이벤트에 진입하지 않고 진행 되면서 Log로 문제가 되는 부분을 찾아야 했습니다.

그리고 시간이 조금 더 남아 Wall을 두개로 나누어 하나는 Climb 전용 Wall.

다른 하나는 Trap에서 사용될 Obstacle로 분리했습니다.

다음에 할 일을 나열해보자면

1. Climb

2. Trap

3. Puzzle

4. 기타 Object

5. Animation 관련 사소한 조정

이렇게 있습니다.

이 중 5번은 다음번으로 미루어도 될 정도의 수준이고,

4번도 구현 기능 테스트를 더 정확히 하기 위한 것으로 엄밀히 말하면 나중에 해도 되긴 합니다.

결국 1, 2, 3이 남는데 이 중 1번 Climb를 먼저 하려 합니다.

일단 기능이 어느정도 완성되어 있는만큼 이 기능을 먼저 Multiplay에서 가능하게 하고, 

그 다음 Trap을 구현하고자 합니다.

Trap이 다 되면 이를 기반으로 Puzzle을 구현하고, 그 뒤에는 기타 사소한 조정을 할 예정입니다.

기한은 솔직히 모르겠습니다.

Attach도 완성되어 있던 것을 구조 변경 하면서 4일은 밤샘으로 열흘 정도 걸렸는데

Climb는 그래도 이전에 어느정도 정리를 했으니 밤샘 없이 열흘 정도 걸리지 않을까 싶습니다.

Trap은 보름에서 스무날이 걸릴 것으로 예상합니다.

개인적으로 이 두개를 8월 안에 끝내는 것이 1차 목표입니다.

Puzzle은 새로 만들어야 하기에 이 역시 열흘에서 보름은 생각하고 있습니다.

이렇게 적어놓으니 중요 기능은 9월 중순까지로 예상됩니다.

1차 목표는 8월 전까지 Trap 구현이지만,

솔직히 Puzzle도 구현하여 9월에 어느정도 완성된 코드를 포트폴리오에 사용하고 싶습니다.

그 전에 지금 면접을 보는 회사 중 마음에 드는 회사에 입사를 하면 더 좋겠구요.

조금씩 버그를 고친 끝에 Attach 기능의 8할? 9할? 정도를 오나성했습니다.

지금은 멀티플레이 상에서 대부분의 상황에서 원하는대로 기능이 작동합니다.

다만 두가지 경우에 원하는대로 작동하지 않는데,

하나는 Latch에 Piece가 Attach된 상태에서 Character가 Piece를 Attach 한 상태로 Latch와 Collision 했다가 취소 했을 때 Detach를 하지 못합니다.

다른 하나는 Latch와 Character가 각각 Piece를 Attach 한 상태에서 Interaction을 하는 경우.

즉, Switch의 경우 마찬가지로 이후 Detach를 할 수 없었습니다.

분기로 보아 어느 순간 InteractionType이 Attach가 아닌 Default로 변하는 것 같습니다.

지금 끝내는 것도 좋으나, 하루 여유가 있으니 무리하지 않고 오늘은 정상적으로 보내고 내일 낮에 마무리 하겠습니다.