첫 PM 프로젝트, Dira - roll tactics 포스트 모템

012

어떤 프로젝트?

컴투스 재직을 제외하고 군 전역후 처음으로 시작한 프로젝트,

Sage 최초의 보드게임 프로젝트,

서브 기획, QA가 아닌 메인 기획 및 PM으로로 처음 시작한 프로젝트,

(했던 프로젝트 중에) 가장 평이 좋았던 프로젝트,

사실 까보면 이래저래 탈도 많았던 프로젝트,

Information

- 어원 : 혈투를 나타내는 라틴어, 디라로 읽는다. (주사위를 뜻하는 Dice와 비슷한 단어로 보드게임의 이미지 부여)

- 핵심컨셉 : 주사위 값을 통해 스테이지를 이동, 전투를 통하여 상대를 제압, 유일한 승리자가 되는 게임

- 플레이어수 : 2 ~ 4명 (Network 미지원)

- 장르 : Dice SRPG

- 플랫폼 : PC (Microsoft Windows XP 이상, 윈도우 7 권장)

- 해상도 : 1024 x 768

- 개발환경 : Direct X9 / C++ / HGE (Haaf’s Game Engine)

- 스토리 : 서로의 누명을 벗기 위한 네 명의 주인공의 치열한 혈투

- 타겟층 : 10~20대 청소년층

Project Log

월	주요 이슈	세부 사항
2012.06	아이디어 최초구상 (1)	보드게임 Entrance of Lord로 제안서 업로드
	팀 멤버 결성 (11)	기획(PM) 1명 / 시나리오 1명 / 아트 3명 / 프로그래머 1명
	최초 미팅(19)	팀원소개, 개인포트폴리오 확인, 게임 컨셉 발표, 일정 조율
	두 번째 미팅(24)	팀 이름 결정 – 6명의 팀원에 모티브를 딴 Hexagon 최초 기획 프로토타이핑 및 브레인 스토밍
	Redmine.NET/ics 기동(29)	효과적인 업무 분장, 관리를 위한 오픈소스 Issue Tracking Tool 인 Redmine 운용개시 (추후 Trello로 선회)
07	컨셉 제안서 발표 (02)	게임 컨셉 및 명칭 변경 / Dira (혈투) 시스템 및 게임 정보에 대한 보강
	SAGE Game Lab 입성,(09)	청소 및 개발 환경 셋팅 및 개발 착수
08	중간 보고서 발표(28)	주사위 값에 따른 전투 프로토타이핑 공개
09	개발 조율	빡빡한 일정과 변수에 따른 개발사항 조율
10	중간 발표 (09)	맵툴만 나오고 게임이 나오지 않아 처참한 결과…
12	발표 전 최종심사(04)	막바지 개발로 MAC 발표를 위한 최종심사

기획 의도

1. 하나의 목적을 가지고 고군분투하는 4인의 이야기
   초기기획부터 쭉 이어져 내려오고 있는 핵심요소로 서로 다른 네 가지 세력이 공통의 목표를 가지고 대결,
   마침내 원하는 것을 쟁취한다는 흐름을 통하여 유저에게 명확한 동기를 부여하고 그 동기를 이루기 위한
   과정을 명확히 제시 함으로서 게임의 몰입을 돕는 역할을 한다.
   
   
2. SAGE(서강대학교 게임교육원) 사상 첫 PC 보드게임 프로젝트
   PC용 보드게임은 서강대학교 게임교육원에서 처음 시도되는 장르의 게임으로 여타 학교 게임에서 느낄 수
   없었던 장르의 참신함과 희소성을 통하여 좀 더 근본적인 게임의 재미에 대한 접근을 꾀한다. 
   
   
3. 게임은 같이 해야 재미있다.
   스타크래프트, 롤, 서든어택, 와우. 이들의 재미는 나 ‘혼자’가 아닌 남이랑 같이 해야 재미있는 게임들이다.
   마찬가지로 혼자서 플레이 하게 되면 재미가 반감되는 보드게임을 통해 남과 같이 플레이 할 때 재미있는 요소
   들에 대한 분석 / 적용을 통해 함께 하였을 때 더욱 재미있는 게임제작을 추구한다.

좋았던 점

1. 좋은 인재가 모였다.
   일본 콘솔 게임을 많이 해본 Lead Artist는 게임리소스 제작에 대한 감과 퀄리티가 뛰어났으며
   개발자 또한 해당 장르에 대한 이해도가 있어 어느 정도 게임이 가야 할 방향에 대한 아낌없는 조언을 해주어 실현 가능한 범위 내에서 게임을 구현을 할 수 있었다.
   
   
2. 공동 작업실(Sage Game Lab)을 얻을 수 있었다.
   의욕적인 팀원들에 의해 학교에서 상위 3팀에게 주는 SAGE Game Lab에 입성 할 수 있었다.
   학교 근처에 팀원이 같이 모여 작업을 할 수 있는 환경이 구성되어 개발에 좀 더 집중할 수 있게 되었다.
   
   
3. 팀원들이 책임감이 강했다.
   Lead Artist의 경우 고등학교부터 원화 외주 작업을 많이 해와 게임 프로젝트에 대한 이해도가 높고
   책임감이 강하여 프로젝트를 추진하는데 있어 결과물 제작 일정 및 제작 방식에 대한 시름을 덜었다.
   또한 (당시) 실패율이 높은 학교 프로젝트에서 첫 프로젝트임에도 불구하고 프로젝트 완성에 대한
   희망을 놓지 않고 끝까지 게임을 완성 시키기 위해 노력했던 개발자의 책임감도 대단하였다.
   

