아트보다 재미를 먼저 검증하라 — 게임 개발의 첫 단추는 프로토타입

게임 개발을 시작할 때 첫 단추는 코드도, 아트도, 스토리도 아닌 재미의 검증입니다. 머릿속 구상이 좋아 보여도 실제로 조작해 보면 전혀 다를 수 있고, 이것은 다 만들기 전에 확인할 수 있습니다. 이 자료는 그 방법으로 작고 엉성한 프로토타입을 제시합니다.

이 문서는 NotebookLM(노트북 LM)으로 자료를 조사해 만든 문서입니다.

• "구상이 멋지니 완성하면 재미있을 것"과 "완성 전엔 재미를 알 수 없다"는 둘 다 착각입니다
• 게임 개발의 토대는 게임플레이입니다. 그 위에 스토리·음악·아트가 올라갑니다
• 프로토타입은 그래픽·스토리·코드 품질을 버리고 핵심 메카닉의 재미만 확인합니다
• 빨리 실패해야 관점을 바꿀 기회가 생깁니다. 자력 플랫포머 사례가 그 과정을 보여 줍니다
• 검증 질문은 셋입니다. 재미있는가, 계속 만들 가치가 있는가, 토대가 튼튼한가

왜 첫 단추를 잘못 끼우는가

카터의 저주 사례가 흔한 이유는, 아트와 컷신은 만든 만큼 눈에 보이는 진척이기 때문입니다. 게임플레이 검증은 결과가 네모 몇 개라 진척이 없어 보입니다. 그래서 팀일수록 보이는 작업부터 하게 되고, 핵심 재미의 문제는 수십 시간이 쌓인 뒤에야 드러납니다.

프로토타입은 이렇게 만든다

원칙 네 가지를 한 문장으로 줄이면 검증할 것 하나만 남기고 나머지는 대충 두라입니다. 그래픽이 엉성해야 오히려 판단이 정확해집니다. 보기 좋은 화면은 재미가 없는 조작도 그럴듯하게 느끼게 만들기 때문입니다.

사례 — 자력 플랫포머의 방향 전환

이 사례에서 눈여겨볼 점은 1차 프로토타입이 실패했기 때문에 더 나은 구조를 찾았다는 것입니다. 자석을 몸에서 떼어 도구로 만들자 조작감이 돌아왔고, 던지기·유인·무게추 같은 플레이는 기획서가 아니라 조작 중에 나왔습니다. 아트까지 입힌 뒤였다면 이 방향 전환은 비용 때문에 쉽게 결정하지 못했을 것입니다. 이동, 점프, 레벨 배치처럼 이미 풀린 문제를 기존 스크립트와 도구로 해결한 것도 같은 이유입니다. 시간은 이 게임에만 있는 메카닉에 써야 합니다.

검증 질문과 경계할 것

세 번째 질문인 "토대가 튼튼한가"는 재미와 다른 기준입니다. 한 판이 재미있어도 레벨을 수십 개로 늘릴 변주가 나오는지, 수익 구조를 얹을 여지가 있는지까지 봐야 본 개발로 넘어갈 수 있습니다. 모바일 게임이라면 여기에 짧은 세션에서도 재미가 전달되는지를 더해 보는 것이 좋습니다.

자주 묻는 질문

프로토타입에는 기간을 얼마나 써야 하나요? 정해진 기준은 없지만 며칠에서 1~2주 안에 판단할 수 있는 크기로 잡는 편이 좋습니다. 길어지면 이미 본 개발이 시작된 것입니다.

프로토타입 코드를 본 개발에 그대로 써도 되나요? 권하지 않습니다. 버그를 감수하고 빨리 만든 코드라 구조를 다시 짜는 편이 결국 빠릅니다. 검증된 메카닉의 규칙만 가져가면 됩니다.

아트 없는 프로토타입으로 투자자나 퍼블리셔를 설득할 수 있나요? 재미 검증용과 설득용은 목적이 다릅니다. 먼저 재미를 확인한 뒤 핵심 장면 하나에만 아트를 입힌 시연판을 따로 만드는 방식이 일반적입니다.

프로토타입이 재미없으면 아이디어를 버려야 하나요? 바로 버리기보다 자력 사례처럼 규칙 하나를 바꿔 다시 시험해 봅니다. 두세 번 바꿔도 재미가 없으면 그때 접는 것이 비용이 적습니다.

저희가 이 이야기를 하는 이유

에버스톤은 2013년부터 모바일 게임을 만들어 왔고, 방치형 RPG와 캐주얼 게임을 직접 서비스하고 있습니다. 아트 작업에 들어가기 전에 핵심 조작을 먼저 만들어 확인해야 한다는 이 자료의 주장에 공감합니다. 재미가 확인되지 않은 채 쌓은 작업은 되돌리기 가장 비싼 작업이기 때문입니다.

이 자료는 YouTube 채널 Game Maker's Toolkit의 영상 "The mistake every new game developer makes (Developing 2)"를 요약·재구성한 것이며, 인용한 사례는 원 자료 기준으로 저희가 검증한 내용이 아닙니다.