힉스필드·Blender로 3D 좀비 게임 만들기: 기획부터 리깅과 브라우저 구현까지

실제 프로젝트에서 확인한 실행 환경은 Node.js 24, Three.js 0.186.1, Vite 8.3.1입니다. Blender 작업 기록은 5.2.1 LTS, Higgsfield 플러그인 기록은 1.5.57을 기준으로 합니다. 재현할 때는 저장된 프로젝트의 package-lock.json과 에셋을 함께 사용하고, 설치 화면의 이름이나 모델 목록이 달라졌다면 해당 버전에서 다시 확인합니다.

플러그인과 Blender Bridge 연결

AI 앱 연결은 Higgsfield MCP 공식 안내에서 사용 중인 앱에 맞는 경로를 선택합니다. Blender 확장은 공식 플러그인 설치 안내를 따라 설치하고 Higgsfield 계정으로 로그인합니다. 플러그인은 생성 결과를 Blender 장면과 에셋 라이브러리에 가져오는 기능을 제공합니다.

이번에 사용한 Blender 패널에서는 Higgsfield의 MCP 항목에 있는 Enable MCP control을 켜야 연결된 AI가 장면을 제어할 수 있었습니다. 설치 직후에는 생성부터 요청하지 말고, 현재 파일명과 장면 이름, 오브젝트 목록을 읽어 달라고 요청합니다. 실제로 열어 둔 작업 파일의 정보가 돌아오면 그 장면에서 작업을 이어갑니다.

블렌더 창이 여러 개라면 이름이 비슷한 파일을 혼동할 수 있습니다. 응답한 프로세스와 파일 경로를 확인하고 기존 파일을 백업합니다. Bridge 인증 정보는 로컬 연결에만 사용하며 게임의 웹 공개 폴더나 프롬프트 공유 자료에 넣지 않습니다.

기획: 캐릭터가 보이는 작은 생존 게임

처음 요청에서는 제작에 들어가기 전에 카메라, 아트 스타일, 전투 방식과 맵 구조를 먼저 정했습니다. 캐릭터를 가까이 보는 재미와 사방의 적을 읽는 재미를 함께 확보하는 것이 목적이었습니다. 첫 버전은 한 개의 맵에서 시작부터 탈출 또는 사망까지 끝낼 수 있게 범위를 줄였습니다.

카메라와 아트 스타일

게임에는 위쪽에서 비스듬히 내려다보는 직교 카메라를 사용했습니다. 플레이어와 주변의 적, 엄폐물 사이 공간을 한 화면에 보여 주기 위한 선택입니다. 얼굴이나 옷의 세부 모양은 별도의 액션 미리보기에서 더 크게 볼 수 있게 했습니다.

디자인은 현실적인 재질을 단순한 형태에 적용한 스타일로 맞췄습니다. 생존자는 주황색 구조대 재킷, 일반 좀비는 회녹색 작업복, 돌진 좀비는 버건디 운동복으로 구분했습니다. 색과 실루엣이 달라 위쪽 카메라에서도 역할을 구별하기 쉽습니다.

맵과 전투 방식

맵 중앙에 검문 부스를 두고 차량과 방벽을 배치했습니다. 구조물은 시각적인 배경이면서 이동 경로를 바꾸는 장애물입니다. 좀비는 길이 막히면 경유점을 찾아 우회하고, 플레이어는 구조물 사이를 돌며 재장전할 공간을 확보합니다.

사격은 마우스로 조준한 방향의 명중을 즉시 계산하는 방식입니다. 발사체를 매번 복잡한 물리 객체로 만들지 않고, 가장 가까운 장애물과 적을 검사합니다. 총구 불빛, 탄도를 보여 주는 선, 효과음은 이 판정에 맞춰 재생합니다.

첫 버전에 넣은 것과 미룬 것

이미지: 디자인 시트와 3D 입력을 나누기

먼저 캐릭터와 소품이 어떤 모습이어야 하는지 레퍼런스 이미지를 만들었습니다. 그다음 실제 3D 생성에 넣을 단일 피사체 이미지를 별도로 준비했습니다. 한 장의 디자인 시트에 담긴 여러 시점과 여러 소품을 그대로 하나의 모델로 만들라고 요청하지 않는 것이 이 작업의 중요한 구분입니다.

