RPG 게임 엔진 비교: RPG Maker, Godot, Unity, Unreal 및 브라우저 빌더

RPG 게임 엔진을 고르는 일은 대부분 세 가지에 대한 결정입니다: 아트를 어떻게 만들지, 누가 코드를 작성할지, 그리고 완성된 게임이 어디에서 실행되어야 하는지입니다. 선택지는 깔끔하게 갈립니다. RPG Maker MV와 MZ는 RPG 시스템이 이미 내장된 채로 나오는 2D 편집기입니다. Godot, Unity, Unreal, Phaser는 직접 프로그래밍하는 범용 엔진입니다. Ren'Py는 게임을 하나의 대본처럼 다루는 대화 우선 엔진입니다. 브라우저 빌더는 설치와 빌드 단계를 완전히 건너뜁니다.

이 페이지는 프로젝트를 실제로 좌우하는 요소들을 기준으로 그 경로들을 비교합니다: 비용과 라이선스, 코드를 만지는지 여부, 2D인지 3D인지, 무엇을 내보낼 수 있는지, 그리고 플레이 가능한 결과물까지 얼마나 걸리는지입니다. 숫자가 추측에 불과할 자리에서는 대신 그 작동 원리를 설명합니다. 엔진을 확정하기 전에 실행되는 세계를 보고 싶다면, 마지막 부분의 엔진 없는 선택지 섹션을 먼저 읽으세요.

빠른 답변

게임이 능력치, 아이템, 대화 상자가 있는 탑다운 2D RPG라면 RPG Maker MV나 MZ가 플레이 가능한 장면에 가장 빨리 도달합니다. 데이터베이스와 이벤트 시스템이 이미 그러한 시스템을 모델링하고 있기 때문입니다. 렌더러와 규칙을 통제하면서 비용은 내지 않고 싶다면, Godot이 특정 포맷에 묶이지 않는 가장 저렴한 경로입니다. 팀, 콘솔 심사, 미들웨어가 얽혀 있을 때는 Unity와 Unreal이 합리적입니다. RPG가 웹 페이지이고 이미 JavaScript를 작성한다면 Phaser가 답입니다. 게임이 대부분 텍스트와 분기 선택이라면 Ren'Py가 답입니다.

아래 표는 일곱 가지 경로를 다룹니다: RPG Maker MV/MZ, Godot, Unity, Unreal, Phaser, Ren'Py, 그리고 결과물이 빌드 파일이 아니라 페이지인 브라우저 빌더입니다. 열은 비용과 라이선스, 필요한 코딩, 2D 또는 3D, 대상 플랫폼, 그리고 첫 플레이 가능까지의 시간입니다. 마지막 열은 충돌과 상호작용 가능한 오브젝트 하나를 갖춘 조작 가능한 캐릭터를 화면에 띄우기까지의 시간으로 읽으세요. 게임을 완성하기까지의 시간이 아닙니다. 대부분의 RPG 프로젝트는 렌더링이 아니라 시스템에서 실패하므로, 표는 거르개로 삼고 뒤의 섹션들을 결정으로 삼으세요.

비교표

그 표에서 두 칸은 경고할 만합니다. Unity의 웹 빌드 타깃은 작동하지만, 소박한 2D RPG라도 WebAssembly 빌드는 애셋 압축 전에 흔히 수십 메가바이트에 이르고, 스레드 빌드는 많은 정적 호스트가 기본적으로 보내지 않는 교차 출처 격리 헤더(COOP와 COEP)를 필요로 합니다. 증상은 빈 화면과 SharedArrayBuffer에 관한 콘솔 메시지이지, 명확한 오류가 아닙니다. Godot의 스레드 웹 내보내기도 같은 헤더를 요구하며, 이는 Godot 프로젝트가 로컬에서는 실행되고 무료 호스트에서는 실패하는 가장 흔한 단일 원인입니다.

Unreal의 HTML5 내보내기는 4.23에서 4.24 시기에 제거되었고 지원되는 대체 수단이 없으므로, Unreal로 만든 RPG는 바이너리로 또는 스토어프론트를 통해 배포됩니다. 링크가 배포 방식이라면, 그것만으로 코드를 한 줄도 쓰기 전에 Unreal이 후보에서 빠집니다.

