김환의 프로그래밍 블로그

상태효과(Buff, Debuff)을 만드는 법 게임을 하다보면 내 캐릭터에게 상태효과가 쌓이는 것 을 볼 수 있을 것이다. 쌓인 리스트에는 저마다의 다른효과를 가진 상태효과들이 있을 것이고, 이것들이 중첩되면서 최종적으로 캐릭터의 스탯이나 특수효과로 반영 될 것이다. 이 모든 상태효과들을 종합해 적용하기 이전에, 어떻게 각각의 버프들의 효과나 지속시간 등을 관리할 수 있을까? 액터 컴포넌트를 만들어 관리 현재 내가 작업중인 프로젝트가 RTS장르이므로, 유닛이나 건물 등이 상태효과를 받을 수 있게 만들어보자. 우선, 버프를 받을 수 있는 액터 를 구별하기 위해 전용 액터 컴포넌트 를 만들어보았다. 액터 컴포넌트에는 당연히 버프가 쌓일 것이므로 이를 배열 TArray로 관리 해준다. [추가작성중... 밀린 작업이 많음.]

비스트세력 지휘관 애니메이션 완성 비스트 지휘관 에셋의 리깅 스키닝을 마치고 애니메이션 제작을 마쳤다. 추가된 애니메이션은 각각 Idle, Walk, Skill, Death 이며, 현재 Idle, Walk만 실제 인게임에 적용되고 있다. Skill Death는 이후 관련 기능을 구현한 후에 애니메이션으로 추가될 예정이다. 실제 적용 화면

비스트세력 지휘관 에셋 리깅작업 몸통의 스키닝은 완료. 갑옷 쪽은 조금 더 손을 봐야함. 내일 이어서 스키닝이 끝나는대로 애니메이션을 추가해 연동 시킬 예정. 애니메이션은 Fab이나 믹사모에서 참고하면 좋을 것 같음.

비스트세력 지휘관 에셋 리깅작업 팀원으로부터 전달받은 비스트세력의 지휘관 에셋의 리깅과 스키닝 작업 진행중. 목표는 내일까지 애니메이션과 함께 제출. 몸통과 몸통에 밀접한 파츠들을 먼저 웨이트를 입히고, 이후 갑옷 파츠에 웨이트를 복제해 적용할 예정. 꼬리의 경우 이후 자연스럽게 움직이도록 피직스 에셋과 연동해서 물리에 맞춰 흔들거리게 만들 예정. 망토의 경우 피직스 에셋으로 움직이게 하기에는 본을 입히고 스키닝하는 과정이 까다로울 수 있으므로 언리얼 엔진의 클로딩 툴을 활용해볼 예정임.

오늘 한 일 팀원들의 초상화 포트레이트 작업을 돕기 위해 내가 알고있는 렌더타겟 지식을 TIL에 작성함으로서 팀원들에게 초상화 제작방법을 알려줌. (분량이 길었던 만큼 2~3일에 걸쳐서 작성함) 내일 어느정도 이해가 되었는지 피드백을 들어볼 예정. 이번 주 내로 할 일 비스트 세력 측 지휘관 캐릭터 에셋과 관련 애니메이션 에셋 제작. [필요한 애니메이션: Idle, Walk, Skill, Death] 일부 TIL 보강 주말에 할 일 건물 건설작업을 위해 이동 중 동일명령이 주어질 경우 건설작업이 되지 않는 에러 해결 종족별로 지휘관 외형 다르게, 스킬 다르게

