치킨 날다

이렇게 이른 시간에 일지를 작성하는 이유는 어제 잠을 자지 않고 이미 12시간 넘게 개발을 했기 때문입니다.

Attach 기능들에 대한 대대적인 수정을 통해 원래 구현하고자 했던 내용들은 구현을 하였습니다.

그 결과 Attach와 관련된 6가지 기능 중 Attach, Detach, Re-Attach는 완벽하게 작동을 하고 있습니다.

다만 Latch와 관련된 기능 중 Attach to Latch는 작동은 하나

작동 이후 Attach 된 Piece가 계속 Collision이 발동된다는 문제가 발생하고 있습니다.

Collision을 계속 건드려주고 있는데 문제를 해결하지 못해 다음에는 bActive 값을 이용해보려 합니다.

OnPiece/LatchStart/EndOverlap에서 대상의 bActive를 확인하고, Attach/Detach 과정에서도 이를 좀 다뤄볼까 합니다.

오늘 저녁도 제대로 잘 것 같지는 않으니 일지를 적고 좀 쉬었다가 하려고 합니다.

갑자기 무슨 바람이 들었냐고 물으신다면,

다음주에 면접 볼 회사 중 한곳에서 이 프로젝트의 현재 코드를 보고 싶다고 요청이 들어왔습니다.

이대로 제출할 수도 있으나, 개발하던 것은 마무리하고 제출하고 싶은 욕심이 있어 시간을 더 투자하고 있습니다.

주말 안에는 Attach 기능이 다 구현 되었으면 합니다.

오늘은 Latch와의 상호작용을 고치려다가 Attach 기능 전반을 다시 만지게 되었습니다.

Latch와의 Attach가 안되는 이유는 Detach를 한 후 Object가 탐색이 되지 않았기 때문입니다.

저는 이 Object를 Output이라는 파라미터에 저장하려 했는데, 저장이 되지 않았습니다.

이를 OverlappedPiece로 우회할까 싶기도 했는데 이 방법도 통하지 않아, 결국 조금씩 함수 기능을 수정하고 있습니다.

우선 Output을 받는 것을 모두 없애고, Attach/Detach 함수들은 기본적인 Attach, Detach만 담당하도록 하였습니다.

그리고 Collision, Visibility 등을 Interface에서 제공하도록 하였습니다.

구현은 아직이지만, 일단 이런 방식으로 하여 값을 변경하려 합니다.

일이 늘어나긴 했지만, 뭔가 전반적으로 다 고치다 보니 2보 전진을 위한 1보 후퇴 느낌입니다.

그리고 한 회사에서 면접 제의가 왔는데,
지금 이 프로젝트의 현재 코드를 보고 싶다고 하여 토요일 일요일 새벽에 무리를 해서라도 마무리 하고자 합니다.

이번에는 반드시 주말 안에 Attach 기능을 마무리 하도록 하겠습니다.

오늘은 Attach 되는 Piece의 크기와 Collision을 조절해서 Attach 후 움직임에 방해가 없도록 하였습니다.

움직이면서 버벅이는건 Piece에 다리가 걸려서 그런 것이었습니다.

이를 Collision과 크기로 조절하니 굳이 동기화 주기를 맞출 필요는 없었습니다.

물론 나중에는 고려해야 하겠지만 아직까지는 패스 해도 될 것 같습니다.

그리고 Detach 시 HoldingPiece를 OverlappedPiece로 저장해 Detach 후 바로 Re-Attach가 가능하도록 하였습니다.

이후 Attach to Latch 과정에서 오류가 발생했는데,

Detach 후 Piece를 변수에 저장하는 것이 제대로 작동하지 않았습니다.

이 부분을 수정해서 Latch에 제대로 저장이 되도록 해보겠습니다.

내일은 이 Latch와의 상호작용을 테스트해볼 것입니다.

우선 비어 있는 Latch에 Piece를 Attach하는 것.

그 다음은 Latch에 Attach된 Piece를 가져오는 것.

그 뒤에는 두 Piece간의 Exchange와 Latch에 Attach된 Piece와의 Exchange를 테스트 할 것입니다.

이후에는 Piece와의 상호작용 시 Text를 화면에 출력해서 간이로라도 결과가 확인이 되도록 할 것입니다.

오늘은 Attach 기능 중에서 Piece와 관련된 기능들을 9할? 정도 구현을 마무리했습니다.

우선 Attach Replicate는 Replicate Movement에 RPC함수를 Attach를 Character에 RPC로 감싸서 해결을 보았습니다.

