레벨디자인심화 14.5주차 보강 - 포트폴리오를 만드는 방법

포트폴리오는 9월까지 완성되어 있는 것이 좋다.

- 봄에는 장기적인 계획을 채우는 것에 대한 채용이 많다.

- 신입을 뽑는 것은 가을이 많다.

- 방학때 취업은 소개로 들어가는 경우가 많다.

- 여름에는 다들 여름휴가를 세우느라 관심이 없다.

 

9~10월쯤 되면 한 학기 공부 열심히 해야지, 하고 마음을 다잡듯이 회사도 마찬가지이다.

프로젝트에 관련된 것이 아닌, 할 수 있는 것에 대해 정리를 해 두면 2학년동안 했었던 부분에 대해 정리를 해 두면 3학년 이후 졸작 프로젝트 관련된 내용만 정리하면 되기 때문에 유리한 면이 있다.

 

했던 것, 할 수 있는 것에 대해서 정리 해 두는 것을 추천한다.

 

 

수업 내용을 어떻게 포트폴리오로 정리하면 좋을 것인가.

시스템, 컨텐츠, 레벨, 어느 쪽을 지망한다고 해도 시스템 포트폴리오는 있는 것이 좋다.

전문적인 시스템을 하고 싶다면 전투나 밸런싱을 넣으면 된다.

컨텐츠 쪽을 하고 싶다면 퀘스트를 넣거나 이벤트와 관련된 것을 넣는 것이 좋다.

 

 

컨텐츠라고 국어, 말을 잘 하는 사람을 뽑는 곳이면 조금 다니더라도 빠져나가는 것이 좋다.

물론 현실적으로 말을 잘하는 사람도 드물다.

허들이 낮다는 것은 경력이 있는 사람이 필요하지 않다는 것이다.

경력의 아웃풋의 차이가 문서만 쓰는 것이라면 차이가 있을까? 없다.

기본적인 기술은 5년차, 빠르면 3년차, 길어도 5~6년차 정도면 평준화된다. 이걸 따라가지 못하면 도태된다.

 

커뮤니케이션 하지 않고 문서만 쓰면 쓸모없는 사람이 된다.

경력은 긴데, 개발할 줄 모르는 기획자가 제일 먼저 도태된다.

3년 이내에 어느 팀을 가도 살아남을 수 있는 기획자가 되어야 한다.

5년동안 능력을 얻지 못한다면 전직하는 편이 낫다. 사람들은 계속 들어오기 때문.

 

 

전투 시스템 문서를 만든다고 해도 컨셉을 만들어야 하고, 설명(국어)을 잘 해야 하고,

문서에 대해서 설계를 할 줄 알아야 한다.

논리적인 구조를 짤 줄 알아야 하고, 데이터 테이블까지는 만들 수 있어야 한다.

 

이후에 차별화 되는 것.

시스템은 좀 더 계산적이고, 컨텐츠는 좀 더 유저친화적인 차이가 생긴다.

 

 

스폰 시스템을 예시로 들면...

스폰 데이터에 대해 플레이 컨셉을 쓰고, 스폰에 대한 설명, 기능, 데이터 테이블 설명을 써야 한다.

프로그래머 베이스들이 프로그래머와 커뮤니케이션을 잘 하는 경우가 많고, 변수와 타이밍, 설계는 잘 알아도 함수를 중심으로 커뮤니케이션을 잘하는 경우가 많다. 하지만 스폰의 구조가 어떻게 되는지를 이해시키는 것이 더 중요하다.

 

무언가 하나를 구현하기 위해서는 데이터, 아트, 로직으로 구현 할 수 있다. 똑같은 방법을 구현하기 위해서는 여러가지 방법이 있기 떄문에 어떻게 돌아가야하는지를 인간의 언어로 이해시킬 수 있어야 한다. 그래서 얘가 어떻게 돌아가는 것인지.

 

 

개발을 위한 문서가 아니라, 포트폴리오를 위한 문서이기 때문에 장황하게 긴 문서보다 짧고 읽기 좋은 문서가 좋다.

청강대 학생들은 꽤 많다. 여러분이 지원하고 싶어하는 개발 스튜디오는 여러분의 동기, 선배, 친구들도 지원을 한다.

