치킨 날다

오늘 처음 시도한 일은 Character에게 Pawn Collision이 설정된 Capsule Component를 배치하여 Character의 말단 부분에서도 중앙 부분과 같이 충돌이 되는 것이었습니다.

하지만 실제로 적용 해보았지만, 여전히 몸통을 관통하였습니다.

이 문제는 당장 해결할 수 없다고 판단하여 뒤로 미루어 두었는데, 다른 Issue를 해결하기 위해 검색하다가 한가지 방법을 찾았습니다.

그것은 Root Motion을 이용하는 방법이었습니다.

우선은 현재 고민 중인 Issue를 해결하고 적용해볼 예정입니다.

두번째로 시도한 것은 bLayeredMotion의 값이 반대로 들어가는 문제였으나, 확인 결과 문제를 찾을 수 없었습니다.

아마도 수 개월간의 코드 수정 과정에서 해결이 된 것으로 보입니다.

세번째로 Dash Jump Bug인데, 이 부분은 두가지 문제로 인해 보류하였습니다.

하나는 버그가 발생하는 조건이 명확하지 못해서 상황을 파악하지 못한다는 것.

다른 하나는 뒤에서 얘기 할 MovementComponent 부분을 해결하면 문제가 해결 될 수 있다는 것 입니다.

네번째로 Check Interaction Object Enhance인데 이는 앞서 미리 수정하였기에 Issue만 정리하였습니다.

다섯번째로, CharacterMovementComponent에 Character의 행동 관련 기능들을 이동하는 Issue입니다.

찾아본 결과, Action Bind는 Character와 Player Controller에서 구현이 가능합니다.

이 중 RTS와 같이 Player가 한번에 여러 Character를 조종하는 경우가 아니면, 보통은 Character에서 Bind합니다.

다만 이동이나 회전과 같은 기본 기능들은 Player Controller에서 bind 한다고 합니다.

MovementComponent의 역할은 이 이동, 회전 이벤트에서 호출하는 함수들을 따로 제공하는 역할입니다.

이 구조를 기억하고, 토요일에는 기능들을 재분리, 구현 할 예정입니다.

이후 시간이 남는다면, Trap에도 MovementComponent를 적용하고자 합니다.

총선 투표날. 사전투표를 하였기에 개발만 하였습니다.

오늘은 Character의 Hit Event가 여러번 일어나는 것을 방지하는 작업을 하였습니다.

처음에 고려한 것은 Semaphore였습니다.

Component와 OverlapStart 이벤트가 발생하면 Semaphore 값을 올려주고,
OverlapEnd 이벤트가 발생하면 Semaphore 값을 내려주는 방식입니다.

그리고 Semaphore 값이 1일 때에만 최초 타격으로 인정하여 데미지가 가해집니다.

하지만 막상 구현을 해놓으니, 움직일 때는 물론이고 가만히 있을 때에도 생각하는것 만큼 Semaphore 값이 잘 작동하지 않았습니다.

다음 구현한 방식은 Mutex를 사용하는 방식입니다.

nullptr로 초기화된 UCapsuleComponent 변수를 하나 두고, OverlapStart 할 때마다 이 변수 값을 체크합니다.

변수 값이 nullptr이면 최초 타격으로 인식하여 데미지를 주고, 값을 저장합니다.

변수 값이 nullptr이 아니면 두번째 세번째 타격이기에 데미지를 주지 않습니다.

하지만 이 방식도 문제가 있었습니다.

여러번 타격을 하는 과정에서 Mutex가 꼬이는 경우가 발생하였고, 값의 초기화가 안되기도 하였습니다.

최종적으로 결정한 것은 이 Mutex를 두개를 사용하는 것입니다.

각각의 변수는 최초 타격 Component와 피격 Component입니다.

판정 시 두 변수가 모두 nullptr이면 최초 타격으로 인식하고, 타격 Component와 피격 Component를 저장합니다.

또한 기존에는 OverlapEnd 시에 판정을 초기화 하지만, 이번에는 이 과정도 OverlapStart 이벤트에 추가하였습니다.

아직은 팔에는 Collision이 Ignore 되지 않아 몸을 통과하기에, 동일 Component에 2번 Hit 이벤트가 발생할수도 있기 때문입니다.

위의 두 변수에 저장된 Component들과 동일한 타격 판정이 일어나면, 두 변수 값을 nullptr로 초기화 합니다.

또한 이 외에 Hit Montage가 재생이 끝난 뒤에도 위 초기화 과정을 추가하였습니다.

그 결과, 타격 모션 1회당 판정이 1번만 발생하도록 하였습니다.

