오래된 캐릭터 Blueprint를 새 프로젝트에 연결하기

무엇을 가져올지 먼저 정하기

자산 패키지의 Character Blueprint를 통째로 쓰는 방법과 메시·애니메이션만 사용하는 방법은 작업 범위가 다릅니다. Paragon 캐릭터인 Gideon의 Blueprint를 Default Pawn으로 지정할 때처럼, 기존 캐릭터를 새 프로젝트에 연결하면 입력 경고와 VR 관련 오류를 만날 수 있습니다. 이는 모델이 손상됐다는 뜻이 아니라 기존 프로젝트의 시스템을 전제로 작성된 동작이 함께 들어왔다는 뜻입니다.

원하는 것이 외형뿐이라면 마네킹 기반 캐릭터를 복제한 뒤 메시와 적합한 Anim Class를 연결하는 편이 시작점을 단순하게 만들 수 있습니다. 반대로 기존 캐릭터의 전투 기능까지 필요하다면 상태·입력·카메라·플러그인 의존성을 따로 정리합니다. 어느 경우든 원본 패키지를 직접 크게 고치기보다 게임용 사본이나 파생 자산에서 변경 내역을 관리합니다.

게임모드와 입력 오류를 분리하기

GameMode의 Default Pawn Class를 바꿔도 해당 레벨의 GameMode Override가 다른 클래스를 가리키면 기대한 캐릭터가 생성되지 않습니다. 플레이어 시작 위치, 실제 Possess된 Pawn, 활성 GameMode를 순서대로 확인합니다. 메시를 레벨에 끌어 놓은 것과 플레이어가 조작하는 Character를 생성한 것도 구분해야 합니다.

옛 InputAction Jump나 InputAxis MoveForward 이벤트는 이름이 같은 레거시 매핑을 기대합니다. Enhanced Input의 IA_Move를 만들었다고 그 이벤트로 자동 변환되지는 않습니다. 재현 목적으로 기존 매핑을 추가할 수는 있지만 신규 동작을 만들 때는 Input Action과 Mapping Context를 기준으로 입력 경로를 한 체계로 정리합니다. 마우스 축과 게임패드 스틱의 크기·프레임 시간 처리도 그대로 같다고 가정하지 않습니다.

사용하지 않는 의존성을 다루는 순서

VR 리셋처럼 프로젝트에서 쓰지 않는 기능이 컴파일을 막는다면 연결된 호출 경로와 목적을 확인한 뒤 게임용 사본에서 제거할 수 있습니다. 필요한 기능이라면 정확히 어느 플러그인 또는 모듈이 해당 노드를 제공하는지 확인하고 지원 버전을 검토합니다. 이름이 비슷한 플러그인을 여러 개 켜서 오류를 숨기는 방식은 후속 빌드를 어렵게 만듭니다.

1. 컴파일 로그에서 첫 오류를 열어 실제 누락된 노드나 타입을 확인합니다.
2. Pawn 생성과 조작 가능 여부를 먼저 검증합니다.
3. 이동·시선·점프를 새 입력 체계에 하나씩 연결합니다.
4. 서기·걷기·점프·착지를 재생한 뒤 전투나 발 IK를 추가합니다.