예비 게임 프로그래머들을 위한 게임 제작 프로세스 게임 컨셉 디자인 게임 제작 프로세스 –Pre-production –Production –Post-production

1. 게임 제작 개론 #8
게임 제작 프로세스
NHN NEXT
구승모

2. Agenda
• 게임 컨셉 디자인
• 게임 제작 프로세스
– Pre-production
– Production
– Post-production

3. 학습 목표
• 아이디어로부터 게임의 컨셉을 잡고 구체화 할 수 있다
• 게임 제작에서 큰 단위의 프로세스를 전반적으로 이해하
고 그 과정을 그릴 수 있다
• 제작 과정 중 일어나는 작은 단위의 프로세스(Iteration)
를 설계할 수 있다
• 프로덕션 과정 중 일어나는 역할별 작업 순서에 대해 이
해하고 마일스톤 및 테스트 계획을 세울 수 있다
• 일정이 밀리는 여러 이유에 대해 설명할 수 있다

4. 게임 컨셉 디자인

5. 게임을 만들 때, 가장 먼저 하는 것
• 컨셉 디자인
– 첫 목표는 아이디어를 생각해내는 것
– 아이디어를 시험해본다
– 괜찮아 보일 때까지 바꾸고 시험해본다
• 영감 캐치
– 게임 외적인 경험에서 열린 마음과 큰 상상력으로 캐치
– 스스로의 삶에서 겪은 경험 중 어떤 것을 공유하고 싶은가?
– 그 경험의 정수를 잡아내고 그것을 게임에 불어 넣을 수 있는 방
법은 작게라도 어떤 것이 있을까?

6. 어떤 게임을 만들까?
• 어떤 게임을 만들지에 대한 질문을 잘 해야 함
– 목표를 정의해야 함
– 제약 사항을 잘 정의 하는 것이 중요
– 자문해볼 것
• 어떤 문제를 해결하려는 것인가?
– 그 문제가 해결되었다고 말할 수 있으려면 어떻게 해야 되는가?
• 게임의 진정한 용도와는 관계 없는 추측을 하고 있지 않은가?
• 진정 최선의 해답인가? 왜 그런가?
• 어떤 게임을 만들지에 대한 질문을 선명하게 명시하면,
– 제시된 아이디어의 질을 명확하게 잴 수 있음
– 문제가 불분명할 때는, 서로 다른 문제를 풀려고 하게 됨
– 해답을 찾는 일로 바로 뛰어들어 창의성을 쓰기 시작

7. 아이디어 모으기
• 브레인스토밍에 도움이 되었던 것들
– Game Play First: 이 게임은 어떤 재미를 주는가?
– 과거의 게임들도 다시 본다 (게임성의 본질은 거의 그대로)
– 이미 명시한 문제에 대한 해결책을 적어본다
– 마인드맵을 그려본다
– 벽에다가 쓰거나 스케치 해본다
– 동료와 농담하고 수다를 떨어본다
– 곰 인형에게 아이디어의 재미를 설명해본다
– 포스트잇으로 (폼나게) 주변에 마구 붙여본다
– 다양한 장소를 방문해본다 (미술관, 동물원, …)
– 한적한 곳에서 멍때린다
– 뭔가 한참 고민하다가 잔다

8. 아이디어 필터링
• 아이디어는 언제든 버리거나 뒤집을 수 있어야 함
– 처음에 바꾸는 것이 제일 쉽다
• 아이디어를 걸러내기
– 이 게임 괜찮을까? (직감)
– 의도한 고객층이 이 게임을 좋아해줄까?
– 좋은 경험을 줄 것 같은지?
– 충분히 참신한가? (예전에 본 적 없는 새로운 것은 무엇인가?)
– 게임이 어떻게 플레이 될지?
– 이 게임을 만드는 것이 기술적으로 가능한가?
– 이 게임이 돈을 벌 수 있나?
• 스토리는 매력적? 시중의 비슷한 게임과 비교한다면? 제작비가 너
무 나가지 않을까?
• 혁신적인 아이디어일수록 여기에 걸릴 확률이 높음