이후 각 Mesh의 Part들에게 Ignore Collision을 두려고 하였으나, 한번 오류가 나서 실패를 하고 원래대로 돌린 상태입니다.

내일은 이 실패한 부분을 구현하고, Hit 이벤트 부분에 변화된 점을 살펴본 뒤 구현을 수정할 예정입이다.

오늘은 병원에서 진료를 받고 와서 하루 쉬었다 가고자 합니다.

그리고 좀... 현타가 오기도 해서 하루 넉넉히 투자해서 쉬었다가 가겠습니다.

오늘은 Trigger의 위치를 수정하고, Editor에서 변경 가능하도록 개별 변수로 전환했으며 데미지 이벤트를 넣었습니다.

그 결과 마지막 부분만 미완성이고, 나머지는 완성할 수 있었습니다.

Trigger의 위치도 사실 개별 변수로 바꾸면서 해결되었습니다.

기존에는 C++에서 생성하는 즉시 TArray에 저장을 하였습니다.

하지만 이 때문에 Editor에서 간단히 수정을 해볼 수 없어서 생성 후 개별 변수를 선언하여 이에 저장하였습니다.

그 결과 Trigger의 위치에 대한 문제가 해결되었ㅅ브니다.

이후 Melee Attack에 대한 데미지 적용을 해보았는데, 한번에 여러 Trigger가 발생 하는 문제가 발생했습니다.

또한 이로 인해 Character가 사망 판정을 받을 때 에러가 발생하였습니다.

다음에는 이 부분을 Semaphore를 적용하여 해결을 해보고자 합니다.

이후 시간이 남는다면 Character의 충돌 판정을 조금 더 상세히 나눠볼까 합니다.

방법은 HitTrigger와 같이 Mesh의 Part별로 Component를 배치하고, 이 Component의 Collision을 조정하는 방식입니다.

이것이 구현 될 경우, 지금처럼 Melee Attack 때 손이 Character의 머리를 뚫고 지나가는 일은 없을 것입니다.

오늘은 Mesh와 Component들간의 Hit, Overlap 이벤트를 다시 구현을 해보았습니다.

다시 해본 결과, Mesh-Component들간의 Hit와 Overlap 이벤트가 발생은 하였습니다.

하지만 공격하는 개체가 아니라 공격 받는 개체의 이벤트가 발생을 하였고,
Component-Component간의 Overlap 이벤트만큼 잘 작동하는 구조가 없었습니다.

그래서 기존의 Component-Component Overlap방식을 채택했습니다.

다만 기본에는 머리와 몸통을 애매하게 구분 하였다면,
이번에는 부위별로 Component를 Socket에 Attach하여 15개의 Component를 두었습니다.

하지만 여기까지 배치를 하고 기능을 구현하려던 찰나, Trigger Component가 원래 위치를 벗어난 것을 발견했습니다.

이를 수정하려고 하였으나, 계속해서 수정되지 않아 일단 개발을 마무리 하였습니다.

토요일에는 이 부분을 수정하기에 앞서, 배열로 관리하여 Editor에서는 직접 접근이 되지 않았던 Component들을 변수로도 관리를 하도록 변경하고자 합니다.

그리고 나서 Component의 위치 문제를 해결하겠습니다.

시간이 남는다면 Attach Interaction 전용 Component를 따로 두고 싶습니다.

원래는 Climb Interaction과 혼용하였는데, 생각해보니 Attach는 하나의 Component가 정면을 광범위하게 커버하면 될 것 같기 때문입니다.

오늘은 여러가지 방식으로 Character의 Melee Attack의 판정을 구현해보았습니다.

하지만 마땅히 잘 작동하거나, 마음에 드는 방식을 찾을 수 없었습니다.

그래서 우선 이전에 작성한 관련 코드들을 삭제하고 다시 고민중에 있습니다.

다행히 commit이 남아 있어 복구하는 것이 매우 쉽기에 할 수 있었습니다.

몇번 더 해보고 안된다면 결국 예전처럼 Hitbox DamageBox의 Overlap을 이용해야 할 것 같습니다.

오늘은 Character의 Hit 이벤트를 Mesh에 직접 적용하는 작업을 하였습니다.

매우 간단한 작업일 줄 알았는데 예상치 못한 문제에 막혀 마무리하지 못했습니다.

공격 기능을 작동하려 할 때 트리거가 제대로 작동하지 않은 것입니다.

공격 기능은 다음 트리거들이 만족해야 합니다.

1. 상대 Character가 존재하는가?

2. 공격한 주체가 공격을 입력했는가?

이 중, 2번 트리거가 버튼 입력에 bind 된 함수에서는 값이 변한 것이 확인되었는데,

