김환의 프로그래밍 블로그

최종프로젝트때 본인이 작업해야할 내용 1) 캐릭터들에 대한 에셋을 Blender를 통해 작업.  : Tripo 3D등의 AI툴을 활용한 로우폴리 모델링을 UV가 정리된 형태로 제공받을 예정. 2) 깃허브 관리  : Git에 대한 규칙을 세우고, 코드 컨벤션을 수립. 3) '지휘관' 캐릭터에 대한 기본적인 작업  : 지휘관을 추가하여 이동, 건설, 스킬 등의 호출명령을 추가하기. 실제 명령수행에 대해서는 팀원이 이어받아 작업할 예정. 4) 그 외 코드설계에 대한 고문  : 팀원들이 코딩에 대해 물어보는 내용에 대해 성실히 답해주기. 문제 발생 시 조언 및 보조.

기술 면접 1. 면접관의 눈을 맞출 것 2. 다리 떨지 말것, 삐딱하지 있지 말 것, 손제스처도 최소화할것 (불안함을 감출 것) 3. 추측성 발언 금지 (모르면 모른다고 해야함) 4. 긴장으로 인해서 질문에 대답하기 어려운 상태라면 솔직하게 긴장된다고 말하고 시간요청을 하거나(1~2분) 물을 길게 마시는 핑계(20초 등) 등을 대서 시간을 버는 것이 좋다. 5. 지식 아는척, 잘난척, 자랑 금지!! 

A* 알고리즘 게임에서 다익스트라를 그냥 쓰기 어려운 이유 파란 칸 = 다익스트라가 확정한 칸 - 목적지(E) 반대쪽 왼쪽 끝까지 다익스트라를 사용할 경우, 목적지를 찾기 위해 사방을 전부 뒤져야 한다. 목적지(E)는 오른쪽에 있는데, 출발지(S)에서 왼쪽까지 찾게 된다. 빈칸 217개 중 185칸을 확정해서 16걸음짜리 경로 하나를 얻은 셈이다. 하지만 게임에서는 이는 비효율적이다.  - RTS 장르: 유닛 100명을 움직이면 길찾기를 100번 수행한다.  - 추격하는 적: 플레이어가 움직일 때마다 경로를 재계산한다. 일반적으로 길을 찾을때는, "목적지가 동쪽이면 일단 동쪽으로" 간다. 이러한 대략의 감 을 수치화하여 다익스트라에 추가 한 것이 A*(에이스타) 이다. ※ A*: 1968년도, 거의 모든 게임 길찾기의 표준 알고리즘. A*의 원리 다익스트라는 동심원 확산 - 방향이 없음 다익스트라는 "출발점에서 가까운 순서로만" 확정하니 목적지 방향과 관계없이 사방으로 퍼진다. 다익스트라의 확정 기준은 "미확정 중 g가 가장 작은 칸"  : 목적지는 없음. 뒤(온 거리)는 알지만, 앞(남은 거리)은 보지 않음. 휴리스틱 h - "대략 얼마나 남았나" "남은 비용"을 정확히 알면 이미 최단경로를 아는 것 (즉, 불가능함) 하지만 어림 은 할 수 있다. 이 어림값이 이름이 휴리스틱(heuristic), 기호로 h 이다. h = "이 칸에서 목적지까지, 대략 얼마나 남았나"의 추정값. 맨해튼 거리 - 세로 차이 + 가로 차이 뉴욕 맨해튼의 바둑판 도로에서 딴 이름 - 대각선 없이 가로·세로로만 걸을 때의 거리 이다. (칸 안 숫자 = n에서부터의 걸음) h = |세로 차이| + |가로 차이| = 2 + 4 = 6 n에서 E까지: 아래로 2칸, 오른쪽으로 4칸, 벽이 있든 없든 이 계산은 똑같다. (장애물 무시)

