게임잼 프로젝트를 ‘완성된 프로토타입’으로 만드는 전략

게임잼의 목표를 다시 정의하기

게임잼에서 중요한 것은 많은 기능을 구현하는 일이 아니라 한 번의 플레이만으로도 게임의 핵심 재미를 전달하는 일이다. 제출물은 상용 게임의 축소판이 아니라 가설을 검증하는 프로토타입에 가깝다.

먼저 팀이 한 문장으로 답할 수 있어야 한다.

플레이어는 무엇을 반복하고 그 반복이 왜 재미있는가?

예를 들어 ‘시간을 멈추는 액션 게임’이라는 설명만으로는 개발 범위를 정하기 어렵다. 반면 ‘시간을 멈춘 짧은 순간에 적의 탄환 배치를 바꾸고 탈출하는 액션 게임’처럼 정의하면 필요한 기능이 선명해진다. 플레이어 이동, 시간 정지, 탄환 상태 전환, 목표 지점만으로도 첫 번째 플레이를 만들 수 있다.

핵심 루프를 먼저 고정한다

게임잼 기획은 아이디어 목록이 아니라 핵심 루프에서 시작하는 편이 안전하다. 핵심 루프는 플레이어가 짧은 시간 안에 여러 번 경험할 행동의 순서다.

flowchart LR
    A[상황 인지] --> B[핵심 행동 선택]
    B --> C[즉각적인 결과]
    C --> D[보상 또는 위험 변화]
    D --> A

이 루프의 각 단계는 프로토타입에서 눈에 보이거나 들려야 한다. 이동만 구현한 상태에서는 ‘핵심 행동 선택’을 검증할 수 없고 공격만 구현한 상태에서는 결과가 재미있는지 판단하기 어렵다. 가장 먼저 만들 기능은 항상 루프를 한 바퀴 돌게 하는 최소 기능이다.

게임잼 프로토타입의 핵심 루프를 메모와 간단한 화면으로 검토하는 모습

핵심 루프를 정했다면 기능을 세 종류로 나눈다.

필수: 루프가 작동하는 데 반드시 필요한 기능
강화: 재미를 더 분명하게 만드는 피드백과 변주
보류: 시간이 남을 때만 추가할 콘텐츠와 장식

이 분류에서 ‘필수’는 가능한 한 적어야 한다. 적을 여러 종류 넣는 일, 복잡한 업그레이드 트리, 온라인 순위표는 대개 보류 항목이다. 대신 명확한 조작감, 실패와 성공의 피드백, 재시작 흐름은 강화 항목이 아니라 사실상 필수에 가깝다.

첫 두 시간에 세로 조각을 만든다

세로 조각(vertical slice)은 게임의 시작부터 결과까지를 아주 작은 범위로 연결한 플레이 가능한 구간이다. 게임잼에서는 이 구간을 초기에 만드는 것이 일정 관리의 핵심이다.

첫 두 시간의 목표는 다음 정도면 충분하다.

플레이어가 조작할 수 있다.
핵심 행동을 한 번 실행할 수 있다.
성공 또는 실패 조건이 있다.
결과를 확인하고 다시 시작할 수 있다.

이 단계에서 그래픽, 레벨 크기, 적 수는 임시여도 된다. 단색 도형과 간단한 텍스트라도 입력부터 결과까지 이어지면 팀은 매 시간 실제 게임을 기준으로 판단할 수 있다.

예를 들어 Unity에서 시간 정지 능력의 최소 상태를 만들 때는 복잡한 상태 머신보다 먼저 능력이 작동하고 종료되는지 확인한다.

using UnityEngine;

public class TimeStopAbility : MonoBehaviour
{
    [SerializeField] private float duration = 1.5f;
    private float remainingTime;

    public bool IsActive => remainingTime > 0f;

    void Update()
    {
        if (Input.GetKeyDown(KeyCode.Space) && !IsActive)
        {
            remainingTime = duration;
        }

        if (IsActive)
        {
            remainingTime -= Time.unscaledDeltaTime;
        }
    }
}

이 코드는 완성 구조가 아니다. 다만 능력의 발동과 지속 시간을 즉시 시험할 수 있다. 이후 적과 투사체가 IsActive를 참조해 움직임을 멈추도록 연결하면 핵심 루프의 첫 버전을 빠르게 확인할 수 있다.

시간은 기능 수가 아니라 위험도로 배분한다