트리거 직전에는 값이 작동되지 않은 걸로 확인되었습니다.

여러 함수들에 로그를 찍어보면서 한참을 들여다 보다가, 잠깐 공격자가 아닌 피격자의 것을 넣어봤더니 정상적으로 바뀌는 것을 확인하였습니다.

이 때문에 크게 혼란이 와서 마무리 하였습니다.

다음에는 좀 더 상황을 정확히 파악하고 이를 수정한 뒤, 안쓰는 함수들을 제거하고자 합니다.

오늘은 개발을 하지는 않았습니다.

대신에 월요일부터 시작할 Refactoring Milestone에서 적용 할 Issue들을 정리하였습니다.

오늘 개발일지는 이들을 작성한느 것으로 마무리하겠습니다.

1. Code arrange

코드 단위에서 정리해야 하는 내용들

 - Class명 중 잘못 적힌 것을 수정

 - Debug에 필요한 매크로 정리

 - TreasureHunter.h에 자주 사용되는 header들 선언

2. Fill out blank animation

적절한 모션이 없어 적용되지 않고 있는 기능들

 - Crouch walk with 8 destination

 - Wall - Bottom exit or enter

 - Slide

3. Check Interaction Object Enhance

현재는 3개의 Trigger 하나의 OverlappedObject 값을 공유한다.

이 경우, 화면을 위아래로 흔들 때 알맞게 OverlappedObject가 탐색되지 않을 수 있다.

이를 해결하기 위해 아래 방법을 제시한다.

 - 각각의 Trigger에 대응하는 OverlappedObject를 둔다.

 - Interaction시 위 OverlappedObjects들이 담긴 TArray의 index를 따라 탐색하여 접근한다.

4. Change Hitbox

현재 Character의 Hit Event는 별도의 CapsuleComponent가 담당한다.

이를 Mesh에 직접 적용이 가능한지 확인하고, 가능하면 Mesh의 Socket에 따라 차등 적용을 하고자 한다.

5. bLayeredMotion reversed

bLayeredMotion이 예상한 값과 반대로 움직여야 정상 작동하는 중이다.

6. Dash Jump Bug

달리면서 점프를 하면 이동속도가 현저히 떨어지는 버그가 있다.

7. Use MovementComponent to Move Wall

현재 BlockTrap의 벽은 Tick에서 움직임을 구성하고 있다.

이는 현저한 성능 하락을 야기할 수 있어, 각 벽마다 MovementComponent를 두어 기능을 개선하고자 한다.

8. Use CharacterMovementComponent

Character에 너무 많이 구현된 함수들을 분리하고

저번에 구현 실패한 Climb 기능 구현을 위해 CharacterMovementComponent를 사용.

기능들을 최대한 해당 Component로 옮기고, 가능하면 Character Movement와 관련된 함수들과 변수들도 옮기고자 한다.

9. Damaged Animation

피격 시 Animation을 재생하도록 적용

10. Detailed component when character move

Character가 이동 시 조정되어야 하는 세부사항들

 - Jump, Crouch, Slide, Climb 시 Camera가 Z값에 따라 움직일 것

 - Slide 시 달리기 초기 속도에서 감속운동을 하면서 정지하도록 적용

 - 화면을 돌리면 그에 따라 얼굴 부분이 회전하도록 적용.

 - 화면을 돌리는 각도를 제한.

 - 제한된 각도 이상 회전하면 몸도 따라 옴직이도록 할 것.

11. Trap Activate in Multiplay

Trap이 현재는 매우 간단하게 발동되도록 하고 있다.

또한 한번 해제 후 다시 Overlap 하여도 중복 발동도 가능하다.

이를 더 그럴듯하게 적용하기 위해 다음 방법을 제시한다.

 - Trap 내부에 다음 항목들을 추가

   * Overlap된 Character들을 저장하는 TArray - [A]

   * Overlap중인 Character들을 저장하는 TArray - [B]

   * 발동 최소 인원 수 - [C]

 - Character가 Overlap 할 때마다 B에 Character를 추가

 - B의 길이가 C보다 작을 경우, Character가 Trap 밖으로 나가면 B에서 Character 제거

 - B의 길이가 C랑 같아지면 함정 활성화, B 안의 값들을 A에 추가

12. Vanish Trap

바닥이 꺼지는 함정을 Geometry Brush로 구현을 시도했다가 실패했다.

이에 대해 더 알아보고, 불가능할 시 다른 방법을 탐구

13. Teleport Trap

Teleport Trap은 다른 Trap들과 다르게 Wrapping Object를 따로 두고 있다.