RPG Maker의 브라우저 배포는 애셋 트리 전체를 처음에 내려받습니다. 작은 프로젝트에는 괜찮지만 사운드트랙이 긴 프로젝트에는 괴롭습니다. 맵보다 오디오가 훨씬 먼저 페이로드를 장악하기 때문입니다. 첫 성능 문제로 프레임 레이트가 아니라 첫 로딩을 예산에 넣으세요.

2D 대 3D RPG 엔진

렌더러는 저렴한 부분입니다. Godot과 Unity는 같은 다운로드로 2D와 3D를 모두 렌더링하고, 카메라를 원근에서 정사영으로 바꾸는 것은 속성 하나입니다. 2D RPG와 3D RPG 사이에서 달라지는 것은 렌더러 이전의 모든 것입니다: 애셋을 어떻게 제작하는지, 몇 사람이 필요한지, 그리고 변경이 눈에 보이기까지 얼마나 걸리는지입니다.

2D 경로는 스프라이트 시트와 타일셋을 뜻합니다. 네 방향으로 걷는 캐릭터는 보통 방향마다 세 프레임, 총 열두 프레임이 필요하며, 16x16, 32x32 또는 48x48 픽셀로 그립니다. 가져오기 설정이 아트보다 더 중요합니다: 픽셀 아트에는 Filter Mode를 Point(필터 없음)로, Compression을 None으로 설정하세요. 그렇지 않으면 편집기의 기본 쌍선형 필터링이 모든 타일을 흐리게 만들어 저녁 내내 아티스트를 탓하게 됩니다. 새 타일을 그려 폴더에 넣기만 하면 되므로 반복이 빠릅니다. 타일당 32픽셀인 100x100 맵은 3200x3200 픽셀 이미지로, 실제 메모리 비용이지만 감당할 만한 수준입니다.

3D 경로는 메시, 리그, 스킨 웨이트, 애니메이션 클립을 뜻합니다. 캐릭터 하나에는 메시, 스켈레톤, 그리고 최소한 대기, 걷기, 공격 클립이 필요합니다. 라이브러리를 라이선스하지 않는다면, 그것은 게임플레이가 존재하기도 전의 모델링 시간입니다. 반복은 양방향 모두 느립니다: 메시가 바뀌면 조명, 세부 수준(LOD) 메시, 충돌 형상을 모두 다시 확인해야 합니다. 그 대가는 타일 격자가 할 수 없는 일을 하는 카메라, 그리고 스캔하거나 키트배시한 환경을 받아들이는 파이프라인입니다.

실용적인 질문은 어느 쪽이 더 좋아 보이는지가 아닙니다. 첫 플레이 가능 시간 이후에 애셋 변경을 얼마나 많이 할 것으로 예상하는지입니다. 2D 프로젝트는 수십 번의 변경을 저렴하게 흡수합니다. 3D 프로젝트는 열두 번쯤 흡수하고 나면 각 변경에 일주일씩 치르게 됩니다.

RPG Maker는 당신을 2D에 고정하며, 그것이 장점입니다: 맵 편집기, 오토타일, 캐릭터 세트가 모두 타일 격자를 전제로 하므로, 타일셋만이 반드시 제작해야 하는 애셋 유형입니다. Unreal은 3D 쪽으로 고정합니다 — Paper2D가 스프라이트를 렌더링할 수는 있지만 조명, 물리, 애니메이션 도구가 메시를 중심으로 만들어져 있어, 그곳에서 2D 게임은 엔진과 싸우게 됩니다.

Godot과 Unity는 나중에 결정하게 해 주는 둘이지만, 그 대가를 치릅니다. 프로토타입을 스프라이트에서 메시로 바꾸는 것은 충돌을 다시 만들고, 카메라 거리를 다시 조정하고, 모든 애니메이션을 다시 제작하는 일을 뜻합니다. 스프라이트 시트의 프레임 수와 리그의 클립 길이는 공통점이 전혀 없기 때문입니다. 첫 전투 조우를 만들기 전에 차원을 고르세요. 그 후가 아니라.

코딩이 필요한가요?

