김환의 프로그래밍 블로그

언리얼엔진5 C++ 기반 멀티플레이 게임 팀 프로젝트 제작 작업내용 요약 폭탄이 만들어지고 타이머가 만료되면 폭탄을 가진 플레이어를 제거하는 로직을 구현하였다. BombActor 관련 작업 팀원의 BombActor 코드 이전 작업TIL에서도 언급되었다시피 본인 은 미니게임 GameMode 규칙 을 정하고 , 다른 한 명 은 게임 룰의 주체가 되는 폭탄 액터의 제작 을 맡았었다. 그리고 고맙게도 담당 팀원께서 폭탄 가동 시 폭발(ExplodeBomb)타이머가 돌아가고, 폭발 시 서버로 무엇을 넘기면 되는지 주석으로 친절히 설명해주셨다. 나는 이 주석에 따라 폭탄을 보유중인 플레이어를 제거할 로직을 짜기로 했다. 플레이어 탈락 로직 구현 폭탄 액터 로부터 EliminatePlayer() 를 게임모드 가 전달받으면 인수에 해당되는 캐릭터를 생존자(AlivePlayer) 중에 해당되는지 검색한 후에 해당 캐릭터가 탈락하는 모습을 모든 클라이언트에게 보여주고, 생존자 명단에서 지우기 로 했다. 플레이어가 탈락하는 모습을 보여주기 위해 MulticastRPC 함수를 사용하는데, 이 함수를 모든 게임에서 사용되는 PlayerCharacter에게 추가하면 해당 캐릭터의 코드가 난잡해질 가능성을 우려해 처음에는 '액터 컴포넌트' 를 추가해 캐릭터에게 Attach 하기로 했다. 1) 액터 컴포넌트를 이용한 플레이어 탈락효과 부여 (실패) 서버는 게임을 시작할 때 모든 플레이어에게 'UMGCharacterComp_PassBomb' 이라는 액터 컴포넌트를 생성/교체 하여 해당 미니게임에 맞는 룰과 관련된 효과를 적용 할 예정이었다. 플레이어가 2명인 데디케이티드 서버 환경 기준으로, 액터 컴포넌트가 생성될 때 [서버], [1번클라], [2번클라] 에서 두 플레이어 캐릭터에게 'UMGCharacterComp_PassBomb' 액터 컴포넌트 가 추가되는 것을 로그로 확인하였다. 오류 발생 시점 그러나 액터 컴포넌트 를 통해 플레이어 ...

언리얼엔진5 C++ 기반 멀티플레이 게임 팀 프로젝트 제작 작업내용 요약 모든 게임모드의 베이스가 되는 GameModeBase 관련 작업 과 미니게임:폭탄돌리기의 폭탄 생성 로직 을 작업하였다. GameModeBase 관련 작업 우리 프로젝트는 여러 미니게임을 순회하면서 플레이 하는 방식이기 때문에 로그인 설정이나 공동규칙을 가진 Base 와 각 미니게임의 규칙을 보유한 파생 게임모드 가 각 미니게임의 레벨을 맡는 식으로 구성된다. 그렇기 때문에 Base 에서 미니게임의 시작을 알리는 virtual void StartMinigame() 과 미니게임의 종료를 알리는 virtual void EndMinigame() 을 만들어 각 파생 게임모드 가 상속할 수 있는 구조로 꾸몄다. 각 게임모드 는 StartMinigame() 을 Super 와 함께 오버라이드 호출함으로서 미니게임 관련 변수를 초기화 하고 현재 게임상태를 진행중(Playing)으로 선언 하는 역할을 하며, EndMinigame() 을 Super 와 함께 오버라이드 호출하면 해당 게임의 스코어를 결산 하고 미니게임 종료(Ending) 를 선언한다. Base 에서 만든 이 함수를 파생되는 게임모드들 이 사용해야 코드의 일관성을 높일 수 있기 때문에 오후 스크럼 회의 때 해당 함수의 목적을 설명 하고 각 미니게임 담당 팀원들에게 PR(Pull Request) 을 요청 해 해당 함수를 사용할 것임을 명시, 장려하였다. 미니게임:폭탄돌리기 - 폭탄 생성 로직 우리 프로젝트는 하나의 미니게임에 2인이 작업 하는 2인1조 방식이다. 그중에서 나는 해당 미니게임의 규칙 로직 을 짜는 역할 을 맡았으며, 다른 한 명 은 미니게임의 핵심인 '폭탄' 액터의 제작 을 맡았다. 팀원의 BombActor의 ActivateBomb() 코드의 일부 팀원이 처음 제작한 BombActor 는 리플리케이션된 액터 로  캐릭터와 접촉 하면 기존 소유자를 Detach 하고 새 캐릭터의 일부로 Attach 되는 구조였...