9. 컨셉 기획
• 컨셉 기획서
– 최초의 기획서로 “이 게임은 어떤 게임이다”를 담고 있어야 함
– 게임의 비전과 방향성이 잘 보일수록 좋음
항목 세부 설명
개요와 기획 의도
수익모델 (옵션)
대상 플레이어, 게임 장르: 어떤 경험을 줄 것인가?
추구하는 핵심 재미: 이 게임은 어떠한 재미를 주는가?
재미 요소가 수익 구조와 밀접한 연관이 있는 F2P의 경우
게임 설정 배경 (세계관)
스토리 (시놉시스)
게임 진행 메커니즘 게임의 전체 흐름: 시작부터 끝까지 플레이어 경험 흐름
기본 플레이 형태: 스토리, 전투 등의 진행 방식
기본 플레이 외 게임에 관여하는 요소들: 인터페이스, 아이템 등
플레이 시나리오 게임 진행 메커니즘에 기반하여 핵심 재미 요소 부분을 잘라서
어떻게 시뮬레이션 되는지 플레이어 시점에서 상세하게 설명
흥미곡선
레벨 디자인 컨셉 (옵션) 레벨 디자인 자체가 핵심 특징이 되는 게임인 경우
스테이지(필드, 동선) 구성 개요

10. 게임의 비전과 방향성
• 게임의 비전
– 게임의 전반적인 모습을 그릴 수 있도록 함
– 개발실 구성원들이 같은 길을 나아갈 수 있게 하는 원동력
• 일관된 방향성을 위한 예
– God of War의 Kratos
• 절대로 웃지 않는다
• 공포를 느끼지 않는다
• 등을 땅에 붙이는 경우는 죽었을 때 뿐이다
• 항상 앞으로 움직인다
– 도망치는 움직임은 없다

11. 게임 제작 프로세스

12. 전체적인 프로세스
• 큰 단위의 제작 프로세스
– 구체적인 부분은 상황(장르 등)에 맞게 간략화 또는 부분 변형
– Pre-production
• 게임의 전체적인 방향성을 잡고 핵심 재미요소를 프로토타이핑
• 게임 제작 계획
– 프로토타이핑 성공시 구체적인 제작 단계(마일스톤)를 설계
• 게임 서비스 기획
– Production
• 마일스톤: 특정 콘텐츠나 특징(feature) 단위의 제작 단계
• 각 마일스톤 사이에는 피드백을 위한 테스트(FGT, CBT)가 보통 존재
– Post-production
• 라이브 서비스 단계
Pre-production Production Post-production
컨셉 / 서비스
프로토타이핑
제작 계획 설계
제작 마일스톤 #1 출시 (Launch)
이벤트
업데이트 / 패치제작 마일스톤 #2
제작 마일스톤 #N
Alpha
OBT
FGT
CBT
CBT#N

13. Pre-Production

14. 게임 컨셉 기획
• 게임의 비전 및 전체적인 방향성 설정
– 어떤 플레이어(타겟)에게 어떤 (재미있는) 경험을 줄 것인가?
– 한 문장으로 요약하기
• “이 게임은 이러이러한 게임이다”
– 2가지 방향성
• 시장 (트렌드) 분석을 통하여 유저들의 입맛에 맞는 방향으로?
– 대중의 성향에 맞는 게임을 만들고자 할 때
– (예) WOW
• 개발자가 정의한 경험을 줄 것인지?
– 쉽게 경험 할 수 없는 독특한 재미를 주고자 할 때
– 주로 인디 게임이나 실험적인 목적의 게임
– 매니아층이 생길 가능성 높음
– (예) Journey
• 디렉터 주관
– 프로듀서 및 각 팀의 리드, 시니어 게임 디자이너 등이 참여