물론 Replicate Movement도 중요했지만, 가장 중요한건 Character에서 RPC를 제공하는 것 같습니다.

RPC 함수를 사용하지 않았던 것은 아닙니다.

다만 Piece에서 제공을 했었는데 Piece에서 제공하면 문제를 해결할 수 없었습니다.

그 다음 문제는 Piece가 Attach 된 이후 이를 Detach 하면 원래 장소에서 나타나는 문제였습니다.

이는 확인해보니 FAttachmentTransformRule이 잘못되어서 그런 것이었습니다.

Actor의 Socket에 Snap 하도록 설정하면서 문제는 해결되었습니다.

그럼에도 1할 정도 남은 것은 두가지 문제가 남았기 때문입니다.

하나는 움직이면서 Actor가 Mesh를 막아서 움직임이 부자연스럽다는 점.

특히 Host에서는 움직임 자체가 기괴하고 조종 할 수 없게 왜곡되어버립니다.

최종적으로 Dedicate Server로 구현할 것이기에 Host에서의 문제는 미뤄두고,

일단 Actor가 Attach 될 때 크기가 줄어들도록 해보려 합니다.

물론 Detach 될 때는 크기가 늘어날 것입니다.

다른 문제는 Client에서의 끊김 문제입니다.

부자연스러운 움직임에 포함될 수도 있으나,
Replicate 동기화를 매 Tick마다 하면 부하가 걸린다는 얘기를 들었기에 이것이 원인이지 않을까 싶기도 합니다.

그래서 Replicate 동기화를 좀 더 드문드문 발생하도록 하는 것을 찾아보고, 적용할 계획입니다.

조건문을 수정해서 어느정도 동작은 하도록 만들었습니다.

하지만 일부 기능은 여전히 제대로 돌아가지 않았고,

무엇보다 Client에서 Attach한 것이 Server에는 정상적으로 적용되지 않았습니다.

이는 아무리 봐도 Replicate가 되지 않는 것으로 Attach의 Replicate를 처리하기 위해 이리저리 고민을 해보았습니다.

하지만 Attach/Detach에서 요구하는 Struct가 UStruct가 아니라서 UFUNCTION의 parameter가 될 수 없었고, 

이것이 모든 해결방안을 막고 있었습니다.

하루 종일.

말 그대로 24시간 고민을 하다가 Attach Replicate라는 것을 발견하였으나 정확히 파악하지 못했고, 

커뮤니티에 질문을 올렸는데 마침 이 문제를 잘 아는 사람이 답변을 해줬습니다.

정리하자면 다음과 같습니다.

1. Attach는 Movement Replicate가 보장되면 저절로 동기화 된다.

2. 다만 Attach가 Movement Replicate이면 Attach 된 후 Object의 움직임에 복잡한 연산이 Tick마다 발생한다.

3. 그러니 Attach는 Replicated로 해두고 Attach된 후에 움직임을 10 Tick에 한번 발생하는 정도로 빈도를 줄여야 한다.

4. Attachment는 RPC로 묶어야 한다.

결국 제 입장에서는

1. Attach를 Movement Replicate를 해두고, Attach가 된 후에는 이를 해제한다.

2. Object에 Attach가 붙으면 Tick 발생 빈도를 조금 줄인다.

3. Character에 RPC 함수를 만들어 Attach 관련 함수를 묶는다.

이정도로 해결을 해야 할 것 같습니다.

되는지는 해봐야 알겠지만 일단 이렇게 해보려 합니다.

오늘은 Attach 기능을 요구하는 AttachPiece, AttachLatch, Character의 Attach 기능의 Script를 작성하였습니다.

작성하면서 여러 종류를 고민하다보니 시간이 많이 흘렀지만, 그래도 하루만에 코드 부분은 대략 작성할 수 있었습니다.

하지만 실제로 테스트를 해보니 정상적으로 작동하지는 않았습니다.

그래서 다음에는 로그를 찍어보고 문제가 되는 부분을 탐색하여 수정하는 작업을 진행해야 할 것 같습니다.

왠지 새벽에 조금 해주면 주말 안에 끝날법도 해서 뭔가 안심이 된달까.

반환점이 하나 보이는 것 같습니다.

8월에는 리빌딩을 꼭 마무리 하고, 했던 작업이 아닌 안해봤던 작업.

데디케이트 서버 구축 단계로 넘어가고 싶습니다.

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

Graph 순회 방법을 대충 맞추어서 정리를 합니다.

하나는 String을 두어 Push_Back과 erase로 정답을 산출.