게임플레이 이펙트 지정된 시간동안 어떠한 효과를 낼 수 있는 기능이다. 주로 GameplayCue, GameplayAbility와 엮어 쓰인다. 디테일 속성 경과시간 정책  - Instance   : 즉시 적용되고 사라짐.   : Active Effects에 남지 않는다.   : Damage, 힐, 스탯변경, 자원소비 등에 사용됨  - Has Duration   : 일정 시간 동안 n초에 한번 씩 작동 후 자동 제거.   : Active Effects에 남음.   : 도트데미지, 쿨타임, 버프 등에 사용.  - Infinite   : 수동으로 Remove하기 전까지 유지   : Active Effects에 남음.   : 패시브, 체력 자연회복 등 모디파이어  - 컴포넌트   : 해당 이펙트가 적용되면 실행할 행동이다.   : [타깃 액터의 태그 부여] 의 경우 이펙트가 적용되는 동안 태그를 부여하거나 제거 할 수 있다.  -  어트리뷰트   : 액터가 가진 AttributeSet의 값을 조절할 수 있다.   : Add, Multiply, Divide 등 각종 연산을 시행할 수 있다.  - 스케일 가능 플로트 크기   : 얼만큼 계산할지 정할 수 있다. 스태킹  - None: 중첩에 제한이 없다.  - Aggregate by Source: 피격자가 공격자 수에 비례 하여 스택을 중첩 으로 받을 수 있다.   ex) 값이 4이면, 공격자가 2명일때 피격자는 스택을 8스택까지 받는다.  - Aggregate by Target: 피격자가 자체적으로 받는 스택을 제한 한다.   ex) 값이 4이면, 공격자가 아무리 많아도 피격자는 스택을 4스택까지 받는다. 스택 경과시간 새로고침 정책  -  Refresh on Succ...

언리얼엔진5 C++ 기반 멀티플레이 게임 팀 프로젝트 제작 첫 기획안 멀티플레이 팀프로젝트 주제로 브레인스토밍을 해본 결과 처음에는 3인칭 액션게임(내 제안) , 시뮬레이션 협동 게임 , 쿼터뷰 RPG , 그리고 마리오파티처럼 여러 미니게임을 합친 캐주얼 게임 장르 들이 제안 되었는데, 4주일이 채 안되는 짧은 시간 동안 프로젝트를 완성 시켜야 한다는 점을 들어 제작시간이 짧을 미니게임들을 여러 개로 만들어 합칠 수 있는 캐주얼 파티 장르 가 선택되었다. 소통 시스템 연결 이번 프로젝트의 경우 내가 팀장으로 선택되었기 때문에 소통을 위한 시스템을 적극적으로 연동시켰다. 1. 팀 프로젝트용 슬랙 개설 및 Trello 연동 2. 코드 작성 중 필요한 규칙 정의 (코드 컨벤션) 주어진 템플릿과 이전 챕터의 컨벤션을 참고해 코드 컨벤션을 정의함. (예: 소스파일 접두사 통일, 언리얼 코딩 규칙 준수, 이름에 용도 명시 등) 역할 분담 초기 기획을 맡으신 팀원이 초기 역할을 정리해주었기 때문에 이를 Trello에 추가하였다. 네트워크 파이프라인 및 미니게임 A팀 , 미니게임 B팀 , 미니게임 C팀 으로 각각 2명씩 맡는 구조로 진행한다. A팀의 경우 기본적인 네트워크 구축도 겸하기 때문에 해야 할 일이 더 많으므로 팀장인 본인을 비롯해 책임감 높은 팀원이 맡기로 결정하였다. 팀장으로서 맡은 첫날에 대한 소감 상당히 어렵다. 최종 프로젝트의 경우 어느 정도 생각해둔 바가 있기 때문에 그때도 팀장을 맡을 예정이지만 이번 프로젝트의 경우 막상 팀장을 맡아보니 당장 주도하고 싶은 주제가 부족했던 것과 겹쳐서 앞날이 캄캄하단 느낌을 받았다. 하지만 그럼에도 최선을 다하지 않으면 최종 프로젝트 또한 내가 팀장자리를 맡아 내가 만들고 싶은 게임을 주도할 자격이 없다고 생각해 맡은 바 힘이 닿는 대로 최선을 다할 생각이다. 내가 해내야 할 것은 내가 맡은 담당 기능을 구현해내는 것도 있지만 팀장으로서 일정을 주도하고 적극적인 소통을 격려하는 것이리라.

