첫 게임은 얼마나 작아야 할까요?

끝까지 만들 수 있을 만큼 작게 잡으세요. 동작 하나, 화면 하나, 이기거나 지는 방법 하나, 몇 분이면 끝나는 플레이. 더 큰 아이디어를 그 크기로 줄이는 방법을 알려 드립니다.

끝까지 만들 수 있을 만큼 작아야 합니다. 플레이어가 하는 일 하나, 화면 하나, 이기거나 지는 방법 하나, 그리고 게임 전체를 플레이하는 데 몇 분이면 되는 크기입니다. 그것을 주말 한 번이나 저녁 시간 2주로 만들 수 있다면 알맞은 크기입니다. AI 코딩 어시스턴트는 플레이할 수 있는 버전에 더 빨리 도달하게 해 주지만 이 답을 바꾸지는 않으며, 이 글은 그 이유를 설명합니다. 더 큰 아이디어를 줄이려면 게임을 한 문장으로 쓰고, 그 문장에 필요한 것만 남기고, 나머지는 모두 '나중에'라는 목록으로 옮기세요.

작은 게임은 어떤 모습인가요?

네 가지 한계를 사용하세요.

• 동작 하나. 플레이어는 움직이거나, 점프하거나, 짝을 맞추거나, 조준합니다. 그중 하나만 합니다.
• 화면 하나, 또는 반복되면서 점점 어려워지는 레벨 하나.
• 이기거나 지는 방법 하나. 넘어야 할 점수, 타이머, 또는 줄어드는 목숨.
• 몇 분, 시작을 누른 때부터 결과를 볼 때까지.

이 한계 안의 게임이 진짜 게임이라는 것을 공개된 두 가지 기준이 보여 줍니다.

첫 번째는 게임 잼입니다. Ludum Dare의 Compo 부문에서는 한 사람이 48시간 안에 게임을 처음부터 만듭니다. Jam 부문은 72시간을 주고 팀 참가를 허용합니다. 이 대회의 규칙은 이상적인 출품작을 브라우저에서, 몇 분 안에, 혼자 플레이하는 게임으로 설명합니다. 2026년 10월 9일에 규칙 페이지에 적혀 있던 내용입니다.

두 번째는 튜토리얼입니다. MDN의 2D breakout game은 같은 날 기준으로 열한 개의 강의로 이루어져 있었습니다. 캔버스, 움직이는 공, 벽, 패들, 게임 오버, 벽돌 배열, 점수와 승리, 추가 목숨, 그리고 애니메이션, 버튼, 약간의 무작위성입니다. 이 목록은 이 크기에서 '완성'이 무엇을 뜻하는지 잘 보여 줍니다.

AI가 코드를 쓰는데도 왜 작은 크기가 여전히 중요한가요?

코드를 쓰는 일이 작업의 전부였던 적은 없기 때문입니다. 어시스턴트는 쓰는 시간을 줄여 줍니다. 세 가지는 여전히 여러분의 몫입니다.

변경할 때마다 여전히 직접 플레이해야 합니다. 변경이 있을 때마다 누군가는 게임을 실행하고, 해 보고, 전보다 나아졌는지 판단해야 합니다. 그 누군가가 여러분입니다.

기능은 곱으로 늘어납니다. 새 기능은 이미 있는 모든 기능과 함께 동작해야 합니다. 기능 세 개는 충돌할 수 있는 쌍 세 개를 만듭니다. 여섯 개는 열다섯 쌍을 만듭니다. 열두 개는 예순여섯 쌍을 만듭니다. 확인할 일은 기능 목록보다 훨씬 빠르게 늘어납니다.

요청은 말한 것보다 더 많은 것을 건드립니다. '상점을 추가해 줘'는 작업 하나처럼 들립니다. 하지만 점수, 일시 정지 화면, 조작, 저장되는 내용이 바뀌고, 누가 코드를 썼든 그 하나하나를 나중에 확인해야 합니다.

작은 게임은 머릿속에 담아 둘 수 있는 게임입니다. 변경 사항을 정확히 설명하고, 돌아온 결과를 읽고, 무엇이 망가졌는지 알아챌 수 있습니다.

기능 하나를 더하면 나중에 어떤 비용이 드나요?

플랫폼이나 언어를 추가할 때마다 비용이 다시 듭니다. 우리는 HeapPlay에서 호스팅하는 슈팅 게임 KittenGalaxy에서 이것을 보았습니다.

터치 조작을 추가했을 때 작업량은 게임 단위가 아니라 화면 단위로 계산되었습니다. 메뉴, 이름 입력, 비행, 상점, 수학 문제, 그리고 게임 오버와 엔딩 화면에 각각 전용 조작이 필요했습니다. 게임을 열 개 언어로 옮겼을 때는 게임 페이지에 기록된 대로 모든 화면을 각 언어로 확인했습니다.