이러한 Wrapping Object 없이 Trap들간 이동을 할 수 있게하는 방법을 탐구

14. Climbing

Climbing 기능 구현에 대한 정리.

정면에 있는 3개의 Trigger들의 Collision 상태에 따라 트리거가 다르게 적용된다.

15. Ledge

Climbing의 구현 방식 변화로 인해 Ledge 기능 구현이 불가피하다.

때문에 Ledge 기능을 추가하고자 한다.

오늘은 Attach Puzzle의 남은 기능을 개발하고, Master에 Merge하였습니다.

첫번째로, Attach시 Index 로그를 찍어 Piece Exchange가 되는지 확인하였습니다.

확인 결과 정상적으로 Exchange가 되는 것을 확인하였습니다.

두번째로, Latch에 Piece가 Submit 될 때 정답 여부를 체크하는 기능을 적용하였습니다.

이는 간단한 함수를 통해 확인 할 수 있었습니다.

세번째로, Latch에 정답 Piece가 모두 적용이 되면 벽이 내려가는 기능을 적용하였습니다.

이는 이번의 Destroy Puzzle과 구현이 조금 달랐습니다.

Destroy Puzzle은 Event 주체가 Piece라서 관련 Event Dispatch를 Puzzle에서 적용할 수 있었습니다.

하지만 Attach Puzzle은 Event 주체가 Character라서 이 작업이 Character에서 이루어졌어야 했습니다.

그래서 C++ 코드상에서 Attach Puzzle Base에 Event를 선언하고, BP에서 Dispatch를 하였습니다.

그리고 Character에서 Piece를 Submit 한 직후, 정답 여부를 확인합니다.

만약 해당 Submit이 올바르면, 모든 Latch의 정답을 확인합니다.

이 때 모든 값이 정답이면, Dispatch 된 함수가 선언 되면서 벽이 올라오게 됩니다.

코드상 구현은 이것이 전부였습니다.

하지만 가장 큰 문제가 있었습니다.

PR 과정에서 conflict가 발생한 것이었습니다.

이를 수정하기 위해 1시간 가량 시도하였지만, 점점 더 꼬이는 것을 느꼈습니다.

그래서 Reset-hard를 통해 문제를 해결하였습니다.

이로서 한달 넘게 진행되던 Trap/Puzzle 마일스톤이 종료되었습니다.

정확히는 일주일이 넘은 기한이었는데, 그 연장된 기한 중 하루가 남았습니다.

이 하루동안 이슈를 정리할 예정입니다.

오늘은 Piece와 Latch들간의 Interaction 부분의 문제를 수정하였습니다.

처음 한 2시간은 디버그를 돌려보면서 트리거가 문제가 생기는 부분을 체크해보았습니다.

그런데 버그 여부를 떠나서 정확히 어느 상황에서 버그가 나는지를 인지할 수 없었습니다.

그래서 다시 종이와 펜을 들고 순서도를 다시 그리기 시작했습니다.

주요 골자는 다음 두가지입니다.

1. Front Trigger와 Overlap을 통해 저장되는 Piece를 OverlappedPiece와 AttachedPiece로 분리

2. AttachPiece와 Latch의 Area에 OverlapEvent를 제거

1번은 Front Trigger가 여러개였기에 특히 의도치 않은 Trigger 값의 변화를 야기했습니다.

이를 캐릭터가 소지중인 Piece와 앞에 놓여진 Piece로 분류를 하였습니다.

이와 동시에 조건을 조금 더 세세하게 나누어 오류가 발생하는 것을 줄였습니다.

2번은 개발 하는 도중에 깨달은 점이었습니다.

어차피 상호작용이 일어나기 전에는 Piece나 Latch의 범위 안에 들어오든 말든 아무 의미가 없었습니다.

그리고 Front Trigger가 존재함으로서 필요한 Trigger 값의 변화는 오히려 이 쪽에서 발생하는 것이 자연스러웠습니다.

그래서 Piece, Latch에서 발생하는 모든 Trigger 변화와 overlap event를 제거하였습니다.

대신 OnInteractionPressed와 OnInteractionReleased 함수에서 기존의 InteractionType 변화를 넣어주었습니다.

이로써 Character의 Interaction에 필요한 정보는 Front Trigger의 overlap 이벤트에서, 

Interaction의 구분과 그에 대한 동작은 OnInteractionPressed/Released 함수에서 담당합니다.

그럼에도 아직 한가지 오류가 있습니다.

Latch에 Attached 되어 있던 Piece를 Detach 하고 있으면 Character가 이상한 곳으로 튀어버립니다.

내일은 이 오류를 중점적으로 수정하고, Piece Switch 기능을 검수할 예정입니다.