첫번째 최종 팀 프로젝트 무산 지난 주, 나는 리더자격으로 최종프로젝트로 스타일리쉬 액션게임 '프로젝트 에러시티(가칭)' 을 신청했으나, 결국 나의 팀에 들어오는 이는 아무도 없었다. 분명 작성한 홍보글 마저 강사님이 문제없다고 말씀하셨음에도 결국 끝까지 아무도 찾아오지 않았다. 팀원이 모이지 않은 이유로, 주변 수강생들로부터 여러 이유를 들었었다. 본인 취향에 맞지 않는다 , 자기 실력에 비해 어려워 보인다 , 이미 틀이 잡혀있어서 함께 방향성을 잡을 기회가 없었다 . 홍보글 작성이 너무 느렸다 . 등이 있었다. 사실 본인 취향이야 어쩔 수 없지만, 본래 내일배움캠프는 교육기관이기 때문에 모르는 것이 있으면 차차 배워가면서 제작하는 것이 옳다고 생각하고, 나 또한 모르는 것이 있으면 이것저것 알려주면서 방향성을 제시할 예정이었다. 또 이미 내용이 정해져 있었다고는 해도 모집이 되면 추후 조율하면 그만이라고 생각했었지만, 무엇보다도 "홍보글 작성이 너무 느렸다" 는 것이 가슴에 와닿았다. 최종 프로젝트는 최종강의 발제와 동시에 팀 모집이 시작되었다. 모집 홍보글을 작성하라는 공지가 올라오고 나는 강사님과 매니저분들의 조언을 받아 하루동안 홍보글을 작성하고 있었지만 , 발제 직후에 이미 상위급의 실력을 갖춘 사람들은 이미 팀이 꾸려져있었고, 홍보글을 작성하는 대신 주변의 함께 했던 팀원들과 접선해 팀을 꾸린 사람들이 수강생의 절반 이었다. 그리고 다른 수강생의 절반은 상대적으로 실력이 낮아 내성적이거나, 팀 프로젝트 자체에 관심이 없는 사람들 뿐이었다. 분명 발제 직전까지 최종 프로젝트 팀 사전 구성은 공식적으로는 금지였는데, 뒤로는 알음알음 서로 친분을 쌓아가며 그룹을 형성하고 있었던 것이다. 나는 정직하게 홍보글을 작성하여 팀원을 모집해봤지만 한 명도 오지 않았고, 홍보글이 부실했던 팀은 이미 모집이 완료되어 있는 역설적인 상황에 나는 운영 시스템의 빈틈이 노려진 듯한 기만을 당한 느낌을 받았다. 실제로 나를 포함해 홍보글을 ...

NavMeshBoundsVolume AI컨트롤러가 탑재된 캐릭터가 길을 찾게하는 볼륨. 프로젝트 세팅 에서 Static / Dynamic / DynamicModifiersOnly 로 내비메시 사용방법을 설정 가능하다.  - Static     : 내비게이면 메시가 오프라인에 생성되어 레벨과 함께 저장.     : 런타임에 로드만 되며, 메시가 변경되지 않음.  - Dynamic     : 내비게이션 메시가 오프라인에 생성되어 저장되거나, 런타임에 새로 생성됨.     : 런타임 중 내비게이션 관련 데이터 변경 시, 변경된 타일에서 메시가 재생성되어 업데이트.  - DynamicModifiersOnly     : 내비게이션 메시는 오프라인에서 생성되어 레벨과 함께 저장.     : 런타임에서는 내비게이션 영역, 링크, 동적 오브젝트 등과 같이 메시의 일부만 수정하여 업데이트.     : 새로운 메시 표면은 생성되지 않음. 콜리전 데이터 캐시를 통해 타일 처리 비용을 최대 50% 절감.    주의)  DynamicModifiersOnly는 영향을 줄 액터 내에 'NaviModifierVolume' 이 존재해야 한다. ※ 세 가지 타입의 장단점을 신중히 고려하여 사용해야한다. 캐릭터의 이동에 따라 내비메시를 동적생성하는 방법 NavigationInvoker 컴포넌트는 이를 가진 액터의 주변에만 내비메시를 연산하도록 유도할 수 있다는 특징이 있다. 이를 통해 연산 비용을 절감할 수 있을 것이다. 내비게이션 메시에 장애물 등록 NavModifierVolume을 월드 내에 추가해 Movable로 설정하고, 영역 클래스를 Obstacle로 설정해주면 해당 영역의 이동비용이 증가하여 AI가 해당 영역으로의 이동을 피하게 할 수 있다. ※ 특정 포인트를 가리키는 액터가 필요하다면 TargetPoin...