슬라이드 윈도우 - 구간을 미끄러뜨리며 본다 개념 확인 아래의 숫자가 나열되어 있을 때, 연속된 5칸의 평균이 가장 높은 지점 은 어디인가? 3 7 2 8 5 9 4 6 가장 단순한 방법 - 매번 다시 더한다  : 매 지점마다 그 자리에서 5칸치를 처음부터 다시 더해 평균을 낸다.  → 1,000칸 이면 약 5,000번 연산 (N칸×K번 덧셈) 구간 크기가 커질수록 매 시점 다시 더하는 비용이 그대로 늘어난다 는 단점이 있다. 슬라이드 윈도우 방식 - 첫 5칸을 한 칸 뒤로 미끄러뜨리면? 3 7 2 8 5 9 4 6 → 7 2 8 5 9 4 6 3  : 가운데 세 칸(7,2,8,5)은 그대로, 나가는 값 하나(3) 와 들어오는 값 하나(9) 만 바뀐다.  : 이전 5칸의 합을 가지고 있다면 거기서 나가는 값(3) 을 빼고, 들어오는 값(9) 를 더하면 지금의 5칸 합.  → 1,000칸 이면 약 1,000번 (N칸×1번 덧셈) 구간 크기와 무관 하게 "변한 부분만 갱신한다" 는 계산 방식이 연산 횟수를 줄인다. 핵심 통찰 - 본질은 "갱신만" 슬라이딩 윈도우의 본질 은 "k개의 합을 계산하는 것" 이 아니라 , 이미 계산한 결과를 "버리지 않고 갱신" 만 하는 것 이다.

언리얼 모듈과 플러그인 언리얼 모듈이란? 언리얼 엔진의 기본 구성요소 로, 순수 소스코드 로 구성되어 있으며 (cpp, h, Build.cs) 언리얼로 만든 프로젝트는 여러 개의 모듈로 구성 된다. (예: UI 모듈, Gameplay 모듈 등) 플러그인이란? 모듈은 전체 프로젝트를 구성하는 것 외에도 독립적인 기능을 구현한 패키지 를 만들 수도 있는데, 이것을 플러그인 이라고 한다. 플러그인 은 프로젝트에 탈부착이 가능한 확장 패키지 이며, 소스코드 외에도 플러그인을 이루기 위한 에셋 또한 포함시킬 수 있다. 탈부착이 가능하기 때문에 기능이 필요한 프로젝트에 코드를 직접 작성하는 대신 플러그인을 부착해 끌어다 쓸 수 있게 해준다.

이전 게시글:  https://khalicika.blogspot.com/2026/06/68-ta.html 이전 작업에서 주어진 제공 샘플을 통해 디포머그래프의 개념을 알아보았다. 그렇다면 좀 더 깊게 파고들어서 저번 영상으로 보았던 '탄흔' 을 직접 구현해볼 수 있을까? 디포머그래프 예시. 총탄을 맞은 지점이 움푹 파여있다. 디포머그래프를 통한 탄흔 구현 이전 디포머 그래프를 사용할 때에는 스켈레탈 메시에 디포머 그래프 에셋을 적용한 후 OptimusDeformerInstance 로 Cast 하고 SetVariable 함수를 통해 값을 넘겨서 변수를 추가 시켰다. 탄흔을 구현하는 디포머 그래프 에서는 BP에서 가져오는 변수 4개 (착탄지점, 탄흔 반지름, 탄흔 방향, 탄흔 개수) 와 메시에서 기본적으로 제공 하는 Vertex의 Position 를 새로 만든 Kernal인 HitMesh의 입력 으로 받고 내부에서 변형된 Vertex의 Position 을 메시에 재적용 한다.

