Memorize: RECALL (12) 썸네일형 리스트형 Weapon 초기화를 위한 새로운 설계 원래 Player와 AI의 Weapon 초기화를 BeginPlay에서 수행했다. 단말 Blueprint의 BeginPlay에서 직접 Wepaon을 생성하는 방식으로 동작하였고, 기존에는 큰 문제가 없었다. 그러나 Anim Montage 등의 각종 Animation Data를 Weapon에 종속적으로 하고, Unequip 상태를 나타내는 Dummy Weapon의 생성 과정에서 다수의 Bug가 발생했고, Refactoring을 감행했다. Refactoring 중 문제가 발생했다. Player와 AI에 모두 적용 가능한 무기 생성 코드를 어떻게 작성해야 할까? BeginPlay에서 수행할 경우, Unequip Weapon의 Getter를 제작해야 하며 Base Class -> Blueprint -> Child.. Runtime에 생성된 Anim Instance의 BeginPlay 추후 Ai 캐릭터의 확장 등을 고려하면 Anim Instance가 Mob의 종류마다 다를 필요가 있다. 그래서 Mob 설정을 저장하는 Data Table에 AnimClass Property를 추가하였다. Property의 추가 이후, 이를 적용하는 Blueprint를 작성하고 테스트하는 과정에서 문제가 발생했다. Mob의 Anim Instance는 BeginPlay가 호출되지 않는 것이었다. 이 때문에 필요한 Delegate를 Bind하지 못해서 모든 Character들이 Animation없이 A 포즈로 움직였다. 이를 해결하기 위해 평소처럼 Document를 찾아보며 Function의 Call Timing과 대체할 만한 다른 Function을 찾아보던 중 중요한 사실을 발견했다. Anim Instanc.. Blueprint의 BeginPlay는 BeginPlay가 아니다. Skill 클래스를 구현하던 중 C++로 작성한 Base Class BeginPlay가 Blueprint로 작성된 Child Class BeginPlay보다 늦게 호출되는 상황이 발생했다. 때문에 Child Class의 BeginPlay에서 User에 접근하면 값이 Null이어서 에러가 발생했다. Skill Class의 BeginPlay는 부모 함수 호출과 User 초기화 밖에 없기에 의심할 코드는 오직 부모 함수 호출이다. 그래서 Actor Class의 BeginPlay 코드를 뜯어보았다. 확인해본 결과 Actor의 BeginPlay는 크게 6가지를 수행한다. 잘 못된 호출인가를 검사하는 ensure문 LifeSpan 설정 Tick 함수 예약 컴포넌트의 BeginPlay 수행 ReceiveBeginPl.. Buff Storage 클래스를 설계한 이유 개요 스턴, 독 등의 부모 클래스인 Buff 클래스를 설계하는데, 고민해 볼 문제가 발생했다. 각 버프마다 각 캐릭터에 저장해야 할 정보가 있다. 대표적인 예시는 최대 5 스택까지 중첩되는 독이 있다. 그런데 이를 저장할 방법이 없던 것이었다. 접근 방법 우선 각 캐릭터마다 저장되는 버프에 '독립적인' 정보라는 점에서 static 변수를 먼저 생각하게 되었다. 그러나 static 변수는 캐릭터마다 독립적이지 못하기에 사용할 수 없다. 하지만 독립적인 변수라는 접근은 유지할 가치가 있었다. 그다음에는 '각 캐릭터마다 저장된다'는 점에 주목했다. 각 캐릭터마다 저장된다는 조건을 충족하는 가장 간단한 방법은 캐릭터의 멤버 변수였다. 그렇다면 '각 버프 클래스 별로 정보를 저장해야 한다.'라는 조건은 어떻게 충.. 이전 1 2 다음