디자인을 정하는 레퍼런스 6장

생존자, 일반 좀비, 돌진 좀비, 카빈, 검문소 환경, 소품 모음의 여섯 시트를 만들었습니다. 캐릭터 시트에서는 정면·측면·후면과 얼굴을 살피고, 환경 시트에서는 배치와 조명을 확인했습니다. 소품 모음에서는 검문 부스, 방벽, 철망, 작업등과 차량 등의 형태를 정했습니다.

다면도도 시점마다 팔 각도나 옷의 작은 장식이 다를 수 있습니다. 이번 무기 시트에서도 측면마다 일부 표면 형태가 달라 모델링 기준 시점을 하나로 정했습니다. 레퍼런스는 디자인을 공유하는 자료로 쓰고, 치수와 관절 위치는 3D 모델을 확인하면서 맞춥니다.

리깅하기 쉬운 A포즈 입력

캐릭터 입력에는 몸통에서 팔을 벌린 중립 A포즈를 사용했습니다. 양팔과 다리가 겹치지 않고 손과 발이 화면 안에 온전히 들어오도록 했습니다. 배낭과 무기는 캐릭터 몸에서 분리했기 때문에, 나중에 소품 위치를 조정할 때 몸 메시를 다시 만들 필요가 줄었습니다.

아래처럼 원하는 한 가지 조건을 짧게 설명할 수 있습니다. 실제 제작에서는 앞서 선택한 디자인 이미지를 함께 참조했습니다. 생존자 전신 A포즈 입력 원본도 함께 확인할 수 있습니다.

이 캐릭터의 옷과 색을 유지하고, 팔과 몸통이 겹치지 않는 중립 A포즈의 전신 이미지로 정리해 주세요.

무기 레퍼런스 재작업

녹화에는 첫 무기 이미지 생성이 콘텐츠 필터에서 막혀 다시 요청한 과정도 나옵니다. 최종 결과는 게임용 가상 카빈의 외형 레퍼런스이며, 내부 구조나 제작법을 다루지 않습니다. 다른 캐릭터의 주황색 포인트와 연결되도록 색을 맞췄습니다.

Tripo H3.1로 모델을 만들고 Blender에서 정리하기

단일 입력 이미지가 준비된 뒤 Tripo H3.1 Image to 3D로 에셋 12개를 생성했습니다. 이 단계의 결과물은 캐릭터와 소품의 형태, UV, 텍스처가 포함된 모델입니다. 이후 캐릭터에 골격과 애니메이션을 붙이는 작업을 따로 진행했습니다.

모델 12개의 구성

캐릭터 목표 높이는 생존자 1.72m, 일반 좀비 1.78m, 돌진 좀비 1.74m로 설정했습니다. 캐릭터는 쿼드 옵션과 상세 형상·텍스처 설정을 사용했습니다. 이 값은 이번 프로젝트의 설정이며 다른 스타일의 게임에 그대로 적용해야 하는 기준은 아닙니다.

생성 결과 확인과 정리

Blender에서는 크기, 정면 방향, 원점, 재질을 먼저 확인했습니다. 리깅 전 베이스 모델은 Z축이 위쪽이고 정면은 -Y 방향이며, 발바닥 중앙을 원점으로 맞췄습니다. 머리카락과 신발 끈 주변의 작은 분리 조각, 비정상적인 연결과 작은 구멍도 정리했습니다.

겉모양이 좋아도 관절을 구부리면 어깨나 무릎이 찌그러질 수 있습니다. 메시 검사와 관절 변형 검사를 따로 진행해야 합니다. 이번 베이스 메시의 열린 경계와 비매니폴드 모서리가 0으로 정리됐다는 결과도 리깅 품질 전체를 보장하지는 않습니다.

