치킨 날다

오늘은 Trigger를 따로 분리 했던 것을 Object 단위로 재편성 하였습니다.

이전 구현은 TriggerBase를 두고 이를 상속 받아서 Trap이나 Puzzle을 만들었다면,

지금은 ObjectBase를 두어 필요한 최소 함수를 제공하고, 이를 각 Trap이나 Puzzle이 상속 받는 형태를 취하고 있습니다.

나누는 것 자체는 오래 안 걸렸는데, 파일 만들 때 자꾸 경로 오류가 떠서 몇번이고 반복 해야 했습니다.

아무튼 일주일동안 하루에 한번씩 구조를 고치던 이 기능도 마무리가 되었습니다.

그 다음에 등반 오브젝트를 잠깐 건들여봤습니다.

원래는 사다리, 로프, 암벽이 있는데 암벽 애니메이션이 완벽히 갖추어지지 않아 우선 사다리와 로프만 구현을 하려 합니다.

이 오브젝트도 ObjectBase를 기반으로 개발하는데, 원래 ObjectBase에서 제공하는 콜리전 범위는 로프 중간 부분을 덮어 공중에서 등반을 하는 이벤트를 적용 할 예정입니다.

그리고 새로운 Actor Component를 추가해 각각 오브젝트의 위와 아래 부분에 둘 예정입니다.

이들은 일반적으로 걸어서 등반을 하는 이벤트를 발생시킬 예정입니다.

대략적인 로직과 함수 틀은 짜 놓은 상태입니다.

다음주 월요일에는 함수들을 적용한 뒤 예시 오브젝트를 만들어 애니메이션을 적용해보고자 합니다.

이 둘이 된다면 코드를 조금 정리 한 뒤, 퍼즐과 함정을 몇가지 기획해 보겠습니다.

그리고 시간이 더 남는다면 첫번째 영상 촬영을 해보겠습니다.

오늘은 어제 개발 했던 THTriggerBase를 THInRangeTriggerBase, THInteractionTriggerBase, THClimbTriggerBase로 나눴습니다.

THInRangeTriggerBase는 범위 안에 캐릭터가 들어가면 일반 로그를 출력하고, 

THInteractionTriggerBase는 범위 안에 캐릭터가 들어가면 상호작용을 할 수 있습니다.

또한 상호작용 중 범위 밖으로 나가면 상호작용이 취소가 됩니다.

하지만 이정도를 구현하고 저녁을 먹다가 문뜩 설계가 잘못 되었다는 사실을 깨달았습니다.

위와 같이 나눈 이유는 결국 트리거의 종류가 완전히 기획이 된 것이 아니기 때문이었습니다.

하지만 같은 범위 판정 트리거 안에서도 필요한 변수가 다를 수 있으며, 이에 따라 함수가 다르게 적용 된다면 위와 같이 나눈 의미가 없을 것 같습니다.

정확히는 위와 같이 특정 트리거 타입에 대하여 상위 클래스를 두는 의미 자체가 없는 것 같습니다.

그래서 구조를 변경하고자 합니다.

여기서도 2단계로 나뉘는데, 처음에는 THTriggerBase는 Actor Component를 상속 받아 구현을 할 계획이었습니다.

그리고 필요한 함정이나 퍼즐마다 이 THTriggerBase를 bind 하려 했습니다.

그럴려면 THTriggerBase는 위치, 크기, collision 변경 함수들과 Event bind 함수가 제공되어야 합니다.

이렇게 써 놓고 보니 THTriggerBase와 Actor Component와 차이가 없다는 것을 깨달았습니다.

최종적으로, THTriggerBase라는 것을 없애는 것이 옳다는 결론에 도달했습니다. 

모든 함정, 퍼즐은 Actor Component를 별도로 bind 하고자 합니다.

아마 이벤트 조건이 다른 경우에는 별도의 Actor로 처리해도 문제가 없을 것입니다.