GAS 대미지를 계산할때 단순히 체력을 줄이는 것은 쉽지만, 속성 대미지나 방어력 계산, 도트 대미지 타이머 관리 등을 넣기 시작하면 명령줄과 변수도 많아져 코드가 복잡하고 지저분해지기 시작한다. 이때 이 복잡성을 줄이기 위해 도입된 시스템 으로, 온갖 오브젝트에 Tag 를 붙여 분류해두고, Tag 에 따라 대미지를 계산 하거나 조건을 붙여 어떤 스킬의 발동 가능 유무판별 등을 간단히 요약할 수 있다. (Tag를 상태효과처럼 씀) 계산이 복잡해지는 코드에는 GAS를 도입해 간소화할 수 있고 또 현업에서 많이 쓰이지만 , GAS 자체에 배울 기능이 많아 간단한 프로젝트에 GAS를 도입하면 오히려 코딩 난이도가 높아질 수 있다는 점을 들어 도입 시 주의가 필요하다. GAS 사용 시 대체되는 특징  - Bool → Tag  - 변수 저장 → Attribute Set  - 변수 수치 변경 → Gameplay Effect  - 스킬 → Gameplay Ability  - 사운드 및 이펙트 → Gameplay Cue GAS 적용법 플러그인 적용 시 사용 가능 프로젝트.Build.cs 코드 GAS 기반 캐릭터 헤더 세팅 태그 변경 방법 3가지  - 폴더: 'Config → DefaultGameplayTag.ini' 에서 직접 수정  - 프로젝트 세팅: '게임플레이 태그' 에서 수정  - GameplayAbility 디테일창: 직접 변경 GameplayAbility (GA) 오브젝트에 대해 능력을 추가 해준다. 주로 Tag의 영향의 받아 사용 된다. GA는 위의 Tag들을 토대로 스킬 사용이 결정된다. Tag 는 주로 블루프린트를 사용 해 추가하며, C++로는 드물게 추가 하므로 참고만 해두는 것이 좋다. Tag를 추가하는 방법. 콤마(.)를 붙여서 하위 카테고리를 만든다. GA 클래스 속성 - 인스턴싱 정책 Non Instanced  - 이 스킬을 위해 별도로 인스턴스를 만들지 않고 이 원...

Property Replication 심화 NetLoadOnClient 레벨 디자인을 통해 레벨에 고정적으로 배치되는 액터 는 NetLoadOnClient 속성을 true 로 지정해서 모든 클라이언트가 스스로 스폰 하도록 한다. ※ 플레이어의 로그인에 따라 스폰되는 액터 (PlayerController, Pawn 등)와 혼동하면 안된다 . 각 PC에 보이는 레벨에 배치된 액터는 NetLoadOnClient == true이다. Replication Notify 레플리케이션 프로퍼티를 읽은 뒤 매 틱마다 함수를 호출하는 것은 비효율적이다. SetActorLocation()등을 사용할 때 값이 변하지 않았음에도 함수를 호출하기 때문이다. 때문에 값이 변할때만 SetActorLocation() 등의 무거운 함수를 호출할 때는 Replication Notify를 쓰는 것이다. Replication Notify 콜백 함수 는 아래처럼 정의가 가능하다. UPROPERTY( ReplicatedUsing = OnRep_함수명 ) float 변수명; UFUNCTION() void OnRep_함수명 ※ 구분을 위해  Replication Notify 콜백함수는 'OnRep_' 접두어 를 붙이는 것이 관례이다. Replication Notify 는 서버 에서는 실행되지 않고 , 클라이언트 에서만 실행 된다. 서버 에서도 해당 로직이 실행되어야 한다면, 명시적으로 호출 해줘야 한다. C++ 'OnRep_' 함수 VS Blueprint RepNotify 함수 공통점  : 속성 값이 변경되면 변경된 값이 클라이언트에 복제(Replicate)되는 시점에 호출 되는 콜백함수를 바인드할 수 있다.  → 이를 Replication Notify 라고 한다. C++ 에서는  'OnRep_' , 블루프린트 에선 'RepNotify' 차이점 C++ OnRep_ 함수  - 클라이언트에서만 호출  - 명시적 호출 가능  - 속성 ...