15. 게임 서비스 기획
• 게임을 어떻게 서비스 할 것인지
– 수익 모델 설정
• Pay to Play (P2P)
• Free to Play (F2P)
– 이 경우, 게임 디자인과 밀접한 관련을 갖게 됨
– 퍼블리셔와 역할 분담
• 마케팅, 이벤트, 수익배분 등
• 오픈 시기 가늠
– 경쟁 타이틀, 성수기/비수기 여부
– 대상 시장 설정
• 한국 우선 or 해외 동시
• 다국어 버전 계획
• 프로듀서 주관
– 퍼블리셔, 경영진 및 디렉터와 각 팀의 리드 등이 참여

16. 게임 제작 계획
• Production 설계
– 마일스톤 및 중간 리뷰(테스트) 일정
– 어떤 콘텐츠를 어느 시점에 만들어서 어떻게 리뷰할 것인지
• 내부 테스트, 포커스 그룹(FGT), 클로즈 베타(CBT) 등의 방법
– 불가피한 일정 밀림을 감안해야 함
• 리뷰 결과가 좋지 못할 경우가 많기 때문
– 수정 보완 작업으로 인한 일정 지연
• 리스크 대응 설계
• 인력 계획
– 개발 조직 구성
– 개발 마일스톤에 따라 인력 확충 계획
• 좋은 사람은 필요 이상으로 (충분히) 뽑아야 함
– 괜찮은 개발자는 필요할 때 찾으면 없음
• 다만, 잘못 뽑은 한 사람이 헬게이트를 열게 되는 경우도 있음
– 인사가 만사
– 아웃소싱(outsourcing) 계획
• 어떤 리소스를 어느 시점에 외주를 줄 것인가?

17. 게임 제작 계획
• 제작 프로세스 수립
– 개발실의 구성원들에게 적합한 개발 프로세스를 확립하기 위함
• 경우에 따라 개발 조직 구성을 변경
• 개발 과정(Iteration) 자체에 대한 프로토타이핑 필요
– 게임의 핵심 재미에 대한 프로토타이핑과 더불어 같이 하는 것이 좋음
– 정석은 2개의 완벽한 레벨을 만들어낼 때까지
– 각 팀의 역량 파악을 토대로 향후 개발 계획의 일정을 가늠
• 게임 제작에 얼마나 비용이 들지 언제 완성될지는
– 실제로 약 30%의 비용을 써서 도달한 뒤에야 알 수 있음
– 개발 과정 중 필요한 문서 정의
• 이 게임을 만들면서 기억해야 하는 것은?
• 이 게임을 만들면서 소통해야 하는 것은?
– 개발자용 각종 툴 제작
• 레벨 디자인 툴 등
• 배포(release) 및 QA 프로세스 수립
– 형상 관리 (SVN, GIT 등), 이슈 트래킹 및 브랜치 구조 수립
– 배포 도구 및 지속적 통합(Continuous Integration) 도구 개발

18. 브랜치 관리
• 제작 프로세스 설계시 함께 설계
– Production 이전에는 브랜치에 관한 룰이 정립되어야 함
• 프로덕션 과정중 훈련이 되어 있어야 라이브 단계의 복잡한 브랜치
상황에 적응이 가능
• 일반적인 브랜치 구조
– 프로젝트의 성격, 규모, 제작 프로세스에 따라 조금씩 다름
DEV
CBT1
CBT2
KR LIVE
US LIVE
OBT
China DEV
RR R
R
RR R
R
R
MAIN
Trunk
bug fix
merge
important
bug fix
bug fix
feature
merge
contents
integration
bug fix bug fix
CN LIVER