다만, 이벤트에 따른 호출 함수가 비슷한 기능을 할 경우에는 내부에서 Native 함수를 호출하고, 이 함수를 override 해서 다형성을 생성 하는 것이 더 적절할 것이라 생각합니다.

정리를 해보자면

1. Trigger를 상속 관계로 묶지 않고, 각각의 함정과 퍼즐들이 하나의 Actor Component를 bind 하여 각기 다른 방식으로 이벤트를 붙인다.

2. 이벤트 발생 조건이 비슷한 경우에는 bind 함수가 특정 Native 함수를 선언하는 방식으로 구현을 고정하고, 이를 상속 받아 Native 함수가 각각 다른 작업을 하도록 한다.

이런 식입니다.

오늘은 범위 판정 트리거를 구현하였습니다.

이 기능은 매우 간단하지만 2가지 문제가 있었습니다.

하나는 overlap을 판정하는 Box Component가 제대로 생성이 되지 않는다는 것.

다른 하나는 collision 선언이 되었음에도 collision이 발생하지 않는다는 것.

첫번째 문제는 Box Component의 사이즈를 지정하는 방식을 변경했습니다.

원래는 FVector 변수를 두고, BP 하위 클래스에서 FVector 값을 조정하였는데 이를 모두 C++ 상위 클래스에서 작업하였습니다.

이렇게 하니까 Component가 제대로 보이기 시작했습니다.

아마 나중에는 width, height, length를 따로 두거나, Box Component를 protected로 두어 하위 클래스에서 직접 접근 가능하도록 할 것 같습니다.

두번째는 collision을 변경했습니다.

기존에는 InteractionArea라는 collision을 선언 했는데, 이 부분이 문제인 것 같아 몇번을 보다가 Trigger라는 것이 이미 존재하는 것을 발견했습니다.

이를 Trigger로 변경을 하니까 제대로 작동하였습니다.

솔직히 왜 문제였는지 아직 파악을 못했습니다.

그리고 기획 부분에 변화? 라고 하기는 그렇고 정리가 하나 되었습니다.

이번에 트리거 구현 마일스톤에서 구현 할 트리거는 4가지였습니다.

피격/타격, 범위 판정, 상호작용, 등반.

이 중 피격/타격은 완전 별도이니 제외를 하고, 나머지 3개가 기능이 큰 차이가 없다는 것을 깨달았습니다.

범위 판정은 넓은 범위 안에 캐릭터가 들어오면 특정 기능을 해야 합니다.

등판은 좁은 범위 안에 캐릭터가 들어오면 애니메이션을 해야 합니다.

상호작용은 좁은 범위 안에 캐릭터가 들어왔을 때, 상호 작용 키를 누르고 있으면 특정 기능을 해야 합니다.

결국 범위 판정만 구현이 된다면, 그 범위와 기능만 다르게 적용하면 되는 것입니다.

여기서 문제는 기능이었습니다.

트리거는 대부분 함정 쪽과 연관이 깊은데, 각 기능이 어떤 파라미터를 받는지 고정을 하기 힘들다는 것이었습니다.

여기서 해결 방안은 두가지였습니다.

하나는 모든 트리거의 상위 클래스인 THTriggerBase에서 OnComponentBeginOverlap 기능에 델리게이트 하는 함수인 OnOverlapBegin 함수를 override 할 수 없으니 내부에 모든 기능 함수들을 다 넣어 두는 것.

사실상 힘들고 복잡하고 더러운 방식입니다.

다른 하나는 Box Component를 하위 클래스에서 접근할 수 있게 하고, OnCOmponentBeginOverlap 기능을 하위 클래스에서 따로 붙이게 하는 방식입니다.

훨씬 깔끔한 방식입니다.

여기서 저는 당연히 후자를 생각하고 있습니다.

그래서 오늘 개발한 기능을 기반으로 각 트리거 종류 별로 기능을 분배하고자 합니다.

상호작용은 잘 하면 내일 안에 끝날 것 같습니다. 그럼 남은 일주일은 등반에 투자를 하고자 합니다.

여기와 다음 퍼즐/트랩까지 구현이 완료가 되면 작년 2월부터 6월? 까지 개발 하다가 엎었던 부분만큼 개발이 끝납니다.

일일 개발일지 쓰는게 조금 부담스럽긴 하지만 슬슬 적응이 되는 것 같습니다.

가능하면 주말 안에 기획서를 개선하고 마일스톤을 좀 손을 보고자 합니다.

굉장히 오랫동안 이 프로젝트를 꿈꾸고 개발해 왔는데, 그 중심에 있던 Auto Map Creation은 아마도 제외를 해야 하지 않을까 예측합니다.

오늘은 경기도 청년구직지원금 신청 하느라 중간에 시간 좀 날려 생각보다 개발을 못했습니다.

그래도 오늘 개발한다고 했던 피격 시 데미지 적용과 범위 인식 트리거 중 데미지 적용을 끝냈습니다.

개발 하면서 다시 보니까 애니메이션에 피격, 사망 애니메이션이 적용되지 않았습니다.

우선 급한대로 사망 애니메이션만 적용을 하고 피격 애니메이션 부분에서 고민을 하고 있습니다.

공격을 받을 시 움찔 거릴지, 그냥 맞으면서 데미지만 깎일 지 고민입니다.

아마 적용이 된다면 기능 리팩토링 시기 때 적용이 될 것 같습니다.

피격 판정이 끝나고 나서 남은 일을 보는데 생각보다 쉽지만은 않을 것 같습니다.

상호작용, 범위 판정은 한번 하면 크게 문제가 없는데, 등반 애니메이션은 감이 잘 오지 않네요.

높은 확률로 앞의 두 일이 끝난 뒤 개발 방식을 생각하다가 뒤로 미룰 것 같습니다.

오늘은 피격 판정을 마저 개발하였다.

기능이 제대로 구현이 되었는지 판단을 하기 위해 component를 인게임 상에서 볼 수 있게 하려 했다.

이 방법은 존재하지 않은 것인지, 있는데 못찾은 것인지 모르겠지만 component 범위를 확인하는 방법은 찾았다.

에디터에서 character를 보면 component 범위를 알 수 있었다.

이를 통해 hitbox와 damagebox의 대략적인 위치와 크기를 조정하였다.

2일 전의 hitbox 구현은 잘못 되어 있었는데, 그 이유는 AttachToComponent를 사용했기 때문이다.

다른 코드에서 SkeletalMeshComponent를 이 함수를 이용해 붙이는 것을 발견하고 사용을 해봤는데, component가 정상적으로 붙지 않았다.

그래서 SetupAttachment를 이용해 중지 부분에 component를 붙였다.

이전에는 그저 컴포넌트끼리 붙이는 것으로만 사용했는데, 도큐먼트를 보니까 그 중 특정 소켓을 지정 할 수 있었다.

두번째로 해결한 이슈는 damagebox 판별이다.

몸통에 hitbox가 자신의 손에 달린 damagebox와 collision을 하는 것을 막아야 했다.

처음에는 hitbox의 parents와 damagebox의 parents가 같은지 비교를 하였으나 원하는대로 작동하지 않았다.

구조상 hitbox는 root component에, damagebox는 특정 소켓에 붙어 있기 때문인 것으로 추측된다.

조금을 더 찾다가 component들이 GetAttachmentRoot 함수를 제공하는 것을 발견했다.

이를 통해 두 component들의 root component를 비교하여 이들이 동일할 경우에는 피격 판정이 일어나지 않도록 하였다.

코드에 필요 없는 부분들을 정리하다가, Layered 된 애니메이션 작동 여부를 알려주는 bLayeredMotion 변수가 사용되지 않은 것을 발견하였다.

이를 사용하도록 적용 하였더니, 피격 판정이 정상적으로 일어나지 않았다.

정확히는, 애니메이션은 정상적으로 재생이 되나, 근접공격이 할당된 키를 누르자 bLayeredMotion 값이 반대로 적용되었다.

