치킨 날다

오늘 안에 마무리가 될까 싶었는데 그러지 않았습니다.

개발을 시작하면서 가장 먼저 살펴본 것은 Character가 Latch에 부딛치지 않고 뚫고 들어가는 문제였습니다.

처음에는 Collision 설정을 계속 만져보다가, Activate 함수에서 이를 잠깐 건드리기 때문에 그 부분을 수정해보기도 했습니다.

하지만 문제는 전혀 해결되지 않았습니다.

한참을 Collision만 건드려보다가, 비슷하게 구현된 다른 Object의 Collision을 log로 확인해보았습니다.

놀랍게도, 동일하게 Collision이 변경되었습니다.

Collision이 문제가 아님을 깨닫고 고민을 하다, 혹시나 하는 마음에 Latch의 Static Mesh를 수정하였습니다.

그러자 Character가 Latch와 부딛치기 시작했습니다.

기존의 Static Mesh는 Geometry Brush로 만든 것이었는데, 그 과정에서 무언가 잘못된 것 같습니다.

Latch가 상호작용을 정상적으로 하게 된 뒤 Interaction Event를 건드려보았습니다.

지금까지 해온 결과, 2가지 문제점이 확인되었습니다.

1. Latch에 Actor를 Attach한 뒤, 곧바로 Detach를 하면 게임이 터집니다.

아무래도 트리거 문제이거나, Latch의 Detach 함수 구현 문제로 생각됩니다.

2. Latch에 Actor를 Attach한 뒤, Latch의 범위 밖으로 나섰다가 다시 들어가서 Detach를 하면 Piece는 Detach 되나, 가만히 있어도 캐릭터가 날라다니는 버그가 있습니다.

이는 솔직히 원인이 예상되지 않습니다.

처음에는 30일까지 개발을 넣었다가, 기간이 안될 것 같아 일주일 연장 하였는데 솔직히 남은 일주일 안에 다 구현 될지 모르겠습니다.

위 과정이 일찍 끝난다면, Check Answer 기능을 추가하겠습니다.

오늘은 기존에 구현된 AttachPiece와 관련된 기능뿐만 아니라 이를 반납하는 Latch와 관련된 Interaction에 대한 Reaction을 채워넣었습니다.

간단하게 몇개만 하면 될 줄 알았는데 경우의 수가 생각하는 것보다 많아 예상치보다 두배는 적용한 것 같습니다.

그리고 이전에 만들어 놓았던 함수들을 까먹고 새 함수를 만들었다가 이를 다시 지우고 원래 만들어 놓은 것으로 적용하느라 시간이 조금 걸렸습니다.

그리고 이 개발일지를 일찍 적는 이유.

날이 좋아서 일찍 마무리 했습니다.

현재 발생하는 문제는 

1. Attach가 되지 않고 있다. 혹은 Attach가 되고 있는데 Location이 제대로 적용되지 않고 있다.

2. Latch와 Character가 서로 통과되고 있다. BlockAll인데?

이정도입니다.

Issue로 적기도 애매한데 안 적어 놓으면 또 까먹어서 개발일지에 적는게 습관이 되어버렸습니다.

이렇다 저렇다 해도 3월 내에는 최대한 마무리 되는 쪽으로 노력하겠습니다.

오늘은 Piece를 Attach 하는 Object인 Latch를 만들었습니다.

처음 개발 할 때에는 이래저래 고민이 많이 되었습니다.

하나의 Latch가 얼마나 많은 AttachPiece를 받을 수 있어야 하나 생각을 해봤는데

어느정도 고민을 하다 보니까 굳이 복잡하게 할 것 없이 간단한 것부터 만들자고 결정을 내렸습니다.

현재는 Latch에 관련된 대부분의 기본 기능들과 Puzzle에 Collide 했을 때 Latch가 Activate 되는 것까지 마무리 했습니다.

다음 개발 때에는 Interaction 이벤트를 넣고 범위 내에 Interaction 할 시 Attach 되는 것까지 구현을 해볼 생각입니다.

아울러 시간이 남는다면 Attached 되어 있는 Latch에서 상호작용을 하면 AttachPiece를 다시 가져오는 기능을 추가하고자 합니다.

오늘은 Piece의 Attach와 Detach 기능을 완벽히 구현을 마무리하였습니다.