최종프로젝트 인원 모집 고급 기술 과정 챕터가 발제된 직후 최종프로젝트 팀 모집이 시작되었다. 발제하자마자 너무 빠르게 시작된 팀 모집이었기에 팀 홍보글 작성능력이 부족했던 나는 강사님에게 도움을 청해 홍보글 작성 요령에 대해 물어보았다. 이미 기본적으로 생각해둔 에셋이나 스토리라인이 있긴 했지만, '어떤 것을 만들 것인지' 머릿속에 든 생각을 꺼내는 것이 어려웠다. 우선 강사님은 팀원이 홍보글을 봤을때 세부적인 내용보다는 '내가 무엇을 담당할 수 있을지', '내가 이 팀에 들어가도 괜찮은 것인지' 판단하는 것이 우선이라고 하였다. 그래서 긴 시간의 상담을 받고 내 나름대로 홍보글을 작성해보았다. 프로젝트 에러시티(가제) 🔥 프로젝트 한 줄 소개 니어 오토마타나, 스텔라 블레이드 같은 서브컬쳐류 스타일리쉬 액션게임을 목표로 하고있습니다.   1️⃣ 프로젝트 개요 프로젝트 목적 : 스팀 출시 아이디어 요약 : 최대 2인 멀티플레이 가 가능한 스타일리쉬 액션 게임. 주요 게임 흐름: 스테이지시작→필드전→보스전→결과창 근접콤보를 구사하며 에너지를 충전하고 특수기술을 사용해서 가로막는 적들과 보스를 쓰러트리는 게임. 주요 기능 (이러한 요소들을 넣고 싶습니다!) : 레퍼런스: 스텔라 블레이드 약공격/강공격을 조합해 본인이 조합하고 싶은 콤보를 구사. 적 타격으로 에너지(BE게이지)를 충전, 스킬을 사용하여 에너지를 소모. 결정타로 다이나믹 카메라 연출, 특수 스킬을 통해 카메라연출 사용. 레퍼런스: 니어 오토마타 스테이지 진행 중 대화문 출력 부위 파괴 시스템 (부위파괴 시 슬로우모션 출력, 패턴 약체화 등) 해킹 등의 채널링 액션 그 외 주요기능 리슨서버 기반 멀티플레이 사용예정 에셋 (진행하면서 추가될 예정): 캐릭터(에어) 에셋: https://sqinc.booth.pm/items/4836044 캐릭터(데벨) 에셋: https://sqinc.booth.pm/items/327...

최종프로젝트 에셋 준비  현재 최종 프로젝트는 시작하지 않았지만, 조만간 시작에 대비하여 최종 프로젝트의 구성에 대한 구상을 하고 있다. 이전에도 이미 수차례 상상하였지만, 이제 그 내용을 머릿속에서 꺼낼 때가 온 걸지도 모르겠다. 내가 생각하고 있는 장르 그대로 진행될 수 있을진 모르겠지만, 미리 준비해둔 두 에셋으로 캐릭터를 만들고 그에 기반한 배경을 가진 액션장르를 만들고 싶다는 생각을 쭉 했었다. 각각 Vroid에서 구매한 소품으로 커스터마이징된 캐릭터 에셋이며, 왼쪽은 피직스 본도 이미 어느정도 구현해둔 상태이다. 본래 왼쪽 캐릭터만으로 진행할 게임을 계획하고 있었지만, 아무래도 포트폴리오적인 면도 있는 만큼, 멀티플레이 요소를 넣기 위해 오른쪽의 두번째 캐릭터도 만들기 시작하였다. 오른쪽 캐릭터에도 옷에 대한 피직스 본을 리깅하고 리타게팅을 작업할 예정이다. 최종 프로젝트가 시작되는 대로 마네킹 대신 투입할 수 있도록 준비하는 것이 목표이다.