SkyBox를 제작해보자 이전 TIL 에서 씬 캡쳐를 활용해 포트레이트를 제작할 때 SkyBox 를 사용한 바가 있다. 하지만 언리얼 엔진에서 제공해주는 SkyBox 는 많은 종류를 제공해주지 않고 지향하는 환경그래픽이 다를 수 있다. 대신 직접 프로젝트 환경에 맞는 SkyBox를 만들어보기에 앞서, SkyBox는 어떤 존재인지 다시 한번 짚어보도록 하자. SkyBox란? 밖에서 본 SkyBox와 안에서 본 SkyBox 언리얼 엔진에서는 SkyAtmosphere와 VolumetricCloud를 통해 하늘을 표현하고 있지만, 과거 에는 하늘을 담은 커다란 구 를 직접 배치해 하늘을 표현 하였으며, 이는 현재까지도 활용되고 있는 방법이다. 구 모양인데 왜 SkyBox? SkyBox의 6면 텍스처 (큐브맵이라고도 불린다) 월드에 배치된 것은 분명 구 모양인데 왜 SkyBox? 라고 하면, 과거 게임에서 하늘을 표현할 때 6면의 전개도 형태를 감싸 만들어진 큐브(Cube)를 사용했기 때문 인데, 현대에 들어서는 구(Sphere)모양이나 돔(Dome), 파노라마 형태로 발전했음에도 맵을 둘러싼 공간이라는 의미의 SkyBox라는 명칭이 관습적으로 사용 되어온 것이다. 물론 박스와 구분하기 위해 SkySphere, SkyDome으로 부르기도 한다. DirectX 환경에서 사용된 SkyBox. 과거 내가 제작한 DirectX 포트폴리오에서 큐브맵을 활용해 하늘을 표현하였다. 언리얼에서 SkyBox 제작법 우선 촬영하고자 하는 배경의 환경을 조성 한 후에 SceneCaptureCube를 배치 하면 카메라 형태의 액터가 배치 되는데, 순수하게 하늘만 찍고자 한다면 메시를 표시 플래그에서 제외 시킨다. (만약  도시나 마천루가 보이는 하늘을 표현하고 싶다면 플래그를 포함 시켜도 무방하다.) 그리고 캡쳐한 하늘을 담아줄 큐브 렌더 타겟 을 추가하여 SceneCaptureCube 의 텍스처 타깃 에 담아준다. SceneCaptrueCube 를 통해 큐브 렌더 타겟 에...

초상화(Portrait)를 구현하는 방법 스타크래프트의 Marine의 초상화 RTS장르를 해봤다면 유닛을 선택하면 인터페이스 내에 해당 유닛의 얼굴이 출력 되는 모습을 보았을 것이다. 이것을 초상화(포트레이트) 라고 하는데, 언리얼 엔진에서 포트레이트를 구현하기 위해서는 몇 가지 기술이 필요하다. 보다 자연스러운 포트레이트 애니메이션을 만들기 위한 과정을 소개하도록 한다. ① SceneCapture2D 캡쳐를 위한 세트장 구현 현재 위치에서 동떨어진 장소를 실시간으로 표현할 수 있는 방법 으로 포트레이트 구현에 안성맞춤이다. 이를 구현하기 위해 렌더타겟에 대해 어느정도 알아둬야 하지만 언리얼엔진에서는 렌더타겟을 구현하기 위한 과정을 간소화했으므로 방법은 한번 익혀두면 어렵지 않다. 1-1) 액터 블루프린트 구성 블루프린트 액터의 뷰포트 내부 포트레이트 영상으로 사용될 블루프린트 액터 를 생성하고 그곳에 캐릭터와 배경역할을 하는 Skybox(※) 와 바닥을 생성한다. 그리고 화면을 비쳐줄 카메라로는 SceneCaptureComponent2D 를 사용한다. 이 카메라가 화면속 모습을 찍어 렌더타겟에 저장 해줄 것이다. ※ Skybox : 월드를 감싸는 하늘을 담은 액터.  [관련 링크: SkyBox를 제작하는 방법 ] 1-2) 액터 내 컴포넌트 설정 컴포넌트들 배치한 후에는 오류를 최소화하기 위해 다음과 같은 설정을 따르도록 한다. 1 - 씬 캡쳐에서만 표시 초상화 액터는 월드 상에 표시되질 원치 않으므로 메시, Skybox(※), 장식물 등 실체가 있는 컴포넌트 들에게 bVisibleInSceneCaptureOnly = true 옵션을 붙여준다. 블루프린트에서 설정해도 된다. 2 - 콜리전 비활성화 마찬가지로 초상화 액터는 월드에 영향을 미치지 않아야 하므로 콜리전을 꺼둔다. 특히, SpringArm 을 채용하고 있다면  bDoCollisionTest = false 옵션을 붙인다. 마찬가지로 블루프린트에서도 설정할 수 있다....

