20.07.20 개발일지

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

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

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

 

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