잘못한 점

1. 어려운 난이도의 장르, 구현방식을 택하였다
   학교에서 보통 처음 프로젝트로는 키를 입력하면 바로로 반응이 오는 액션(슈팅)게임,
   단방향(종/횡)으로 진행되는 스크롤 형식 게임을 제작하는데 반해
   개발에 대한 노하우가 없는 상황에서 Isometric(쿼터뷰) 방식과 턴제 보드게임을 선택하였다.
   룰에 대한 많은 고민과과 밸런싱 과정을 거쳐야 하는 보드게임을 개발하기에는 짧은 학교 프로젝트의
   개발 주기는 맞지 않았다. 덕분에 타 팀에 비해서 결과물이 늦게 나오게 되었다.
   
   
2. 관리툴이 만능은 아니다.
   완벽한 팀원 관리를 위해 오픈소스 일감관리 툴인 레드마인 서버를 구축하여 지메일과 연동,
   일감 생성과 동시에 지메일을 통해 메일로 쏴주고 네이버 캘린더를 통하여 특정 일정에는 SMS를 발송해주며
   카카오톡 대화방을 통해서 회의방을 만들고 관리하려고 했었다.
   하지만 팀원들이 이러한 툴을 쓰는데 거부감을 가졌고(특히 레드마인 이슈 기입),
   툴을 쓰는 것보다 바로 지시하고 작업을 감독하는 것이 더 효율이 좋아
   소규모 팀에서의 관리툴 사용에 대한 효율성을 다시한번 재고해보게 되었다.
   
   
3. 어떤 게임이 될 것이라는 비전을 정확히 보여주지 못하였다. (계속된 기획수정)
   프로토타이핑을 진행하였지만 구현 범위에 대한 예측을 하지못해 게임에 대한 정확한 비전을 제시해주지 못했다.
   기획은 어느정도 뼈대가 완벽히 나와야하는데 그 부분이 부족했으며 불확실한 비전을 가지고 작업을 하는 팀원들은
   확신을 가지지 못한체 작업을 진행함으로서 사기저하를 불러 일으켰다.
   
   
4. PM은 여유가 있어야한다.
   당시 이 프로젝트를 진행하면서 아르바이트와 새 학생회 구축을 위한 작업을 하다보니
   다양한 일에 치여 프로젝트에 모든 관심을 쏟지 못하였다.
   그 결과 처음 생각했던 프로젝트의 디테일은 떨어지고 팀원 관리는 점점 엉망이 되어갔다.
   (특히 넘겨줘야할 기획서가 지체되면서 일부 팀원들은 마음의 문을 닫았다!)
   
   
5. 팀원의 결과물을 믿지 못하였다.
   머릿속에 원하는 느낌을 정해두고 큰 길을 제시하고 작업 지시를 하였으나
   의욕이 앞서 자신의 역량을 발휘하여 해당 팀원의 작업 방식대로 돌아온 결과물에 크게 만족 할 수 없었다.
   (주 된 이유는 '기획'을 해야하는데 '글'을 쓰려고 했기 때문이다. 전혀 원하지 않았던 방향으로,)
   엎친데 덮친격으로 오해가 겹치는 바람에 서로간의 신뢰도는 나락으로 떨어졌다.
   
   
6. 무작정 수평적 구조의 개발을 시도했다.
   시니어끼리가 아닌 주니어보다 못한 학생들 끼리의 작업에서 수평적 구조의 개발방식을 시도하였다.
   하지만 서로가 해당 분야에 대한 명확한 지식 없이 권한만 가지고서는 의미가 없어
   이런 상황에서 개발을 해야된다면 수평적 구조는 지양하라고 권하고 싶다.
   (때로는 독재가 나을때가 있다!!! 때로는...)

(내가) 느낀 점

1. 설계가 탄탄해야한다.
   기획자에게 집을 기획하라고 한다.
   빨간 지붕이 있고 마당이 있고 창문이 셋 달린 집을 기획한다.
   아티스트에게 이러한 집을 그려보라고 한다.
   어떤 느낌의 빨간색인지, 어떤 모양의 창을 달것인지 고민한다
   개발자에게 이러한 집을 개발하라고 한다.
   아까 기획자가 기획한 내용 그대로 반영해서 개발한다. 집에 필수로 있어야 할 문이 없지만 정해준 만큼 개발한다.
   하나의 목표가 있지만 서로가 어떻게 생각하는가는 모두가 다르게 생각한다.
   이럴 때 일수록 기획자의 설계가 탄탄해야 다른 팀원들이 그런 부분에서 헤매지 않고 작업을 할 수 있을것이다.
   
   
2. 잘 한것을 많이 봐야한다.
   앞서 말한 탄탄한 설계의 연장선상이다.
   초보 기획자가 그러한 탄탄한 설계의 집을 단순히 머릿속으로만 생각하고 만들 수는 없다.
   그러면 잘 된 설계(집)을 많이 보고 그 가운데서 그 설계를 배우고 응용하여 좀 더 나은 설계를 할 수 있을 것이다.
   처음부터 완성작/대작이 나올수는 없다, 단순히 다른사람이 한 것을 경외시 할 것이 아니라
   다소 부끄럽더라도 다른 사람의 잘 된 작품을 많이 보면서 그 가운데서 자신만의 색을 찾아 응용할 수 있어야 한다.