다익스트라(Dijkstra) 교차로 = 점, 도로 = 선. 그런데 도로마다 걸리는 시간이 다름. 간선에 붙은 이 숫자가 가중치(weight) . 우리가 원하는 건 "총 시간 최소" 이다. Queue를 딱 하나만 업그레이드 하면? BFS 는 "환승 횟수 최소" 였다. 모든 도로를 똑같은 1단계로 세기 때문이다. "총 시간 최소" 를 풀려면, BFS의 큐(FIFO) 를 "가장 짧은 거리부터 꺼내는" 큐 로 바꿔야 한다. 큐(FIFO) 먼저 온 순서대로 →  업그레이드  → 우선순위 큐 가장 가까운 순서로 이것이 에드거 다익스트라가 제안한, 가중치를 사용한 최단 경로, 다익스트라(Dijkstra) 이다. 다익스트라의 원리 1) 가중치가 생기면, 왜 BFS가 무너지는가? 간선 옆 숫자가 가중치이다. - BFS로 A에서 C까지 의 최단 거리를 구하면 어떻게 되는가? 위로 두 칸(1+1) 아래로 직통 한 칸(10) 같은 목적으로 향하는 경로. BFS의 눈에는 어느 쪽이 먼저 우선적일까? BFS의 답  : A-C 직통(간선 1개)  = 거리 10 실제 최단 A->B->C (간선 2개)  = 거리 2 BFS는 간선 개수만 세니까, 간선 1개(거리 10)를 간선 2개 (거리2) 보다 가깝다고 착각한다. 이럴 때 바로 "확정(confirm)" 이라는 개념이 필요하다. 2) 다익스트라는 두 단계만 반복 정점마다 "지금까지 알려진 최단 거리" 를 들고 있다. 처음엔 출발점만 0, 나머지는 전부 ∞. 1. 확정  : 아직 확정 안된 정점 중, 거리가 가장 작은 것을 골라 확정 . 2. 갱신  : 확정된 정점을 거치는 길이 더 짧으면 이웃의 거리를 줄임. 이렇게 모든 정점이 확정될 때까지 반복 하면 된다. 2-1) 다익스트라 예시 시작)  거리: A=0 , B=∞ , C=∞ , D=∞ , E=∞ 출발점 A 만 0 , 나머지는 아직 가는 길을 모르니 ∞ . 단계...

언리얼엔진5 C++ 기반 멀티플레이 게임 팀 프로젝트 제작 프로젝트 마감 약 한달에 걸친 프로젝트가 다시 한번 마감되었다. 비록 마지막날까지 매우 바빴고 그로인해 패키징 이후로도 발생한 문제들까지 해결하진 못하였지만 에디터상으로는 문제없이 잘 돌아갔고 덕분에 프로젝트에 좋은 평가를 받게 되었다. 프로젝트 최종 결과물은 다음과 같다.

언리얼엔진5 C++ 기반 멀티플레이 게임 팀 프로젝트 제작 작업내용 요약  - 플레이에 중대한 영향을 끼칠 수 있는 큰 버그 수정    : 폭탄넘기기 상호작용 중 특정 상황에서 물리엔진 오류로 콜리전이 동작 되지 않는 문제 수정    : 플레이어 캐릭터의 색상 머티리얼이 레벨 시퀀스 진행중에 적용되지 않는 문제 수정  - 패키징 작업 완료 폭탄 콜리전 비활성화 오류

언리얼엔진5 C++ 기반 멀티플레이 게임 팀 프로젝트 제작 작업내용 요약 캐릭터 애니메이션 블루프린트 제작  : 폭탄과 관련된 애니메이션 제작후 ABP에 연동.  : 폭탄을 들고 있는 상태, 폭탄을 들고 움직이기, 폭탄을 넘기는 동작. 폭탄넘기기 상호작용 기존에는 폭탄을 들고있음을 프로토타입 형태로 표현된 폭탄이 몸에 겹쳐진 상태로 부착된 모습이었다. 하지만 계속 이러한 형태로 계속 유지할 수는 없었기 때문에 스틱맨을 제작할 때 별도의 본을 새로 만들었는데, 그것이 바로 아이템이 부착되는 본인 ItemBone이다.

DFS / BFS DFS(깊이 우선 탐색) - 한 길로 끝까지, 막히면 되돌아온다. DFS 방문순서: 0 → 1 → 3 → 5 → 4 → 2 방문 규칙 1) 현재 위치를 방문 표시(visited) 한다. 2) 안 간 이웃이 있으면 깊이 내려간다. 3) 더 갈 곳이 없으면 한 단계 되돌아온다. 생명선 - 방문 체크(visited) 만약에, "방문 표시" 를 하지 않는다면 ?  : 0에서 1로 간 뒤, 1의 이웃인 0으로 다시 가게 된다. 0 → 1 → 0 → 1 → … 영원히 반복 현실의  BFS(너비 우선 탐색) 파동처럼 모든 길을 한걸음 씩 번갈아 움직여 체크하는 방식.

언리얼엔진5 C++ 기반 멀티플레이 게임 팀 프로젝트 제작 작업내용 요약 캐릭터 애니메이션 블루프린트 제작  : 캐릭터의 시선이 카메라를 따라감  : 캐릭터의 시선방향을 다른 클라이언트에게도 동기화 캐릭터의 시선처리 이전 TIL에서 언급하였듯, 컨트롤릭을 사용해 머리 Bone의 회전을 조정 하였다. 컨트롤 릭 자체는 자주 접하지 않은 에셋 툴이라 사용법을 찾는 데에 약간의 노력이 필요했지만, 기본적으로 카메라의 로테이션값에 비례해 머리가 회전하므로 복잡한 계산은 필요가 없었다. 다만 사람의 목이 180도 돌아가기에는 어려운 노릇이므로 Clamp를 더했으나, 머리 각도가 경계를 넘을 때 반대방향으로 부자연스럽게 전환되는 문제 가 있었으므로 애니메이션 보간처리 를 하였다. 또한 머리 Bone 회전의 핵심 이 될 클라이언트 카메라의 회전값 을 Replicated하고 ServerRPC를 통해 모든 클라이언트에게 동기화 하였다. 이렇게 하면 캐릭터의 시선방향이 모든 클라이언트에게 똑같이 보여질 것이다. 보간처리를 하지않은 얼굴회전. 머리가 순식간에 회전한다. 보간처리를 한 얼굴회전. 머리가 자연스럽게 돌아간다. 머리 회전값의 동기화도 완료함.

언리얼엔진5 C++ 기반 멀티플레이 게임 팀 프로젝트 제작 작업내용 요약 캐릭터 필수 애니메이션 제작 완료. 애니메이션 블루프린트에 기본적인 로코모션 연동 완료. 팀원들의 시스템 기획 고민 해결. 캐릭터 애니메이션 제작 주말동안 진행했던 캐릭터 애니메이션 작업 은 기술적 어려움보다는 디자인적 고민 의 연속 이었다. 캐주얼을 표방하는 게임에서 폴가이즈 같은 우스꽝스러운 모션을 만들기 위해서는 관절을 어떻게 움직여야 하는가? 게임 내에서 폭탄, 깃발 같은 인터랙션 아이템을 픽업했을 때  기존 모션에 픽업모션을 합치기 위해  어떤 본을 기준으로 본 블렌딩 을 거쳐야 할까? 캐릭터의 시선은 항상 정면을 향해야 하는가? 등의 사소한 고민부터 게임의 비쥬얼을 결정할지 모르는 고민까지 놓이는 경우가 잦았다. 이러한 내적갈등 중에서 기술적인 비중을 차지하는 고민 해결사례를 치자면 다음과 같다. 1) 캐릭터의 시선처리 이 에셋의 원본은 애당초 표정이 존재하지 않았다. 그렇기 때문에 캐릭터가 바라보는 정면을 표현하기 위해 추가적인 작업을 진행해야 했는데, 이 캐릭터 메시 위에 표정 텍스처를 얹는 것이었다. 이 에셋의 라이선스는  CC BY 4.0 로, 저작권자 표시만 지킨다면 어느 정도의 에셋 변형은 문제없다. 캐릭터가 움직일 때는 몸은 이동 방향으로 향하되, 얼굴의 방향은 카메라 방향으로 향하게 할 예정이다. 얼굴을 돌릴 때에는 컨트롤 릭 을 사용해 본을 움직이고, 얼굴 각도가 비정상적으로 변하지 않게 클램프 처리를 해야 할 것이다. 2) 상태 변화 시의 본 블렌딩 이전의 나는 과제를 진행하면서 이미 본 블렌딩 을 다뤄본 바가 있었다. 비행기가 Z가속도에 따라 날개를 올렸다 내리고 싶을 때, Layered blend per bone 노드를 사용해 날개 bone 이후 부터 날개 애니메이션의 영향 을 0~1 사이 로 받게 할 수 있었다. 위에 본 블렌딩 과 관련된 고민은 픽업 아이템을 들어올렸을 때 이므로, 어깨 bone 이후 부터 '아이템을 들어올리는...

