Game Engine I · 8주차 중간고사 · 게임 디자인 기초와 GDD 작성 양식 이름 / 학번: 게임명: 문서 버전 / 수정일: 작성 안내 - 최종 제출물은 상세 GDD입니다. 1쪽 기획서는 준비 단계이며, 이것만으로는 제출 요건을 충족하지 않습니다. - 1쪽 기획서를 바탕으로 2단계의 필수 항목 10가지를 구체화해 제출합니다. - 기획 의도에는 만들고 싶은 경험과 설계 이유를 서술합니다. 규칙과 기능에는 행동·조건·수치·결과를 명시합니다. - 같은 문장도 디자이너·개발자·기획자·슈퍼바이저가 다르게 해석할 수 있습니다. “화려하게”, “직관적으로”, “적당히 어렵게”를 제작 기준으로 쓸 때는 구체적인 행동·조건·수치·화면 반응을 덧붙입니다. - 각 기능의 적용 범위와 완료 기준을 기록합니다. 미정 사항은 결정 방법과 시점을 남기고, 참고 이미지에는 참고할 부분을 표시합니다. - 각 항목을 자신의 게임에 맞게 작성하고, 표와 스케치로 설명을 보완합니다. - 하나의 핵심 행동과 작은 맵으로 3~5분 안에 완결되는 개인 2D 게임을 기획합니다. - 표지·참고자료를 제외한 6~10쪽 내외는 권장 분량입니다. - 예시 수치는 필수 조건이 아닙니다. 자신의 규칙에 필요한 초깃값을 정합니다. - 구현한 기능과 앞으로 구현할 기능, 확인 결과와 검증 계획을 구분합니다. - 필요한 기술은 직접 찾아 추가로 학습하고 활용할 수 있습니다. 학습·구현에 필요한 시간과 적용할 기능을 개발 계획에 반영합니다. - 제출 일시·경로·최종 파일 형식·세부 배점·시험 중 AI 허용 범위는 별도 공지를 따릅니다. 1단계. 준비 · 1쪽 기획서 작성 - 준비 순서: 한 문장 콘셉트 → 목표·규칙·보상과 재미 → 시점·조작 → 대표 화면 스케치. - 어떤 게임이며 왜 재미있는지, 아래 내용을 한 장에 정리합니다. - 실제로 플레이할 때 보이는 대표 화면 한 장을 러프하게 그려 넣습니다. 손그림·도형·화살표로 충분합니다. - 시점(측면·탑다운 등), 플레이어, 행동 방향, 목표물, 위험 요소와 UI를 표시합니다. 게임명 / 한 문장 콘셉트: 대상 플레이어 / 인원 / 플랫폼·입력 장치: 의도한 경험과 핵심 재미: 목표 / 행동의 규칙 / 보상과 지급 조건: 핵심 행동 / 선택의 장단점: 핵심 플레이 루프: [행동] → [결과] → [다음 판단 / 반복] 조작할 대상 / 카메라 시점 / 입력 방법: 구별되는 특징: 최소 완성 범위 (맵·콘텐츠 수량 / 필수 기능 / 한 판의 예상 시간): [대표 플레이 화면 스케치: 선택한 시점에서 카메라 안에 보이는 장면] 시점 / 플레이 방식 (예: 측면 시점의 2D 플랫포머): 스케치 설명: 플레이어가 [대상]을 조작해 [방향·행동]으로 [목표]를 달성한다. 2단계. 제출 · 상세 GDD로 확장 - 1쪽 기획서의 각 내용을 아래 항목에 맞춰 구체화합니다. - 예: “아이템을 모아 탈출한다” → 수집 조건·수량, 출구 개방, 성공·실패, 화면 표시, 재시작 규칙. - 각 문장에 필요한 조건·수치·예외를 정하고, 규칙표와 화면 스케치, 개발 계획으로 설명합니다. - 1쪽 기획서는 GDD의 첫머리에 게임 개요로 포함할 수 있습니다. - 상세 설계가 달라지면 1쪽 기획서도 함께 고칩니다. - 문장 점검: 무엇을 그릴지, 어떤 조건을 구현할지, 의도에 맞는지, 어떤 결과물을 승인할지가 같은 문서에서 읽혀야 합니다. 01. 게임 개요 한 문장 소개: 플레이어는 [상황]에서 [핵심 행동]으로 [목표]를 달성한다. 장르 / 2D 시점: 대상 플레이어 / 그 대상을 정한 이유: 실행 플랫폼 / 입력 장치: 한 판의 예상 시간: 02. 기획 의도와 핵심 재미 기획 의도: 플레이어에게 제공할 경험과 이를 구현할 설계 이유: 핵심 재미: 반복되는 선택과 각 선택의 장단점: 그 선택의 위험 또는 비용 / 얻는 보상: 참고 게임·장면 1~2개 / 출처: 참고할 구체적인 규칙 / 자기 게임에서 바꿀 점과 이유: 배경 이야기나 세계관이 목표와 규칙을 이해시키는 방법: 03. 핵심 플레이와 조작 Character: 조작할 대상 / 할 수 있는 행동 / 크기·이동·점프의 한계: Control: 입력 장치 / 키 배치 / 반응 / 입력이 가능한 상태: 핵심 메커니즘: 반복 루프: [행동 1] → [행동 2] → [행동 3] → [다음 판단 / 반복] 반복이 끝나는 조건: 조작표 (입력 | 행동 | 허용 조건): 04. 게임 규칙과 상태 플레이어의 목표: 시작 조건 / 초기 데이터: 성공 조건: 실패 조건: 핵심 수치 (이름 | 초깃값 | 변화 조건 | 값을 정한 이유): 규칙표 (사건 | 적용 조건 | 데이터·상태 변화 | 화면·소리): 상태 흐름 (준비 → 플레이 → 성공·실패 → 재시작): 재시작 때 초기화하거나 유지할 항목: 중복 입력·반복 접촉 처리: 성공·실패가 동시에 발생할 때의 우선순위: 05. 레벨과 콘텐츠 맵 / 스테이지 수: 등장 오브젝트의 종류 / 수량 / 역할: [맵 스케치 삽입: 시작점, 경로, 목표물, 위험 구역, 출구, 범례] 처음 배우는 구역 / 선택하거나 도전하는 구역 / 마무리 구역: 비트 차트 [선택] (게임 안의 구간 | 예상 플레이 시간 | 행동 | 도전·배움 | 보상·피드백): ※ 레벨의 흐름을 더 자세히 정리할 때 활용하는 보조 도구입니다. 제작 일정과 구분하며, 구간별 시간은 제작 단계에서 조정합니다. 각 배치의 의도 / 난이도 변화: 프로토타입에서 조정할 거리·간격·속도: 06. 플레이 화면과 UI - 1쪽 기획서의 대표 플레이 화면을 바탕으로 배치와 주석을 구체화하고, 시작·결과 화면을 추가합니다. - 맵 스케치는 전체 공간의 배치, 플레이 화면 스케치는 한 순간에 카메라 안에 보이는 범위를 설명합니다. 플레이 방식 / 시점 (예: 측면 시점의 플랫포머, 탑다운 시점의 수집·회피 게임): Camera: 시점 / 가시 범위 / 고정·추적 방식 / 맵 경계 처리: 플레이어가 다음 목표·발판·위험을 미리 볼 수 있게 하는 방법: [시작 화면 스케치: 목표, 조작법, 시작 버튼] [플레이 화면 스케치: 시점, 플레이어, 행동 방향, 목표물, 장애물·위험 구역, UI] 설계용 화살표·주석 / 실제 게임에 표시할 정보 구분: 스케치 속 행동과 연결되는 조작·규칙: 카메라가 이동하거나 화면 밖에 목표가 있을 때의 처리: [결과 화면 스케치: 성공·실패 원인, 다시 하기 버튼] 화면 전환 순서 / 각 버튼의 결과: 상태별 표시·숨김 규칙: 색이나 소리만으로 전달하지 않을 정보 / 보완할 문구·형태: 07. 아트·사운드와 에셋 시각 스타일 / 색·형태·대비 기준: 참고 이미지·분위기 자료 / 출처 / 참고할 부분: 에셋 목록 (이름 | 용도 | 수량 | 규격 | 확보 방법 | 현재 상태): 효과음·음악이 재생되는 사건과 시점: 직접 제작 / 외부 자료 / AI 생성 예정 범위: 미확보 에셋의 대체안: 실제 사용할 외부 자료의 제작자·출처·이용 조건 확인 여부: 08. Unity 구현 계획 Scene 구성: 주요 GameObject / Component / Script와 각각의 역할: 저장할 데이터 / 데이터를 관리할 오브젝트: 핵심 사건의 연결: [입력·사건] → [조건] → [데이터 변화] → [UI·소리] 현재 활용할 수 있는 기술과 적용할 기능: 이미 확인한 기능 / 확인한 프로젝트나 화면: 추가 구현·학습이 필요한 기능 / 먼저 검증할 방법: 09. 개발 범위와 일정 필수 기능 (빠지면 한 판이 성립하지 않는 기능): 선택 기능 (필수 기능 검증 뒤 추가할 기능): 이번 프로젝트에서 제외할 기능: 9~10주 결과물 / 완료 기준: 11~12주 결과물 / 완료 기준: 13주 Alpha 빌드와 3인 플레이테스트 / 관찰·기록할 내용: 14~15주 면담 반영과 제출 후보 빌드 / 완료 기준: 16주 최종 결과물 / 실행 확인 방법: 가장 큰 위험 / 발생 징후 / 축소하거나 대체할 방법: 10. 검증 기준과 제작 기록 상세 기능 기록 (기능 ID·이름 | 목적 | 조건 | 처리·수치 | 화면·소리 | 예외 | 검증): 기능 테스트 (조건·절차 | 예상 결과 | 예정·확인 완료·수정 필요 | 증거): - 성공 / 목표 미달 상황: - 실패 조건별 상황: - 중복·동시 판정: - 성공·실패 뒤 재시작과 초기화: - Unity Editor 밖의 실행 빌드: 플레이테스트 대상 / 관찰할 행동 / 의도한 재미를 확인할 질문: 참고자료 목록 (이름·제작자 | 출처 | 참고한 부분 | 실제 사용 여부): AI 사용 기록 (사용한 경우): 도구·모델 / 사용 부분 / 프롬프트 / 채택 이유 / 직접 수정한 부분 / 확인 결과 AI를 사용하지 않았다면: 사용하지 않음 기획 변경 기록 (버전·날짜 | 변경 전후 | 변경 이유·테스트 근거): 제출 전 점검 [ ] 게임을 이해할 수 있는가? 한 문장 소개에 행동과 목표가 있고, 대상·플랫폼·플레이 시간이 적혀 있다. [ ] 재미의 근거가 있는가? 플레이어가 반복할 행동과 선택·위험·보상이 연결되어 있다. [ ] 규칙이 명확한가? 성공·실패·재시작과 핵심 수치, 중복·동시 상황의 처리 기준이 있다. [ ] 화면에서 목표가 읽히는가? 플레이 화면 스케치에 시점·목표·행동·UI가 드러나고, 시작·결과 화면과 상태별 피드백을 설명했다. [ ] 학기 안에 완성할 수 있는가? 필수·선택·제외 기능, 주차별 결과물과 지연 시 축소안이 있다. [ ] 완료를 판단할 수 있는가? 최종 결과물에 포함할 기능과 각 기능의 완료 기준이 정해져 있다. 참고 도서 스콧 로저스, 게임 디자인 레벨업 가이드(한빛미디어, 개정2판). 아이디어를 게임으로 구체화하고, 캐릭터·카메라·조작과 게임플레이를 설계하며, GDD로 정리하는 과정을 다루는 게임 디자인 안내서입니다. 공개 목차와 원서 미리보기의 GDD 작성 단계·3C 구성을 참고했습니다. 개인 2D 게임 수업에 맞춰 “1쪽 기획서 작성 → 상세 GDD로 확장”의 두 단계로 재구성하고, 비트 차트는 선택 도구로 소개합니다. 공개 목차: https://www.hanbit.co.kr/books/B9086837682?code=B9086837682 이 양식의 질문과 구성은 개인 2D 게임 수업을 위해 새로 작성했습니다.