치킨 날다

오늘은 Attach 기능 중에서 Piece와 관련된 기능들을 9할? 정도 구현을 마무리했습니다.

우선 Attach Replicate는 Replicate Movement에 RPC함수를 Attach를 Character에 RPC로 감싸서 해결을 보았습니다.

물론 Replicate Movement도 중요했지만, 가장 중요한건 Character에서 RPC를 제공하는 것 같습니다.

RPC 함수를 사용하지 않았던 것은 아닙니다.

다만 Piece에서 제공을 했었는데 Piece에서 제공하면 문제를 해결할 수 없었습니다.

그 다음 문제는 Piece가 Attach 된 이후 이를 Detach 하면 원래 장소에서 나타나는 문제였습니다.

이는 확인해보니 FAttachmentTransformRule이 잘못되어서 그런 것이었습니다.

Actor의 Socket에 Snap 하도록 설정하면서 문제는 해결되었습니다.

그럼에도 1할 정도 남은 것은 두가지 문제가 남았기 때문입니다.

하나는 움직이면서 Actor가 Mesh를 막아서 움직임이 부자연스럽다는 점.

특히 Host에서는 움직임 자체가 기괴하고 조종 할 수 없게 왜곡되어버립니다.

최종적으로 Dedicate Server로 구현할 것이기에 Host에서의 문제는 미뤄두고,

일단 Actor가 Attach 될 때 크기가 줄어들도록 해보려 합니다.

물론 Detach 될 때는 크기가 늘어날 것입니다.

다른 문제는 Client에서의 끊김 문제입니다.

부자연스러운 움직임에 포함될 수도 있으나,
Replicate 동기화를 매 Tick마다 하면 부하가 걸린다는 얘기를 들었기에 이것이 원인이지 않을까 싶기도 합니다.

그래서 Replicate 동기화를 좀 더 드문드문 발생하도록 하는 것을 찾아보고, 적용할 계획입니다.

조건문을 수정해서 어느정도 동작은 하도록 만들었습니다.

하지만 일부 기능은 여전히 제대로 돌아가지 않았고,

무엇보다 Client에서 Attach한 것이 Server에는 정상적으로 적용되지 않았습니다.

이는 아무리 봐도 Replicate가 되지 않는 것으로 Attach의 Replicate를 처리하기 위해 이리저리 고민을 해보았습니다.

하지만 Attach/Detach에서 요구하는 Struct가 UStruct가 아니라서 UFUNCTION의 parameter가 될 수 없었고, 

이것이 모든 해결방안을 막고 있었습니다.

하루 종일.

말 그대로 24시간 고민을 하다가 Attach Replicate라는 것을 발견하였으나 정확히 파악하지 못했고, 

커뮤니티에 질문을 올렸는데 마침 이 문제를 잘 아는 사람이 답변을 해줬습니다.

정리하자면 다음과 같습니다.

1. Attach는 Movement Replicate가 보장되면 저절로 동기화 된다.

2. 다만 Attach가 Movement Replicate이면 Attach 된 후 Object의 움직임에 복잡한 연산이 Tick마다 발생한다.

3. 그러니 Attach는 Replicated로 해두고 Attach된 후에 움직임을 10 Tick에 한번 발생하는 정도로 빈도를 줄여야 한다.

4. Attachment는 RPC로 묶어야 한다.

결국 제 입장에서는

1. Attach를 Movement Replicate를 해두고, Attach가 된 후에는 이를 해제한다.

2. Object에 Attach가 붙으면 Tick 발생 빈도를 조금 줄인다.

3. Character에 RPC 함수를 만들어 Attach 관련 함수를 묶는다.

이정도로 해결을 해야 할 것 같습니다.

되는지는 해봐야 알겠지만 일단 이렇게 해보려 합니다.

오늘은 Attach 기능을 요구하는 AttachPiece, AttachLatch, Character의 Attach 기능의 Script를 작성하였습니다.

작성하면서 여러 종류를 고민하다보니 시간이 많이 흘렀지만, 그래도 하루만에 코드 부분은 대략 작성할 수 있었습니다.

하지만 실제로 테스트를 해보니 정상적으로 작동하지는 않았습니다.

그래서 다음에는 로그를 찍어보고 문제가 되는 부분을 탐색하여 수정하는 작업을 진행해야 할 것 같습니다.

