GameCraft-Bench - Can Agents Build Playable Games End-to-End in a Real Game Engine?
T. Luo, R. Wang, J. Bi, C. Xu, et al., "GameCraft-Bench: Can Agents Build Playable Games End-to-End in a Real Game Engine?," arXiv:2606.17861, 2026.
저자
Benyou Wang CUHK Shenzhen 교수 그룹과 Tencent Hunyuan 팀이 힘을 합친 논문입니다. 제1저자 세 명(Tongxu Luo, Rongsheng Wang, Jiaxi Bi)은 모두 공동 제1저자(*) 표기로 균등 기여를 인정받았습니다. Tongxu Luo와 Rongsheng Wang은 Wang 교수 소속 CUHK Shenzhen 연구 그룹이고, Jiaxi Bi는 Tencent Hunyuan 팀에서 왔습니다. USTB, DualverseAI, SJTU, NUS 소속 연구자들도 참여해 총 25인 규모의 협업으로 완성된 벤치마크입니다.
이 팀이 게임 생성 벤치마크를 만든 배경에는 공통된 문제의식이 있습니다. 코딩 에이전트를 평가하는 도구는 많지만, "실제로 실행되고 플레이 가능한" 결과물을 측정하는 도구는 없었습니다. 게임 생성은 코드·에셋·씬·런타임 상호작용이 모두 맞물려야 성립하기 때문에, 기존 코딩 벤치마크가 비켜 가는 바로 그 통합 능력을 시험할 수 있다고 판단했습니다.
배경
기존 코딩 에이전트 평가 벤치마크들, SWE-bench·HumanEval·LiveCodeBench 등은 주로 함수 단위 코드 완성 또는 깃허브 이슈 수정을 측정합니다. 결과물이 "컴파일 가능하고 테스트를 통과하는가"가 기준입니다. 그런데 실제로 인터랙티브한 소프트웨어를 만드는 능력은 이와 다릅니다. 에이전트가 코드를 짜도 화면에 아무것도 안 뜨거나, 버튼을 눌러도 아무 반응이 없거나, 게임 루프가 돌아가지 않는 경우가 얼마든지 생깁니다. 코드가 구문적으로 올바르더라도 런타임 상호작용에서 실패하는 종류의 버그를 기존 벤치마크는 잡지 못합니다.
이 논문은 그 공백을 세 개의 요구사항으로 정의합니다.
- Engine Grounding: 실제 게임 엔진에서 빌드·실행되어야 합니다. 시뮬레이션·샌드박스가 아니라 진짜 엔진.
- Artifact Completeness: 씬·스크립트·에셋·데모 트레이스까지 갖춘 완성된 결과물이어야 합니다.
- Interactive Verification: 키보드·마우스 입력을 실제로 주입해 동영상을 녹화한 뒤, 그 영상을 보고 평가해야 합니다.
엔진 선택지로 Godot 4를 택한 것은 실용적인 이유입니다. 무료·오픈소스라 라이선스 제약이 없고, --headless 플래그로 디스플레이 없이 실행할 수 있어 자동화 파이프라인에 적합합니다.
어떻게 만들었나
평가 단위는 **태스크(task)**입니다. 각 태스크는 하나의 게임 장르에 속하는 특정 변형입니다. 예를 들어 Strategy 장르에 "Skirmish"(다크 판타지 전술 전투)가 있고, Racing 장르에 "City Chase"가 있는 식입니다. 140개 태스크가 15개 장르에 분포합니다.
각 태스크는 두 파일로 구성됩니다.
- instruction.md: 에이전트에게 전달하는 자연어 지시문. "당신은 Godot 4에서 다크 판타지 전술 스커미시를 만들어야 합니다. 격자 이동, HP 시스템, 복수의 유닛 타입이 있어야 합니다"처럼 플레이어 경험을 구체적으로 기술합니다.
/workspace/assets/library/에 Kenney CC0 스프라이트 팩이 마운트되어 있어 에이전트가 직접 골라 쓸 수 있습니다. - rubric.json: 자동 평가 기준. 4개 카테고리(M, D, V, A)에 각 4개 요구사항 항목이 들어 있고, 각 항목은 0~1점으로 채점됩니다.
점수 공식은 다음과 같습니다.
\[\text{Score} = \text{BUILD} \times (0.15 \cdot M + 0.35 \cdot D + 0.15 \cdot V + 0.35 \cdot A)\]
- \(\text{BUILD} \in \{0, 1\}\): Godot 헤드리스 실행이 성공하면 1, 실패하면 0.
- \(M\): Core Mechanics (코어 메커닉 구현)
- \(D\): Content Depth (콘텐츠 깊이)
- \(V\): Functional Visuals (기능적 비주얼)
- \(A\): Art & Presentation (아트와 연출)
BUILD가 0이면 나머지 점수와 무관하게 전체 점수가 0이 됩니다. 게임이 실행조차 안 된다면 아무리 코드가 정교해도 의미가 없다는 판단입니다. Content Depth와 Art & Presentation에 각각 0.35로 가중치가 높은 이유는, "동작하는 프로토타입"과 "완성도 있는 게임" 사이의 거리를 측정하고자 했기 때문입니다.
평가 파이프라인은 이렇게 돌아갑니다. 에이전트가 7,200초(2시간) 안에 /workspace/game/에 Godot 프로젝트와 최대 10개의 데모 트레이스(demo_outputs/*.json)를 제출합니다. 각 트레이스에는 마우스 클릭·키보드 입력의 시간 순서가 적혀 있고, 검증기(verifier)가 Godot 인스턴스를 새로 시작하고 트레이스를 재생하면서 30fps로 1280×720 화면을 녹화합니다. 녹화된 영상에서 0.5초마다 프레임을 추출해 GPT-5.5에 넘기면, 각 요구사항 항목을 0~1점으로 채점합니다.
무엇으로 구성돼 있나
15개 장르는 다음과 같습니다: Platformer, Strategy, Tycoon, Open-world, Roguelike, Visual novel, Puzzle, Shooter, Simulation, Card game, Horror, Rhythm, Idle, Racing, Sports. 각 장르에 평균 9~10개 태스크가 있고 전체 140개입니다.
루브릭 설계에서 눈에 띄는 점은 아트 요구사항입니다. Art & Presentation 항목은 단순히 "그림이 있느냐"가 아니라, 테마와 일관성을 묻습니다. Strategy-Skirmish 예시에서 A1 요구사항은 "다크 판타지 아트 디렉션이 있어야 한다: 지형·유닛·UI·이펙트·배경이 하나의 시각적 언어를 공유해야 한다"고 씁니다. ColorRect 도형이나 기본 Godot 위젯으로 채우면 0.5점 이상을 받을 수 없습니다. 에이전트가 CC0 에셋 라이브러리에서 적절한 스프라이트를 골라 쓰지 않으면 자동으로 감점됩니다.
결과
최강 조합은 Claude Code + Opus-4.7 high (41.46%)이지만, 절반에도 미치지 못합니다.
하네스 |
모델 |
전체 (%) |
M |
D |
V |
A |
|---|---|---|---|---|---|---|
Claude Code |
Opus-4.7 high |
41.46 |
55.34 |
39.48 |
42.78 |
36.86 |
Codex |
GPT-5.5 high |
39.49 |
54.36 |
38.61 |
41.84 |
32.94 |
Kimi Code |
Kimi-K2.6 |
30.65 |
39.76 |
28.07 |
33.66 |
27.99 |
Claude Code |
MiMo-V2.5-Pro |
24.10 |
32.33 |
22.59 |
27.45 |
20.65 |
Code Buddy |
GLM-5.1 |
18.29 |
25.23 |
17.80 |
21.14 |
14.59 |
Code Buddy |
MiniMax-M2.7 |
10.95 |
14.27 |
9.92 |
14.92 |
8.85 |
Codex |
DeepSeek-V4-Pro |
2.15 |
2.25 |
1.69 |
1.97 |
2.63 |
M = Core Mechanics, D = Content Depth, V = Functional Visuals, A = Art & Presentation
논문은 이 결과에서 5가지 핵심 발견을 뽑아냅니다.
발견 1: 메커닉은 구현하지만 게임은 완성 못 한다. 상위 두 모델도 \(M\) 점수는 54~55점이지만 전체 점수는 41점 수준입니다. 에이전트들은 개별 메커닉을 잘 구현하는 편이지만, 네 카테고리를 모두 높은 수준으로 통합하는 데서 실패합니다.
발견 2: 렌더된 상호작용이 디버깅을 돕는다. 영상으로 실제로 확인해야 잡히는 버그가 있습니다. "코드에서는 정상인데 화면에서는 버튼이 클릭 안 됨" 같은 류의 비코드 오류는 정적 분석으로 발견이 불가능합니다. 검증기의 Interactive Verification 단계가 이 역할을 담당합니다.
발견 3: 도구 사용량과 품질은 무관하다 (\(r = +0.016\)). 에이전트가 도구를 많이 호출한다고 해서 게임 품질이 올라가지 않았습니다. 전략적으로 어떤 도구를 쓰느냐가 중요하지, 호출 횟수 자체는 지표가 되지 못합니다.
발견 4: judge는 안정적이지만 관대한 편이다. 동일 녹화를 반복 채점했을 때 표준편차가 약 0.004로 일관성은 높습니다. 다만 0.5점 구간에서 약간 관대한 경향이 있어, 실제 점수가 인간 평가자 기준보다 다소 높게 책정될 수 있습니다.
발견 5: 게임 생성 능력은 4개 카테고리 간에 부분적으로 독립적이다. 특정 카테고리가 두드러지게 높고 다른 카테고리가 낮은 패턴을 모델마다 보입니다. 예를 들어 Opus-4.7 high는 Art 점수가 다른 카테고리 대비 상대적으로 낮은 반면, Strategy, Simulation, Racing 같은 복잡한 장르에서도 일정 수준을 유지합니다.
가족 단위 결과(Appendix B)에서 흥미로운 점은 Horror와 Rhythm 장르입니다. 두 장르 모두 상위 모델에서 50점대 이상을 기록했는데, 이는 상대적으로 단순한 게임 구조(공포 연출은 텍스트+음향 없이 비주얼로 처리 가능, 리듬 게임은 타이밍 메커닉 하나에 집중) 덕분으로 보입니다. 반대로 Card game 장르는 모든 모델에서 가장 낮은 점수를 보였습니다. 카드 규칙, 덱, 상태 머신을 동시에 관리해야 하는 복잡성이 이유로 보입니다.
회고
저자들은 세 가지 한계를 밝힙니다.
첫째, 2D Godot만 평가합니다. Unity·Unreal·3D 게임은 포함되지 않았습니다. 2D 제약은 자동화 파이프라인 구축 비용을 낮추기 위한 실용적 선택이지만, 에이전트의 3D 게임 생성 능력은 별도 벤치마크가 필요합니다.
둘째, 오디오는 평가하지 않습니다. 게임 경험의 중요한 축인 음악·효과음이 채점 기준 밖입니다. GPT-5.5 judge가 영상 기반으로만 작동하기 때문입니다.
셋째, judge가 약간 관대합니다. 발견 4에서 언급했듯 0.5점 구간 판정에서 인간보다 높게 줄 가능성이 있습니다. 에이전트 품질이 올라가면 judge calibration도 함께 정교해져야 할 것입니다.
논문에 명시되지는 않았지만, 에이전트가 CC0 에셋 라이브러리에 의존하도록 설계한 점도 현실과의 차이를 만듭니다. 실제 게임 개발에서는 에셋 생성·구매·라이선스 확인까지 에이전트가 처리해야 합니다.
정리
- 최강 에이전트도 41점: Claude Code + Opus-4.7 high가 1위이지만 100점 만점에 41.46점. 에이전트가 게임 메커닉은 구현하지만 완성도 있는 게임을 조립하는 능력은 아직 입증되지 않았습니다.
- 빌드 실패가 점수 0으로 직결: \(\text{BUILD} = 0\)이면 전체 점수가 없습니다. DeepSeek-V4-Pro가 2.15점에 그친 것은 빌드 실패율이 높기 때문입니다.
- 도구 많이 쓰기 = 품질 향상 아님: 호출 횟수 상관계수 \(r = +0.016\). 에이전트 스캐폴딩 설계가 양보다 질에 집중해야 한다는 시사점입니다.