그리고 두개의 Stack을 두어 하나는 순회를 하고 다시 되돌아 올 Index를 저장.

다른 하나는 되돌아 왔을 때 어느 Node로 넘어가야 하는지를 알려주는 Stack입니다.

지금 개발중인 기능을 마무리 하고 8월 중으로 여러 회사들에 입사지원서를 쓰기 위해 언리얼 개발에 더 전념중입니다.

그러다보니 알고리즘 풀 체력이나 정신력이 부족해 한 문제를 몇 주씩 물고 늘어지게 되는 것 같습니다.

여태까지 못푼 문제들 위주로 잡다보니 어려운 것도 한 몫 하고 있긴 합니다만.

빨리 못푼 문제 다 털어버리고 부족한 부분을 더 다잡고 싶습니다.

오늘은 Attach 관련 기능들을 구현하다가 시간을 다 보냈습니다.

우선 UniqueID로 관리하던 고유값을 ObjectName으로 교체했습니다.

어떤게 더 나을지는 시간이 지나봐야 알겠지만, 큰 문제는 없을 것 같습니다.

그리고 AttachLatch, Piece는 어느정도 기능 구현이 완료된 상태입니다.

다만 이를 테스트 하려면 Attach 기능이 Character에게도 구현이 되어 있어야 하는데, 

아직 이 부분을 완수하지 못했습니다.

우선 Interface의 포인터 형을 변수로 UPROPERTY 변수로 받지 못하는 부분에서 컴파일 에러가 발생하고 있습니다.

또한 Character는 Piece 뿐만 아니라 장비나 소모품과 같은 다른 Attachable도 취급하는데, 

이들에 대한 기준이 명확하지 않은 상태입니다.

그래서 Character 부분의 기능 구현에 하루 정도 더 투자를 해야 할 것 같습니다.

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

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

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

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

예전에 시도 했는데 풀지 못하고 보류 했던 문제입니다.

문제를 정리하자면

1. 개구리는 가로세로로만 움직일 수 있으며, 인접한 다른 개구리를 밟고 그 개구리의 다음 좌표로 이동할 수 있다.

2. 밟힌 개구리는 터져 죽는다.

3. 파리는 {(x, y) | x >= 0, y = 0}에, 개구리는 {(x, y) | x < 0, y = 모든 정수}에 위치한다,

4. 좌표별 파리를 먹을 수 있는 개구리의 최소 숫자를 출력하라. 불가능 할 시 Frogger 출력.

이렇습니다.

처음 접했을 때도 4 이후로 규칙을 찾을 수 없어 고민을 하다가 멈췄습니다.

그러다가 심심해서 커뮤니티에 올려봤는데, 누군가가 풀이를 적어줘서 보고 이해를 할 수 있었습니다.

https://github.com/marteloge/Programming-contests/blob/master/IDI%20Open/solutions/2007%20solutions.pdf

요약을 하자면 이렇습니다.

1. 개구리는 가로와 세로로만 움직일 수 있으니 개구리와 파리와의 거리는 맨하튼 거리로 표시한다.

2. 개구리들과 파리와의 가중치의 합을 구한다. Sum(K^d) = D_fly라고 봐도 무방할 것이다.

3. 위 과정을 거치면 개구리와 파리의 평면이 하나의 방정식으로 표시된다.

4. 하지만 5차 이상의 방정식은 근의공식이 존재하지 않는다.

https://m.blog.naver.com/PostView.nhn?blogId=iphone_dev&logNo=80145256483&proxyReferer=https:%2F%2Fwww.google.com%2F

5. 그렇기에 우리는 거리가 0~4일 때의 값만 작성을 하고, 그 위의 값은 frogger를 출력하면 된다.

Mathematics 문제는 항상 이런 문제? 매력?이 있습니다.

모르면 절대로 죽었다 깨어나도 풀 수 없지만, 풀면 그 쾌감이 다른 문제보다 더 강렬합니다.

하지만 이 문제는 가중치 계산을 하는 것에 전혀 다가가지 못해서 결국 이렇게 보고 풀 수 밖에 없던 것 같습니다.

#include <iostream>

using namespace std;

int main()
{
    const int Mem[5] = { 1, 2, 4, 8, 20 };
    int times = 0, input = 0;
    cin >> times;
    while (times-- > 0)
    {
        cin >> input;
        if (input < 5)
        {
            cout << Mem[input] << endl;
        }
        else
        {
            cout << "frogger" << endl;
        }
    }
    return 0;
}