Game Off 2026 SHIFT 시작: 작은 게임 하나를 제출까지 가져가는 계획

Game Off 2026의 주제는 SHIFT이며, 참여하려면 공개 GitHub 저장소에 코드를 올리는 일과 itch.io에 플레이 가능한 게임을 제출하는 일을 둘 다 마쳐야 합니다. ‘이번 달에는 작은 게임 하나를 만들어 보고 싶다’면 이 두 결과물을 처음부터 계획에 넣어 보세요. 기능 목록을 길게 만드는 것보다 어떤 상태를 제출할지 정하는 데서 시작할 수 있습니다.

GitHub는 2026년 11월 1일 올해 Game Off를 발표했습니다. 11월 동안 게임을 만드는 행사이고 혼자 또는 팀으로 참여할 수 있습니다. 언어와 엔진을 특정하지 않으며 SHIFT의 해석도 열어 두고 있어요. 주최 측 발표를 읽고, 오늘 시작하는 사람이 놓치기 쉬운 제출 조건과 작은 프로젝트 계획을 정리했습니다.

한국에서 보는 제출 마감은 12월 2일 아침이에요

공식 발표의 제출 마감은 2026년 12월 1일 13:37 PST입니다. 이 시각을 한국시간으로 환산하면 12월 2일 06:37 KST예요. 달력에는 원문의 날짜·시간대와 환산한 한국시간을 같이 적어 두세요. ‘12월 1일까지’라는 날짜만 기억하는 것보다 어느 시각을 기준으로 삼았는지 확인하기 쉽습니다.

마감은 원고 작성일인 11월 4일에 확인한 안내입니다. 실제 참여를 결정하거나 제출할 때는 Game Off 2026 공식 행사 페이지에서 현재 조건을 다시 확인하세요. 이 글이 이후의 일정 변경이나 자신의 제출 접수 상태까지 확인한 것은 아닙니다.

개인 계획에서는 공식 마감과 ‘내가 새 기능을 더하지 않을 시점’을 나누어 보는 방식을 제안합니다. 후자는 주최 측 규칙이 아니라 스스로 정하는 작업 기준이에요. 게임을 내보내고, 다른 사람이 실행할 수 있는지 보고, 소개 문구를 고치는 일을 어느 때 할지 함께 적어 볼 수 있습니다.

달력에 적을 항목	이번 글의 기준
공식 제출 마감	2026년 12월 1일 13:37 PST.
한국시간 환산	2026년 12월 2일 06:37 KST.
개인 작업 기준	내보내기·플레이 확인·제출 준비를 고려해 자신이 따로 정할 시점.
제출 확인	저장소 링크와 행사 제출 화면에서 실제로 확인한 상태.

도구를 새로 배우는 일과 게임을 제출하는 일을 나눠 보세요

이번 행사는 원하는 프로그래밍 언어·게임 엔진·도구를 사용할 수 있다고 안내합니다. 특정 엔진을 선택해야 참여 자격을 얻는 구조로 읽을 필요는 없어요. 새 도구를 써 보는 것이 목표인지, 익숙한 도구로 결과물을 만들어 보는 것이 목표인지 먼저 적으면 자신의 선택을 설명하기 좋겠습니다.

예를 들어 평소 쓰던 엔진에서 조작 한 가지를 다듬고 싶은 사람과, 처음 보는 도구의 화면 구성을 이해하고 싶은 사람은 작업 계획이 달라질 수 있습니다. 둘 다 개인 목표로 삼을 수 있지만, 하나의 짧은 프로젝트에서 모든 것을 같은 비중으로 시도해야 하는 것은 아닙니다. 아래 계획은 선택을 정리하기 위한 제안이지 학습 효과를 입증한 방법은 아니에요.

목표를 한 문장으로 좁혀 보세요. ‘작은 게임을 만든다’에서 한 걸음 더 나아가 ‘처음 보는 사람이 설명을 읽고 시작해서 한 판을 끝낼 수 있는 게임을 만든다’처럼 쓸 수 있습니다. 무엇을 제출하려는지 드러나는 문장이면 자신의 진행 상태를 점검할 때 다시 참고할 수 있습니다.

작업에 쓸 수 있는 시간을 정할 때도 실제 일정부터 살펴보세요. 이 글은 하루에 얼마를 투자하면 실력이 얼마나 좋아진다는 수치를 제공하지 않습니다. 업무와 생활을 포함한 자신의 상황에서 가능한 범위를 적고, 그 범위 안에서 무엇을 만들지 고르는 방식입니다.

SHIFT를 하나의 놀이 규칙으로 바꾸어 봐요

자체 작성 예시로 ‘역할이 바뀌는 분류 창고’를 생각해 보겠습니다. 화면에는 두 칸의 보관함과 옮길 물건이 있습니다. 플레이어가 전환 버튼을 누르면 두 보관함이 받아야 할 물건의 규칙이 서로 바뀝니다. 목적은 표시된 규칙을 읽고 정해진 물건을 알맞은 칸으로 보내는 것입니다. 실제 출시한 게임이나 주최 측의 공식 예시는 아닙니다.

