Acura의 Dev.NET/ics

Hdac 기반의 아이돌 팬덤 커뮤니티 플랫폼

Hdac Hackathon 2018 - participation prize

• Hdac Private Blockchain을 기반으로 모금, 결제 지원
• 유사 수신 행위 우회
• 해외 결제 용이

• 태그 기반의 구독형 SNS 커뮤니티 제공
• 타임라인 형태로 설정한 태그를 구독
• 업보팅 / 다운 보팅 기능으로 라이터에게 리워드 제공

• IOT Device 연동으로 팬덤 특화 기능 제공
• 경광봉 타입의 전자지갑 단말기 제작
• 공연 관람 / 모임 참석 인증 기능 제공
• 등급제 인증 기능 제공

삼성 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. 잘 한것을 많이 봐야한다.
   앞서 말한 탄탄한 설계의 연장선상이다.
   초보 기획자가 그러한 탄탄한 설계의 집을 단순히 머릿속으로만 생각하고 만들 수는 없다.
   그러면 잘 된 설계(집)을 많이 보고 그 가운데서 그 설계를 배우고 응용하여 좀 더 나은 설계를 할 수 있을 것이다.
   처음부터 완성작/대작이 나올수는 없다, 단순히 다른사람이 한 것을 경외시 할 것이 아니라
   다소 부끄럽더라도 다른 사람의 잘 된 작품을 많이 보면서 그 가운데서 자신만의 색을 찾아 응용할 수 있어야 한다.

1. 나도 스카이림 같은 게임정돈 만들수 있는 아이디어가 있어!
   or 시중의 게임은 너무 식상해, 세상에 없는 나만의 진짜 참신한 게임을 만들겠어!
2. 그렇게 시작 되는게 대작병
3. 감당할 수 있는 범위를 넘어선 개발 범위 + 개발요소 -> 프로젝트 패망의 지름길
4. 가급적 하나의 Core Mechanics 에 집중
   - 코어가 튼튼하면 게임도 튼튼하다.
5. GTA / 스카이림은 이것도 재밌고 요런것도 재밌는데 다 들어가면 안되나요? (코어가 여러개)
   - 하지만 우리는 소규모 제작팀, 그런 다양한 요소를 다 넣겠다는 생각 이전에 가장 핵심 요소만이라도 재미있게,
6. 일단 할수 있는 범위내에서 50~70% 의 목표를 잡고 시작
   - 걸음마 부터 먼저, 성공의 체험이 필요
7. 생각 한 범위 내에서 만드는 데 충실하자.

이전다음

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달간 불철주야 개발 삼매경에 빠졌습니다.

Com2us QA팀에 있을시적 Mantis를 통해 ITS 툴에 대한 개념을 익히고

지지난학기 브리디아 소프트에서 제작중이던 SNG를 Redmine을 이용하여

프로젝트 매니징 및 기획서를 작성하는 것을 보았다.

그리고 지난학기, 나는 ITS를 쓰면 PM이 엄청나게 수월해 질 것 같아 학교 프로젝트로 보드게임을
제작하면서 ITS를 사용하여 이슈 및 기획서를 관리하려고 하였다.

기본적으로 비슷한 툴은 많다. Mantis(Wiki가 없다), Trac 등등등...

하지만 기본적으로 제일 이쁘게 생긴게 Redmine이었고 본것도 그거밖에 없어서

맨땅에 헤딩해가며 구축을 했다. 몇가지 이슈를 적어보면...

1. 서버가 없으면 쓸 수 없는 프로그램 (비용발생)
   기본적으로 Mysql 기반으로 짜진 프로그램이다보니 항시 DB를 읽고 쓰려면
   24시간 돌아갈 수 있는 Mysql 서버가 있어야 한다.
   24시간 켜둘 수 있는 서버란 것은 회선 + 서버 사용비가 항상 들기 때문에
   무일푼으로 진행하는 학교프로젝트에는 걸맞지 않았다.
   (다행히도 나는 학교에 서버를 둘 수 있어서 비용은 들지 않았다.)
2. 아직도 Stable 하지 못했던 2.x 버전
   브리디아에서 사용하고 있던건 1.x 대 버전이었고
   내가 redmine을 설치하려고 했을때 1.x 대 버전과 2.x 대 버전이 동시에 올라와있었다.
   그 때는 그냥 무조건 버전 높은게 짱일거라 생각하고 2.x 대 버전을 설치했었는데
   2.x대 버전은 아직도 제대로 된 피드백이 축적되지 않았으며 여러가지 버그가 난무해
   사용하기가 껄끄러웠다.
   
3. 무궁무진한 커스터마이징, 노가다.
   기본적으로 오픈소스 프로그램이고 비교적 쉬운언어라는 ruby로 짜져있어
   무궁무진한 커스터마이징이 가능하다.
   근데 이 말은 즉슨 넣고 싶은 기능을 가감하는데 있어서 너무 많은 손이가
   redmine 전담이 없으면 너저분한 메뉴를 다 올려놓고 써야 하는 것이다.

Wiki를 작성하던중 페이지를 열어놓고 딴짓을 하고 계속 반복작성을 시도했는데
점점 서버를 여는 시간도 길어지더니 결국은 서비스 임시 사용 불가와 프록시 에러가 떴다.
일단 급한데로 서비스를 껐다켰는데도 마찬가지로 계속 그러다 어느순간 잘 동작하는것이었다.

근본적인 문제를 해결하기 위해서... 구글링을 해보니 해당사례가 이미 있었다.

http://xyz37.blog.me/50090489826