아니요, 도구가 이미 모델링하지 않은 무언가를 원하는 순간까지는요. RPG Maker의 이벤트 시스템은 조건, 스위치, 변수를 가진 명령 목록이며, 코드를 한 줄도 입력하지 않고 퀘스트 체인, 상점, 턴제 전투를 만들 수 있습니다. 벽은 데이터베이스가 표현할 수 없는 사용자 정의 메뉴 레이아웃과 전투 공식에서 나타납니다. 그 지점에서 당신은 JavaScript 플러그인 파일을 편집하고 플러그인 목록에 등록하게 되는데, 이는 초보자의 일이 아니라 플러그인 제작자의 일입니다.

Unreal의 Blueprints는 완전한 비주얼 스크립팅 계층을 갖춘 범용 엔진에 가장 가까운 것입니다. RPG 전체의 로직을 노드 그래프로 만들 수 있으며, C++ 대비 성능 차이는 대규모 군중이나 발사체 루프처럼 액터마다 매 프레임 실행되는 코드에서만 드러납니다. Unity의 비주얼 스크립팅은 패키지에 서드파티 애셋을 더한 것이고, 대부분의 튜토리얼과 포럼 답변은 C#을 전제로 합니다. Godot에는 내장 게임플레이 노드 그래프가 전혀 없습니다. GDScript가 그 경로이며, 구문이 의도적으로 Python에 가깝습니다. Phaser는 첫 줄부터 코드입니다. Ren'Py의 스크립트 형식은 프로그램보다 시나리오에 가깝게 읽히며, 예외적인 경우에는 Python을 쓸 수 있습니다.

노드 그래프 대 언어라는 구도에 들어맞지 않는 네 번째 선택지가 있습니다: 게임을 설명하면 도구가 그것을 구축하게 하는 것입니다. Neta Studio의 3D 게임 빌더는 작성된 설명을 받아 탭에서 실행되는 Three.js 세계를 만들어 냅니다. 장면 파일을 열어 알맞은 인스펙터 패널을 찾아 헤매는 대신 변경 사항을 설명함으로써 수정합니다. 피해 공식에 대해 프레임 단위의 정확한 통제가 필요할 때는 노드 그래프의 형편없는 대체물이고, 대부분의 프로젝트가 설정에 허비하는 2주를 대신할 때는 아주 좋은 대체물입니다.

Ren'Py가 가장 명확한 경우입니다. 프로젝트는 평범한 텍스트 스크립트 파일 폴더이며, 아무 텍스트 편집기와 런처만 있으면 작성하고 실행할 수 있고, 런처의 유일한 필수 역할은 게임을 시작하는 것입니다. Phaser가 두 번째 경우입니다: 프로젝트는 JavaScript 폴더와 HTML 파일 하나이고, 브라우저가 편집기입니다. 어느 경로도 시각적 맵 페인터를 주지는 않지만, 텍스트 편집기에서 읽을 수 없는 프로젝트 포맷을 설치하라고 요구하지도 않습니다.

RPG Maker는 해당되지 않습니다. 데이터베이스, 맵, 이벤트 페이지가 편집기의 프로젝트 포맷 안에 있기 때문입니다. 브라우저 빌더는 반대 방향으로 갑니다: 설명이 곧 프로젝트이고, 편집기는 이미 보고 있는 텍스트 필드입니다. 편집기를 피하는 이유가 배우고 싶지 않아서라면, 그 구분이 기능 목록보다 더 중요합니다.

내보내기와 게시

무엇을 내보내는지가 플레이어가 플레이 전에 무엇을 해야 하는지를 결정합니다. RPG Maker는 NW.js를 통해 Windows 및 macOS 빌드를 배포하며, 브라우저와 모바일 배포는 버전과 커뮤니티 도구에 따라 다릅니다. 브라우저 배포는 HTML 파일, JavaScript 런타임, 프로젝트의 이미지 및 오디오 디렉터리로 이루어집니다 — 어떤 정적 서버에도 호스팅할 수 있지만, 타이틀 화면이 나타나기 전에 애셋이 다운로드됩니다.

