48시간 게임잼에서 개발 속도를 높이는 방법

속도는 구현력보다 결정력에서 나온다

게임잼에서는 제한된 시간 안에 아이디어를 정하고 기능을 만들고 오류를 고치며 플레이어 반응을 확인한 뒤 제출해야 한다. 이 글에서는 시간을 잃기 쉬운 위험으로 무엇을 만들지 오래 고민하거나 이미 만든 것을 뒤늦게 바꾸는 일을 다룬다.

따라서 게임잼의 목표는 기능 목록을 많이 채우는 것이 아니다. 플레이어가 시작부터 종료까지 한 번의 분명한 경험을 하도록 만드는 것이다. 이동, 상호작용, 실패 또는 성공, 재시작이라는 최소 순환이 먼저 작동하면 그 위에 연출과 변주를 올릴 수 있다.

48시간 게임잼에서 핵심 루프를 빠르게 검증하는 개발 장면

첫 두 시간에 정리할 항목

아이디어 회의가 길어지면 실행과 테스트가 뒤로 밀릴 수 있다. 예를 들어 첫 두 시간에 아래 네 가지를 한 문장씩 정리해 둘 수 있다.

플레이어는 무엇을 반복하는가
한 판은 언제 끝나는가
실패하면 무엇을 잃는가
테마는 어떤 규칙 또는 연출로 드러나는가

예를 들어 테마가 ‘연결’이라면 “전선을 이어 제한 시간 안에 장치를 켠다”처럼 조작과 목표가 바로 연결되는 문장이 좋다. ‘연결’이라는 단어를 배경 대사나 장식에만 붙이면 테마는 있어도 플레이 경험의 중심이 되기 어렵다.

아이디어를 고르는 간단한 기준

후보가 여러 개라면 재미의 크기보다 검증 비용을 비교한다. 다음 질문에 모두 빠르게 답할 수 있는 아이디어를 우선한다.

30분 안에 가장 재미있는 행동을 흉내 낼 수 있는가?
핵심 행동을 설명 없이 이해할 수 있는가?
외부 에셋, 네트워크, 복잡한 AI 없이도 성립하는가?
한 가지 변주만 더해도 후반부를 만들 수 있는가?

하나라도 답이 불분명하면 아이디어를 버릴 필요까지는 없다. 다만 제출용 핵심 루프에서 빼고 시간이 남을 때 추가할 후보로 내려놓는 것이 안전하다.

작업 순서는 ‘완성 가능한 흐름’ 기준으로 잡는다

개발 항목을 직군별로만 나누면 프로그래밍, 아트, 사운드 사이의 의존 작업에서 대기 구간이 생길 수 있다. 이 글에서는 게임잼 작업을 플레이어가 만나는 순서대로 묶는 방식을 제안한다.

flowchart TD
    A[플레이어 입력] --> B[핵심 행동]
    B --> C{성공 또는 실패 판단}
    C -->|성공| D[보상과 다음 목표]
    C -->|실패| E[즉시 재시작]
    D --> B
    E --> B

이 흐름의 각 상자를 임시 도형과 임시 사운드로 먼저 연결한다. 캐릭터 애니메이션이나 메뉴는 그 다음이다. 이른 시점에 재시작까지 구현해 두면 테스트 때 장면을 다시 실행하는 반복 작업을 줄이는 데 도움이 될 수 있다.

기능을 세 층으로 분리하기

작업 목록은 처음부터 우선순위를 드러내야 한다.

층	포함할 항목	판단 기준
필수	조작, 목표, 판정, 재시작	이것이 없으면 게임을 플레이할 수 없다
강화	난이도 변화, 피드백, 짧은 튜토리얼	핵심 루프를 더 잘 이해하게 한다
여유	추가 스테이지, 수집 요소, 설정 화면	없어도 제출물이 성립한다

‘강화’와 ‘여유’ 항목은 핵심 루프를 먼저 확인한 뒤 검토할 수 있다. 저장 기능, 여러 해상도 대응, 절차적 생성, 온라인 순위표처럼 기술적으로 흥미로운 기능도 같은 우선순위 기준으로 판단한다.

빠른 구현은 교체 가능한 구조에서 나온다

게임잼에서는 장기 유지보수용 설계를 그대로 가져올 필요가 없다. 대신 규칙의 숫자와 상태를 한곳에 모으면 수정할 지점을 찾기 쉬워진다. 아래는 Unity에서 제한 시간과 목표 점수를 한곳에서 다루는 작은 예시다.

using UnityEngine;

public class JamRules : MonoBehaviour
{
    [SerializeField] private float roundSeconds = 45f;
    [SerializeField] private int targetScore = 10;

    public float RemainingSeconds { get; private set; }
    public int Score { get; private set; }
    public bool IsFinished => RemainingSeconds <= 0f || Score >= targetScore;

    private void Start()
    {
        RemainingSeconds = roundSeconds;
    }

    private void Update()
    {
        if (!IsFinished)
            RemainingSeconds = Mathf.Max(0f, RemainingSeconds - Time.deltaTime);
    }

    public void AddScore(int amount)
    {
        if (!IsFinished)
            Score += amount;
    }
}

핵심은 이 코드의 규모가 아니라 roundSeconds와 targetScore를 한곳에서 바꿀 수 있다는 점이다. 예를 들어 테스트 결과에 따라 “45초가 너무 길다”, “목표 점수가 낮다”고 판단하면 이 값을 조정할 수 있다. 수치를 여러 스크립트에 흩어 두는 경우에는 빠뜨린 참조가 없는지 함께 확인해야 한다.

24시간 시점에는 플레이 테스트로 우선순위를 다시 정한다

절반이 지났는데 아직 처음부터 끝까지 플레이할 수 없다면 새 기능보다 핵심 흐름을 완성하는 데 남은 시간을 우선 배정하는 편이 좋다.

플레이 테스트는 질문을 넓게 던지기보다 관찰 가능한 질문으로 제한한다.

시작 후 10초 안에 무엇을 해야 하는지 알았는가?
실패 이유를 알 수 있었는가?
다시 시도하고 싶었는가?
가장 지루하거나 혼란스러운 순간은 어디였는가?

테스터가 막히는 곳을 설명으로 덮지 말고 화면 피드백이나 레벨 배치로 먼저 고친다. 버튼을 누른 순간의 소리, 목표물의 색 변화, 실패 직후의 빠른 재시작은 비교적 작은 피드백 작업의 예이며, 상황에 따라 게임의 반응성을 높이는 데 도움이 될 수 있다.

마지막 6시간의 원칙

마지막 시간대에는 새 기능 추가보다 제출 실패를 막고 처음 보는 사람도 플레이를 마칠 수 있도록 점검하는 데 집중하는 편이 좋다.

제출 전 점검 목록

처음 실행했을 때 조작과 목표를 알 수 있는가
승리와 실패가 모두 정상적으로 끝나는가
재시작 후 상태가 깨지지 않는가
창 모드와 전체 화면에서 UI가 읽히는가
빌드 파일을 새 폴더에서 직접 실행해 보았는가
게임 페이지의 조작법과 짧은 소개를 작성했는가

게임잼에서 연습할 수 있는 습관 중 하나는 ‘더 만들기’보다 ‘지금 있는 것을 끝까지 작동하게 만들기’를 우선하는 것이다. 이 접근은 프로토타입, 데모, 업데이트 작업에도 적용해 볼 수 있다. 범위를 정하고 빠르게 검증하는 흐름을 각 팀의 일정과 작업 방식에 맞게 조정한다.