20.07.29 개발일지

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

대규모 변경점으로 인한 기본 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 작업이기도 하고, 아직 아무 생각이 없어 뒤로 미루었습니다.

 

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