게임잼의 일정은 남은 시간보다 통합 위험에 더 크게 좌우된다. 각 작업이 단독으로는 쉬워 보여도 서로 연결되는 순간 문제가 생긴다. 입력, 물리, 애니메이션, UI, 사운드가 한 기능에 동시에 얽히면 마감 직전에 해결하기 어렵다.

기능을 추가하기 전에는 다음 질문을 확인한다.

이 기능이 없으면 핵심 루프가 성립하지 않는가?
기존 시스템과 새로 연결해야 하는 지점은 몇 개인가?
실패했을 때 되돌릴 수 있는가?
임시 구현으로 먼저 검증할 수 있는가?

작업 시간은 낙관적으로 잡기보다 버퍼를 포함해 계산하는 편이 낫다.

예상\ 작업\ 시간 = 구현\ 시간 + 통합\ 시간 + 수정\ 버퍼

특히 마지막 20~30%의 시간은 새 기능보다 빌드 확인, 입력 오류 수정, 난이도 조정, 제출 페이지 작성에 남겨 두는 것이 좋다. 게임잼에서 가장 아쉬운 결과는 기능이 많지만 실행되지 않거나 처음 몇 분이 불친절한 게임이다.

피드백을 가장 값싼 방식으로 보강한다

프로토타입의 재미는 콘텐츠 양보다 피드백의 명확성에서 크게 달라진다. 플레이어가 행동의 결과를 즉시 이해하면 단순한 규칙도 의도적으로 느껴진다.

우선순위가 높은 피드백은 다음과 같다.

행동 직후의 시각 변화: 색상, 크기, 흔들림, 짧은 잔상
행동을 구분하는 소리: 성공, 피격, 능력 사용에 서로 다른 소리 배치
상태를 알리는 UI: 체력, 남은 시간, 목표를 한 화면에서 확인
결과 화면: 성공과 실패의 이유, 재시작 입력을 명확히 표시

핵심 행동의 성공과 실패를 색상 변화, 타이머, 결과 화면으로 전달하는 게임 UI 예시

이때 화면 효과를 많이 넣는 것보다 행동과 결과의 연결을 분명하게 만드는 것이 우선이다. 시간 정지 능력이라면 화면 전체의 색조를 약간 바꾸고 정지 중인 탄환에 다른 색을 적용하며 남은 시간을 짧은 게이지로 표시하는 정도로도 상태를 충분히 전달할 수 있다.

테스트는 ‘재미있었나요?’보다 구체적으로 묻는다

팀 내부에서 반복 플레이하면 조작 방식과 규칙을 이미 알고 있기 때문에 문제를 놓치기 쉽다. 가능하다면 개발에 참여하지 않은 사람에게 3~5분만 플레이를 부탁하고 설명 없이 첫 시도를 관찰한다.

테스트 뒤에는 다음처럼 구체적인 질문을 한다.

처음 목표가 무엇이라고 이해했나요?
가장 먼저 누른 버튼은 무엇이었나요?
실패한 이유를 알 수 있었나요?
다시 해 보고 싶은 순간이 있었나요?

답변을 모두 반영하려고 할 필요는 없다. 여러 사람이 같은 지점에서 멈추거나 같은 규칙을 오해했다면 그 문제는 콘텐츠 추가보다 먼저 고쳐야 한다. 반대로 플레이어가 스스로 규칙을 발견하고 다른 선택을 시도했다면 그 부분이 게임의 확장 후보가 된다.

제출 직전에는 완성도를 좁힌다

마감 전에는 ‘더 넣을 것’ 목록을 닫고 이미 있는 경험을 끝까지 다듬는다. 최소한 아래 항목을 확인한다.

새로 실행한 빌드에서 첫 화면부터 플레이가 가능한가?
키보드와 마우스 또는 안내한 입력 장치가 정상 동작하는가?
성공, 실패, 재시작이 모두 가능한가?
사운드가 없더라도 게임 진행에 필요한 정보가 화면에 있는가?
게임 설명과 조작법이 제출 페이지에 짧고 명확하게 적혀 있는가?

게임잼 프로토타입의 완성은 모든 아이디어를 넣었다는 뜻이 아니다. 핵심 루프가 끊기지 않고 플레이어가 무엇을 할지 이해하며 한 번 더 시도할 이유를 느끼는 상태에 도달했다는 뜻이다. 이 기준을 지키면 짧은 일정에서도 다음 개발 단계로 이어질 만한 단단한 출발점을 만들 수 있다.