19. 이슈 관리
• Issue Tracking System (ITS)
– 개임 개발 및 서비스 중에 다양한 이슈가 발생
• 개발 또는 서비스 중에 발생하는 수많은 이슈와 각종 요구 사항을 수동
으로 처리하기에는 한계가 있기 때문에 사용
• 대표적으로 버그 처리 요구와 추가 기능 요구
– (예) “시궁창 던전의 마지막 보스가 가끔 없어지는 현상이 있습니다”
– (예) “지형에 끼였을 때 탈출 기능이 필요합니다”
• 작업 관리용으로도 사용 가능
– 작업(todo)을 이슈로 등록하여 특정 개발자에게 할당
• Bug Tracking System (BTS)도 ITS의 일종
– 이슈 추적
• 이슈가 어떻게 어디에서 얼마만큼 처리되고 있는지 확인
• 과거에 발생한 이슈가 재발생 되는 경우에도 찾아서 확인 가능
• 이슈의 처리 과정
•
이슈 등록 담당자 할당 담당자 확인 담당자 처리 완료 보고
담당자가 아닌 경우 계속 포워딩
이슈 등록자 및 확인자(리드)에게 통지됨
리뷰
승인여부 결정
확인자(리드)가 수정 보완 지시 가능

20. 프로토타이핑
• 게임 컨셉 기획을 토대로 핵심 재미요소를 프로토타이핑

21. 프로토타이핑시 고려 사항
• 질문에 답하기
– 프로토타입은 질문에 대답하기 위해 디자인 하는 것
• 질문을 명확히 기술할 수 있어야 함
• 크게 만들려는 유혹을 이겨내고 핵심 질문에 답할 수 있게 집중
• 빠르고 지저분하게
– 빨리 만드는 편이 흉해 보이는 것보다 낫다
• 집착하지 말 것
– 갖고 있는 것을 버릴 계획을 세우기 (언젠가는 버리게 됨)
– 모두 임시적인 것이라는 마음가짐
– 실패가 아닌 배움의 기회라고 생각할 것
• 우선순위 설정
– 가장 큰 위험부터 직면하도록 우선순위와 의존성을 고려
• 장난감부터 만들기
– 갖고 노는 것 자체가 재미있는 장난감
– 장난감에 기반한 게임을 디자인하기 전, 장난감 자체가 재미있음이 확실해야 함
• (예) 공은 장난감, 야구는 게임
• (예) GTA는 팩맨으로부터 옴 (노란 점은 시민, 유령은 경찰)

22. Production
(Mass-Production)

23. 마일스톤
• 특정 콘텐츠나 핵심 특징(feature)을 목표로 하는 제작 단계
– (예) 20레벨 이전 성장 구간의 레벨 디자인 검증 (사냥터, 퀘스트 등)
– (예) 공성전을 통한 대규모 PVP의 재미 요소 확인
– (예) 레이드 던전에서의 핵심 시나리오 플레이 확인
• 마일스톤 리뷰
– 해당 마일스톤의 목표가 잘 달성되었는지 확인하는 테스트
– In-house Test, Focus Group Test, Closed Beta Test를 통해 확인
– 목적 달성이 실패라고 판단된다면?
• 일정이 밀리게 되는 주요 원인
• 당연히 한번에 성공하기 힘들다 (게임은 감성의 물건이기 때문)
• 차기 마일스톤의 목표로 넣거나 수정 보완 프로세스를 거치도록 함
• 위험 완화 계획(Risk Mitigation Plan) 반드시 고려
– 개발 과정에서 실수가 있다면?
• 다음 마일스톤에서는 같은 문제가 발생하지 않도록 개선 과정이 필요

24. 제작 파이프라인 설계
• 작업간 의존성이 존재
– 특정 기간에 놀아야(?) 되는 팀을 최소화 하는 전략
– 4종 캐릭터 제작 파이프라인 예시
• 최대한 효율적인 팀 작업을 하기 위해서 치밀하게 설계
– 100인 이상의 대규모 프로젝트에서는 이것이 매스 프로덕션의 핵심
• 파이프라인이 깨지는 경우
– 특정 작업이 밀리는 경우 의존성을 가지는 다른 작업도 밀림
• 사람은 기계가 아니기 때문에 칼같이 일정을 맞출 수 없는 경우가 많음
• 예술(?)에서는 정량화된 끝(end)이 없기 때문에 어느 시점에서는 품질과
의 타협이 필요
• 파이프라인이 깨지는 경우를 항상 고려해서 일정을 관리해야 함
– 아웃소싱 리소스
• 외주 업체의 경우 일정 컨트롤이 쉽지 않음
– 피드백을 계속 주면서 지속적으로 수정해야 하는 경우가 많기 때문