수업 내에서 진행했던 포트폴리오는 더 덧붙인 내용을 가지고 쓰는 것이 좋다. 전부 같은 것을 가져오면, 전부 감점이다.

학원생들을 선호하지 않는 것과 같은 이유.

 

게임 기획 포트폴리오를 만드는 학원에 가 보면, 폼이 다 정해져 있다.

여러분들끼리는 서로 크게 비슷한지 모를 수 있지만, 받는 사람 입장에서 보면 들어오는 게 다 똑같아 보인다. 생각하고 쓴 것이 아니라, 형식에 맞춰서 내용을 넣었음을 눈치챌 수 있다. 그래서 과제를 포트폴리오로 넣는 것은 위험하다.

 

포트폴리오를 위한 문서들을 최소한 3개는 써야 하는데, 3학년 프로젝트를 하면서 하는 것이 생각보다 코스트가 크다.

50%만 더 추가해도 서로 다른 것이 보인다.

 

 

아이디어는 플레이 컨셉에서 넣어주면 된다. 컨셉이 어떻게 동작하는지 설명과 예시를 적으면 좋다.

데이터테이블 구조는 크게 달라지지 않아도 된다.

 

 

컨텐츠 기획을 하고 싶다면, 던전 도면과 던전 컨셉을 부각시키는 것이 좋다.

범용 던전의 spec, 개요, 설명, 그리고 던전의 고유한, 유니크한 고유 성격.

던전의 플레이 시나리오(배경 설정, 스토리)를 만들고 저는 이렇게 컨셉을 엮을 수 있어요' 를 보여주고, 배치 계획과 데이터 예시를 작성한다. 데이터테이블의 설명까지 제작.

 

 

우리나라에서 가장 많이 사람을 뽑는 것은 RPG이고, RPG는 사실 던전 하나하나마다 유니크하게 만들기 어렵다. 대량으로 만들어야 하기 때문에. 11강 과제를 한 내용을 잘 다듬으면 도움이 될 수 있다.

 

 

 

레벨 디자이너가 되고 싶다면, 중간고사때까지 작성한 문서를 잘 작성해서 가면 된다.

본격적으로 배경 설정과 스토리. 플레이가 진행되는 내용을 넣어주면 된다.

스토리에는 플레이어가 알고 들어가는 내용이 아닌, 실제로 플레이어가 경험하게 되는 이야기를 적어야 한다.

이를 기반으로 플레이 스토리를 만들고 플레이 시나리오를 작성한다. 구간별 플레이, 특징이 드러나게 작성해야 한다. 너무 길어도 피곤하다. 포트폴리오 문서를 읽는 사람들은 5분 내외로 보고 싶은 페이지들을 위주로 본다.

 

보통 10~30페이지가 나오게 되는데, 시선을 붙잡을 수 있는 인상적인 페이지가 3페이지는 있어야 한다.

추천하는 것은 도면과 함께 있는 플레이 개요.

 

- 컨셉

- 도면 + 개요

- 제작 목록.

 

포트폴리오 PPT에서 컨셉은 무조건 읽어보고 간다. 기반이고, 문서의 앞에 있기 때문. 그렇기 떄문에 쓸데없는 내용 쓰는 것 보다 핵심적인 내용을 쓰는 것이 좋다.

기본적으로 맵이 들어가면 그림이 들어가기 떄문에 눈에 잘 보인다. 그리고 눈에 잘 보이게 설명되어 있어야 한다.

읽는 사람 입장에서는 구간별로 상세한 것 보다 전체 도면이 꼭 들어가는 것이 좋다.

지형 제작의 경우 엔진에서 대략적으로 구상해서 스크린샷을 넣거나 스케치업을 쓰거나 아트가 잘 이해할 수 있게 이동 구간과 랜드마크 위치, 퀘스트나 시나리오의 주요 스팟들, 넓이 등이 들어가는 것이 좋다.

 

제작 목록을 넣어주는 것을 추천한다. 등장하는 몬스터, NPC, 주요 오브젝트, 랜드마크, 특징적인 환경 요소에 대한 목록. 단순히 지면을 그리는 것과 목록을 리스트업 할 수 있는 것은 다른 영역. 하나를 만들어서 얼마나 사용할 수 있는가도 어필하면 좋다. 개발을 염두에 두고 경제적인 목록을 만들었는가.

 

 