구현하던 중 발생했던 이슈 중 Detach가 되지 않는 이슈가 있었습니다.

처음에는 Enum 값이 제대로 변하지 않는 것인줄 알고 이를 확인하였으나, 값이 정상적으로 변하였습니다.

그 다음에는 Attach 될 때 OnCharacterOverlapEnd가 호출되어서 AttachedPiece가 nullptr로 초기화 된 것인줄 알았지만, 디버그 결과 해당 이벤트가 호출되지 않았습니다.

좀 더 세밀히 디버그 플래그를 세우고 돌려보니, AttachToComponent 함수가 작동된 후에 AttachedPiece가 nullptr로 초가화 된다는 것을 알아냈습니다.

그래서 AttachToComponent 함수 호출 전에 AttacnedPiece가 가지고 있는 주소값을 지역변수에 복사 하였다가 호출 후에 복구 해주는 방식을 채택했습니다.

내일은 CheckObject를 생성하여 범위 안에서 Attach 되도록 구현할 예정입니다.

큰 문제가 없다면 이번주 안에 마무리가 될 것 같습니다.

오늘은 Piece에 인접했을 때 Character가 인식을 하는 것을 개발하였습니다.

아마 저번에 적은 남은 작업으로 구분한다면 1번이지 않을까 싶습니다.

이에 대해서 조금 생각이 많았습니다.

Object와의 Interaction은 Character마다 Object를 판단하는 것이 아니라, Object가 주위의 Character들에게 권한을 줘야 했습니다.

하지만 동시에 Character는 자신에게 권한을 준 Object가 어떤 것인지 알아야 했습니다.

그리고 가능하다면 캐릭터의 눈 앞의 것이 좋겠지요.

이를 종합적으로 고민해본 결과, 이전에 등반 애니메이션 때 생각을 했던 Capsule Component 방식으로 귀결되었습니다.

그래서 조금 이르지만, 이 기능을 먼저 구현을 하였습니다.

방법은 간단합니다.

캐릭터의 정면에 Z값이 다른 3개의 Capsule Component를 배치합니다.

이 Capsule Component에 Piece Actor가 Collision 되면 AttachedActor에 해당 Actor Object를 저장합니다.

물론 몇가지 문제가 있기는 합니다.

하나는 카메라가 아니라 Mesh에 Attach된 Component들이라 카메라 방향이 아닌 캐릭터의 정면 방향에서 판단이 된다는 점.

넘어갈 수도 있는 부분이긴 합니다.

다른 하나는 여러 Component들간에 하나의 변수를 건드리면서 발생하는 문제.

예를 들면 2개의 Component와 Collision 했다가 1개의 Component가 Collision 하지 않을 때,

AttachedActor가 nullptr이 되어 버리는 경우가 발생 할 수 있습니다.

사실 그런 문제가 발생하는 경우가 있을까 싶습니다.

하지만 혹시 모르는 일이니 이슈로 남겨두고, 후일 개선을 하고자 합니다.

수요일에는 Interaction Event 발생 시 실질적으로 Piece를 손에 Attach 하는 부분을 구현하고자 합니다.

이것이 일찍 마무리 되면 Attach Object를 생성하고, 정답을 제출하는 것까지 구현할 예정입니다.

오늘은 Character의 Interaction을 그 종류와 단계별로 정리한 것을 토대로 새로운 Trigger를 넣었습니다.

원래 Interaction은 간단하게 bool 변수로 체크를 했었는데 상황별로 정리를 하다보니

결국은 Enum으로 대동단결 하였습니다.

Character에 Interaction과 관련된 두 개의 Trigger(InteractionType, AttachSequence)와 관련 함수를 추가했습니다.

그리고 이를 이용해 AttachPiece에 트리거 값이 변경이 되도록 하였습니다.

남은 작업은 다음과 같습니다.

1. Piece에 인접 할 시 적용되는 Trigger 값에 따라 적절한 기능을 할 것

2. Piece를 Attach하는 Object를 구현할 것

3. 2의 Object와 관련된 기능들을 구현할 것

마지막으로 오늘 갑자기 터져버린 빌드 에러로 상당시간 멘붕하며 개발을 하지 못했다는 변명과 함께 개발일지를 마무리 하겠습니다.

오늘 Tick을 쓰지 않고 일반 함수로 벽의 움직임을 구현해보았습니다.