25. Integration
• Continuous Integration (CI)
– 지속적인 통합
– 언제 어느 시점에서도 플레이 가능한 버전 필요
• 게임의 완성도를 체감할 수 있음
• Daily Build
– 빌드가 깨지는 경우
• 누가? 어떤 작업 때문에? 바로 확인 가능
– 게임의 경우 다른 분야의 소프트웨어보다 복잡
• 데이터시트 + 각종 리소스 + 프로그램
• 제작 프로세스와 콘텐츠 특성에 영향을 많이 받기에 보통은 제작사마다
직접 만들어서(in-house) 사용
• 회귀(regression) 테스트
– 이전에 잘 동작하던 기능이 갑자기 뻑(?)나는 경우를 찾기 위함
• 통합시에 자주 발생하기 때문에 배포시 마다 반드시 검증
– 버그픽스가 버그를 유발하는 경우가 많기 때문
• (예) 멀쩡하던 스킬 싱크(sync)가 왜 갑자기 어긋나지?
– 아트 리소스 문제? 데이터시트 문제? 프로그램 문제?
– CI 과정에 포함해야 개발팀의 삽질을 줄일 수 있음

26. Iteration
• 작은 단위의 제작 프로세스
– 게임의 재미는 정량화 되지 않음
• 해봐야 아는 물건이기 때문에 플레이 하면서 계속 수정해야 함
– 프로토타이핑 및 마일스톤 단계 내에서의 일반적인 과정
– 제작 부분 상세 흐름
• 디자인 데이터시트, 아트/사운드 리소스, 프로그램 구현 측면
계획
(What To Do)
제작
(기획, 아트, 구현)
플레이 테스트
(QA, FGT)
다듬기
(Polishing)
피드백 반영
기획 / 컨셉
(D, A, P)
작업용 mock-up
(D, A)
구현 / 테스트
(P, Q)
리소스 / 데이터
(D, A)
통합 / 테스트
(D, A, P, Q)

27. Iteration
• 똑같은 시간을 들이더라도, 그 결과는 다르다
– 그것이 인생이다(?)
– 준비(계획)만으로 시간을 보내는 것은 최악
– 기획 문서 품질에 시간을 들이지 말 것
• 빠르게 공유하고 피드백을 받아가며 완성
• 어차피 완벽한 설계는 존재하지 않음
• 그래서, 게임 디자이너는
– 가장 먼저 생각하고 준비해야 함
• 빠르게 준비하고 만들어봐야 문제점을 빨리 찾을 수 있음
• 기획자가 미리 고민할수록 아트와 프로그램의 삽질이 줄어들 수 있음
– 게임 콘텐츠에 대해 아트팀과 프로그램팀을 설득해서 리드
• 동료들을 잘 설득 했다는 것은?  그만큼 좋은(?) 기획
완벽한 준비와 계획 개발 퀄리티 업
적당한 준비와 계획 개발 퀄리티 업

28. Post-Production

29. 라이브 서비스
• 오픈(launch) 이후의 모든 과정
– 이때부터는 개발이 아닌 서비스 관점에서 의사 결정
– 이 시점에서 조직 구조가 보통 변경됨 (LIVE팀 구성)
• 업데이트
– 소규모 패치 (치명적인 버그 수정, 밸런스 조정 등)
• LIVE: 라이브 팀에서 주로 작업
– 대규모 업데이트 (콘텐츠 추가, 확장팩 등)
• DEV: 차기 콘텐츠 개발팀에서 주로 작업
• 이벤트
– 콘텐츠 추가 없이 리텐션(retention) 유지하는 대표적인 방법
• (예) 설날, 크리스마스, 방학 시즌 이벤트 등
– 라이브 팀과 퍼블리셔가 협의
• 효율적인 브랜치(branch) 관리 필요
– 안정성 확보가 최우선이므로 코드/데이터 변경이 쉽지 않음
– 차기 콘텐츠 작업과 라이브의 마이너한 패치의 충돌을 피해야 함
– 다국어 지원과 같은 해외 시장을 위한 버전 고려