GAS를 사용해 공격콤보 만들기 GA에서 애님 몽타주 재생 기본설정 GA가 Activate되면 애님 몽타주를 재생 하고, 몽타주가 정지되면 GA를 끝내는 Delegate를 추가 하는 기본적인 로직을 작성한다. .h파일 모든 AbilityTask 는 Delegate 정의 후 ReadyForActivation() 으로 준비를 확정해야한다. ※ K2 접두어 함수는 블루프린트에서의 함수 로, 블루프린트의 함수의 인자와 동일 하게 들어간다. 즉, BP함수가 인자를 요구하지 않으면 C++에서도 인자를 넣지 않아도 동일하게 작동된다. 능력 중복 방지를 위해 위 사진처럼 배치한다. 또한 C++에서 태그를 사용하기 위해 위 사진처럼 static함수를 정의해볼 수 있다. 노티파이를 통한 이벤트 넘겨주기

언리얼엔진5 C++ 기반 멀티플레이 게임 팀 프로젝트 제작 작업내용 요약 캐릭터 애니메이션 작업 시작 캐릭터 에셋 이번 프로젝트에서 사용할 에셋은  Free Pack - Stick Man (Rigged) 로, 팀원끼리의 회의를 통해서 해당 에셋을 캐릭터로 채용하기로 결정하였다. 해당 에셋이 우리가 제작하고자 하는 캐주얼 파티 미니게임 장르에 어울리는 캐주얼한 캐릭터라고 판단되었기 때문이다. 다만 해당 에셋은  Creative Commons Attribution(CC BY 4.0)  라이선스 기준을 따르며, 사용 시 크레딧에 저작권 표시가 필수적으로 따르게 된다. CC BY 4.0 저작권 표기 예시 해당 에셋은 이미 리깅이 되어있고, 블렌더를 통해 애니메이션 추가작업을 진행할 수 있도록 fbx파일과 .blend 파일 또한 마련되어 있다. 나는 이 내일부터 주말동안 캐릭터 애니메이션을 블렌더를 통해 제작하고, 애니메이션 블루프린트에 연결하는 작업을 거치게 될 것이다. 블렌더 작업 레이아웃