왠지 새벽에 조금 해주면 주말 안에 끝날법도 해서 뭔가 안심이 된달까.

반환점이 하나 보이는 것 같습니다.

8월에는 리빌딩을 꼭 마무리 하고, 했던 작업이 아닌 안해봤던 작업.

데디케이트 서버 구축 단계로 넘어가고 싶습니다.

오늘은 Attach 관련 기능들을 구현하다가 시간을 다 보냈습니다.

우선 UniqueID로 관리하던 고유값을 ObjectName으로 교체했습니다.

어떤게 더 나을지는 시간이 지나봐야 알겠지만, 큰 문제는 없을 것 같습니다.

그리고 AttachLatch, Piece는 어느정도 기능 구현이 완료된 상태입니다.

다만 이를 테스트 하려면 Attach 기능이 Character에게도 구현이 되어 있어야 하는데, 

아직 이 부분을 완수하지 못했습니다.

우선 Interface의 포인터 형을 변수로 UPROPERTY 변수로 받지 못하는 부분에서 컴파일 에러가 발생하고 있습니다.

또한 Character는 Piece 뿐만 아니라 장비나 소모품과 같은 다른 Attachable도 취급하는데, 

이들에 대한 기준이 명확하지 않은 상태입니다.

그래서 Character 부분의 기능 구현에 하루 정도 더 투자를 해야 할 것 같습니다.

약 먹은 병아리 마냥 비실비실 거리다가

대규모 변경점으로 인한 기본 15분의 빌드시간들을 거쳐 겨우 무언가 해냈습니다.

우선 InRange 기능을 개선했습니다.

예전에 Notify와 관련해서 질문을 올린 글에서

"Character의 UniqueID를 Set으로 관리하면 되지 않느냐"라는 댓글이 올라왔습니다.

결과적으로 Notify가 없다면 원치 않은 HitEvent.

예를 들어 왼손 펀치 공격을 하는데 오른손에서 먼저 펀치 이벤트가 발생하는
불상사가 발생하기에 Notify는 꼭 필요합니다.

하지만 UniqueID와 Set은 썩 그럴듯하였고, 이를 적용해보았습니다.

하지만 직접 시도해본 결과, Set은 Replicate가 되지 않고

UniqueID의 타입인 uint32와 같은 numeric은 BP에서 지원하지 않았습니다.

그래서 두 차례 대규모 공사를 한 뒤, Set을 다시 Array로 되돌렸습니다.

다만 원래는 Object&를 지니고 있었으나, 이를 FString으로 교체해서 UniqueID를 적용은 유지 중입니다.

비록 FString이 uint32를 Fstring으로 형변환 해주지는 않지만, 일반 int32는 지원을 합니다.

unsigned int에서 signed int로 형변환 시 유일성이 훼손되지 않으므로, 이를 그냥 사용하고 있습니다.

그리고 나서 Latch와 관련된 기능들을 구현하였습니다.

이 부분에서 조금 혼동이 있었습니다.

기존의 Latch는 AttachLatch. 즉 무언가를 부착하는 기능만 구현을 했었습니다.

때문에 Latch와 AttachActivity의 기능을 계속 구분하지 못하고 몇번이고 작성과 지우기를 반복했습니다.

그러다가 Latch의 Check Answer는 정답 여부만 받아오도록 하고, 

AttachActivity. 즉 부착 주체는 부착과 해제. 그리고 각각의 가능 여부를 받아오도록 하였습니다.

부착 객체(Attachable)에게는 부착이 가능한지와,  현재 소유권자가 누구인지를 확인하는 기능을 부여했습니다.

이전 Latch와 Piece 안 기능들을 모두 지우고, 이를 사용하는 다른 코드에서 해당 내용을 주석처리 했습니다.

그리고 Latch와 Piece의 기능을 대략적으로 선언만 해두었고, 이를 상속받는 몇가지 Latch와 Piece를 생성했습니다.

기존 기획에서 바뀐 점이라면, 원래 Latch가 부착, 피격, Widget에 상호작용.

그리고 Piece는 부착을 생각하고 있었습니다.

하지만 피격 Latch. 즉 때려서 부숴야 하는 경우에는 상호작용을 할 수 없습니다.

때문에 이를 Piece로 옮겼습니다.

