치킨 날다

오늘 Unreal 개발 하면서 너무 정신이 말렸는지 멀미가 나기 시작해 쉽니다.

오늘은 하루를 꼬박 투자해 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의 판정을 다듬을 것 같습니다.

https://www.acmicpc.net/problem/3300

버그가 나는 부분은 수정을 하였습니다.

탐색이 모두 끝날 때 되돌아 갈 위치가 없는데 받아오려 해서 문제가 생겼습니다.

몇가지 테스트를 하였는데 예시랑 맞지 않는 답이 출력되어 내일 자세히 디버깅을 해보려고 합니다.

원래 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 발생으로 해결을 해보고자 합니다.

오늘은 기본 Windows Application Template Project에 책에서 예시로 제시된 코드를 작성하려 했습니다.

그런데 DX11와 DX12가 생각보다 많이 다르더군요.

이론 부분은 검색을 하면 어느정도 나오는데 코드는 이게 잘 안됩니다.

가장 먼저 DX11에서 DX12로 넘어올 때 원래 있던 코드가 어떻게 바뀌었는지가 검색이 잘 안됩니다.

예를 들어서 ID3D11DeviceContext에서 하던 작업이 ID3D12GraphicsCommandList로 넘어 왔다던가.

dxerr.h의 DXTrace 함수가 사라진 것이라던가.

이 부분이 검색이 되어 인지가 되었다 해도 바뀐 이후에는
어떻게 작성해야 하는지 기반 지식 없이는 검색으로 숙지를 할 수 없었습니다.

여기서 DX11 책에 검색을 더해 DX12를 공부하는 것에 한계를 느꼈습니다.

그래서 DX12 책을 구매했습니다.

아마 내일 쯤 올텐데 내일 오후에나 올테니 오늘 내일은 더 진행할 수 없을 것 같습니다.

가능하면 금요일부터 상황을 봐서 진행하도록 하겠습니다.

오늘 마지막 남은 회사의 면접을 보느라 개발하지 못했습니다.

내일과 모래는 DirectX를 공부하고, 금요일에 마저 개발하겠습니다.

https://redchiken.tistory.com/209

면접을 갔다 오느라 많이 시간을 투자하지 못했습니다.

입력값을 처리하는 부분을 구현하였는데, 몇가지 index 오류가 발생하고 있습니다.

이 부분을 수정하면 생각한 방식이 옳은지, 시간 안에 동작 하는지 알 수 있을 것 같습니다.

https://www.acmicpc.net/problem/3300

어제도 상당히 복잡해서 하다가 말았는데 오늘도 역시 복잡했습니다.

꽤 시간을 투자 한 끝에서야 대략적인 구조를 완성 할 수 있었습니다.

일단 가정은 다음과 같습니다.

1. 비어있는 심볼에 공백 문자는 들어올 수 없다.

2. 비어있는 심볼 없이 일치하는 문장이 완성된다면 비어있는 심볼을 유일하게 유추할 수 없다.

사실 중요한건 2번입니다.

만약 2번이 성립하지 않으면 지금보다 더 복잡할 것입니다.

제가 생각하는 방식은 대략 다음과 같습니다.

1. 괄호가 열리면 높이를 1 증가시킨다.

2. 괄호가 닫히면 높이를 1 감소시킨다. 변화된 높이가 저장된 높이보다 1 작을 경우 입력 트리거를 킨다.

3. 알파벳('_' 포함)이 입력된 경우, 입력 트리거가 켜져 있으면 입력된 값을 Stack에 담는다.

4. '|'이 입력 되면 index를 저장하고 입력 트리거를 끈다.

5. 마지막 문자까지 연산이 마친 뒤 값을 비교한다.

문장에 '_'이 포함되어 있지 않고 예시 문자와 동일하다면 결과에 '_'를 저장하고 탈출한다.

문장에 '_'이 포함되어 있고 나머지 문자들이 예시 문자와 동일하다면 결과에 '_'에 대응하는 문자를 저장한다.

이 외에는 저장된 '|' index로 iterator를 이동시킨다.

현재 4번까지는 정리 되었고 5번만 구현해서 테스트를 하면 됩니다.

이렇게 구상한 이유와 기타 주의사항 등은 정답을 맞춘 뒤 작성하겠습니다.

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

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

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

원래는 바로 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하여 지정된 위치로 되돌릴 것입니다.

https://www.acmicpc.net/problem/3300

원래 Frogger를 풀려고 했는데 문제 해석까지만 되고 규칙을 찾지 못하여 다른 문제를 선택했습니다.

입력되는 직병렬 무어 기계와 입력값을 보고 지워진 심볼을 유추하는 문제입니다.

유추가 된다면 유추값을, 안 된다면 _를, 잘못된 입력 값이라면 !를 출력하면 됩니다.

처음에는 모든 경우에 대한 그래프를 만들어서 그래프 순회를 할까 싶었지만,
그래프 만드는 것 자체가 시간이 많이 드는 작업이라 시간 초과가 될 것 같았습니다.

그래서 Array로 Tree를 만들듯이 단순 순회로 입력을 조정해보려 합니다.

이에 대한 제대로 된 로직은 차후 짜보겠습니다.

어제서부터 피로가 쌓였는지 낮에도 비몽사몽해서 일찍 정리하고 하루종일 쉬려 합니다.