치킨 날다

오늘도 오버워치 리그 여파로 비실비실 거리다가 시간을 날렸습니다.

확실히 제가 유니티에 많이 미흡하긴 한가봅니다.

3년?  4년 전에 언리얼 엔진을 처음 사용 했을 때 겪었던 느낌을 그대로 느끼고 있습니다.

언리얼 엔진은 막히더라도 금방 해결법을 찾는데 유니티는 한번 막히면 그날 내리 막히니 비교되서 더 힘듭니다.

누군가 유니티 문서 잘 되어 있다고 그랬는데... 문서도 왠지 언리얼이 더 잘 나오는 것 같고 으음...

원래는 오늘 UI를 모두 만든 뒤 연결을 해보려 했는데 연결 부분을 먼저 만지다 보니까 하나 정도만 만들었습니다.

유니티 UI는 canvas 밑에 panel을 두고 그 밑에 botton이나 text를 두는 방식입니다.

간단하게는 UI별로 Scene을 따로 두는 것이지만 성능 저하가 심하다고 알고 있습니다.

그래서 하나의 Scene에서 여러 UI를 열었다 닫았다 하는 방법을 찾았습니다.

여러 시도가 있었고, 지금 정한 방식은 panel을 여러개 생성한 뒤 하나만 active 해놓고, 나머지는 버튼 이벤트에 따라 active, inactive를 해주는 방식입니다.

이 방식으로 정하니 다음 단계가 보였습니다.

첫째. 버튼 별 이벤트들을 어떤 방식으로 나눌 것인가. 하나의 파일에 둘 것인가 각자의 파일을 만들 것인가.

둘째. panel을 게임 시작 할 때 다 같이 생성해서 바로 inactive 하는 방법을 찾아야 한다.

이 두가지를 금요일에 좀 찾아봐서 해결하면 될 것 같습니다.

아마 두번째 문제를 해결 먼저 하고 첫번째를 해결할 것 같습니다. 아무래도 이벤트는 정리가 안되어서...

상당히 더뎌서 집중이 떨어지지만 여기까지 해 놓으면 그 뒤로는 좀 더 속도가 날 것이라 믿습니다.

오늘은 등만이 가능한 Actor들의 최상위 C++클래스인 THClimbBase와

현재 구현이 가능한 Rope와 Ladder의 C++ 상위 클래스인 THRopeBase, THLadderBase를 작성했습니다.

"작성"이라 한 이유는 아직 기능이 구현 됨을 확인하지 못했기 때문에...

그저께부터 시작한 오버워치 리그 때문에 생활 패턴이 좀 꼬였는데 이 때문에 오늘 체력이 많이 부족해 개발 시간이 적었습니다.

그래도 개발 양은 크게 차이가 없는 것 같습니다.

시간 부족하니까 양 채우려고 집중 해서 그런가...

이것 외에 평소와의 차이점이 한가지 더 있습니다.

바로 개발하면서 구조 개선이 되었다는 점입니다.

처음부터 좋은 구조를 바로 생각해 냈으면 더 좋았겠습니다만,

이전에는 하루 개발을 다 하고 자기 전에 개선된 구조가 생각이 났다면 오늘은 개발을 하고 잠깐 숨을 돌릴 때 개선된 구조가 생각이 났습니다.

구체적으로는 Character와 THClimbBase와의 Collision 시 필요한 트리거들과 이벤트 할당에 관한 것입니다.

처음 생각 했을 때에는 이 모든 것들을 THClimbBase에서 처리하도록 했습니다.

이벤트는 당연히 이 Actor 안에서 처리하고, 처리 과정에서 Character를 받아야 하니 트리거도 Actor 안에서 처리했습니다.

그런데 이를 개발하면서 트리거들 중 동일한 부분이 반복되었습니다.

그래서 이 부분을 함수로 묶었는데, 묶인 함수에서 선언하는 함수가 모두 Character의 함수들이었습니다.

게다가 원래 외부로 공개되지 않은 변수에 대한 Setter들을 선언해야 했습니다.

결국 트리거 처리를 Character에서 해주었습니다.

이 뒤로는 손쉽게 정리가 되었습니다.

상황 별로 차이가 나는 트리거 값들은 두가지로 나뉘었습니다.

현재 캐릭터가 처한 상황을 나타내거나, 캐릭터가 collision을 하는 Actor를 가르키거나.

전자는 파라미터로 Actor 안에서 넘겨주었고, 후자는 THClimbBase를 상속 받는 THRopeBase와 THLadderBase에서 Character의 트리거 처리를 wrapping하는 함수를 override한 뒤 해당 설정을 추가했습니다.

Unreal을 쓰면서 정말 간만에 기존에 알던 구조로의 개발을 고민하고 적용해본 것 같습니다.

이 뒤로는 각 Base Actor를 상속받는 BP Example들을 만든 뒤 맵에 추가했습니다.

다만 컴파일 에러가 없을 뿐 기능 확인은 아직 못한 상태입니다.

수요일, 목요일동안 이 부분을 처리해 구현을 할 예정입니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

오늘은 메인 UI에서 버튼 이벤트를 붙여보았습니다.

다행히도 어제 주문한 책이 모두 배달 와서 이것 저것 보면서 시도해볼 수 있었습니다.

또한 책과 검색을 통해 대략적인 Unity의 개발 방식을 이해할 수 있었습니다.

그래도 아직은 언리얼 개발 때만큼 집중이 되지는 않습니다.

좀 더 집중있게 하여 하루에 더 많은 일을 진행 할 수 있으면 합니다.

다음 주에 할 일은 두가지 정도로 생각하고 있습니다.

하나는 메인 UI에서 Next, Preview 버튼을 누를 시 텍스트 뿐만 아니라 실제 아바타에 이미지를 추가하는 기능을.

다른 하나는 멀티플레이 기능을 제외하고 세션 생성 또는 탐색 시 새로운 UI를 띄우는 기능을 구현하고자 합니다.

이와 동시에 시간이 남으면 블루투스로 구현 하고자 하는 멀티플레이 방식의 구현 방식과 테스트 방식을 고민해보려 합니다.

오늘은 어제 개발 했던 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은 아마도 제외를 해야 하지 않을까 예측합니다.

오늘은 UI 이벤트에 필요한 기능들을 정리하였습니다.

한 3시? 쯤에 개발을 멈춘것 같습니다.

개발 일지 적은지 열흘 정도 된것 같은데 여러모로 집중이 떨어지네요.

일단 익숙치 않으니까 손에 잘 잡히지가 않습니다.

그러다보니 모르는 부분이 생기더라도 흥미가 계속 떨어지는 느낌입니다.

주말에 입문서 몇 개를 구매 하였는데 품절되어 배달이 꽤 늦을 것 같습니다.

금요일 전에 온다면 책을 읽으면서 조금이라도 개발을 해보고, 그보다 늦는다면 금요일도 개발을 잘 못할 것 같습니다.

유니티... 익숙치 않아서 그런 것일수도 있지만 처음 스크립트 언어 썼을 때와 같은 느낌입니다.

막막하네요.

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

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

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

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

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

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

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

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

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

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

기능이 제대로 구현이 되었는지 판단을 하기 위해 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를 중심으로 몇몇 기획서를 다시 작성하려 합니다.

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

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

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