그래서 현재는 Latch에 부착, Widget. 그리고 Piece에 부착, 피격이 존재하고 있습니다.

이 과정에서 너무 많은 코드를 수정하여 오늘은 이쯤에서 일단락 했습니다.

내일은 Base 코드 안의 기능들을 구현하고, 부착 Latch와 Piece를 먼저 구현해보려 합니다.

이 다음에는 피격 Piece를 구현하고, 마지막에 Widget Latch를 구현하려 합니다.

Widget Latch는 간만의 Widget 작업이기도 하고, 아직 아무 생각이 없어 뒤로 미루었습니다.

가능하면 이번주 안에 두 기능이 완성되었으면 합니다.

오늘은 크게 무언가를 하지는 않고 간단하게 구현만 조금 했습니다.

우선 어제 새벽에 작성한 내용들을 담을 수 있는 Interface를 새로 선언했습니다.

가능하면 함수 선언도 해두려고 했으나 기능 구현에 대해
포괄적으로 적용 할 수 있는 형태를 아직 확립하지 못해 몇몇 부분을 보류하고 있습니다.

그리고 일전에 선언 해두었던 InRangeCharacter와 IObjectActivity Interface를 ActorBase와 Character에 적용하였습니다.

아무래도 내용이 많다보니 이 부분이 의외로 시간을 꽤 잡아먹었습니다.

마지막으로 Melee Attack의 판정을 개선했습니다.

Notify 발생 위치를 조절하고,
왼손 오른손을 햇갈려 했던 것을 명확히 하여 수정한 결과 비교적 만족스럽게 작동하고 있습니다.

가능하면 FSM을 관리하는 Sequential Interface도 미리 선언해두고 싶으나, 시간이 오래 걸릴 것 같습니다.

저번처럼 밤에 생각이 나면 맞춰보겠지만, 우선은 후순위로 미뤄두려고 합니다.

일단은 CheckAnswer 부분을 구현을 해볼까 합니다.

현재 생각나는 것은 물건 부착, 피격, Widget에 텍스트 입력을 생각하고 있습니다.

그 다음에는 Climb 기능을 먼저 구현하고자 합니다.

Trap보다는 아무래도 이미 완성된 기능들이다 보니 Climb를 먼저 정리하는 편이 더 적절하다고 생각합니다.

하면서 생각이 뚫리면 장애물을 넘어가는 기능도 조심스래 건드려볼 계획입니다.

그 다음에 Trap을 구현하고, Puzzle을 제작해보려 합니다.

조금 조급해져 주말에 개발하려다가 지원을 고민하는 회사에 지원하기로 마음 먹어 야밤에 글을 씁니다.

Trap과 Puzzle의 관계에 대해서 고민을 해보았습니다.

제가 개발하는 게임 내에서

Trap이란 유저의 진행을 방해하는 모든 장치들을 지칭합니다.

단순히 텔레포트, 총알 발사, 몬스터 소환, 방해물 설치서부터 시작해 여러 장치들이 복잡하게 발동되기도 합니다.

Puzzle이란 유저의 행동으로 해제가 가능한 모든 장치들을 지칭합니다.

Puzzle은 대체로 Trap을 동반하지만, 단순한 입력도 게임 내에서는 Puzzle로 취급됩니다.

Trap은 여러 Trap이 복합적으로 발동되더라도 기본적으로 각각의 Trap의 발동 조건이 변하지 않습니다.

하지만 Puzzle이 지니고 있는 Trap은 발동 조건이 바뀔 수도 있습니다.

예를 들어, 범위 안에 플레이어가 존재해야 발동하는 Trap의 경우,
Puzzle에 붙으면 그 범위가 Puzzle의 범위에서 발동해야 할 수도 있습니다.

이전 구조에서도 이 문제를 고민하면서 변경을 꾀했는데 현재 이에 대해 두가지 방안을 고민 중입니다.

1. 이 문제는 모든 Trap과 Puzzle의 SuperClass인 THActorBase가 태생적으로 Area를 지니고 있기 때문이다.

그러니 Puzzle에서 Trap들의 Area를 자신의 Area와 동일하게 지정하여
동일한 이벤트가 발생하는 대상을 Trap의 Area에서 Puzzle의 Area로 바꾸어 보려 합니다. 