투 포인터 숫자 배열이 정렬되어있을 때 , 왼쪽과 오른쪽에서 하나 씩 골라서 조건을 충족할 때까지 가운데에서 만날 때 까지 순회하는 비교 방식. 예를 들어, 두 칸의 합이 100이 되는 경우 를 고를 때 순회로 완전 탐색 O(n^2)을 하는 방법도 있지만, 양쪽 끝부터 비교해서, 다음과 같이 조건에 따라 인덱스를 고르면서 중앙에 맞닿을 때 까지 순회하는 방법도 있다. 두 칸의 합에 대해  - 100보다 작으면 → R번 칸을 한 칸 우측이동  - 100보다 크면 → L번 칸을 한 칸 좌측이동  - 100이면 → 정답 위와 같은 비교방식은 100만 칸 배열 에 대해 완전 탐색 과 비교하면 다음과 같은 연산횟수 를 가진다. 완전 탐색 (모든 쌍 시도) : 5,000억 번 투 포인터 (양쪽 끝에서 좁혀오기) : 100만 번  = 50만배의 차이

전처리기 명령어 #pragma region {블록명} ~ #pragma endregion  : 두 블록 사이의 영역을 접을 수 있게 해준다.  : 이는 언리얼 뿐만 아니라 다른 코드에서도 사용할 수 있는 기능 이다. #include "CoreMineral.h"  : 대부분의 게임개발에 쓰이는 헤더파일들의 집약체 . 새 C++ 헤더 작성 시 이미 include 되어있지만, 최적화를 위해 해제하면 필요한 헤더를 하나하나 손수 include해줘야한다. 사실상 초보자 전용. Assert 매크로 언리얼 엔진 환경 에서 사용할 수 있는, 특정 상황에서 실행을 종료하고 문제 발생 지점을 체크할 수 있는 Assert 매크로 관련 코드 이다. 매크로 발동 조건에는 DO_GUARD_SLOW / DO_CHECK / DO_ENSURE 가 있으며, 각 빌드모드에 따라 1(True), 0(False) 로 갈린다. check (표현식) (DO_CHECK == 1 일때 작동)  : 언리얼의 Assert매크로. 반환값이 false라면 실행을 중지 시킨다. checkf (표현식, 문자열포맷) (DO_CHECK == 1 일때 작동)  : check와 동일 하지만, 실행 중지 시 매개변수에 입력된 메세지를 출력 한다. verify (표현식) (DO_CHECK 무관)  : check와 동일 하지만, DO_CHECK에 무관 하게 작동한다. verifyf (표현식, 문자열포맷) (DO_CHECK 무관)  : checkf와 동일 하지만, DO_CHECK에 무관 하게 작동한다. 언리얼 매크로 FORCEINLINE 함수명  : 함수를 강제적으로 inline화 시킨다.  : inline화란 컴파일 단계에서 컴파일러가 함수 호출 지점에 함수 내용을 갖다 붙이는 것을 의미한다.  : getter, setter 등 간단한 함수 를 호출할 때 발생하는 오버헤드 비용이 호출지점에서 함수로 이동 하는 것보다 코드내용을...

