Ogre 3D Engine을 사용한 MOBA, 저스티스 콜로세움 포스트모템,

저스티스 콜로세움 포스트 모템 from Acura Netics

학교에서 발표했던 자료, 개정판이긴 한데 완전판은 아니고 하고싶은 이야기가 많이 빠져있다.

01

Intro,

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

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

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

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

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

프로젝트 소개,

게임 타이틀은 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 게임을 한번도 만들어본 경험이 없었고, 또한 다른 사람이 진행하던 프로젝트를 이어서 진행해본 경험도 없었고
또한 망한 게임을 성공시켜본 경험도 없었습니다. 그런 경험을 할 수 있다는 것이 저에게는 메리트로 다가왔고
이 프로젝트를 수락하고 진행하게끔 하였습니다. (그리고 나락으로 떨어집니다...)

3D 캐릭터/몬스터 모델링

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

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

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

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

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

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

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 파일에서 사운드는 출력이 되지 않는 등 다양한 문제를 짧은 개발 시간내에 해결한다는 것은 불가능 했습니다.

일정 조율 실패,

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

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

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

기획서는 재활용이 가능한가?

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

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

일정표가 있어도 꼭 그대로 굴러가진 않습니다.

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

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

쓸데없는 고퀄 (목적망각)

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

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

알아야 잘 만들 수 있습니다.

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

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