그래프 그래프는 점(객체) 와 간선(관계) 으로 이루어진 존재다. 정점(Vertex) = 동그라미, 객체 하나하나. 간선(Edge) = 선, 두 객체 사이의 관계 정점 V = {A, B, C, D, E} (5개) 간선 E = {A-B, A-C, B-D, C-D, D-E} (5개) 수학에서는 이 둘을 묶어 G = (V, E) 라고 쓴다. 그래프의 구성요소 그래프는 세 가지 축 으로 나뉜다. 무방향:  선이 양방향  (친구, 양방향 도로) 방향: 선에 화살표  (팔로우, 일방통행) 가중치: 선에 값  (거리, 시간 비용) 세 축은 서로 조합된다. 무방향 + 비가중치  : 가장 단순한 그물망  : DFS · BFS 의 기본 무대 방향 + 가중치  : 비용이 붙은 지도  : 다익스트라 의 무대 컴퓨터가 보는 세계 인간: 점과 선이 한눈에, "A랑 B가 이어져 있네" 컴퓨터: '그림'이란 게 없음. 저장할 수 있는 건 숫자와 목록 뿐. 따라서 그림속 "무엇이 무엇과 연결됐는가" 를 숫자 데이터로 옮겨 적어야 한다. ★ 이 데이터가 답해야 할 질문 질문1) "둘이 연결됐는가?"  - A와 B는 친구인가?  - 이 역에서 저 역으로 바로 가나? 질문2) "이웃은 누구인가?"  - A의 친구를 전부 알려달라.  - 이 역에서 갈 수 있는 다음 역들은? ※ 앞으로 배울 모든 탐색·길찾기가 이 두 질문을 수없이 반복 한다. ★ 질문에 대답하기 위한 전략 전략1) 모든 쌍의 체크표를 만든다. 점이 N개 면 N×N 칸 의 표. 이 표의 이름이 인접 행렬(Adjacency Matrix) 이다. 학급의 "짝꿍 여부 체크표" 처럼, 가능한 모든 (점, 점) 쌍 에 대해 "선이 있으면 1, 없으면 0"을 적어둔다. 세 간선의 인접부분을 모두 표에 적으면 대칭이 보인다. 단점: 표의 대부분이 0 이다.  : 점이 10만개면 100억 칸, 그마저 대부분 0임.  ...

언리얼엔진5 C++ 기반 멀티플레이 게임 팀 프로젝트 제작 작업내용 요약 관전자 시점에서 입력을 통해 관전자 전환 추가 관전자 전환 기능 플레이어 캐릭터도 컨트롤러 입력을 받았던 것처럼, 관전자 폰도 컨트롤러 입력을 받기 위해 EnhancedInputComponent를 받아 활성화하도록 한다. 단, 관전자 폰은 플레이어 캐릭터가 활동하는 동안에는 사용하지 않으므로 초기에 입력을 막아 놓는다. 당시에 목적은 게임 시작 시 플레이어 캐릭터와 동시에 관전자 폰 도 EnhancedInput을 활성화하는 것이었다. 하지만 관전자 폰 은 시작 시 컨트롤러 빙의를 받지 않아 서 SetupPlayerInputComponent() 이벤트가 실행되지 않았다. 과거  7~8일차 당시 나는 관전자 카메라는 나 혼자만 사용하므로 클라이언트 자기자신에서만 스폰하면 된다고 생각하였다. 하지만 이 경우 컨트롤러를 관리하는 서버 로부터 관전자 카메라 가 Possess 를 받을 수 없었고 EnhancedInput 도 쓸 수 없었기에 나는 코드를 고칠 수밖에 없었다. 하지만 관전자 카메라 를 리플리케이션 액터 로 만든다는 것은 트랜스폼 변경을 서버 에 맡겨야 한다는 것이고, 이는 위치 갱신 시 지연이 걸릴 수 있다 는 것을 의미했다. 그렇다고 클라이언트 측에서 값을 수정하자니 서버의 값으로 덮어 씌워지는 러버밴딩 현상이 걸림돌이었다. Gemini의 제안 나는 여기서 "관전자 카메라의  이동만 리플리케이트를 적용하지 않는 방법이 있나? " 라고 Gemini에게 질문해보았더니, 이는 SetReplicateMovement(false) 를 통해 가능 하다는 답변을 받았다. 그리고 이 함수는 런타임중에 실행이 가능 하여 원하는 타이밍에 위치를 리플리케이션해 서버와 동기화할 수 있다고 한다. 나는 이 정보를 토대로 관전자 폰 의 ReplicateMovement 값을 false 로 지정하고, 관전자 카메라 함수 DeathCamFollowCharacter() 를 클라이언트 만 접...