그런데 Tick을 쓰는 것보다 더 결과가 만족스럽지 못했습니다.

Tick을 쓰면 프레임이 떨어지는 느낌이라면, 함수로 구현하면 움직이는 순간 연산 때문에 게임이 끊기는 느낌이었습니다.

그래서 이 문제에 대한 해결은 refactoring 기간으로 미루었습니다.

AttachTrap은 여러 트리거 부분이 꼬여서 그 부분을 정리하였습니다.

아마 토요일에는 어떻게든 마무리 될 것 같습니다.

오늘은 Character의 Attach Piece와의 상호작용 부분을 수정하다가 머리속이 심히 꼬이는 것을 느끼고

Destroy Piece 개발로 선회하고, 기능 구현을 마쳤습니다.

Piece가 melee attack을 받으면 없어지면서 index가 저장되고, 옳바른 값이 저장 되면 벽이 내려오도록 구현하였습니다.

기존에 벽을 올리는 기능과 범위 내에 들어올 시 piece를 소환하는 기능은 구현되어 있었습니다.

하지만 벽을 내리는 기능, Piece가 attack을 받을 시 후처리에 대해서는 구현된 바가 없어 이 부분을 구현했습니다.

하지만 아직 끝난것은 아닙니다.

현재는 벽의 이동을 Tick에다가 함수를 넣어두었습니다.

하지만 데모를 하면서 벽이 한번 올라왔다가 내려오면 프레임이 거의 반토막이 나는듯한 느낌을 받았습니다.

때문에 Tick에 구현하지 않고 벽을 움직이는 방법을 먼저 구상하고, 이를 적용한 뒤 Attach Piece를 구현할 예정입니다.

오늘은 Child Actor의 코드가 정상 작동이 되도록 수정을 하였습니다.

저번에는 Parent Actor의 tick이 Child Actor의 tick을 override 해서 문제가 생긴 것이 아닐까 예상 했습니다.

하지만 로그를 하나씩 찍어보다가 문제를 발견할 수 있었습니다.

원인은 Child Actor의 BeginPlay가 호출되지 않고 있었습니다.

올라올 벽과 함수가 호출하는 변수가 매칭되어야 하는데 BeginPlay가 호출되지 않아 함수가 작동을 제대로 하지 않았습니다.

그래서 Initialize 함수를 하나 만들어서 Parent Actor의 BeginPlay에서 호출하였습니다.

추가로, Trap의 On Actor Begin Overlap 이벤트에 Key를 Activate하는 함수를 Bind 했습니다.

다음에 할 일은 Key의 상호작용을 넣고, Puzzle에 Answer를 넣어 퍼즐 입력을 넣는 작업입니다.

이를 위해서 몇가지 선행되어야 하는 일이 있습니다.

첫번째. Character에서 상호작용이나 Melee Attack을 구분하는 변수를 추가해야 합니다.

현재는 둘 다 Layered Motion이라 Layered Motion 트리거만 작동하고 있습니다.

여기에 트리거를 추가할 계획입니다.

두번째. Block Trap에 벽을 해제하는 로직을 추가해야 합니다.

예전에는 큰 고려 안하고 개발하였으나, 현재는 로직에 의해 벽이 제거되기도 해야 합니다.

때문에 벽을 내리는 로직도 추가를 하고, 가능하면 벽을 움직이는 로직을 개선하고자 합니다.

오늘은 Child Actor에 이벤트를 bind 하는 부분을 시도했습니다.

우선 외부에서 Child Actor의 함수를 Implement 하는 방법은 찾지 못했습니다.

대신 Implement 해야 할 함수가 Bind 되어 있는 Event가 Multicast Delegate라서 여러 함수를 Bind 할 수 있다는 것을 알았습니다.

때문에 Trap의 Wall을 움직이는 함수는 Trap 내부에서 구현하고, 그 외에 Spawn이나 Activate 관련된 함수들은 Puzzle에서 구현을 하면 될 것 같습니다.

하지만 문제는 이것이 아니었습니다.

Trap만 맵에 두면 잘 작동하는데, Child Actor로 붙인 Trap은 작동을 하지 않습니다.

확인해본 결과 Bind된 함수는 Call이 되고 있었습니다.

좀 더 찾아봐야겠지만, Tick 부분에서 Trap 작동 부분이 if문으로 붙어 있는데 이 부분이 문제라 생각됩니다.