이 방법의 가장 큰 장점은 나중에 기획을 하면서

Multiple Trap에서 Trap의 발동 범위가 바뀌는 경우에도 문제 없이 적용이 가능하다는 점입니다.

단점? 아니 문제점은 정상적으로 작동할지 아직 모릅니다.

2. Puzzle이 가지고 있는 Trap의 이벤트 함수를 모두 지운 뒤, 자체적으로 생성해서 다시 배정하는 방식입니다.

이는 구조 변경 전에도 동일하게 적용될 수 있는 방법이라 1번 방안에 비해 비교적 적절치 못하다고 생각합니다.

Trap과 Puzzle의 관계를 배정하면서 몇가지 추가되어야 하는 Interface가 있습니다.

첫번째로, FSM을 관리하는 Interface가 필요합니다.

여러 Trap들이 발동 할 때, 순차적으로 발동한다는 보장이 없습니다.

지름길이 있을 수도 있고, 실패 시 다른 Sequence로 움직여야 할 수 있습니다.

그리고 이러한 흐름을 관리하려면 FSM이 필요할 것이라 봅니다.

더불어서 FSM을 효과적으로 표현할 수 있는 자료구조 방식도 구상해야 합니다.

두번째로, CheckAnswer Interface를 다시 되살려야 합니다.

Puzzle의 복합적인 작동을 고려하다 보니 Check Answer 과정도 유일하다고 볼 수 없습니다.

때문에 Check Answer를 하는 Object를 종류별로 제작하고, Puzzle이 상황에 맞게 1개 이상 소유하도록 하려 합니다.

우선은 각 Interface들을 제작하고, Trap에 적용을 한 뒤 Trap과 Puzzle을 더 기획하려 합니다.

가능하면 Check Answer Object을 3가지 정도 만들고, Trap과 조합하여 여러 종류의 Puzzle을 생성해보려 합니다.

오늘은 하루를 꼬박 투자해 Melee Attack에 Interface를 적용하였습니다.

구현 방식은 다음과 같습니다.

1. Melee Attack 키를 누를 시 LayeredMotion 트리거가 켜집니다.

2. Animation FSM에서 동기화 된 LayeredMotion 트리거에 따라 Melee Attack Montage가 재생됩니다.

3. Montage가 재생되자마자 Left Hand HitBox의 Hit 판정 트리거가 켜집니다.

4. Montage의 적절한 중간 지점에서 Left Hand HitBox의 Hit 판정 트리거가 꺼지고,
한번 충돌 판정 난 객체들을 저장하는 Buffer가 비워집니다.

5. 3과 4사이에 HitBox가 무언가와 Collision이 발생했을 경우 HitBox의 Collision 이벤트가 발생합니다.

6. Collision 대상이 자기 자신(Character)와 다르고,
동일한 Melee Attack 모션 중 한번도 Collision이 발생하지 않았으며,
현재 Melee Attack 중일 경우 데미지를 계산합니다.

왜 처음 생각하고 개발 할 때는 엄청나게 복잡했는데 다 만들고 정리하니까 이리도 간단한지 모르겠습니다.

이런걸 이렇게 시간 들여서 만들었나 자괴감 들고 괴롭습니다.

이렇게나 못했다니...

Hit 판정 다음에는 Trap에 대한 것인데 여기에 대해 크나큰 고민이 있습니다.

Trap과 Puzzle의 관계에 대해서는 처음 구조를 구상했을 때부터 고민이 많았습니다.

우선 기본적으로 두 Object 모두 범위 판정이 필요하기에 THObjectBase를 만들고,
THTrapBase, THPuzzleBase는 이를 기반으로 만들어졌습니다.

그리고 Puzzle은 대체로 Trap 성분도 지니고 있기에 Puzzle이 Trap을 지니고 있어야 합니다.

여기서 Trap을 상속 받는 방법과 Trap을 Component로 가지고 있는 방법이 있는데 저는 후자를 택했습니다.

Puzzle과 Trap은 속성이 완전히 다르다고 생각하기 때문입니다.

여기서 한가지 문제가 발생하는데, Puzzle의 범위 판정 Component가 쓸모 없어졌습니다.

범위 판정을 이미 Puzzle이 가지고 있는 Trap이 하고 있기 때문입니다.