모델 생성이 완료되면 작업 ID와 결과 파일을 저장합니다. Blender로 가져오는 단계에서 멈췄다고 곧바로 새 생성 요청을 보내면 같은 모델을 중복 생성할 수 있습니다. 이미 완료된 작업인지 확인한 뒤 다운로드나 가져오기부터 다시 진행합니다.

리깅과 애니메이션: 필요한 동작을 먼저 정하기

리깅은 캐릭터에 골격을 만들고, 뼈의 움직임이 어느 부분의 메시를 움직일지 연결하는 작업입니다. 애니메이션 클립은 그 골격이 시간에 따라 움직이는 데이터입니다. 골격이 있다는 것만으로 걷기나 공격 동작이 모두 준비된 것은 아니어서, 캐릭터별 필요한 클립 목록을 먼저 정했습니다.

최종 캐릭터는 Higgsfield 생성 리그를 사용

초기에는 수동 Rigify 리그와 코드로 만든 동작을 연결했지만, 사용자가 본 결과가 기대한 움직임과 달랐습니다. 이후 열린 Blender의 Higgsfield Bridge에서 실제 3d_rigging 작업을 실행해 캐릭터를 교체했습니다. 이 작업에서 Higgsfield가 표시한 리깅 공급자는 Meshy입니다. 베이스 모델을 만든 Tripo 단계와 구분해야 합니다.

최종 리그는 캐릭터별 24개 본을 사용합니다. 전달본 검사에서는 웨이트가 없는 정점과 웨이트 합계 오류가 없었고, 게임용 파생본은 정점당 최대 4개 본의 영향을 유지했습니다. 손가락별 본과 얼굴 표정 리그는 포함하지 않습니다.

연결한 동작 목록

동작 이름과 ID는 Meshy 공식 애니메이션 목록과 대조했습니다. 이 표는 이번 생성 기록을 설명합니다. 공급자 API에 있는 모든 옵션이 Higgsfield Bridge의 같은 이름 옵션으로 노출된다고 가정해서는 안 됩니다.

모션을 옮길 때 기준 자세를 맞추기

같은 캐릭터를 입력해도 서로 다른 생성 작업의 골격 기준 자세에는 미세한 차이가 있었습니다. 본 이름이 같다는 이유로 회전과 위치를 그대로 붙이면 어깨나 손의 위치가 어긋날 수 있습니다. 그래서 기존 캐릭터의 골격과 스킨을 유지하면서, 원본 모션의 기준 자세 차이를 반영해 회전과 루트 이동을 변환했습니다.

이 작업은 새 포즈를 임의로 만드는 방식 대신 공급자 모션을 다른 리그에 맞추는 자동 리타기팅으로 처리했습니다. 원본 모션과 생성 파일은 보존하고, 게임에 사용할 동작을 각 캐릭터의 NLA 트랙으로 묶었습니다. 내보낸 GLB에 이동과 공격이 모두 있는지도 확인했습니다.

액션 미리보기를 먼저 만드는 이유

게임 화면에서는 캐릭터가 작고 적도 계속 움직입니다. 팔이 꺾이는지, 발이 미끄러지는지, 공격 클립이 들어 있는지 판단하기 어렵습니다. 그래서 로딩 화면의 버튼으로 들어갈 수 있는 액션 미리보기를 먼저 만들었습니다.

미리보기에는 캐릭터 선택과 동작 선택을 따로 뒀습니다. 생존자는 걷기와 사격 이동, 일반 좀비는 걷기와 양팔 공격, 돌진 좀비는 달리기와 양팔 공격을 고를 수 있습니다. 걷기만 있는 파일을 공격까지 준비된 것으로 착각하지 않도록 목록에서 구분합니다.

확인 순서는 캐릭터와 동작을 선택하고, 정상 속도로 전체를 본 뒤 느리게 재생하며 이상한 구간을 찾는 방식입니다. 정지한 한 프레임만 괜찮다고 완료 처리하지 않습니다. 이번 미리보기는 공급자 클립의 전체 구간을 보여 주고, 게임의 공격은 그중 필요한 구간을 사용합니다.

Three.js에서는 로드한 animations 배열에서 이름에 맞는 클립을 골라 AnimationMixer와 AnimationAction으로 재생합니다. 여러 동작의 전환과 재생 속도를 다루는 기본 구조는 공식 애니메이션 문서에서 확인할 수 있습니다.