이 예시를 프로젝트 메모로 옮기면 세 문장이 됩니다. 플레이어는 무엇을 하는가, 전환이 무엇을 바꾸는가, 어떤 상태에서 한 판이 끝나는가예요. 멋진 세계관이나 많은 캐릭터를 먼저 정하지 않아도 조작과 결과의 관계를 설명할 수 있는지 살펴보자는 제안입니다.

새 아이디어가 생기면 기존 규칙을 더 분명하게 만드는지, 다른 게임을 하나 더 만들게 하는지 물어보세요. 가령 보관함 색을 알아보기 쉽게 바꾸는 일과 온라인 순위 기능을 넣는 일은 작업 목적이 다릅니다. 둘 중 어느 것이 지금 목표에 필요한지 자신의 기준으로 선택할 수 있습니다.

가상 프로젝트의 항목	처음 확인할 범위
핵심 조작	물건을 고르고 옮기는 조작, 규칙을 바꾸는 전환.
규칙 전달	보관함의 현재 조건과 전환 후 달라진 조건을 읽을 수 있는지.
한 판의 끝	정한 물건을 처리했을 때 결과를 알려주고 다시 시작할 수 있는지.
후보로 남길 기능	여러 스테이지·온라인 순위처럼 첫 목표 밖의 요소.

기능을 적게 썼다는 사실이 곧 재미나 품질을 보장하지는 않습니다. 이 표를 실제 작업에 쓴다면 자신이 확인한 조작과 아직 살펴보지 못한 부분을 구분하세요. 다른 사람에게 직접 플레이를 부탁했다면 어떤 버전에서 어떤 피드백을 받았는지도 남길 수 있습니다.

코드 저장소와 플레이 가능한 게임은 다른 결과물입니다

주최자가 작성한 공식 FAQ는 제출에 필요한 두 가지를 분명히 설명합니다. 공개 GitHub 저장소의 소스 코드와 itch.io의 행사 페이지를 통해 제출한 플레이 가능한 게임이에요. GitHub에 코드를 푸시하는 것만으로 자동 참가 접수가 되지 않는다는 점도 반복해서 안내합니다.

따라서 마지막 할 일을 ‘업로드’ 한 줄로 적지 않는 편이 좋겠습니다. 저장소에 필요한 코드가 있는지, 게임을 열 수 있는 파일이나 실행 경로가 준비됐는지, 행사에 실제 제출했는지를 각각 확인할 항목으로 두세요. 이것은 자신이 만든 결과물을 구분하는 체크리스트이며, 이 글에서 누군가의 접수를 대신 처리한 것은 아닙니다.

게임 소개에는 처음 접하는 사람이 알아야 할 내용을 적어 보세요. 어떤 환경에서 여는지, 조작은 무엇인지, 목표는 무엇인지가 기본 질문이 될 수 있습니다. 제작자가 알고 있는 폴더 구조나 내부 용어를 설명의 전제로 삼지 않도록 읽어 보는 방법입니다.

내보낸 파일을 확인할 때는 편집기 안에서 실행한 버전과 전달할 버전을 구분해 보세요. 게임을 만드는 화면에서 동작했다는 사실을 다른 사람도 같은 방식으로 실행할 수 있다는 확인으로 바꾸지 않는 겁니다. 실제로 어느 파일을 어떻게 열어 봤는지 적으면 남은 확인이 무엇인지 더 정확히 알 수 있겠습니다.

공개 코드와 에셋의 이용 조건을 함께 챙겨요

행사는 공개 GitHub 저장소를 요구하지만, 코드를 특정 오픈소스 라이선스로 배포해야 한다고 요구하지는 않습니다. 공식 FAQ는 코드와 에셋에 다른 라이선스를 사용할 수 있다고 설명해요. 유료·독점 에셋의 조건상 재배포할 수 없다면 저장소에 넣지 않고 대체 자료와 필요한 에셋 정보를 README에 설명할 수 있다는 안내도 있습니다.

이 설명을 자신의 에셋을 검토할 때 참고해 보세요. 어디에서 얻었는지, 어떤 이용 조건을 확인했는지, 출처 표시가 필요한지, 공개 저장소에 함께 배포할 수 있는지를 나눠 적는 겁니다. 인터넷에서 내려받을 수 있다는 사실만으로 재배포 허락까지 얻었다고 판단할 수는 없겠죠.

공개할 폴더에는 게임에 필요한 자료와 개인적인 작업 자료를 구분해 담는 방식을 제안합니다. 계정 정보나 비밀키, 다른 프로젝트의 자료를 섞어 넣는 일이 없는지 검토하세요. 이 글은 라이선스에 관한 개별 법률 판단이나 저장소의 실제 보안 점검을 대신하지 않습니다. 불명확한 자료는 해당 권리자와 이용 조건을 확인할 항목으로 남겨 두세요.

