게임시스템기획포트폴리오 13주차 - 프로젝트 개발문서 작성 요령

수업 진행 안내

14주차까지 과제 제출. 기말과제 마감일 12/14 (토) 23:59까지

피드백은 12일까지, 성적 마감은 20일까지.

물량 채우면 B학점은 줄 예정. 기본은 수량. 수업시간에 제출한 것은 카운팅하지 않는다.

자기소개서, 역량기술서는 평가 항목에서 제외된다.

제출 필요 항목

- 자기소개서

- 역량기술서

- 프로젝트 개요

- 프로젝트 개발문서

- 경험 프로젝트 기술서

- 지망분야 개발문서

 

역량기술서에 통합될 경우, 몇 페이지부터 해당 내용인지를 전달 해 주면 된다.

 

경험 프로젝트 기술서

프로젝트 개요, 컨셉, 무엇을 참가했는지, 개발 일정, 스크린샷

 

프로젝트 개발문서 작성요령

신입이 작성하는 시스템 문서 : 시스템 설계할 수 있다, 문서작성 이렇게 할 수 있다.

시스템을 만든다는 것은 뒤를 생각하면서 만든다는 것.

이 기반이 얼마나 탄탄한지가 중요하다. 그리고 여러분은 그런 경험이 없을 것이다.

 

프로젝트 개발 경험은 게임 개발판에서 중요한 경험이다. 게임은 기본적으로 개발 기간이 길다.

게임 개발판에서 9~10개월은 긴 시간이 아니다. 개발 기간이 5년 이하인 경우, 생각한 것을 바로 만들기는 어렵다.

졸업작품은 아트를 잘 붙인 프로토타이핑이다. 제대로 된 시스템이 나올 수 없다. 미래를 생각하지 않고 달린 케이스.

 

시스템을 만든다는 것은 틀을 만들고, 공장이 돌아가는 구조를 설계하는 것이다.

병의 모양은 몰드가 있기 때문에 하나를 만들면 여러가지를 못 쓴다. 하지만 라벨은 프린팅을 자유롭게 할 수 있다.

틀이 있으면 커피 우유병에 아메리카노를 담을 수도 있고, 주스를 담을 수도 있다.

 

 

게임 개발에 있어서 가장 어려운 것은 무엇이었는가? 사람, 인간관계가 제일 어렵다.

- 개발자들이 연애를 한다 > 개발이 진행되지 않는다.

- 개발자들이 연애를 하다가 깨졌다  > 개발이 진행되지 않는다.

- 개발자들이 연애를 안해요  > 개발이 진행되지 않는다.

 

게임 개발을 진행하며 어떤 난관이 닥치는지를 한 번쯤을 경험 해 봤다는 것이 여러분들의 프로젝트가 가지는 가치이다.

 

 

프로젝트를 진행하면서 작성한 개발문서

- 시스템은 어떻게 설계했는가, 설계할 줄 아는가.

- 시스템을 설계하면서 무엇을 고민했는가.

- 자신이 아는 것을 잘 설명하는가.

 

문서를 작성할 때는 기본적인 편집이 중요하다.

행간, 가독성, 문단 간격 등등 기본적인 것들을 신경써서 작성할 것. 본인의 섬세함을 보여주어야 함.

아마추어 프로젝트의 현실

- 서로의 합심으로 이루어진 팀이 아님

- 서로의 플레이 성향이 다를 수 있음

- 목적(컨셉)이 불명확한 상태에서 시작

- 내가 원하는 목적과 다를 수 있음

 

아마추어들이 시스템 설계까지 하면서 구현할 수 있을까?

대부분의 졸작은 문서가 제대로 없다. 메모, 흔적만 남아있다.

 

"이렇게 돌아가요" 하는 코드를 텍스트로 풀은 문서는 시스템 문서가 아니다.

- 어떤 의도로 설계했는가

- 어떤 구조로 설계했는가

- 내가 한 설계의 문제는 무엇인가. (약점을 가지고 있어요 X, 약점을 파악할 수 있어요 O)

 

개발에 필요한 요소 설명 + 게임과 시스템을 이해할 수 있는 설명

프로젝트에 적용한 이후 발견된 사항들 : 아쉬운 점(개선점)

문서가 나오는 이유는 유지보수 하기 위해서이다.

물량이 적다는 것은, 하나하나 개성이 강해야 한다는 것을 뜻한다.

 

현실적인 문제로 이러저러해서 프로젝트를 진행하면서 하지는 못했지만..

- 내가 이 시스템 설계를 한다면, 이렇게 하겠다.

- 현재 프로젝트에 맞는 시스템 설계문서 작성.

 

요즘 세상에는 전투 없는 게임이 없는 수준이다.

전투를 하기 위해서는 전투 시스템, 캐릭터(플레이어, 몬스터), 스킬,,,

 

데이터의 경우 이런 항목이 있다는 것은 의미가 있지만, 각각의 수치는 의미가 없다. 데이터 하나하나를 설명하지 말 것.

현실은 개별적으로 만들었다고 하더라도, 문서는 남들에게 보여줄 수 있게 잘 포장할 것.

포트폴리오용 문서는 게임을 설명하는 문서가 아니라, 나를 설명하는 문서. "나는 이렇게 만들 수 있어요."

취업을 위한 포트폴리오의 문서

경력자 : 이전의 프로젝트에서 어떻게 했는가, 설계 성향은 어떠한가.

 

겜디들은 좋아하는 게임 장르, 개인의 성향, 스타일이 중요하다.

여러분의 포트폴리오는 성향을 체크하기 위해 사용된다.

전투를 잡을 때 타이밍 중심으로 전투를 잡는지, 전략을 중심으로 전투를 잡는지.

어떤 것을 중심으로 디자인하는지의 코멘트가 필요하다.

 

신입 : 할 줄은 아나...?

문서 구조

- 컨셉

- 설명

- 상세 내용 및 구현 구조

- 적용 후 결과 혹은 기대 결과

 

컨셉 제발 쓸 것

모든 시스템은 컨셉이 존재한다.

컨셉에 따라 시스템 구조가 달라진다. 무엇을 지향하고자 하는지 설명이 반드시 필요하다.

 

설명해야 할 것

개념적으로 어떻게 동작하는지를 설명한다.

구현시 필요한 사항을 설명한다.

세부 조건, 예외사항 등을 설명한다. (예외 사항은 무조건 있어야 하는 것이 아니다)

 

프로젝트를 경험했으므로, 설계한 시스템의 장단점을 파악할 수 있음을 설명한다.

프로젝트에 적용하지 못했다면, 어떤 장점이 있을 것이라는 것을 설명한다.

 

플레이어 캐릭터가 문을 열고 나서 걸어나가면 닫히는 프로세스를 만든다면

- 문을 열고 나가지 않는다면 문은 열려있는가? 닫혀있는가?

- 문을 열고 나가다가 되돌아온다면 문은 플레이어 캐릭터를 뚫는가? 미는가?

 

시뮬레이터에 랜덤값 넣지 말 것.

시뮬레이션은 미래 상황을 예측하는 것. 그래서 평균값이 중요하다.

전투 시간이 얼마나 되는지, 몬스터는 언제 주는지.

좋은 문서 소재

플레이 내용을 포함하는 시스템 (컨텐츠를 포함하는 시스템)

단순 기능이 아니라, 디자인 의도가 들어갈 수 있는 시스템

레벨, 보스, 시즈널 이벤트, 설정, 스토리 등등은 컨셉 설명이 중요하다.

UI는 조금 다르다. (구조, 레이아웃, 아트 리소스 관리, 감각적인 영역)