이를 Interface로 개선 하면서 관계에 대해 다시 고민을 하게 되었습니다.

Puzzle은 Trap을 가지고 하나만 가지고 있을 수도 있지만, 여러개를 가지고 있을 수도 있고, 없을수도 있습니다.

부착된 Trap도 Puzzle 범위와 동일하게 작동해야 할 수도 있고, 그렇지 않을수도 있습니다.

그래서 이 구조를 어떻게 해야 할지를 고민하다가, Trap과 Puzzle의 관계부터 다시 생각을 하게 되었습니다.

때문에 이에 대한 답을 내는데에 시간이 좀 걸릴 것 같습니다.

우선은 남은 시간 짬짬히 Melee Attack의 판정을 다듬을 것 같습니다.

원래 DirectX 공부를 하려다가 계획이 틀어져 늦게라도 개발을 하였습니다.

시간이 얼마 없어 많이 하지는 못했습니다.

InRange Interface를 상속 받는 HitBox를 생성해 보았습니다.

그리고 원래 계획은 각 Component마다 RPC 함수를 만들어 놓으려 했는데,

Component가 Character에 부착 될 예정이라 Character에 RPC 함수를 만들고, 
이 함수가 Interface의 함수들을 호출하도록 변경해 보았습니다.

여기까지 개발해보니 생각이 조금 바뀌었습니다.

원래는 각 Component가 자신이 접촉했던 Character를 관리하도록 했는데,
어차피 Character가 한 Character에게 한 모션에 1번만 타격이 가능합니다.

때문에 InRange Interface는 Character가 Implement 하도록 할 예정입니다.

남은 고민거리는 모션 별 판정 가능한 HitBox 지정입니다.

예를 들어 왼손 잽 공격을 할 때는 왼손의 HitBox만 타격이 가능해야 합니다.

오른발 발차기를 할 때는 오른쪽 다리의 HitBox들만 타격이 가능해야 합니다.

이를 HitBox에 Activate Interface를 부착하고 애니메이션 재생 때마다 Notify를 발생 시킬 것인지, 

충돌 함수를 따로 배정하여 각 함수별로 자신이 속한 Montage가 재생 중일 때 타격 판정을 발생시킬 것인지.

좀 더 고민을 해봐야 할 것 같습니다.

----------------------

이곳저곳 질문을 올렸는데 Notify가 생각보다 무거운 연산은 아니라고 합니다.

이 문제는 Notify 발생으로 해결을 해보고자 합니다.

사람은 역시 큰일이 나야 정신을 차리는가 봅니다.

과제 제출한 회사가 느낌이 좋아 요 몇일 멍하니 쉬면서 지냈는데 탈락해버렸습니다.

탈락하니까 손은 떨리고 기운은 빠지는데 머리는 더 잘 돌아가는 것 같습니다...

원래는 바로 Melee Attack을 건드려보려 했는데 저번에 선언했던 Interface 중 누락 된 것도 있고,
Interface가 혹시 모를 문제가 생길 수 있어 Movement(Locomotion, FullBody, Layered)와 관련된
Interface들을 먼저 적용해 보았습니다.

문서로 읽을 때에는 미처 깨닫지 못했는데 직접 해보니까 알 수 있던 것이 있었습니다.

하나는 Interface 함수는 virtual이나 BlueprintImplementEvent나 BlueprintNativeEvent 선언만 가능하다는 점.

때문에 RPC 함수를 선언 할 수는 없었습니다.

개인적으로 RPC함수까지 모두 Interface로 제공하고 싶었으나,
RPC 함수는 Class별로 선언하고 각 Client가 호출하는 함수만 Interface로 다형성을 제공하는 형태가 되었습니다.

이런 형태도 괜찮기는 하지만 아쉬운 것은 어쩔 수 없는 것 같습니다.

하지만 덕분에 THCharacterBase와 AnimInstance 사이에 존재하던 Coupling은 지울 수 있었습니다.

이쪽을 수정하는 김에 Movement와 관련하여 사용되지 않는 변수들을 삭제하였습니다.

또한 Jump를 누를 시 연속 Jump를 하지 못하여 1번만 가능하게 해놓은 것을 Animation Notify로 해결했습니다.

그리고 시간이 남아 Damage 관련된 Interface들을 선언하고 각각 Projectile와 Character에 부착했습니다.