데이터테이블 샘플을 넣어놓고 0, 1, 0, 1을 넣어두면 무슨 생각으로 넣었는지 꼼꼼하게 찾아보지 않는다. 차라리 문자열을 써도 상관 없으니 데이터 테이블만 봐도 이해가 가능해야 한다. 실제로 개발에 들어갔을 때 숫자로 넣을 수 있지만, 포트폴리오를 보는 여러분들의 미래 팀원들에게는 아무런 도움이 되지 않는다. 읽는 사람들이 이해할 수 있게 써야 한다.

 

 

한 번쯤 정리를 해 두면 생각을 정리하는 데에 도움이 될 것.

적게는 문서 2개부터 많이는 8개까지 봤다. 하지만 8개를 내면 다 잘 보지 않는다.

노션은 읽는 사람 입장에서 불친절하다. pdf가 가장 읽기 편하고, pdf 파일의 분량은 중요하지 않다.

포트폴리오를 여러개 낼 것이라면, 내가 가장 못한 것을 면접관이 볼 것이라는 생각을 하고 낼것.

처음 열어본 것이 흥미가 없다면 아예 열어보지 않는다.

 

 

컨셉 기획의 경우

- 시스템

- 퀘스트 + 시나리오

- DataTable

- BalanceTable (가장 먼저)

- 시뮬레이터 (열어본다.)

시뮬레이터를 가져온 사람 중 멀쩡한 것을 가져오는 사람을 교수님은 거의 보지 못했다.

우리가 원하는 것은 기댓값. 몇 퍼센트의 확률로 잡고, 죽는지. 안정적으로 몇 마리를 잡게 되는지. 얼마만큼 성장하는지.

전체 상황을 예측하기 위해서 만드는 것을 시뮬레이션이라고 한다.

 

장기적인 호흡을 볼 수 있는 사람인지를 보기 위해 시뮬레이터를 먼저 열어보는 경향이 있다.

어설프게 만들었으면 넣지 않는 게 낫다.

 

 

팀 프로세스가 졸작보다 못한 팀일 경우 굳이 1년을 채운다거나의 이유로 여러분들의 1년을 버리지 않는 것이 좋다.

1년 채워도 경력으로 인정받지 못하는 경우가 있고, 1년을 못 채워도 포트폴리오가 멀쩡하면 잘 다닐 수 있다.

1년의 차이는 퇴직금이다. 오래 있어봤자 많은 것을 배울 수 없다.

다시 말하지만, 이 바닥에서 가장 쓸모 없는 것은 개발 할 줄 모르는 기획자.

여러분들의 정체성이 있어야 시니어로 올라갈 수 있다. 뭔가 탁월한 스킬이 있던가.

 

 

퀘스트나 시나리오 지망하는 사람 중에 제대로 가져오는 사람을 교수님은 거의 모지 못했다.

스토리 하나는 들고와야 한다. 나의 창작물을 들고 오던가, 퀘스트 시스템을 만들어오던가.

퀘스트쪽이 굉장히 사람 구하기가 어렵다. 이야기를 잘 쓰는 사람이 없기 떄문.

이야기를 잘 쓰는 사람들은 게임을 개발하기보단 웹소로 가는 경향이 있고, 팀에 소속하는 것 보다 개인 작업을 선호하는 경향이 많다. 게다가 소설을 잘 쓰는 것과 게임의 시나리오를 잘 쓰는 것은 다른 이야기이다. 이야기를 보기 위해서 하는 게임은 우리나라에서 잘 만들지 않는다.

 

 

인디팀은 장단점이 뚜렷하다.

하지만 인디팀은 큰 팀에 비해서 프로세스가 좋지 않는 경우가 많다. 그리고 프로세스가 좋지 않으면 개발 기간이 늘어난다. 하지만 인디는 빨리 게임을 성공시키는 것이 중요해서 속도가 빠르다.

경험이 적은 사람이라면 눈치가 필요하다. 하지만 큰 팀은 조금 소외되어도 살아남을 수 있다.