Replication 생성된 액터의 정보를 네트워크 내 다른 클라이언트 에게 복제하는 작업 을 말한다. 서버-클라이언트 모델 기준 서버→클라이언트 로 복제 되는 것이 기본 규칙이다. 레플리케이션 하는 방법에는 두 가지가 있다. 1) RPC (Remote Procedure Call) 2) Property Replication 프로퍼티 레플리케이션 은 항상 Authority → Proxy 방향으로만 가능하다. Property Replication 액터의 모든 속성의 변경된 값 을 모든 클라이언트에게 복 제하는 것은 비효율적 이다. 우리가 원하는 속성만 을 다른 클라이언트에게 복제 하는 것을 프로퍼티 레플리케이션 이라고 한다. 프로퍼티 레플리케이션 설정 방법 1) 액터의 bReplicates 속성을 true로 설정한다. 2) 네트워크로 복제할 액터의 속성을 키워드로 지정  - UPROPERTY(Replicated) 3) GetLifetimeReplicatedProps() 함수에 네트워크로 복제할 속성을 추가한다.  - #include "Net/UnrealNetwork.h" 헤더 추가한다.  - DOREPLIFETIME() 매크로를 사용해 복제할 속성을 명시한다. 프로퍼티 레플리케이션 가능여부 1) 액터가 클라이언트에 존재할 때,  클라이언트 → 서버 로 프로퍼티 레플리케이션 이 가능한가? 정답: 불가능  - 프로퍼티 레플리케이션 은 서버 → 클라이언트 로의 단방향성만을 가짐. 서버에 액터가 없어서 불가능. 2) 액터가 서버에 존재할 때, 서버 → 클라이언트 로 프로퍼티 레플리케이션 이 가능한가? 정답: 불가능  - 서버의 액터가 클라이언트에도 복제가 되어있어야 함 (bReplicates == true) . 복제되어있지 않아서 불가능 3) 액터가 서버에 있고, 클라이언트로 복제가 되어있을 때 서버 → 클라이언트 로 프로퍼티 레플리케이션 이 가능한가? 정답: 가능  - 서버의 액터가 클라이언트에...

컨트롤 릭 가끔 게임 속 모험을 하다 보면 잠깐 멈추고 그 세상을 들여다 볼 때가 있다. 그리고 내 캐릭터가 어떤 자세로 서 있는지 쳐다보게 될 때 일부 게임은 위 사진처럼 계단에 걸쳐 있을 때 발이 공중에 떠있지 않고 자연스럽게 계단 위에 올려져 있을 때가 있다 . 이런 기술은 IK(Inverse Kinematics) 를 적용한 것으로, 발이 위치할 IK좌표 를 지정하면 발이 그곳에 위치하기 위해 다리를 어떻게 움직여야 하는지, 몸체는 얼만큼 내려가고 올라가야 할 지를 연산한다 . 언리얼에서도 제공 하는 기술이지만, UE4 에서는 이를 애니메이션 블루프린트에서 직접 본을 움직여 처리 를 해줬어야 했다. 하지만 UE5 에 들어오면서 이를 따로 처리해주는 에셋 이 생겨났는데 이를 컨트롤 릭(Control Rig) 이라고 한다. 컨트롤 릭은 위 처럼 발의 위치를 보정해줄 뿐만 아니라 언리얼 내에서 애니메이션을 생성하고 싶을 때 각 관절들이 위치할 좌표들을 임의로 정의해 해당 관절이 위치하기 위해 다른 관절들이 어떻게 움직여야 할 지를 알려주는 지침을 해준다. 간단한 컨트롤릭 제작법 아래의 과정은 발이 지면 위에 자연스럽게 올라가기 위해 필요한 계산을 지침하는 과정이다. 모두 CR_Mannequin_BasicFootIK 에셋을 그대로 복사해 참고하였다. 아래의 본을 움직이는 기준은 모두 IK_Foot본이 있다는 전제 하 에 만들어진 것이다. 지정한 Foot IK본에 대한 Trace함수 각 Foot가 이동해야할 Z거리를 계산하는 과정 (시퀀스 A) 계산된 위치로 IK본(변수)이 보간이동하고 현재 이동한 Z거리를 저장하는 과정 (시퀀스 B) 저장된 현재 Z거리를 실제 IK본에 반영하는 과정 (시퀀스 C) 실제 IK본을 따라 실제 Foot본을 움직이는 과정 (시퀀스 D) ※ Full Body IK 노드를 사용할 때에는 [루트 행동:Pin to Input] 을 주로 사용한다. 이렇게 만들어진 컨트롤릭 에셋 은 애니메이션 블루프린트에 적용 할 수 있다. Control ...