게임에 모션을 연결하며 고친 두 가지 문제

Blender와 미리보기에서 잘 움직여도 실제 게임에서는 동작 선택과 판정 시점이 어긋날 수 있습니다. 이번 프로젝트에서는 생존자의 걷기와 좀비의 공격이 바로 그 문제였습니다. 파일에 클립을 추가하는 작업과 게임 상태에 연결하는 작업을 함께 고쳤습니다.

생존자: 걷는 하체와 총을 든 상체

처음에는 사격 이동 클립 하나로 이동까지 처리해 걷기가 충분히 드러나지 않았습니다. 최종 구현에서는 Walk의 하체 트랙과 ArmedMove의 상체 트랙을 분리해 동시에 재생합니다. 사격하지 않고 이동할 때는 실제 이동 방향으로 몸을 돌리고, 사격할 때는 조준 방향을 따릅니다.

뒤로 이동하며 사격하는 경우에는 걷기 사이클을 역재생합니다. 이 방식으로 기본 후진을 표현했지만 방향별 옆걸음 클립이나 발을 지면에 정교하게 맞추는 작업까지 끝난 것은 아닙니다. 녹화에서도 총을 쥐는 모습은 추가 수정이 필요하다고 짚었습니다. 손가락 본이 없는 현재 리그의 한계를 고려해 손과 무기의 위치를 더 다듬을 여지가 있습니다.

좀비: 공격 장면과 피해가 같은 순간에 나오게 하기

초기 게임에는 가까이 온 좀비가 일정 시간 뒤 피해를 주는 규칙만 있었고 공격 클립이 없었습니다. 일반 좀비와 돌진 좀비에 양팔 공격을 생성해 연결한 뒤, 이동에서 공격으로 전환하고 한 번 휘두른 후 이동으로 돌아오도록 바꿨습니다.

이번 공격은 공급자 클립의 16~85프레임 구간을 사용하고, 팔을 뻗는 46프레임을 접촉 시점으로 잡았습니다. 같은 구간을 일반 좀비는 1.35초, 돌진 좀비는 1.05초에 재생합니다. src/game/motion.js의 공통 시간표를 애니메이션과 피해 판정이 함께 읽도록 했습니다.

공격이 시작될 때 방향을 고정하고, 접촉 시점에 플레이어가 사정거리 안의 앞쪽에 있는지 검사합니다. 옆이나 뒤로 빠져나가면 피할 수 있고, 공격 한 번에 피해가 여러 번 들어가지 않게 했습니다. 일시정지 중에는 공격 진행 시간도 멈춥니다.

스킨 복제와 실제 이동

같은 좀비 모델을 여러 마리 만들 때는 골격 연결이 유지되는 SkeletonUtils.clone()을 사용했습니다. 이 유틸리티가 스킨 메시와 본을 어떻게 복제하는지는 Three.js 공식 문서에 설명되어 있습니다. 각 적의 재생 상태는 별도로 관리합니다.

맵 위의 실제 이동과 충돌은 게임 시뮬레이션이 계산합니다. 원본 클립에도 앞으로 이동하는 값이 있으면 화면에서 이중으로 이동할 수 있어, 런타임에서는 직선 수평 루트 이동만 제거했습니다. 걷는 동안 몸이 위아래로 움직이는 모션은 유지했습니다.

시작부터 탈출까지의 플레이 흐름

첫 화면에서는 바로 생존을 시작하거나 캐릭터 액션을 먼저 볼 수 있습니다. 게임에 들어가면 5분 뒤의 구조 신호를 기다리며 적을 처치합니다. 그동안 이동할 공간과 재장전할 시간을 확보하고, 신호가 켜지면 탈출 차량으로 이동합니다.

조작과 전투

기본 체력은 100, 탄창은 24발, 재장전은 1.5초입니다. 예비 탄약은 제한하지 않았습니다. 회피의 기본 대기 시간은 2.3초이고, 회피하면 진행 중인 재장전이 취소됩니다. 회피로 지형이나 좀비를 통과할 수는 없습니다.