30. Post Mortem
• 게임 출시 이후 전반적인 회고
– 어떤 점이 잘 되었는지? 어떤 점이 아쉬웠는지?
– 반드시 분석해서 기록으로 남기는 것이 좋음
• 차기 프로젝트에 상당한 도움이 됨
• 잘한 것은 계승 발전시키고 못한 것은 개선
– 똑같은 실수를 반복 하지 않도록 노력
• 건강한 토론 문화가 전제 되어야 함
– 감정적이 되지 않으면서
– 서로 깔 수 있는(?) 분위기가 필요
• 라이브 서비스에 중요한 정보를 제공
– 게임의 방향성과 비전 달성이 우선?
– 유저의 목소리 우선?
– 이에 대한 판단 기준을 마련하는데 도움이 됨
• 유명한 게임들의 포스트모템 참고
– Game Developer Magazine
– 거의 매달 특집으로 수록됨

31. 교훈
• 큰 규모의 게임 제작은 원래 어려운 것
– 정량화가 쉽게 되는 제조업과는 다름
• 대량으로 찍어내기 힘든 감성의 물건
– 다양한 종류의 사람이 다양한 일을 함
• 프로그래머, 게임 디자이너, 아티스트 각각 언어(?)와 뇌구조(?)가 다름
– 커뮤니케이션 비용  성격이 좋으면 협업에 유리 (경청의 생활화)
• 복잡한 사람간의 상성관계도 영향을 줌
• 규모가 커질수록 복잡도는 제곱으로 증가
– 많은 종류의 리소스
• 그래서 CI가 필요
– 게임 제작 프로세스의 최적화는 아주 어려운 문제
• NP-Complete 문제
• 개발 환경, 게임 특성 등 고려한 상황에 맞는 휴리스틱
• 그러나, 라이브 서비스는 더 어려움
– 수많은 유저들의 목소리가 더해져 복잡도 급상승
• 차기 콘텐츠 개발 + 서비스중인 콘텐츠에서 드러나는 문제들 처리
• 어떻게 대응을 해야 하는지에 대해서도 사람마다 판단 기준이 다름

32. 끝
• 학습 목표 요약
– 아이디어로부터 게임의 컨셉을 잡고 구체화
– 게임 제작에서 큰 단위의 프로세스의 전반적인 이해
– 작은 단위의 프로세스(이터래이션)를 이해하고 설계
– 역할별 작업 순서에 대해 이해 및 마일스톤 계획 설계
– 일정이 밀리는 여러 이유에 대해 설명
• Q & A
• 차주 강의 내용은 라이브 서비스

33. 참고 자료
• 참고 문헌 및 관련 링크
– Game Design / Iteration and Rapid Prototyping
• http://gamedesignconcepts.wordpress.com/2009/07/02/level-2-game-design-iteration-and-rapid-
prototyping/
– 동접 개선을 위한 개발 이야기
• http://ndc.nexon.com/150143358315
– 게임 개발과 양보, 그리고 이상과 현실
• http://blog.daum.net/gdocument/315
– 비효율적이고 불합리한 게임 개발
• http://blog.daum.net/gdocument/317
– 플랜츠 vs 좀비, 프로토타이핑 이야기
• http://www.slideshare.net/gwertzman/the-making-of-popcaps-plants-vs-zombies
– 포스트모템으로 살펴보는 위대한 게임 개발팀의 공통점
• http://www.slideshare.net/parkpd/ss-14718729
– Issue Tracking Systems
• http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems