Acura의 Dev.NET/ics

삼성 S-Pen 또는 터치 스크린 인터페이스를 이용하여 즐길 수 있는 한국풍 3D 액션 RPG

4명의 캐릭터를 통해 기호에 맞는 스킬을 제스쳐로 호출하여 퍼즐을 풀고 몬스터를 사냥할 수 있다.
보스를 저지하는 스토리모드와 계속 몰려오는 몬스터를 잡을 수 있는 무한모드,
기록을 남겨 상대방과 겨룰 수 있는 리더보드(랭킹) 이 구현되어있다.

Galaxy Note에 탑재된 S-pen의 기능을 이용하여 게임을 만들어보자는 취지로 시작하여
Nintendo DS로 출시된 젤다의 전설 몽환의 모래시계와 같은 Pen-Based 게임을 레퍼런스로 선정
Roguelike형 게임처럼 랜덤으로 던전을 생성하고 그곳에서 전투가 이루어 질 수 있게 개발하였다. (2013.12 중반 ~ 2013.2 중반)

개발 중반에 급하게 이매진컵 참전을 위하여 W8 Modern / WP8로 플랫폼을 변경하고
Pen-based 에서 Touch based 로 변경, MS의 클라우드 서비스인 Azure를 이용한 웹 랭킹까지 구현하였다. (2013.3)

Angel In Earth(이하 AIE)를 통해 이미 서로의 성향을 잘 파악한 인원들로 시작한 프로젝트로
서로가 어떤 방식으로 어떻게 일을 진행하는지에 대한 이해가 이루어진 상태에서 프로젝트를 시작하였다.
특히 본인이 학교를 다니느라 초반 기획이 온전히 나오지 않은 상태에서도 단편적인 정보들을 끌어모아
먼저 프로토타이핑을 진행하여 다소 빠듯한 일정속에서도 서로 원하는 것을 잘 캐치하여
여지껏 멤버십 수준에서 진행하기 힘들었던 3D RPG 프로젝트를 데드라인 이내에 완수 할 수 있었다.

AIE 프로젝트에서는 팀원 모두가 Unity 라는 엔진에 숙련되지 않아 다소 진행이 더뎠으나,
본 프로젝트에서는 어느정도의 스터디가 이루어 진 뒤에 착수하여 예전보다 더 빠른 시간 내에 원하는 결과물을 만들 수 있었다.
또한 프로젝트 완수를 위해서 제작은 가능하지만 시간이 걸리는 모듈과 사운드, 이펙트 등의 리소스를 에셋스토어에서
구매해 사용함으로서 짧은 개발 기간을 단축 시킬 수 있었다.

모든 팀원들이 Agile 방법론의 하나인 Scrum을 주지하고 함께 실천함으로서 짧은 개발 기간 (실 투입기간 2.5개월) 에도
불구하고 프로젝트를 완수 할 수 있었다. Pay가 걸려있는 과제도 아니었지만 (물론 과제비가 나옵니다만 이건 풀칠...)
초기에는 과제 달성, 후기에는 이매진컵 수상이라는 비전이 있었기에 가능 했었다고 생각한다.

최초 계획에는 마켓 출시라는 목적이 있었으나 상용 엔진을 가지고 게임을 진행하다보니
실제 출시에는 라이센스 보유가 가장 큰 문제가 되었다. (멤버십에서 라이센스를 보유하고 있었지만 좀 꼬인 상태)
또한 심의비 또한 만만찮아 정식 출시까지 드는 비용이 300만원에 육박하게 됨으로서 자연스럽게 상용화를 포기하게 되었다.
(그래서 런칭 경험까지는 얻지 못하였다.)

Unity에서는 마우스 디바이스와 키보드, 게임패드에 대한 지원은 있었지만 Stylus에 대한 지원은 없었다.
그렇다보니 삼성에서 별도로 제공하는 S-Pen SDK와 S-Pen Plugin을 쓸 수 밖에 없었는데
유니티용으로 지원되는 S-Pen Plugin은 단순한 캔버스 기능에 대한 예제만 들어있었고
S-Pen SDK를 include 해도 호버기능과 서드파티 UI 인식이 제대로 되지 않았다.
이러한 점을 Unity 커뮤니티와 삼성 개발자 커뮤니티에 어필을 했으나 제대로 해결되지 않았고.
(특히 삼성에서는 오픈소스 커뮤니티에 요청해보세요~ 라는 희대의 망언을...)
결국은 내부적으로 노가다를 통해서 해당 위치에 S-pen을 인식할 수 있도록 2중처리를 해주어서 해결을 했었다.

이러한 처리는 Windows 8 플랫폼 포팅때도 동일하게 있었는데
빌드옵션에서 Windows 8 / Phone 8 선택하면 바로 포팅이 되는건 아니였다. (세상일이 이렇게 편하게 될 리가 -_-;;;)
그래서 포팅랩에 가서 게임을 포팅하는 실습을 해보았지만 엔진이 완벽하지 못해 화면이 깨지는 문제도 발생하였다.
(계속 깜빡깜빡거리고 엄청나게 느리게 동작을 한다거나...)
그 후 개발 환경을 선회하여 Windows Desktop모드로 개발헤가 되는데
슬레이트의 스타일러스 입력처리를 받으려니 마우스 커서 동시입력을 지원받지 못해서
펜터치와 터치입력의 딜레이가 발생하였다. 부랴부랴 Modern 모드로 포팅하기 위해서 만들어 두었던
커스텀 셰이더를 모두 다 엎어보고 재 조립하여 포팅을 하였다.

사실 프로젝트를 참여하면서 프로젝트 시작보다 더 후회하는 것이 이매진컵 참여이다. 
나는 이매진컵을 참전하면서 마이크로소프트에게 큰 실망을 하였다.
공모전임에도 불구하고 형평성이 적용되지 않았기 때문이다.

마이크로소프트(이하 MS)에는 MSP (Microsoft Student Partners) 라는 삼성의 소프트웨어 멤버십 같은 그룹이 있다.

일반적인 참가자는 이매진컵에 대한 정보를 마이크로소프트 홈페이지와 이매진컵 페이지를 통해서 제한적으로 습득하고
준비하는 것에 반해 MSP의 회원들은 출전을 위한 정보와 심사 기준에 대한 자세한 사항을 내부인들을 통해서 습득함으로서
다른 경쟁자와의 형평성 문제를 가지고 왔다. 
(내부의 심사위원들의 사전 심사 및 피드백 제공/ MS 인턴들의 자료 번역 및 영상 촬영 등의 도움 제공)

또한 MS에서는 사전 일정에 대해서도 내부에 미리 공개를 하고 그에 맞춘 준비를 미리 시킴으로서
이매진 컵이라는 행사는 외부에서 참가한 인원들보다 MSP를 위해서 치루어지는 행사라는 이미지가 더 강하게 들었다.
(MSP 회원들이 먼저 의상 사이즈를 선점한다거나 포토제닉, 부스 등의 행사는
 MSP 회원들의 전유물이 되어 일반 참전팀은 이용도 하기 힘들었다.)

엄연한 공모전임에도 불구하고 프로젝트의 완성도 보다는 성장가능성(?)이라는 모호한 심사기준을 들며
공정하지 못한 심사를 한 부분도 한 몫 거들었다. MSP를 위해서 미리 짜여진 판에 놀아 나는 것 같아 많이 불쾌했다.

혹시 이매진컵을 준비하는 인원이 있으면 아래의 부분을 필히 준비해서 MSP 인원들에게 뒤쳐지지 않기를 바란다.

1. 외부 리서치 : 당신의 솔루션을 쓸 타겟에게 오프라인 리서치를 진행하고 촬영해서 심사위원에게 보여줘라 (이것은 보여주기 쇼다.)
2. 프레젠테이션 : 솔루션이 못나도 그럴싸하게 보이고 어필만 잘하면 된다. 당신을 심사하는 사람들은 전문가가 아니다.
3. MSP 지인 보유 : MSP 지인을 꼭 보유해라, 그들이 있으면 정보가 먼저 돌기 때문에 준비가 30배 편하다.
4. 선 로컬라이징 : 모든 자료와 솔루션은 영어로 제공되어야한다. 사전에 번역을 염두에 두고 제작을 하여라.

http://carfain.tistory.com/146 - [개발일지] 요마전1

http://carfain.tistory.com/147 - [개발일지] 스킬액션 구현하기 #1

http://carfain.tistory.com/148 - [개발일지] 스킬액션 구현하기 #2

http://carfain.tistory.com/149 - [개발일지] 스킬액션 구현하기 #3

http://carfain.tistory.com/151 - [개발일지] 요마전 #2

이전다음

012

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

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

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

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

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

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

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

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

- 장르 : Dice SRPG

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

- 해상도 : 1024 x 768

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

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

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

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

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

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

이전다음

01

본 프로젝트는 정말 처참하게 말아먹었습니다.

개발된 리소스를 모두 사용하지 못하였고 네트워크 게임으로 개발되던것을 급하게 싱글플레이로,

그것도 플레이가 안되는 상태로 마무리를 했기 때문이죠,

멀쩡하게 플레이 되는 클라이언트도 없어서 포트폴리오로 내기도 무안한 프로젝트입니다.

... 하지만 이 프로젝트에서 배운것은 참 많았습니다.

게임 타이틀은 Justice Colosseum(저스티스 콜로세움), 네오위즈 배틀 스타디움과 비슷한 의미로 따왔습니다.

장르는 3D MOBA, 요즘 가장 핫한 게임인 리그 오브 레전드와 동일한 장르입니다

플랫폼은 Windows 기반 PC, 1024 x 768 해상도로 개발 되었습니다.

개발환경은 오픈소스 공개엔진인 Ogre(오거) 엔진 1.8.2에 Boost(C++) 라이브러리 1.5.3을 이용하였습니다.

저는 이 프로젝트를 처음부터 한 것이 아니었습니다.

처음 프로젝트를 진행할 때는 기획자 2명(시스템)에 시나리오 1명(컨텐츠), 3명이라는 널널한 환경에서 출발했습니다.
6개월 정도 진행을 했지만 멀쩡한 게임의 모습은 나오지 않았고, 기획자가 다 빠진 상태에서 제가 이어받습니다.
시나리오 학과 학생은 쓸 수 있는 인력이 있었지만 제 개인적인 판단으로 인해 따로 두지 않았습니다.

그렇게 연장 하게 된 프로젝트는 기획자 1명, 프로그래머 2명, 3D 아티스트 3명(배경, 캐릭터, 몬스터), 2D 아티스트 1명,
총 7명으로 재구성 되었습니다, 저중에 프로그래머 2명과 3D 아티스트 1명은 졸업을 앞두고 있던 졸업 준비생이었습니다.
학교에는 인력수급에 대한 호소문 까지 제출했지만 형평성을 이유로 인력 충당을 받지 못하였습니다.
(여기서 일어난 트러블로 인해 저는 과생활을 기피하게 됩니다 -_-...)

한번 망했다고 평가받는 프로젝트를 다시 받아 진행한다는 것, 그것은 저에게도 살짝 힘든 결정이었습니다.
하지만 3D 게임을 한번도 만들어본 경험이 없었고, 또한 다른 사람이 진행하던 프로젝트를 이어서 진행해본 경험도 없었고
또한 망한 게임을 성공시켜본 경험도 없었습니다. 그런 경험을 할 수 있다는 것이 저에게는 메리트로 다가왔고
이 프로젝트를 수락하고 진행하게끔 하였습니다. (그리고 나락으로 떨어집니다...)

여러분이 배워 왔던 게임 기획, 게임 개발은 이런게 아니었나요? (5 Slide)
기획자/기획팀이 디자인 컨셉을 잡고 그래픽 원화팀에게 전달하면 그 그래픽 원화를 바탕으로 3D 결과물이 나오는 방식,
저도 그렇게 배워왔고 다른 사람도 그렇다고 했었습니다. 기획서 없이 게임 만드는 사람이 이상하다고 했었죠,

먼저 보여드리는 그림(6 Slide)는 컨셉 작업을 모두 마치고 작성한 리소스 입니다.
하나는 뽀샤시하고 하나는 우중충하고... 또 같은 게임에 쓰이는게 맞는지 모를 퀄리티 차이도 보입니다.
저 캐릭터들은 시간에 부쳐서 애니메이션도 만들지 못하였습니다.

지금 보여드리는 그림(7 Slide)는 기획서 없이 컨셉 잡고 바로 제작한 리소스 입니다.
동일한 기간에 기획서가 없는데도 애니메이션 까지 다 나왔습니다.
물론 기획서가 없다고 해서 요구사항과 레퍼런스가 없는건 아닙니다.

왜 이런 차이가 벌어졌을까 간단히 설명하자면... 설계와 제작 의사소통에 달려있다고 말씀드리고 싶습니다.
이전 프로젝트는 설계와 동시에 제작이 이루어졌기에 설계가 끝날때 까지 제작 파트에서는 손가락 빨고 있던 시간이 많았고
또한 이러한 과정을 거치면서 작업이 굉장히 늦게 착수되었기 때문입니다. 또한 기획서라고 자세하게 적어서 준 문서들을
아티스트들은 바로 이해하지 못하였고 두번 세번 물어보게 됨으로서 작업 진척을 더디게 하였습니다.

반면 이번 진행방식에서는 원화팀에 부연 스토리같은 짜잘한 설정 없이 바로 어떠한 컨셉의 어떤 캐릭터를 디자인해달라,
라고 말을 한뒤 3D 아티스트가 바로 거기에 맞춰 모델 작업을 들어갔습니다.

여기서 시간 낭비를 줄일 수 있었고 줄인 시간을 애니메이션에 투자하여 기대만큼의 결과물을 받을 수 있었습니다.
그리고 그렇게 만들어진 결과물에다 살을 붙여 캐릭터 설정을 완성함으로서 좀 더 효율적으로 작업할 수 있었습니다.

모티브가 된 맵이 있었기 때문에 (리그 오브 레전드의 뒤틀린 숲) 빠르리라 생각했던 3D 배경...
레퍼런스가 있고 그걸 뜯어서 볼 수 있다고 해도 쉽게 풀리진 않았습니다 -_-;

가장 큰 실수를 꼽자면 배치는 있었지만 축척 및 시안 그림을 그리지 않고 작업을 한 문제가 있었습니다.
이 실수는 다른 문제와 연결되는데... 필드에 캐릭터가 표시될 정확한 사이즈와 오브젝트의 비율을 계산하지 못했던것이었습니다.

2D 게임에서는 이런 캐릭터나 오브젝트를 보이는데로 (Pixel) 배치하면 그만이었지만 3D 게임은 엔진에서 쓰는 단위가 있고
FOV(Filed of View) 등 고려해야될 요소가 많았던겁니다. 그래서 가급적 원화 작업으로 어떤 오브젝트를 어디다가
배치하고 이 오브젝트 크기가 캐릭터에 비례했을때 어느정도인지, 그리고 어떠한 모습을 보여주고 싶은지를 명확히 정한뒤
모델 및 맵핑작업을 했으면 좋았을 것이란 생각이 듭니다.

즉, 즉홍적으로 오브젝트를 마구마구 배치하다보면 다른 작업물이랑 비율이 맞지 않아 요리조리 손보다 보면 작업물이 더디게 나오게 되니 사전 원화 작업 및 축척을 미리 다 정하고 작업하세요! (더미로 엔진에 올려보셔도 좋습니다.)

캐릭터의 기본 정보와 유래, 출신배경, 성격, 행동, 적대관계 등등...
3개월이란 짧은 시간내에 만들어야 되는 게임에서 이러한 설정문서를 짜고 이 문서를 바탕으로
아티스트들이 설정집을 이해하고 리소스를 제작하고 좀 더 멋진 작업물을 만든다......

정말 이상적인 환경입니다. 하지만 우리는 그러지 못하였습니다.
성향에 따라 다르겠지만  아티스트들은 자신이 무엇을 그려야 하며 어떤것을 모델링하고 맵핑하고 애니메이션 하는지에
관심이 있었습니다. 이런 화려한 설정문서는 교수님과 단순히 지켜보는 독자들은 좋을지 몰라도 아티스트들과
실제 작업하는데는 전혀 좋은 영향을 주지 못하였습니다. (무엇보다 글 많으면 잘 안읽습니다 -_-;)

가급적 이러한 설정을 반영을 하여 작업을 꼭 시키고 싶다면 이런 글보다는 다양한 레퍼런스를 잘 수집해서
이 레퍼런스를 보여주면서 거기에 맞춰달라는 부탁을 하는게 좋습니다.
특히 3D 작업을 부탁 할때는 게임에서 분해한 fbx 나 시뮬레이터를 많이 보여줄 수록 좋습니다.

그러게 말입니다. -_-;

가장 억울할때가 열심히 하고 결과물이 그렇게 안나왔을때라고 하죠..

먼저 제가 3D 무경험 기획자였기 때문에 3D 작업물이 어떻게 만들어지고 어떻게 결과물이 게임에 반영이 되는지 몰랐습니다.
제가 결정하고 지시를 내려야 되는 사항은 많았지만 거기에 대한 지식이 많이 부족했죠,

그걸 납득 할만큼 깨달은 순간에는 이미 개발 기간이 중반을 넘어선 뒤였습니다.
제가 개념을 안 뒤에 프로젝트에 착수했더라면 이것보다 좀 더 좋은 결과물이 나오지 않았을까 싶습니다.

제가 JC를 개발하면서 가장 많이 도움받았던 책 두권을 들자면

- 열혈강의 3ds Max 게임 캐릭터 디자인 - FREELEC (신장판이 나온걸로 알고있습니다.)
- 셰이더 프로그래밍 입문 - 한빛미디어

를 꼽을수 있겠습니다, 둘 다 기획자가 개념 이해하고 읽어 보기엔 좋았지만
셰이더 프로그래밍 입문은 말그대로 프로그래밍 입문이라 어떤 셰이더가 게임내 결과물에 어떤 느낌을 주고
어떤 게임을 만들때 이러한 기법을 써야된다 같은 정보는 부족해서 다소 아쉽긴 했습니다.

저희가 게임을 개발했던 엔진은 Ogre 3D 엔진입니다.

2005년쯤 대중에게 공개된 오픈소스 3D 엔진이며 디아블로류 게임인 토치라이트가 이 엔진으로 개발 되었습니다.

요즘 가장 많이 쓰이는 Unity 3D 엔진은 포럼도 왕성하고 오픈된 자료도 많고 에디터로 뭐가 뭔지 바로 볼수도있고
쉽게 수치를 바꿀 수 있어 민첩하게 개발 할수 있는것과 반대로 저희가 게임 개발을 했던 엔진은 Ogre 3D 엔진은
엔진 자체는 공짜고 소스가 오픈되어있어 배울 수 있는 요소도 많긴한데
돈을주고 산 익스포터도 불편하고 제대로 작동하지 않으며 에디터 기반엔진도 아니라서
뭘 만지면 무엇이 어떻게 바뀌고 기획자가 잘 되고 있는지 바로 바로 확인도 힘듭니다.

유니티가 나오면서 자연스레 찬밥이 되어서 국내 유일한 포럼인 네이버 카페에 가도 질문글만 있고 답변이 없으며
영문권 포럼에 가봐도 만족할만한 글과 정보를 접하기가 힘들어 (자료가 없습니다...) 
제작 환경 구성이 굉장히 불편하다고 할 수 있습니다.

...제일 난관이었던 이러한 난관속에서
검증이 안된 오픈소스 라이브러리를 이것저것 더 붙여 완성에 대한 실낱같은 희망을 버린겁니다.

Autodesk 사에서 나온 Scaleform 이라는 솔루션이 있습니다.
플래시로 UI를 만들어서 동적 인터렉션을 같이 줄 수 있는 라이브러리인데요,
스트리트 파이터 4 등의 게임에 사용되어 큰 호평을 받았습니다.

Ogre 엔진에는 이 기능을 카피한 오픈소스 라이브러리인 Hikari가 있습니다.
Swf 파일을 게임에 불러와 사용할 수 있게끔 제작이 되어있지만 오픈소스 라이브러리다 보니
공식적으로 이 코드에 대해서 지원해주는 개발자가 없어 (이미 해당 프로젝트에 관심이 떠남)
문제가 생겨도 도움을 받을 수 없었으며 파이널 버전인 v0.3에서 메모리릭(누수)이 되는
치명적인 문제가 있어 사용에 애로사항이 많았습니다.

더군다나 같이 작업을 했던 아티스트 들이 이러한 작업에 익숙하지 않아 작업이 힘들었고
불러온 SWF 파일에서 사운드는 출력이 되지 않는 등 다양한 문제를 짧은 개발 시간내에 해결한다는 것은 불가능 했습니다.

기존에 제작된 결과물이 어느정도인지 파악할 수 없었으며, (로그도 없고 인수인계도 제대로 되지 않았고...)
불확실한 변수가 많은 상황에서 만들다보니 완충 기간을 뛰어넘어서도 개발이 이루어졌습니다.

또한 팀원들이 개인 성장에 초점을 맞추고 게임을 제작하다보니 꼭 그렇게 안해도 되는 방식을 많이 채택하기도 하여서
스스로 무덤을 많이 팠습니다.

사실 이런 짧은 프로젝트에서는 얼마나 코드가 이쁘고 설계가 깔끔했냐라는 것 보다는
한정된 기한내에 만져 볼 수 있는 결과물을 내는게 우선이었는데 제가 그렇게 설득하지 못한점이 많이 아쉽습니다.

네, (반은 맞고 반은 틀림)

하지만 저는 새로 작성했습니다, 아티스트가 한 말 그대로 알아먹을 수가 없었기 때문이죠 -_-;
제작을 하고 기획서를 다시 썼습니다. 기획자가 바뀐다고 꼭 한번 엎는것이 아니라 제대로 명기가 되지 않은 상황을
다시 지정하는 작업이 거의 기획서를 새로 쓰는 만큼의 분량이 되어서 기획서를 새로 쓰다시피 했습니다.

일정표는 꼭 있어야 하고 그렇게 되게끔 짜는게 가장 중요하지만

유도리 있게 땡길건 땡기고 밀건 밀어도 좋습니다. 꼭 그대로만 하려고 하지 마세요

우리는 주어진 본분에 충실해야됩니다. 이번 학교 프로젝트는 학생들이 배운 기술로 예측했던 결과물을 낼 수 있는가가
목표였지만 그 뜻을 학생 개인의 성장으로 해석하고 공부만 실컷했습니다 -_-...
즉 결과물이 나오지 않았습니다. 기본적인 목적을 망각한거죠...

우리는 게임을 잘 만들었어야 했습니다.

만들면서 배워나가는 것도 있겠지만
최소한 접근하려는 프로젝트에 대한 기본적인 소양을 갖추고 임하는것이 가장 우선이며

주어진 일정과 목적에 대한 것을 망각하지 않고
꾸준히 그 목표를 향해 달려갈 때 원하는 결과물을 손에 쥘 수 있을 것 입니다.