이에 대한 코드들을 살펴 보았으나, 중간에 값이 반전되는 원인을 찾지 못하였다.

때문에 이 부분을 이슈에 bug로 작성해 남겨 두고, 우선 기능이 정상 작동하도록 정리를 하였다.

마지막으로, 범위 판정 트리거 부분은 개발을 잠깐 시도 하였으나, 여전히 미구현인 상태이다.

에디터에서 컴포넌트 범위가 보이지 않는 것으로 보아 C++ 코드에서 추가한 Component에 추가적인 작업이 필요한 것으로 판단된다.

오늘 저녁과 내일은 기획을 정리하고, 월요일에는 피격에 따른 데미지 적용과 범위 판정 트리거 기능을 우선적으로 구현 할 예정이다.

일주일 가까이 걸릴 것으로 예상했던 피격 판정이 하루만에 끝나 다행이라 생각한다.

원래는 오늘은 다른 프로젝트를 하는 날인데 중간에 던져 놓아서 이 프로젝트에 관해 조금 공부를 했습니다.

우선 이전에 타격 판정이 없는 것을 확인 하고 싶어 컴포넌트에 색을 넣어 게임 상에서 보이게 하려고 한 건에 대해서입니다.

이것저것 찾아보다가 우연히 에디터에 캐릭터를 올려 놓으면 컴포넌트 범위가 보인다는 것을 알아냈습니다.

이를 보고 테스트 레벨을 만들어 캐릭터를 올려 놓으니까 컴포넌트가 손에 붙어있지 않더군요.

코드 자체를 잘못 짠 것으로 생각됩니다.

두번째는 조금 큰 것인데, 개발하는 게임 장르를 변경해볼까 합니다.

요즘 보는 인터넷 방송에서 Escape from Tarcorv라는 게임을 한창 하고 있었습니다.

직접 해보지는 않았지만 느낌은 광활한 맵에 들어가 아이템을 파밍하고 탈출하면 그 아이템을 사용 할 수 있는 형태 같았습니다.

다만 세션이 생성이 되면 유저들이 다 빠져나가기 전까지는 세션은 늘 유지가 되고, 유저들은 자유롭게 매칭 되는대로 들락날락 하는 것 같았습니다.

제가 개발하던 게임도 비슷한 아이템 정책을 생각하고 있었습니다.

접속시 랜덤의 장비 혹은 장비를 뽑을 재화를 주고,

이 장비는 소모템이라 일정 횟수 이상 사용하거나 내구도가 다 닳으면 파괴됩니다.

장비를 유지하는 방법은 맵 내에 특정 장치를 이용해 생명을 연장시키거나,

영구적으로 사용 가능하도록 만드는 것이었습니다.

또한 배틀로얄과 가장 비슷한 전투 및 플레이 방식이라 생각하여 배틀 로얄로 만들려고 했지만,

전투 뿐만아니라 퍼즐도 있기에 플레이 시간이 제한된 배틀 로얄로는 퍼즐이 사장 될  것이라 생각했습니다.

마지막으로, 아직 장르가 정해질 정도로 많이 개발되지 않았습니다.

때문에 Escape from Tarcorv를 중심으로 몇몇 기획서를 다시 작성하려 합니다.

이 경우, 아마도 랜덤 맵 생성은 꽤 뒤로 미루어질 것 같습니다.

또, 이전에는 미로와 필드가 적절히 섞인 맵을 구상했다면, 변경 후에는 목적지 없이 돌아다니는 플레이를 지향하므로 필드에 더 중점을 둘 것 같습니다.

내일은 버그를 고쳐보고, 남은 시간에 기획서를 개선해보려 합니다.

어제 올렸던 질문에 답변이 없어서 우선 손 끝에 새 컴포넌트를 부착하고, 이를 히트박스와 콜리전 판단을 해보았습니다.

그런데 제대로 작동하지 않았습니다.

오히려 상시 자기 자신과 콜리전이 발생하는 문제가 발생했습니다.