AI를 썼다면 사용한 곳을 설명할 준비도 해 두세요

주최 측은 AI 보조 개발을 허용하고 제출할 때 AI 사용에 관해 묻겠다고 안내합니다. 이 사실을 바탕으로 아이디어, 코드, 그림, 소리 등 어떤 부분에 도움을 받았는지 자신이 이해할 수 있도록 정리해 볼 수 있습니다. 이 목록은 주최 측 제출 서식을 미리 확정해 복제한 것이 아니라 준비 메모의 예시입니다.

가령 배경 아이디어를 논의한 것과 완성된 이미지 파일을 생성해 사용한 것은 설명할 내용이 다릅니다. 코드 제안을 받았다면 실제로 채택한 부분과 자신이 확인한 동작을 구분할 수 있겠죠. 직접 만들지 않은 결과를 전부 수작업으로 제작한 경험처럼 적지 않는 방식입니다.

AI를 사용했다는 이유로 작품의 재미나 완성도가 자동으로 정해지는 것은 아닙니다. 자신의 제작 과정을 어떤 근거로 설명할지와, 플레이 가능한 결과물이 실제로 준비됐는지를 따로 살펴보세요. 이 글은 특정 도구를 쓰면 완성이나 수상이 쉬워진다는 효과를 주장하지 않습니다.

마지막에는 무엇을 만들었고 무엇을 남겼는지 정리해요

개인 회고는 거창한 성과표보다 구체적인 기록이면 충분합니다. 처음 정한 목표, 실제로 제출한 버전, 확인한 동작, 아직 남아 있는 문제를 나누어 보세요. 제출하지 못한 기능도 이유와 함께 후보 목록으로 남길 수 있습니다. 결과가 좋았다는 인상과 무엇을 확인했는지는 다른 기록입니다.

예시 프로젝트라면 ‘전환 후 보관함 규칙이 바뀌는 동작을 구현했다’, ‘처음 보는 사람에게 목표 설명이 부족하다는 의견을 받았다’ 같은 항목을 적을 수 있습니다. 물론 실제로 관찰했을 때만 자신의 기록으로 사용해야 합니다. 여기서는 어떤 형태로 적을 수 있는지 보여 주는 가상의 문장입니다.

다른 사람의 피드백을 받았다면 버전과 질문도 함께 남겨 보세요. ‘재미있나요?’라는 질문과 ‘전환한 뒤 무엇이 달라졌는지 알 수 있었나요?’라는 질문은 서로 다른 정보를 얻으려는 것입니다. 원하는 확인에 맞는 질문을 고르되, 몇 명의 의견을 모든 이용자의 반응이나 객관적인 학습 성과로 일반화하지 않습니다.

완성하지 못한 경우에도 실제 남아 있는 작업을 정리할 수 있습니다. 실행 파일은 만들었지만 제출 페이지를 작성하지 못했는지, 핵심 조작은 있지만 게임을 끝내는 흐름이 없는지 구분하는 거예요. 막연하게 ‘실패했다’고 적는 것보다 다음에 어디에서 시작할지 판단할 자료가 될 수 있습니다.

자주 묻는 질문과 이번 글의 한계

처음 만드는 게임이어도 참여할 수 있나요? 주최 측은 첫 게임을 만드는 사람도 환영하며 특정 엔진을 요구하지 않습니다. 다만 참여가 자신의 학습 효과나 결과물의 품질을 보장한다는 뜻은 아닙니다. 목표와 가능한 범위를 자신에게 맞게 정해 보세요.

예전에 만들던 게임에 조금만 덧붙여 내도 되나요? 공식 FAQ는 행사 기간에 게임을 시작하고 개발의 대부분을 제출 기간에 진행하는 취지를 설명하며, 기존 게임에 작은 변경만 해서 제출하지 말라고 안내합니다. 실제 참여 전에는 현재 규칙을 읽어 확인하세요.

코드를 올렸는데 제출 화면을 확인하지 못했어요. 그 상태를 참가 접수 완료로 표시하지 마세요. 코드 저장과 행사 제출은 별개라는 공식 안내를 기준으로 자신이 어디까지 했는지 확인할 일입니다.

사실 기준일은 2026년 11월 4일입니다. 주최 측 발표·공식 행사 페이지·주최자 FAQ를 읽고 PST 마감의 한국시간 환산을 계산했습니다. 실제 게임 제작, 참가 신청, 제출이나 학습 효과 시험은 하지 않았습니다. 이번 계획표는 연구로 검증한 자기계발 처방이 아니라 최근 행사를 활용해 자신의 작은 프로젝트를 정리해 보는 제안입니다.

제출할 버전을 Git 태그로 구분하려는 경우에는 브랜치와 태그 전송을 구분한 안내도 참고할 수 있습니다. 태그 사용을 행사의 필수 제출 조건으로 추가하는 뜻은 아닙니다.

직접 생성한 개념 이미지입니다. 실제 서비스 화면이나 구축·성능 시험 결과가 아닙니다.