2012년 중후반, 저는 G스타 2013에서 학교 부스 스텝으로 참여 하고 있던 와중 
박근혜 대선후보(현 댓통령...)을 만나 셧다운제에 대한 질문을 하게되었습니다.
(http://ppss.kr/archives/5124)

그리고 이 일로 오랫동안 연락이 뜸했던 동호회 지인 용가리님을 통해 용가리님이 일하던 레지오 소프트에서
Neurosky사의 Mindwave Mobile을 대여받게 됩니다.

막상 단말기를 빌렸지만 저는 개발자가 아니었기에 아무것도 할 수 없었습니다.
그러던 와중 재학중이던 SAGE(서강대학교 게임교육원)의 학술동아리 선빈동의 2대 부장을 맡게되면서
게임을 이용한 다양한 분야에 관심이 많은 권순정 교수님을 만나 장비를 전달하고
BCI를 이용한 게임을 만들어보자고 마음을 먹었지만 바로 시작할 엄두를 못내고 있었습니다.

게임을 만들려면 먼저 기획이 있어야 합니다.

처음 교수님은 미니게임을 여러개 만들어보고 미니게임 묶음팩을 만들어 본 뒤 그것을 포스트모템하여
학생들끼리 이러한 시도를 해보았다 라는 초점으로 가자고 이야기를 했습니다.

그래서 선빈동 내부에서 게임 아이디어 공모전을 진행을 하고 다수의 게임이 출품되었습니다.
(사비로 PC판 스파4, 스마트폰용 수화기를 상품으로 걸고 진행했습니다 -_ㅠ)

But... 여기서 제출된 아이디어를 거의 쓸 수가 없었습니다.

왜냐하면 BCI 단말기의 특징을 제대로 알려주지 않은 상태에서 게임 기획을 지시하다 보니
단말기의 스펙과 성격을 뛰어넘은 게임 기획이 나왔기 때문입니다 -_-;

이러한 미니게임 형식의 게임은 기존의 논문에서 다 시도가 되었던 부분이었습니다.
그래서는 이 개발의 의미와 우리가 가질 수 있는 가치가 떨어질 것이라 생각했습니다.

그러던 와중에 디지털 스토리텔링 학과에 있는 동아리원이 늦었지만 한번 써본다고 기획서를 넘겨주었습니다.

플라밍고라는 이름의 기획서를 받아 든 순간 머리속에서는 어드벤처야 말로 BCI에 가장 적합한 장르의 게임이 아닐까 생각했습니다.

앞서 나왔던 아이디어를 쓸 수 업섰던 가장 큰 이유는 기계는 정적인 인터렉션(명상, 집중)을 지원하는데 반해
나와있는 아이디어는 모두 순발력을 요구하는 동적 컨텐츠 들이 주를 이루었기 때문이지요,

하지만 어드벤처 장르는 이야기가 다릅니다. 게임 자체가 정적으로 진행이 되고 퍼즐을 푸는 요소에는 순발력보다는
집중력이 요구 되기 때문이지요, 그래서 우리는 어드벤처 게임을 BCI로 개발하기로 합니다. 

플라밍고에서 기획되었던 BCI활용 요소의 대다수가 단발성으로 진행이 되는 미니게임이다보니
지속 가능한 게임 플레이를 위해서는 인터렉션을 활용하는 요소를 새로 기획할 필요가 있었습니다.

그래서 스코프 개념을 도입하여 방안에 있는 수수께끼 요소를 찾는 방탈출 게임을 기획하게 되었습니다.

일정 미스로 인해서 실질적인 개발착수는 중간고사 기간이 끝나고 시작되게 되었습니다.
추가로 교수님의 희망에 의해 한국게임학회 추계 학술발표대회에 나간다고 신청까지 한 상황,

테크 데모를 위한 3스테이지 제작을 목표로 1달간 불철주야 개발 삼매경에 빠졌습니다.