오늘 안에는 해결을 하지 못할 것 같아 다른 작업을 병행했습니다.

범위 안에 캐릭터가 있는지 판단하는 트리거를 제작 하였는데 작동이 정상적으로 되지 않고 있습니다.

토요일에 마저 개발을 하게 될텐데 우선 범위 트리거를 구현 하려 합니다.

이것이 구현이 되면 그 이후로는 매우매우 쉬운 작업이기에 문제가 없을 것입니다.

때문에 이 쉬운 작업들은 뒤로 미루고, 범위 트리거 개발 직후에는 타격 판정을 완성 할 것입니다.

윤곽이 잡히는데 마일스톤 기간 안에 될것 같기도 안 될것 같기도 하고 아슬아슬하네요.

마일스톤을 칼같이 잡은건가 싶습니다.

오늘 할 일은 트리거를 구현하는 일이었습니다.

그 중, 가장 먼저 피격 판정/타격 판정 개발을 시도하였습니다.

제가 알고 있던 피격/타격 판정 구현 방식은 하나였습니다.

Capsule Component를 생성하여 Collision을 적용한 뒤, 이를 Root Component에 붙이는 것.

가장 간단하지만 경험 상 공격을 하지 않더라도 Capsule Component만 닿으면 공격 판정이 들어가는 방식이었습니다.

이를 좀 더 그럴듯하게 구현하고 싶었습니다.

정말로 손이 닿아야지만 타격 판정이 일어나도록.

그러면서 몇가지 방법을 생각했습니다.

하나는 양 손에 타격용 Capsule Component를 붙인 뒤, 두 Component간의 collision을 체크하는 방법.

다른 하나는 손에 해당하는 socket을 직접 collision 체크 하는 방법.

우선은 후자가 가능한지 찾아 보다가 OnComponentBeginOverlap가 받는 변수 중 OtherBodyIndex를 발견하였습니다.

이를 이용하면 혹시 특정 소켓의 collision을 탐지할수 있지 않을까 싶어 AnswerHub에 질문을 올려놓았습니다.

만약 내일 답이 온다면 구현을 할 것이고, 불가능하는 답이 나오거나 답이 없다면 전자의 방식으로 구현을 할 것 같습니다.

앞으로 2주가 채 안남았는데 그 안에 모든 트리거가 구현이 될지 슬슬 걱정이되기 시작했습니다.

마지막으로, 테스트 중 한가지 버그를 발견했습니다.

달리던 도중 점프를 하면, 착지 후 이동속도가 매우 매우 느려지는 버그를 발견했습니다.

우선은 이슈로만 등록을 하였고, 고치는건 언제가 될지 모르겠습니다.

가능하면 마일스톤 먼저 해결을 하고 일정이 남으면 고쳐보려 합니다.

오늘 개발 해야 했던 부분은 점프 반복이었습니다.

하지만 이에 앞서 한가지 소름 돋는 일을 적어볼까 합니다.

저는 이전까지 프로젝트를 4.23 버전으로 개발 하다가, 이번에 4.24 버전으로 올렸습니다.

그런데 버전을 올리자 멀티플레이 기능이 마비가 되는 일이 발생 했습니다.

정확히는 다른 플레이어가 생성한 세션을 검색 할 때 남은 인원이 0으로 처리 되는 문제였습니다.

AActor의 Role 호출을 새로운 getter 함수로 바꿨을 뿐인데 이게 무슨 일인가 싶어 이것 저것 건드려 보다가 문뜩 이런 생각이 들었습니다.

"이거 생성은 잘 되는데 탐색 한 결과 출력이 이상한거 아니야?"

이를 확인하기 위해 해당 함수로 이동하자, 아뿔싸.

세션 탐색 후 이를 표기 할 때 최대 수용 인원 정보가 비어 있었습니다.

이를 제대로 고칠 수도 있었으나 언젠가는 P2P 방식에서 Dedicated Server로 변경할 예정이기에 당장 테스트가 가능하도록만 수정을 하였습니다.