두 작업 모두 실수가 아니었습니다. 하지만 둘 다 게임에 이미 있던 화면 수에 따라 크기가 정해졌습니다. 화면이 하나인 게임은 그 값을 한 번만 치릅니다.

아이디어를 그 크기로 어떻게 줄이나요?

1. 게임을 한 문장으로 쓰세요: 플레이어가 무엇을 하고 어떻게 끝나는지. 예: '우주선을 좌우로 움직이며 침입자를 쏘고, 목숨이 다하면 끝난다.'
2. 상상한 나머지를 모두 적으세요. 보스, 상점, 2인 플레이, 스토리. 아무것도 잃지 않도록 전부 적습니다.
3. 그 문장에 필요한 것만 남기세요. 어떤 기능이 없어도 문장이 참이라면 그 기능은 '나중에' 목록으로 갑니다. 미룬 것이지 지운 것이 아닙니다.
4. 아이디어를 줄이기 전에 콘텐츠를 줄이세요. 적은 다섯 종류가 아니라 한 종류. 스무 개의 레벨이 아니라 점점 빨라지는 웨이브 하나.
5. 시작하기 전에 기간을 정하세요. 주말 한 번, 또는 저녁 시간 2주. 늦어지면 게임에서 무언가를 빼고 날짜는 지키세요.

줄이고 난 뒤의 그 예시입니다.

어시스턴트와 작업하면서 그 크기를 어떻게 지키나요?

• 그 한 문장과 '나중에' 목록을 프로젝트 안의 파일에 넣고, 세션을 시작할 때마다 어시스턴트에게 그 파일을 가리켜 주세요.
• 한 번에 한 항목만 요청하고, 다음 항목을 요청하기 전에 게임을 플레이하세요.
• 요청하기 전에 동작하는 버전을 버전 관리의 커밋으로 저장해 두어, 나쁜 변경을 되돌릴 수 있게 하세요.
• 변경이 요청한 것보다 많은 것을 가져오면 남는 부분을 빼세요. 아무도 요청하지 않은 기능도 범위에 들어갑니다.

완성되었는지 어떻게 알 수 있나요?

시작하기 전에 정하고 적어 두세요. 첫 게임은 다음과 같을 때 완성된 것입니다.

• 낯선 사람이 여러분의 설명 한마디 없이 링크에서 게임을 시작할 수 있다.
• 조작 방법이 화면에 표시되어 있다.
• 질 수 있고, 페이지를 새로 고치지 않고 다시 시작할 수 있다.
• 지원한다고 말하는 모든 기기에서 처음부터 끝까지 플레이했고, 어떤 기기는 해 보지 않았는지 밝힌다.

그런 다음 사람들이 플레이할 수 있는 곳에 올리세요. 이렇게 작은 게임도 게임입니다. HeapPlay의 제출 규칙은 실제로 플레이할 수 있고 공식 링크가 있는 게임을 요구하며, 최소 크기는 정하지 않습니다. 계정 없이 제출할 수 있고, 모든 제출은 게시되기 전에 에디터가 검토합니다.

'나중에' 목록은 어떻게 되나요?

그 목록이 여러분의 계획이 되고, 순서를 더는 짐작하지 않아도 됩니다. 사람들이 작은 버전을 플레이하면, 그들의 말이 어떤 항목을 먼저 할지 알려 줍니다. 그 하나를 추가하고, 새 버전으로 공개하고, 다시 들어 보세요.

자주 묻는 질문

첫 게임은 얼마나 걸려야 하나요? 측정된 답은 없습니다. 지킬 수 있는 기한을 고르고 게임을 거기에 맞추세요. Ludum Dare는 참가자에게 48시간 또는 72시간을 줍니다.

고전 게임의 클론이면 충분한가요? 연습으로는 충분합니다. '완성'이 어떤 모습인지 이미 알고 있기 때문입니다. 다른 사람에게 보여 주기 전에 한 가지를 바꿔 여러분의 것으로 만드세요.

첫 게임이 꿈의 게임이어야 하나요? 그 게임에서 플레이할 수 있는 가장 작은 조각을 먼저 만들고, 나머지는 '나중에' 목록에 두세요.

AI 어시스턴트가 코드를 쓰니 더 크게 시작해도 되나요? 플레이할 수 있는 버전에는 더 빨리 도달합니다. 플레이하고, 확인하고, 결정하는 일은 여전히 여러분의 몫이며, 기능이 하나 늘 때마다 함께 늘어납니다.

3분짜리 게임도 공개할 가치가 있나요? 완성되어 있다면 그렇습니다. 플레이어는 평점을 주고 리뷰를 쓸 수 있으며, 인증된 개발자는 새 버전마다 버전과 변경 사항을 기록할 수 있습니다.