결론은 mySQL쪽 DLL에서 문제를 일으킨다고 했는데 bitnami로 깐 내 redmine은
mongrel.log 파일이 없어서 분석도 못해보고 아파치 로그만 디립다 보다가
결국은 저기서 나온 sql dll 파일 교체를 시도했다. (물론 원본파일은 libmySQL1.DLL 로 백업해둠)
SQL 서버가 안돌면 어쩌나 했는데 잘 돌아간다.

redmine은 기본적인 위키 작성 툴인 textile이 있음
근데 이게 너무 기능이 간편해서... 좀 잘 해보려고 redmine 포럼의 ono란 사람이 개조한
redmine_ckeditor를 받았음, 근데.. 문제는 이걸 받아서 redmine 폴더의 plugin에 넣으면
무조건 구동이 안된다. 100%, 이걸로 오늘 삽질, 어떻게 해결할지 생각해봐야겠다.

1. rake db:migration RAILS_ENV='production' 은 redmine 폴더안의 htdocs 에서 실행해야된다.
    ㄴ 추가로 2.x대 버전에서는 db:migration이 아니라 db:migrate로 입력해줘야 한다(12-07-12)

2. 왠만한 프로그램 설치 안됐다는건 gem install 'xxx'로 해결할 수 있는건 좋은 기능인것 같다.

3. redmine 2.x 대에서는 plugins 폴더가 vendor 안에 넣으면 오류메세지도 뜨고 실행도 안된다.

4. execjs 설치시 Permission Denied 문제가 뜬다. / Redmine Stack 사용을 관리자 권한으로 실행하니 잘된다.

5. 이제 htdocs로 들어가니 안먹던 rake db:migrate_plugins RAILS_ENV="production"이 먹기 시작한다.
    ㄴ 2.x대 버전부터는 db:migrate_plugins가 아니라 redmine:plugins:migrate 라고 입력해줘야한다.
        (rake redmine:plugins:migrate RAILS_ENV='production' / 12-07-31)

6. 마이그레이션 완료 CKeditor가 구동된다

교훈.

(1) Redmine Stack 사용 (CMD로 실행된다) 은 무조건 관리자 권한으로 실행시켜라

(2) 인터넷에 온 글은 살짝 유행이 지났기 때문에 무조건 Redmine 공식홈페이지 매뉴얼을 읽어라

(3) 절대 vendor 안에 plugins 폴더 만들어 넣지마라, 이건 커맨드 창에서도 경고해준다

(4) 에러메시지만 봐도 반은 이해함

(5) migration을 안하고 바로 plugins에 넣고 재시작시 무조건 레드마인이 뻗는다. 구동 안됨!

(6) db:migrate를 했을때도 뜨던 internal error가 redmine:plugins:migrate를 하니 훨씬 덜 뜨는 것 같다.

1. 발단.

프로젝트 관리를 redmine으로 하고 싶은 욕심이 생김

2. ruby install

bitnami를 이용해서 redmine을 구동하는데는 성공을 했으나
이미 apmsetup을 깔아놓았기 때문에 한번에 관리하는게 편하다고 판단하고
bitmani를 지우고 apmsetup을 통한 설치에 도전하기로 함 (http://kindi.tistory.com/104)
더불어 redmine도 2.x 최신빌드를 이용하기로 함

3. rubygems install failed

ruby를 운용함에 있어서 gem 버전을 1.8.7 이상으로 업데이트를 해야되는데..
기본적인 ruby 인스톨러는 1.8.6에 gem 버전 1.1.2, 여기에 1.3.6을 까는건 되는데
1.8.24는 구문에러를 뱉으면서 설치가 안되는 것이다.
여기서 든 생각은 1.3.6을 먼저 설치해서 그런가? 라는 생각이었다.

3. ruby uninstall, reinstall

설치 도중 ruby가 bundler setup이 안되었네 구문에러니 난리를 피워대니 미칠 노릇, 
결국 ruby를 통째로 날렸다 (클린 설치를 위해) 
그리고 루비를 재 인스톨 해서 바로 디렉토리에서 setup.rb를 실행시켰지만... 잘 되지 않았다.

4. 1.9.1 덧씌움, 1.8.24 설치 성공

그래서 찾다찾다 보니 인스톨러는 1.8.6이지만 덧씌울수 있는 1.9.1 을 발견
그리고 1.9.1 을 덧씌우고 rubygems 1.8.24를 설치하니 말짱히 설치되는것이었다.

5. 순순히 될줄 알았냐? zlib킥!

그래서 이제 rail을 설치하려고 하는데 zlib이 없다고 하는 것이다.
i386-mswin32에는 zlib.so가 있었을 텐데 -_-;
그래서 구글링 열심히 했지만 뚜렷한 해결책을 찾을 수 없었고
zlib을 다시 받아 넣을까 했는데... 이런.. bin 폴더에 있는 파일이름이 zlib1.dll 이다. 
zlib1.dll을 zlib.dll로 바꿔주니 rail 설치 잘만된다.

6. 최신빌드는 명령어 부터 다르다

저 블로그에 나와있는건 1.x빌드 기준이고 공식홈에서는 secret_token으로 생성을 하란다

7. mocha는 깔았다.근데 rmagick는 왜 안깔려?

mocha가 없다고 해서 mocha를 깔았다.
그리고 rmagick가 없어서 gem install rmagick로 설치를 시도했는데..
디벨롭먼트 킷이 필요하단다. 7-zip exe로 된 DEV kit을 깔았는데도 안된다

8. 포기

rmagick gem 파일은 받았지만 너무 덕지덕지 많이 깔릴바에야 한방에 bitnami를 깔아서
ddns 접속 설정해주는게 현명하다고 판단. 오늘의 놀이는 여기까지..

6. 결론

아무것도 모르면 Bitnami Stack 깔아 쓰시면 됩니다. 속편해요