Godot는 export_presets.cfg에 저장된 프리셋을 통해 내보냅니다. 웹 내보내기는 HTML 셸, .wasm 바이너리, 프로젝트 데이터가 담긴 .pck 파일을 만들어 냅니다. Godot 4의 스레드 웹 내보내기는 SharedArrayBuffer를 필요로 하며, 이는 호스트가 COOP와 COEP 헤더를 보내야 함을 뜻합니다. 그것이 없으면 단일 스레드 빌드를 배포하거나 아니면 페이지가 시작되지 않습니다. Unity의 웹 빌드는 IL2CPP를 거쳐 WebAssembly와 데이터 번들을 만들어 내며, 스레딩에는 같은 헤더가 필요하고 무시할 경우 결과도 같습니다.

Unity의 두 가지 실질적인 웹 문제는 최초 로딩과 메모리입니다. 시작 시 모든 것을 로드하는 장면은 첫 프레임에서 멈춥니다. 해결책은 더 작은 빌드가 아니라 어드레서블 애셋과 장면 분할입니다. Unreal은 데스크톱과 콘솔용 네이티브 바이너리를 내보내고 지원되는 브라우저 타깃이 없습니다. Phaser는 아무것도 내보내지 않는데, 파일이 이미 웹 파일이기 때문입니다 — 배포는 폴더 복사입니다. Ren'Py는 빌드 설정에서 플랫폼별 배포판을 만들어 내며 웹 빌드도 포함하고, 애셋을 런타임과 함께 패키징합니다.

정적 호스트에 게시한다면 게임을 테스트하기 전에 헤더를 테스트하세요. COOP와 COEP를 설정하는 로컬 서버는 운영 환경에서만 나타나는 호스팅 문제를 숨겨 줍니다.

엔진 없는 선택지

위의 어느 것도 적용되지 않는 경로가 있습니다. 설치할 엔진도, 프로젝트 폴더도, 설정할 내보내기 프리셋도 없기 때문입니다. Neta Studio의 3D 게임 빌더는 작성된 설명을 받아 브라우저 탭에서 Three.js로 렌더링되는 세계를 만들어 냅니다. 결과물은 페이지입니다. 링크를 보내면 세계가 열립니다. 상대는 압축 파일을 다운로드하거나, 설치 프로그램을 실행하거나, 실행 파일을 신뢰할지 판단할 필요가 없습니다.

그것은 작업의 형태를 바꿉니다. 수정 후 다시 실행할 빌드 단계도, 유지 관리할 플랫폼별 내보내기도 없습니다. 지형, 카메라 각도, 조명, 존재하는 캐릭터, 플레이어가 할 수 있는 일을 설명하면 빌더가 장면 그래프를 조립하고 Three.js가 그것을 그립니다. Agent Sprite Forge는 아티스트가 존재하기 전에 캐릭터나 소품이 필요할 때를 다루며, Mini World와 The Cyclops' Island는 카메라, 지면, 이동이 이미 작동하는 모습을 보려고 열어 볼 수 있는 플레이 가능한 세계입니다.

이것은 대규모 RPG에서 Godot나 Unity를 대체하지 않습니다. 정확한 수치 요구 사항이 있는 시스템 — 피해 공식, 버전 간 호환성을 유지해야 하는 저장 형식, 십여 개의 상호작용하는 상태를 가진 전투 상태 머신 — 에는 여전히 진짜 스크립팅 계층이 필요합니다. 이것이 제거하는 것은 그 이전 단계, 즉 세계가 아직 존재하지 않아 카메라가 잘 읽히는지나 축척이 잘못된 느낌인지 판단할 수 없는 단계입니다.

10분 만에 고르는 방법

이것들을 순서대로 짚어 보고, 결정이 나는 첫 줄에서 멈추세요. 대부분의 프로젝트는 처음 두 개에서 결판이 납니다.

그것이 속한 세계로 걸어 들어가세요

엔진 비교는 한 행이 실행되기 전까지는 표에 불과합니다. 브라우저 행은 아무것도 설치하지 않고 시험해 볼 수 있는 행입니다: 한 문장으로 설명되어 페이지로 내보내진 세계를 열어 보세요. 표의 마지막 행이 실제로 어떤 느낌인지 알 수 있습니다.