적은 사방에서 접근하며, 일반 좀비와 더 빠른 돌진 좀비가 다른 압박을 줍니다. 공격 예고를 보고 공간을 벌리고, 엄폐물 때문에 총알이 막히면 위치를 바꿉니다. 첫 5마리를 처치했을 때와 이후 처치 수가 8의 배수일 때 응급 키트가 나오며, 가까이에서 체력 30을 회복할 수 있습니다.

강화와 구조 신호

체력이 0이 되면 사망 결과가 표시되고, 제한 시간 안에 탑승 준비를 마치면 승리합니다. 결과 화면에서 다시 시작할 수 있습니다. 포커스를 잃거나 다른 탭으로 이동하면 자동으로 일시정지해 조작하지 못하는 동안 게임이 계속되지 않게 했습니다.

배경음, 효과음과 웹용 에셋 최적화

모델을 많이 불러오는 브라우저 게임에서는 에셋 크기와 재생 비용도 확인해야 합니다. 편집용 모델을 보존한 채 게임용 파생 파일을 따로 만들었습니다. 소리는 외부 음원 파일 대신 Web Audio로 합성했습니다.

오디오

배경음은 긴장감을 유지하는 앰비언트 시퀀스로 구성했습니다. 사격, 명중, 피격, 발소리, 재장전, 회피, 좀비 공격, 회복, 구조 신호와 승패에 효과음을 연결했습니다. 게임의 생존 시작 버튼을 누른 뒤 오디오를 활성화하고, 일시정지 메뉴에서 배경음과 효과음 볼륨을 각각 조절할 수 있습니다.

음량과 음소거 설정은 현재 브라우저에 보관합니다. 이번 프로젝트에는 외부 음원 다운로드나 유료 오디오 API 호출을 넣지 않았습니다. 이 설명은 실제 구현 방식이며, 별도 오디오 서비스를 쓰는 다른 제작 방식까지 다루지는 않습니다.

모델과 텍스처

플레이어는 약 22,000삼각형, 좀비는 각각 약 10,500삼각형으로 게임용 메시를 줄였습니다. 캐릭터 텍스처는 1024px, 소품은 512~1024px 파생본을 사용했습니다. 이 수치는 이번 에셋에 적용한 설정으로, 모든 브라우저와 장치에서 같은 성능을 보장하는 기준은 아닙니다.

다운로드한 공급자 원본, Blender 편집 파일, 애니메이션 전달본, 게임용 경량본을 분리했습니다. 원본을 덮어쓰면 나중에 손이나 옷을 다시 다듬을 때 선택지가 줄어듭니다. 게임용 내보내기에서는 골격, 웨이트, 텍스처와 필요한 클립이 함께 남았는지 검사합니다.

프로젝트 파일과 실행 방법

아래 경로는 실제 zombie 프로젝트의 구성입니다. 이번 글에서 생성한 결과가 어느 파일에 들어 있고, 나중에 무엇을 수정해야 하는지 찾을 때 사용할 수 있습니다. 실행 명령은 프로젝트 소스와 에셋을 로컬에 준비한 상태를 전제로 합니다. 의존성 설치 명령의 동작은 npm ci 공식 문서를 참고할 수 있습니다.

수정 위치 찾기

이전 수동 Rigify 결과는 복구용으로 남아 있습니다. art/rigged의 옛 파일을 최신 캐릭터로 다시 연결하지 않도록 주의합니다. 현재 웹 복사 스크립트는 Higgsfield 리깅의 ready와 runtime 폴더에서 캐릭터 파일을 가져옵니다.

Windows에서 실행

PowerShell에서 프로젝트 폴더로 이동한 뒤 실행합니다. 아래 경로는 자신의 저장 위치로 바꿉니다. package-lock.json이 있는 프로젝트 복사본을 재현할 때는 npm ci로 기록된 의존성을 설치할 수 있습니다.

개발 서버는 http://127.0.0.1:5173/에서 확인합니다. 수정한 코드는 개발 서버에서 확인하고, 배포 형태의 파일은 빌드한 뒤 별도로 검사합니다.