아직 테스트는 하지 않았으나, 조만간 테스트가 가능할 것 같습니다.

그리고 이 부분이 아직 완전히 끝나지 않은 것이, Melee Attack 시 Damage 계산에 이 방식을 적용해야 합니다.

Melee Attack에 대해서는 고민이 많았습니다.

우선 Damage를 주는 Interface의 적용입니다.

이것을 Character에 적용한 경우 내부 함수가 복잡하게 계산될 가능성이 높았습니다.

그렇다고 Capsule Component에 붙이자니 새 Class를 만들어야 하고,
기능 선언이 Capsule Component와 Character 양 쪽으로 분할 될 수 있습니다.

여기서 저는 그래도 좀 더 정확한 판정을 위해 Capsule Component를 새로 만드는 쪽을 선택했습니다.

두번째로 Hit 이벤트 발생 위치입니다.

Hit 이벤트가 타격자에게 발생 할 경우 아무 문제가 없습니다.

하지만 피격자에게 발생할 경우 여태까지 생각했던 모든 것이 날라갈 수 있었습니다.

처음에는 테스트를 잘못 하여 피격자에게 발생하는 줄 알고 시간을 많이 날렸지만, 
제대로 테스트 해본 결과 다행히도 타격자에게 발생하고 있었습니다.

지금 제가 생각하는 Melee Attack 개선안은 다음과 같습니다.

1. ICheckInRangeCharacter를 구현하여 Semaphore 기능을 먼저 구성한다.
2. ICheckInRangeCharacter, Damage Activity, Capsule Component를 상속 받는 새로운 Component를 생성한다.
3. Character의 모든 Hit Component를 2의 Component로 교체한다.
4. Hit 이벤트 발생 시 Semaphore에 Character를 할당하고, 데미지를 계산한다.
   1. Notify를 이용해 주먹을 뻗을 때까지만 판정을 하고, 그 이후로는 판정이 불가능 하도록 할 수도 있다. 
5. Animation이 종료될 시점에 Notify를 발생시켜 Semaphore를 모두 리셋한다.

이 방식은 여러모로 장점이 있습니다.

첫째. 이후 Melee Attack이 확장 될 때에도 큰 문제가 없습니다.

콤보 어택은 필연적으로 Notify가 발생하는데,
각 Notify마다 어떤 Component가 Hit 판정이 가능하게 할 것인지 지정할 수 있습니다.

덕분에 얼마나 늘어나든 중복 타격이 될 가능성이 낮습니다.

둘째. 현재 굉장히 후한 판정을 줄여줍니다.

4.1.와 같이 어느 시점까지만 판정을 받을지 지정이 가능합니다.

때문에 무자비로 일어나는 타격 판정을 줄일 수 있습니다.

셋째. 공격 방식이 확장 가능합니다.

현재 Melee Attack은 오른손 펀치입니다.

이것이 콤보 어택이 되든, 다른 형태의 공격이 되든 판정은 Component가 합니다.

Character는 모션만 계산하고, 각 모션 때마다 어느 부위가 타격이 가능하게 할 것인지만 지정하면 됩니다.

때문에 얼마나 늘어나든 문제가 될 것이 없습니다.

이런 이유로 다음에는 ICheckInRangeCharacter를 먼저 구현하고, 이후 Child Capsule Component를 만들 계획입니다.

당일 시간이 된다면, Melee Attack까지 수정을 해서 마무리할 계획입니다.

그 이후에는 ICheckInRangeCharacter를 Trap에 적용하고, Trap 기능 완성에 필요한 Interface들을 우선 구현할 것입니다.

마지막으로 한가지 더 적어보자면, Projectile이나 Puzzle에 Pool을 적용하고자 합니다.

이들은 실제로 Spawn된 Actor가 작업을 모두 마치면 destroy되게 구현되어 있습니다.

하지만 실제 게임에서는 이들이 얼마나 많이 작동해야 할지 모릅니다.

만약 두번 이상 작동한다면, 그때부터는 수 많은 Actor를 Runtime 상에서 Spawn해야 합니다.

이 때문에 발생하는 부하를 막기 위해 작동을 마치면 InActive 상태로 두고,
Active 하기 전에 Reset하여 지정된 위치로 되돌릴 것입니다.