그 후에 드는 생각.

"도대체 이전에는 어떻게 됐던 거지?"

버전을 내려서 테스트 하기에는 번거롭고 조금 기괴하고 소름 돋는 경험이었습니다.

다시 원래 작업으로 돌아와, 점프 반복입니다.

점프 키를 누르고 있으면 계속해서 점프가 되어야 하는데 애니메이션은 반복되는 반면, 점프 함수 자체는 1번만 출력이 되었습니다.

이전서부터 몽타주를 사용하는 방법을 알고 있었는데 다른 방법이 혹여 있나 하여 시간을 끌다 면접을 보면서 개발을 멈췄었습니다.

오늘은 몽타주를 적용해 보았습니다.

방식은 2가지가 있었습니다.

하나는 착지 몽타주가 끝날 때 점프 함수를 호출하는 것.

다른 하나는 점프 몽타주가 재생 되면 점프 함수를 호출하는 것.

이 두가지 방법을 Notify 없이 구현을 해보았습니다.

하지만 조건이 안 맞았는지 둘 다 제대로 적용이 되지 않았습니다.

개발을 멈추기 전에도 이 문제로 오랜 시간 고민을 했던터라 안되니까 갑자기 힘이 쭉 빠지더군요.

그래서 이 기능 자체를 차후 구현하는 것으로 변경하였습니다.

단순히 취미 같은것이 아니라 어느정도 기간 안에 성과가 뚜렷이 보여야 하는 상황이라 불가피하게 정한 결정입니다.

다행히도, 이 기능 구현을 뒤로 미루니 많은 부분이 해결이 되었습니다.

첫번째는 Git으로만 관리하던 프로젝트를 Github로 올릴 수 있었습니다. 

이전에도 가능은 했으나 현재 branch에서 작업이 남아 있어 이를 하지 않고 있었는데 작업을 미룬 후 드디어 Github에 올렸습니다.

덕분에 포트폴리오에는 링크로 대체를 할 수 있게 되었습니다.

두 번째는 작업 정리가 가능했습니다.

다음 일에 대해 생각을 하게 되니 자연스럽게 앞으로 해야 할 일들을 정리 하는 시간을 가지게 되었습니다.

현재는 이와 같은 형태로 이슈를 정리하고, 마일스톤을 짜 놓은 상태입니다.

이에 따라 수요일(화요일은 Mighty 개발 함)부터는 트리거 위주로 개발을 하면 될 것 같습니다.

트리거까지 구현이 완료되면 간단한 기능 영상을 촬영해서 공유해보겠습니다.

취준생 2년차에 들어섰습니다.

한 6개월 동안 개발했던 프로젝트인데 서류 쓰고 면접까지 보면 왠지 될것만 같아 중간중간 놓게 되었습니다.

하지만 몇번을 희망고문 당하다가 오늘 심하게 데이고 다시 개발을 시작할 준비를 하고 있습니다.

몇일 전에 학교 선배를 만났는데 꾸준히 개발 일지를 쓰라고 말씀해 주셨던게 기억났습니다.

예전에는 개발일지에 불규칙적으로 이슈가 끝나는대로 올렸습니다만

이제는 이슈 해결 여부와 관계 없이 좀 상세히 적어서 올려보려 합니다.

현재 Treasure Hunter는 기본적인 움직임에 대한 애니메이션이 구현되어 있습니다.

당장 해야 할 일은 점프 키를 눌렀을 때 연속 점프가 가능하도록 하는 것.

그리고 공격과 피격, 몇가지 트리거를 통한 상호작용 기능 구현입니다.

이 부분이 완료가 되면 이 프로젝트에서 가장 구현하고 싶었던 맵 자동 생성을 해볼 생각입니다.

그 이후에는 직업별 스킬 구현과 데디케이트 서버 쪽으로 생각 중입니다.

늘 목표를 크게 잡고 일정을 제대로 소화 못했는데 이번에는 꼭 좀 했으면 좋겠습니다.