프로덕션 미리보기 주소는 http://127.0.0.1:4173/입니다. 이 주소는 서버를 실행한 자기 컴퓨터에서 사용하는 주소입니다. 다른 사람이 웹에서 접속할 수 있는 게임 주소와는 구분합니다.

WSL에서 같은 Windows 프로젝트 열기

Windows에 저장한 프로젝트를 WSL에서 확인할 때는 드라이브를 /mnt/c 경로로 접근할 수 있습니다. 다만 의존성을 설치하고 실행하는 환경은 하나로 정하는 편이 관리하기 쉽습니다. Windows와 Linux의 node_modules를 섞어 사용하지 않고, 실행 환경을 바꾸면 그 환경에서 의존성을 다시 설치합니다.

서버를 끌 때는 서버를 실행한 터미널에서 Ctrl+C를 누릅니다. 다시 켤 때는 개발용이면 npm run dev, 빌드 확인용이면 npm run preview를 실행합니다. 소스나 에셋을 고친 뒤 preview만 다시 켜면 옛 dist가 보일 수 있으므로 먼저 npm run build를 실행합니다.

실제로 겪은 문제와 확인 순서

작업 중의 문제는 연결, 생성, 리깅, 내보내기, 게임 재생 중 어느 단계에서 생겼는지 나눠 확인했습니다. 같은 증상이라도 원인이 다르면 고칠 파일이 달라집니다. 다음 표는 이번 프로젝트의 수정 내용과 다시 확인할 위치입니다.

생성과 내보내기 실패를 구분하기

이번 Bridge 작업에서는 생성 작업이 완료된 뒤에도 Blender 파일 내보내기가 응답하지 않는 경우가 있었습니다. 모델 생성 ID가 이미 있다면 같은 생성부터 다시 시작하지 않습니다. 완료 상태와 결과 파일을 먼저 확인하고, 필요한 경우 저장된 .blend를 별도 백그라운드 Blender에서 읽어 내보내는 방식으로 복구했습니다.

이런 복구는 작업 중인 창과 원본 파일을 보존한 상태에서 진행했습니다. 연결이 끊겼다는 이유만으로 기존 Blender 프로세스를 모두 종료하거나, 생성 원본과 중간 기록을 정리하지 않습니다. 문제가 난 단계부터 다시 시작할 수 있도록 작업 ID와 파일 경로를 함께 남깁니다.

검증 결과와 다음 개선 순서

현재 버전은 자동 테스트 17개와 프로덕션 빌드를 통과했습니다. 실제 GLB에서 스킨과 애니메이션 데이터를 읽는 검사, 사격·충돌·재장전·회피·공격 시점 검사, 탈출 승리까지 이어지는 게임 규칙 검사를 포함합니다. 이 검사는 동작 연결과 규칙의 오류를 찾기 위한 것으로, 사람의 플레이 감각 평가와 구분합니다.

관련 녹화본에서도 피격 시 체력 감소, 응급 키트 회복, 재장전, 돌진 좀비 접근과 장비 강화가 확인됩니다. 05:12 부근에서는 총을 드는 자세를 더 수정할 필요가 있다고 설명하고, 06:01 부근에서는 전용 재장전 액션을 다음 개선 대상으로 언급합니다. 이 한계를 숨기지 않고 첫 버전의 작업 범위로 남겼습니다.

다음 수정은 총과 양손의 정렬, 방향별 이동, 재장전과 피격·사망 동작 순으로 진행할 수 있습니다. 그다음 실제 플레이를 여러 번 하며 적의 속도와 출현량, 회복 빈도, 탈출 구역의 난도를 조정합니다. 장시간 FPS, 모바일 조작, 공개 호스팅은 각각 별도 확인이 필요합니다.

자주 묻는 질문

따라 만드는 동안 헷갈리기 쉬운 범위를 모았습니다. 모델 생성이 끝난 상태, 리깅이 끝난 상태, 게임에서 동작을 쓸 수 있는 상태를 나눠 확인하면 다음 작업을 정하기 쉽습니다.