사람은 역시 큰일이 나야 정신을 차리는가 봅니다.
과제 제출한 회사가 느낌이 좋아 요 몇일 멍하니 쉬면서 지냈는데 탈락해버렸습니다.
탈락하니까 손은 떨리고 기운은 빠지는데 머리는 더 잘 돌아가는 것 같습니다...
원래는 바로 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 개선안은 다음과 같습니다.
- ICheckInRangeCharacter를 구현하여 Semaphore 기능을 먼저 구성한다.
- ICheckInRangeCharacter, Damage Activity, Capsule Component를 상속 받는 새로운 Component를 생성한다.
- Character의 모든 Hit Component를 2의 Component로 교체한다.
- Hit 이벤트 발생 시 Semaphore에 Character를 할당하고, 데미지를 계산한다.
- Notify를 이용해 주먹을 뻗을 때까지만 판정을 하고, 그 이후로는 판정이 불가능 하도록 할 수도 있다.
- 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하여 지정된 위치로 되돌릴 것입니다.