깃허브 브랜치 전략 참고영상 이전에 PR 관리방법에 대해 튜터님에게 질문을 구하였을 때 조언 과 함께 해당 자료를 참고자료로 보내주셨었다. 이것은 PR을 효율적으로 진행하기 위해 조직이 취할 수 있는 깃허브의 브랜치전략의 종류를 설명한 것으로 보이는데, 현재 develop브랜치를 주력으로 사용하는 GitFlow전략을 이미 사용하고 있지만, 추후 취업 이후 협업을 하게 될 때 브랜치 전략이 다를 경우 참고할 수 있을 것 같다.

원시포인터(*)는 언리얼 환경에서는 불안정하다 나는 언리얼 C++에서 코딩을 했을때 TObjectPtr과 원시포인터를 섞어 쓰는것을 즐겨했다. 강의 초기에 언리얼 포인터를 배웠을 때 원시포인터에게도 장단점이 있는것처럼 설명이 되어있었기 때문이다. (관련자료:  https://khalicika.blogspot.com/2026/04/39-c-2.html ) 원시포인터는 확실히 가볍다는 장점이 있지만, 튜터님들의 조언에 따르면 그 짧은 시간을 위해 안정성을 버리는 것이 옳지 않다는 것이었다. 다소 무거운 로직이 되더라도 안정성을 챙기는 것이 이득 이라는 것이다. 단순 참조는 TWeakObjectPtr을 이용하자 본래 나는 원시 포인터를 주로 함수 구현부의 지역변수로만 활용했었지만, 사실 UE5부터는 원시포인터 사용을 줄이기 위해 언리얼 오브젝트 포인터라는 것이 개발 되었다고 한다. 다시 말해, 원시 포인터를 대체하기 위해 똑같이 GC에 의해 회수될 수 있는 약한 참조 를 하지만 유효성 검사 면에서 더 뛰어난 TWeakObjectPtr 등이 사용된다고 한다. 언리얼 오브젝트 포인터는 UPROPERTY()와 함께 써야한다는 생각이 있었기 때문에(TObjectPtr은 같이 쓰는 것이 정답이다), TWeakObjectPtr도 UPROPERTY()를 같이 쓸 수 있는 헤더 파일(.h)에서만 사용했었다. 하지만 TWeakObjectPtr 은 약한 참조 이기 때문에 UPROPERTY()의 영향을 받지 않기 때문에 사실 같이 쓸 필요가 없고, 따라서 소스 파일(.cpp)에서도 지역변수로 사용이 가능하다는 것 이었다. 따라서 헤더 뿐만 아니라 함수의 지역변수로 UObject를 참조해야할 때는 원시 포인터 대신 TWeakObjectPtr 을 적극적으로 사용하는 것을 고려해볼 필요가 있을 것 같다. 원시포인터 사용시 언리얼 환경에서 불안정한 이유, 그리고 TWeakObjectPtr로 대체해야하는 이유

PR을 하다보면 생기는 문제: 내용이 너무 길어요 주말, 대체공휴일이 끝난 뒤 팀원으로부터 PR을 받았는데, 주말동안 혼자 작업한 분량이 꽤 많았는지, 무려 56개의 파일에 달하는 어마어마한 분량의 PR 을 받게 되었다. 이 팀원은 PR피드백을 받아오면서 피드백이 필요한 부분이 점점 줄어들었지만, 매번 작업하신 분량이 상당하였기에 "피드백 할 부분이 그렇게 많지는 않은데, 코드 전체를 보는 편이 과연 옳은 것인가?" 하는 질문을 스스로 하게 되었다. 팀원이 추가한 56개에 달하는 파일, 분량이 어마어마하다. 그렇다고 팀원에게 작업을 줄여 달라고 하는 것은 불가능하고, PR에 포함시킬 파일을 적당히 나눠서 보내달라고 하기에는 이 수많은 파일이 하나의 기능만을 위해 존재할 수도 있기 때문에 그 경우 반쪽짜리 기능이 되어 에러를 일으킬 가능성도 있다. 때문에 이런 경우에선 차라리 PR을 효율적으로 하는 방법을 내 쪽에서 기르는 것이 좋을 것이라는 생각이 들었다. PR을 효율적으로 하는 방법: 구현 배경을 먼저 확인하라 Gemini에게 긴 내용의 PR을 효율적으로 하는 방법에 대해 질문하여 다음과 같은 답변을 얻었다. 나는 이전까지 코드리뷰를 할 때, 변경된 파일 내용 전체를 읽으면서 추후 문제가 발생할 법한 부분을 짚어 피드백을 하였다. 하지만 위처럼 긴 내용을 리뷰해야할 때에는 코드 전체를 보기에는 너무 오래 걸린다는 문제 가 있었다. 이에 Gemini는 "커밋 단위로 구현배경을 훑어보면서 확인" 하는 것을 제안하였다. Gemini의 답변 확실히 커밋을 할때 작성양식을 지켜야하는 이유 가 여기서 나오는 것 같다는 생각이 들었다. 그 팀원은 각 커밋에 어떤 작업을 했는지 내용을 작성했었다. 그 내용들을 확인하면서 핵심이 되는 내용들을 파악 하면 될 일이었는데, 커밋의 존재의의를 잊고 있었다는 생각이 들었다. 긴 내용의 코드를 리뷰할때는, 파일 단위 로 보기보다는 커밋 단위 로 보는 것도  좋을 것 같다는 생각이 든다. 커밋 내...

최종프로젝트: RTS장르 프로토타입 간단한 규칙을 가진 프로토타입이 완성되었다. 이 프로토타입에는 간단한 승리/패배로 이어지는 흐름구조 및 유닛 조작에 대한 구현이 담겨있다. 이 영상에서는 본인은 '지휘관'이라는 유닛을 조작하여 구조물 건설을 위한 이동방법을 담당하였다. 장애물 없이 건축물을 작업할 수 있는 가까운 로케이션를 선정하는 알고리즘 을 구성한 것이다. 건설위치가 지정되면 이동은 다른 팀원이 구현한 이동 매커니즘을 따라 움직인다. 그 외에 나는 주로 깃허브 PR을 관리 하면서 오류를 검사하는 일을 맡았기 때문에 이 외에 내가 직접 추가구현한 사항은 없다. 그래도 최근 지휘관 유닛에 대한 전반적인 담당을 맡았기 때문에 이후에는 스킬구현, 지휘관 전용 애니메이션 작업을 맡게 될 것이다.

최종프로젝트 외 해야할 일 요근래 최종프로젝트에 시간을 많이 투자하다보니 면접, 코딩테스트 등의 취업준비가 많이 밀렸다. 강사님의 말로는 요즘 시대에는 팀프로젝트 포트폴리오만으로는 취업이 어렵기 때문에 개인역량도 기르는 것이 좋다고 하였다. 최종 프로젝트에 할애할 시간을 약간 내어서 취업준비를 하는것이 좋다고 하였기에 주어진 역할 외에 다른 작업은 잠깐 미루고, 주말에 지휘관 캐릭터의 스킬 작업을 해야 할 것 같다는 생각이 든다.

RTS게임에서 건설위치의 유효성 판단 이전 일차에서 건설 명령을 내리면 해당 위치까지 이동한 후에 건물을 짓는 로직을 작성하였다. 하지만 내가 만들어낸 것은 어디까지나 건설과정의 정의지, 건설을 하기 위한 조건을 붙인 것은 아니었다. 그 때문에 NavMesh 영역 바깥 같은 건설이 유효하지 않은 위치를 지정할 경우 해당 위치에까지 이동하려고 하는 문제가 있었다. 이러한 문제를 해결하기 위해 건설명령을 내리기 전 조건을 하나 더 추가하였는데, 이전에 건물 설치를 확정 지을 때 사용했던 ProjectPointToNavigation() 이다. 해당 함수는 입력한 좌표가 NavMesh와 근접한 지 확인하고, 지정한 범위 내로 NavMesh내의 좌표로 투영할 수 있으면 True를 반환한다. 만약에 False를 반환한다면 입력한 좌표는 NavMesh위에 있지 않을 가능성이 크므로 건설명령을 내리지 않는다. 건설불가 영역에 건설을 시도할 경우 "Build Error" 메세지를 출력한다. 이 함수는 NavMesh내의 유효한 근사 좌표값을 찾는데에 좋지만, NavMesh 위로 좌표를 투영하는 과정에서 오차가 발생할 수 있다. 또한 해당 함수가 판단하는 것은 포인트 단위의 좌표가 NavMesh위에 있는가지, 건설영역의 바운드까지 포함해서 계산해주지 않는다. 따라서 지형이나 장식물 등에 건물의 일부가 겹쳐있는 문제를 피하기 위해서는 추가적으로 지형/장식물에 콜리전을 추가하는 것으로 충돌검사를 해줘야할 것이다.

오늘 한 작업 PR피드백 내가 제작한 지휘관 소스코드와 다른 팀원이 담당한 건설코드를 통합하는 과정에서 동작 방식에 약간의 차이가 발생. 본래 내 코드는 우클릭을 통해 지휘관을 이동시키지만 팀원의 의도는 지휘관을 먼저 좌클릭으로 선택한 상태에서 우클릭을 해야만 이동할 수 있게 만드는 것이었음. 이동과 관련된 코드를 팀원의 로직에 흡수시킴. 다만 막 통합을 한 참이라 몇몇 부분에서 예외사항이 발생함. 아래와 관련된 문제에 대하여 우선 내 코드만을 사용해 테스트 했을 때는 문제가 없었기에 팀원 코드쪽에서 문제가 있을 것으로 판단됨. 하지만 내 지휘관 동작코드와도 깊게 연관되어 있기에 상호소통을 통해 해결해나갈 예정임. 

RTS 장르에서 건물을 짓는 법 개요 나는 이번 주말에 직접 조종할 수 있는 지휘관 캐릭터를 생성해 건설/스킬 사용 명령을 내릴 수 있게 만드는 역할 을 부여 받았다. 특이하게도, 우리가 진행하는 RTS 팀프로젝트에서는 '지휘관'이라는 유닛이 직접 건설을 주도 할 수 있는데, 지휘관이 직접 건물을 짓는다기 보다는 스타크래프트의 프로브처럼 가까이 접근해 건설 부지를 확보하면 이후에는 자동으로 건설되는 방식 이다. 스타크래프트1의 프로브가 건물을 짓는 방식. 영역을 확보하면 자동으로 건설된다. RTS 장르의 꽃인 건물 건설이 최우선이기에, 지휘관에게 이동능력을 부여하는 대로 건설기능을 먼저 추가 하기로 했다. 그렇다면 건물을 건설하기 위해서는 지휘관은 어떻게 행동해야 할까? 여기서부터는 보편적인 RTS장르에 대입해서 건설기능을 가진 지휘관 을 '일꾼' 으로 치환해서 설명하기로 한다. 일꾼과 유닛의 이동 일반적인 RTS장르에서는 '유닛'이라는 캐릭터에게 명령을 내려 행동을 취하게 할 수 있다. 가장 일반적인 이동의 작동 방식에 대해 알아보도록 하자. 이동좌표와 유닛 RTS장르 는 거의 대부분이 캐릭터를 직접적으로 조작해 이동하는 것이 아닌 "명령"을 내려 이동을 유도 한다. 그렇기 때문에 이동 시 델타시간 단위로 이동값을 계산해 움직이는 것이 아닌 목적지를 지정해 AI컨트롤러에게 좌표를 전송, 이동을 지시 한다. 때문에 이동을 하기 위해 필요한 매개변수는 목적지가 되는 벡터좌표값 이 될 것이다. 이동조작 시 EnhancedInput을 통해 실행되는 함수 목적지를 구하기 위해서는 커서와 맞닿는 지형의 좌표를 구해야 하는데, 엔진에서는 이미 이와 관련된 함수가 마련되어 있다. GetHitResultUnderCursor 함수는 커서를 기준으로 카메라 정면을 향해 RayCast 하므로(이때, 캐스팅 방향은 현재 카메라의 Projection 방식을 따른다) 함수의 Result 좌표값을 가져와 준비된 이동지시 함수를...