원문 : Halo 3: How Microsoft Labs Invented a New Science of Play( http://www.wired.com/gaming/virtualworlds/magazine/15-09/ff_halo?currentPage=all )

번역과 출처: All that Entertainment Technology ( http://blog.hirihiri.com/ )

원제목 : How Microsoft Labs invented a New Science of Play

사용자 삽입 이미지

WIRED의 편집자 Clive Thompson가 쓴 이 글은 헤일로 3가 만들어지는 과정에서 대작의 위용을 갖추기 위해 어떠한 usability test(사용성 테스트)를 거쳤는 지를 재미있게 설명하고 있다.

1999년 맥월드 엑스포에서 발표한 초기 헤일로를 보고 MS는 2000년에 5,000만불에 번지를 인수한다. 그 당시 게임계의 초심자(?)였던 MS와 번지의 만남이 결정적인 시너지를 발휘한 부분이 있었는데, 그것은 번지가 당시 최고 수준이던 MS의 usability lab의 힘을 빌릴 수 있었던 것이다.

사용자 삽입 이미지

헤일로 3의 멀티맵인 Valhalla에서 발견한 문제점. 빨강점은 그 지점에서 죽은 플레이어를 가리킨다. (진할 수록 많이 죽음) 죄우 대칭인 가운데 맵에서 죽는 횟수는 왼쪽으로 치우쳐있을 것을 발견할 수 있다. 오른쪽 진영에서 접근하는 것이 조금 더 유리하다는 얘기다. 결국 작업자들은 좌우의 지형과 아이템을 조절하여 양쪽 진영의 발란스를 조절하였다.

당시 usability lab은 experimental psychology(실험심리학)으로 phD를 받은 Pagulayan가 있었다. Pagulayan 팀은 헤일로 2를 만드는 과정에서 400명의 게이머와 2,300시간에 걸친 사용성 테스트를 수행하고, 초반에 형편 없었던-초반 80%의 작업을 다 버렸다고 함- 게임 플레이 수정에 막대한 기여를 하였다. 그러나, 헤일로 1보다 떨어진다고 평가되는 부분도 있었는데, 양손총의 경우 너무나 강력한 도움이 되기 때문에 플레이어들이 다른 방식의 플레이패턴을 버리게되는 악영향을 주었다고 자평한다. (헤일로 1에는 gun, grenade, or punch attack가 "golden tripod"처럼 조화롭게 사용되었다고 함.)

2006년 헤일로 3의 첫 빌드가 나왔을때, Pagulayan 팀은 20명의 테스트 인원을 추가 고용하고, 600명의 게이머와 3,000시간에 걸친 헤일로 3의 사용성 테스트를 시작하였다.

사용자 삽입 이미지
(초반 정글 맵입니다)

플레이어의 움직임을 나타낸 그래프. 다른 색은 시간별로 움직인 궤적을 보여준다. 흩어진 부분은 플레이어가 의도와는 다르게 길을 잃어버리는 것이 빈번한 곳이다. 이후 작업자들은 지형을 조절하여 플레이어가 지속적으로 맵을 따라갈 수 있도록 조정하였다.

전작에서 제기 되었던 많은 문제점이 3편에 반영되었다. 에너지계열 웨폰이 너무 많았다던가, 무너졌던 "golden tripod"의 황금비를 살리는 기획이 적용되었다. 또한, 테스트 결과는 세분화되어 현재 플레이나 스테이지가 가진 문제점을 찾는데 큰 도움이 되었다고 한다. (불행히도 자세한 테스트 방법에 대해선 나오지 않았음)

예전에 학교에 Bungie 스튜디오 관계자가 왔었는데, 헤일로 2의 사용성 테스트 동영상을 볼 기회가 있었다. (찾아봤는데 웹상에 공개된 것은 없는듯 하다.) 인상적인 부분은 플레이어의 테스트 시스템은 TV와 게임기, 그리고 카메라로 구성되어 있는데, 1개의 카메라는 패드부분을 비추고 있었다. 테스트 결과는 2개의 화면을 연속으로 보여주는데, 플레이어가 망설이거나 불편해 하는 컨트롤을 금방 알 수 있었다.

기어스오브워 이후 헤일로 3에게는 무거운 짐이 지워졌었다. 엑박 최고의 대작이라는 타이틀을 지킬 수 있을 것인가에 많은 관심이 모아 졌었다. 결과는 성공이었지만, 그 뒤에는 이러한 시행착오와 노력이 있었던 것이다.
:
출처 : KGDC 2003 문서강연 참가 글 / 작성자 김의민님 (Nickname : 아리랑피바람 )


시작하는 기획자의 실수, 시작하는 게임 개발에서 중요한 점
- 아마추어 게임개발에서 기획자의 존재 이유 -


작성자: 김의민

청강문화산업대학 게임과 재학 중

mal_min99@hotmail.com


도입:

시작하는~ 이라는 제목은 흔히 ‘게임 개발자 지망생’, ‘초보’ 이런 말을 보다는 좀 더 어감이 친근하고 듣기에도 좋지 않을까 해서 사용하게 되었습니다. 또 아마추어 개발자, 아마추어 게임 과 같은 경우도 모두 똑같이 아마추어 라고 불리우지만, 그 중에서 상대적으로 경험이 풍부한 아마추어도 있고, 이제 막 시도하는 아마추어도 있기 때문에, 그리고 저의 글의 타깃이 되는 대상은 아마추어 개발자 중에서도 '시작하는~' 등급이 적절하다고 판단 되었기 때문 입니다.


1. 시작하는 기획자

- 기획자는 무엇을 하는 걸까?

필자가 접해본 대다수의 개발자 지망생 중 게임 기획 & 디자인 을 지망하는 사람들은 대다수가 게임 기획이란 것이 추상적이고, 어떤 형식이 없고, 문서 위주의 작업, 그리고 심지어는 시나리오 작성이 기획자가 해야 할 일의 전부로 착각하는 사람도 아주 많았다.

개인적으로 생각하기로는 우리나라의 기존 게임 기획자들이 잘못된 선례를 남겼고 이 잔재를 후배들이 받은 것 같아서 언짢다. 필자가 생각하는 올바른 기획자 또는 게임 디자이너는 관념 속에서 멋지게 포장되어있는 ‘리더’, ’설정자’ 같은 것이 아니다. 이들이 분명 멋져 보이긴 하지만 아무런 기반 없이 그 위치에 오른 것이 분명 아닐 것이다.

특히 현실적인 기획자라면 역시 개발의 일선에서 툴을 만지면서 레벨디자인을 하고 스크립트 작업과 같은 힘든 일을 하면서 항상 자신들이 만드는 게임에 대해서 생각하고 더 좋은 게임으로 만들기 위해서 고민해야 하는 사람이 아닐까?. 물론 흔히들 잘 알고 있는 기획서 작성 및 시나리오, 설정 같은 것도 해야 한다. 필자는 우선 기획자가 되려면 게임 기획에 관해서 멋지게 포장되어있는 기존의 관념, 거짓 환상을 버리고, 무엇을 할지 분명히 알아야 한다고 생각한다. 게임 기획도 프로그래밍, 그래픽 과 같이 똑같이 진흙탕을 구르는 것이고, 똑같이 힘든 일이다.

- 문서작성에 대한 잘못된 생각.

옛날 유명한 수학자이자 철학자 파스칼은 언젠가 친구에게 한정 없이 긴 편지를 한 통 쓰고 난 후 추신에 짧은 편지를 쓸 만한 시간이 없었노라고 사과하는 글을 덧붙인 적이 있다. 하물며 편지를 길게 쓰고도 사과를 해야 할 정도이니, 그것이 게임 기획서 라면 어떻겠는가?

정말 무진장 지루하게 읽기만 하고 이해조차 할 수 없는 기획서를 쓰는 기획자라면 깊이 반성을 해야 할 것이다.

시작하는 기획자들은 종이에 한이 맺혔는지는 몰라도, 무한정 기획서를 길게 쓰려고 하는 경향이 있다. 특히 기획서를 써본 경험이 별로 없는 사람의 경우는 ‘양이 많은 기획서 = 잘 쓴 기획서’로 착각을 하는 경우가 많다. 그들이 쓰는 기획서들을 살펴보면 앞부분에 커버가 있고, 목차, 게임에 대한 기획의도 랄지, 게임의 핵심 같은걸 쓰고... (여기까지는 나무랄 수는 없다) 꼭 그 다음에는 한 페이지의 도표에 일정표가 들어간다. 그 이후에 친절한(?) 유저 인터페이스 설명이 나오는데, 이것들에 시시콜콜히 표나 그림 같은걸 집어넣어서 그 분량이 장난이 아니다. 이후에는 다닥다닥 아이템 표, 캐릭터 설정, 그리고 줄기찬...시나리오...시나리오...시나리오.

[공모전 등지에서 소개된 기획서들의 양식 영향인지 몰라도, 기획서들을 살펴보면 거의 형식은 비슷비슷하고, 전부 몇 십 페이지의 방대한 분량을 자랑한다. 필자는 이런 기존의 방식 보다 좀더 효율적이고 새로운 방법을 강구 해야 된다고 주장한다.]

필자가 본 많은 기획서가 이렇다. 물론 무조건 나쁘다는 것은 아니다. 하지만 그들 기획서에서 기획서가 가져야 할 실질적으로 중요한 내용이 무시되기 일쑤이다. 특히 지금 설명하려는 부분은 지금까지의 전반적인 기획서 작성법에 관한 내용인데, 기존의 거의 모든 게임 기획서 들은 나열식 수직 구조이다.

워드프로세서의 구조 자체가 원래 그렇지만, 이런 구조일 경우 10 page 가 넘어가면 보는 사람은 지루해지고 집중력을 잃는다. 팀원들에게 그걸 던져주면... "어! 기획자 수고했어, 잘 읽어보겠어~ (하지만 내일...)" 그리고 이 기획서는 그냥 문서더미 속에 던져진다.

현업의 기획자들도 팀원들이 기획서를 안 읽는다고 불평이 많은데, 그것이 지망생 개발팀이나 아마추어게임 팀이면 더 심할 것이라고 생각한다. 이 부분은 팀원을 탓하기 이전에 기획자가 기획서를 좀더 보기 편하게 만들어 놓아야 하는 문제이다.

필자가 제시하는 대안은 이렇다.

우선 나열식의 기획서는 되도록 10장 이내로 제한 하자. 멋들어진 커버는 생략 하고, 일단 간단한 목차와 게임의 핵심적인 요소, 기승전결의 간단 시놉시스, 필요한 기술적인 능력 등을 구체적이고 명확하게 명시하는 것이 본 기획서의 목적이다.

그리고 파생되는 캐릭터, 아이템, 시나리오는 차라리 다른 문서로 준비를 하자. 일정표도 마찬가지이다. 기획서에 한 페이지에 쓰인 도표는 일정관리에 별로 쓸모가 없다는 것이 필자의 생각이다. 일정관리를 문서화 할 필요가 있다면 역시 외부의 다른 문서로 만들어주자.

정리 하자면 핵심이 되는 기본 문서와 그것에서 파생되는 간략하지만, 잘게 나뉘어진 문서로 기획서를 구성하자.

이보다 좀 더 발전적인 기획 문서를 만든다면 '하이퍼텍스트’ 를 이용하자.

간단히 활용을 할 수 있는 것은 ‘인트라넷’ 을 하나 구축하고 위에 쪼개진 각각의 다른 문서들의 제목을 하이퍼텍스트 화 해서 필요할 때 쉽게 찾아볼 수 있도록 하는 방법이 있을 것이다.

‘나열식 기획서’와 ‘목차 지향형’ 기획서
좀더 발전시키자면 애초부터 모든 기획 문서의 하이퍼텍스트 화를 하는 방법이 있다.

‘WikiWiki’와 같은 발전적인 기술을 써도 좋고, 모든 문서를 Html파일로 만들고, 서로를 이어줘도 좋을 것이다. 물론 이때 가장 중요한 것은 한번에 그들 문서를 찾아볼 수 있는 '목차' 라고 생각한다. 메인 페이지 의 목차를 보고 빨리 이해하고, 개발진이 필요한 정보를 목차를 따라 이동해서 볼 수 있고, 다시 메인 페이지로 돌아갈 수 있어야 한다.
사용자 삽입 이미지
하이퍼텍스트 화 된 기획서의 예시
[세부적인 예시가 될 수 있는 예제를 차후 필자의 홈페이지에서 공개할 예정이다.]

흔히 간결한 문서를 쓴다는 것을 문서를 짧게 작성하라는 걸로 착각하는 사람이 있다.

간결함과 짧음은 같지가 않다. 개발자가 문서를 읽어보고 그것에 대한 모호함이 없이 정확히 기획자의 의도를 파악할 수 있다는 것이 간결함 이라고 할 수 있다.

간결성을 강조한다고 그냥 막무가내로 짧은 문서를 쓴다면 그 모호함은 가중될 것이다.

또한 정형화된 방법으로 기획서를 만들려고 하지 마라. 여기서 말하는 것과 ‘포맷’은 다른 것이다. 틀이 잡힌 문서의 ‘포맷’은 효율적이다. 하지만 ‘배경 시나리오를 쓰고, 세계관을 설정하고, 그 다음에는 일정표 차트를 하나 넣어주고...' 바로 이런 것이 ‘정형화’ 혹은 ‘악습화’ 된 형식으로 그대로 따라 하는 것들이다. 이것은 게임을 만드는 것과 전혀 무관하다. 기획서에 시시콜콜히 ‘세계관’, ‘배경스토리’ 이런 것은 넣을 필요는 없다고 생각한다. 그런 것은 시간 날 때 하고 당장은 게임을 만들 때 실질적으로 필요한 작업을 하라. 단순히 기획서 몇 페이지 늘린다고 바뀌는 것은 아무것도 없다. 문서를 늘리기 보다는 줄일 수 있는 기획자가 되자.

아마추어 개발팀 중에서 열심히 하는 개발자들이 많다. 필자가 겪어본 팀들도 다 자신만의 기술과 능력이 있고 근면하다. 하지만
그 중에서 기획자가 가장 쓸데없는 작업을 하고 있고, 가장 많이 논다.
(필자도 기획자이다.)

그래픽 팀원이 도트 찍고, 프로그래머가 힘들게 코딩 할 때, 기획자라면 위에 명시한 정도의 노력은 해야 하지 않겠는가? 이 정도를 기획이 못해준다면 아마추어 개발에서 기획자가 하는 일은 무엇인가? 있기라도 할까?
 

2 시작하는 게임개발

- 분명한 목표를 세우자

나는 시작하는 게임 개발에서 가장 중요하게 생각하는 것이 분명한 목표를 세우는 것 이라고 자신 있게 말할 수 있다. 가장 흔히 들 수 있는 잘못된(?) 목표가 바로 ‘게임을 같이 만들어 가면서 실력향상을 도모하자’ 라는 목표 이다. 일단 얼핏 듣기에 전혀 문제가 없는 말이지만, 이 목표는 우선적으로 게임 보다는 개인의 실력향상에 주안점을 둔 것 이기 때문이다. 처음의 목표부터 ‘게임의 완성’ 이라는 목표를 분명히 설정해두지 않았기 때문에 이런 막연한 목표에서는 게임이 나오기 힘들 것이다.

어떤 종류와 어느 정도의 기술력이 요구되는 게임을 만들지도 중요하다. 게임을 만들면서 실력이 좋아지기는 하지만, 그렇다고 처음부터 완성될 게임의 목표를 개개인의 잠재적 성장도 까지 생각해서 잡는 건 문제가 있다. 자신들의 실력이 10이라고 할 때 첫 번째 만들 게임 이라면 8 정도 되는 수준의 게임을 만드는 것을 권장한다. 우선은 완성이 관건이기 때문이다. 아마추어 게임 개발에서 완성은 무엇보다 중요한 목표 라고 생각한다.

한가지 게임을 처음부터 끝까지 만드는 경우가 아마추어 게임 개발에서는 희귀할 정도이다. 한 개의 게임을 끝까지 완성을 할 수 있는 팀은 그걸로 대단하다고 판단할 수 있을 것이다. 완성은 성공이고 성공은 자신감이다. 이 성공이 아마추어 개발팀을 존속시킬 수 있는 이유가 될 것이다.

- 가능하면 빨리 만들자

아마추어 게임 개발은 비영리적인 일이다. 아무도 그들에게 돈을 주지 않는다. 그렇다고 게임을 완성하면 돈을 벌기도 힘들다. 또한 게임을 만든다는 것이 그렇듯, 완성하기 이전에는 명확히 눈에 보이는 것도 없고, 결과물을 예측하기 힘드니 마치 맨땅에 헤딩하는 기분일 것이다. 그래서 위에서 말했든 달성 가능한 목표를 세우는 것이 중요한 것이다.

빨리 만들어야 하는 이유도 이것의 연장선에 있는 내용이다. 개발 프로젝트의 시간이 길어질수록 점점 프로젝트의 목적에 회의감이 들고, 이탈하는 인원이 생길 수 있을 것이다. 마치 둑에 균열이 생기는 것처럼 일단 이런 일이 시작하면 팀 자체의 존속은 어려워질 것이다. 특히 오랜 시간 동안 진행해야 할 프로젝트일수록 위험도는 크다. 필자가 생각하는 가장 적정선은 6개월 이내 라고 생각한다. 학교라면 한 학기 동안 정도일 것이고, 이정도 라도 충분히 게임 하나 만들 시간은 될 것이다. 이 이상 길어지면 상당히 어려워진다.

게임을 만든다는 것은 집중을 한다면 그리 큰 시간을 잡아먹지는 않는다. 시간의 손실은 주로 쓸모 없는 잡업이나 개으름이 대부분이다. 특히 강조하고 싶은 것은 아마추어 수준 (첫 경험이라면 더더욱) 에서 년 단위로 진행되는 프로젝트를 성공시킨다는 것은 팀원들이 준 프로나 현업 경험자가 아닌 이상 절대적으로 어렵다. 팀의 리더라면 적절한 수준의 일정 관리와 팀원 관리로 목표한 시간 안에 완성시키도록 노력하자. 시간이 길어질수록 위험도 커진다.

- 팀 작업과 대인관계

팀 작업은 근본적으로 어려운 일이다.

어쩌면 혼자서 게임을 만드는 것이 더 쉬울 수 있다. 팀으로 작업을 한다는 것은 사람 (팀원) 의 관리에 신경을 써야 한다는 의미 이기도 하다. 경험이 없는 개발자 지망생들은 이 점에 있어서 매우 큰 약점을 가지고 있다. 팀이라는 것은 사람의 모임인데, 대다수의 지망생들은 팀 작업 경험이 전무하고, 팀원의 관리를 잘 할 수 있는 사람이 드물기 때문이다.

아래는 필자가 생각하는 팀 작업의 몇 가지 기본적인 조건사항 이다.

1. 소규모의 팀이어야 한다.
2. 그들에게 믿음을 주라!
3. 노는 작업자가 없어야 한다.
4. 서로간의 신뢰는 기본이다.
5. 군대를 앞두고 있는 팀원, 커플이 될 가능성이 있는 팀원은 피한다.
6. 원격 작업은 가능하면 피하자.
7. 자주 만나서 예기를 해야 한다.

기술력이 된다면, 팀은 작을수록 좋다. 한 사람의 개발력이 1이라고 봤을 때 7명이 작업한다고 7의 개발력이 발휘되는 것은 아니다. 팀 작업의 여러 가지 어려운 점은 관리가 안 되는 많은 팀원 숫자에도 있다고 생각한다.

아마추어 개발팀에서 대인관계의 핵심은 팀원들에게 믿음을 주라는 것이다. 자신이 팀장의 위치라면 게임을 완성할 수 있다는 확신을 주어야 하고, 솔선수범을 해서 작업을 열심히 하는 모습을 보여주어야 한다. 특히 대다수가 팀의 리더인 기획파트가 모범을 보여야 한다고 생각한다. 상대적으로 기획 쪽이 가장 일을 안 하는 것으로(!) 보이기 때문이다. 아까도 말했듯, 기획 쪽도 실질적으로 작업을 해야 하고 그 밖의 업무를 할 때도 모범을 보여야 한다.

팀원 중 노는 사람이 생긴다는 것은 팀 작업에 문제가 생기고 있다는 것을 반증한다.

우선 먼저 작업 분배를 잘해서 노는 인원의 발생을 최소화 시켜야 한다. 초기 팀원 모집부터 분명히 프로젝트에 필요한 사람을 모집하는 것도 중요하다. 너무나 뜻이 다르고 작업에 저해가 되는 사람이 생기면 빨리 프로젝트에서 제외를 시켜라. 한 사람과의 우정을 생각하다가 모든 것을 잃을 수도 있다.

서로를 신뢰한다는 것은 당연한 것이다. 설명할 필요가 없을 듯 하다. 이것에 관한 노하우는 스스로 찾아가는 것이 빠르다고 생각한다.

우스운 소리 같지만, 군대를 앞두고 있는 사람이나 이제 막 연애를 시작한 사람은 피해야 한다. 군대를 가게 된다면 당연히 프로젝트는 할 수가 없다. 연애를 시작하는 사람의 경우도 연애하는 것을 게임개발보다 더 매력적으로 받아들일 것이다. 당연히 프로젝트 도중에 공백이 생길 것이고 다른 팀원들의 사기에도 영향을 미친다.

인터넷이 발전해서 이제 모든 개발을 100% 인터넷으로 하려는 사람도 생겼다. 하지만 해당되는 사람들이 철저한 프로의식이 없는 이상 원격작업은 불가능하다고 생각한다. 우선 얼굴을 마주보고 예기를 하는 것과 인터넷으로 대화를 하는 것은 근본적으로 다르다. 또한 정상적인 오프라인 개발팀도 상당한 문제가 생기는데, 하물며 온라인이라면 어떻겠는가?

팀원간에 서로 자주 만나서 예기하는 것은 중요하다. 대화를 통해서 서로의 신뢰를 쌓을 수 있고, 직접 부대끼면서 토론하는 것은 결과적으로 좋은 영향을 준다. 게임 작업 뿐 아니라 일상에서도 서로간의 친목을 도모하면 여러모로 도움이 될 것 이라고 생각한다.

- 다른 방법은 없는가?

굳이 처음 시작하는 작품을 보통 게임 만들 듯, 코딩하고, 그래픽 리소스 직접 그리고, 기획서 쓰고…이런 보편적인 방식을 고수할 이유는 없다고 생각한다. 그냥 소규모 (3명 이하) 의 규모로 간단한 게임 제작 툴 (예를 들자면 퓨어엔진, V-nap 앤진, 알피지쯔구르) 와 같은 걸로 자신들의 첫 게임을 만들어보는 것은 어떨까? 이들 툴은 공개이긴 하지만 충분히 게임을 만들 수 있고 능력에 따라서 창조적이고 독창적인 작품이 나오기도 한다. 특히 이런 공개 툴로 게임을 만든다고 그 가치가 떨어진다고 생각해본 적은 없다. 게임을 게임으로서 잘 만든다면 뭐가 나쁘겠는가?
 

[공개 게임 개발 툴의 간단한 소개]

비주얼노벨 툴‘Pure’:: 장기현(neoojang) 님이 개발하신 ‘비주얼노벨’ 스크립트 엔진으로 사용이 쉽고 강력한 툴 입니다. 청강대학교 게임과 에서 학습 교제로도 사용되었습니다. 곧 최신 버전이 발표됩니다. http://noeejang.net
사용자 삽입 이미지
비주얼노벨 툴 : P u r e

비주얼노벨 툴 ‘V-nap’ :국내의 많은 동인 게임 팀이 사용하는 공개 비주얼노벨 툴 입니다. 상당히 많이 사용을 해서 그 명성이 높습니다. http://vnap.x-y.net/

이하 쯔구르 시리즈 : RPGMAKER 2000, RPGMAKER 2003, 액션 RPG 만들기, 연애 시뮬레이션 만들기, 격투 게임 만들기 등등 (알피지메이커 시리즈는 개인적으로 추천하는 개발 툴 입니다. 개발자에 따라서 이 툴을 사용해서 무척 멋진 게임들을 탄생하기도 합니다.) http://www.acoc.co.kr/ : 유명한 쯔구르 커뮤니티 사이트 ‘창조도시’)

 
3. 왜 ‘시작하는 개발자’ 들을 지원해야 하는가?

우리나라 게임산업 초창기부터 지금까지 게임업계의 인력은 항상 부족한 편이다.

더군다나 몇 년 전부터 급격한 양적인 팽창으로 더욱 많은 인력이 요구되고 있다. 이제는 우리나라에 게임에 관련된 2년제~4년제 대학의 게임학과도 몇 개 생겼고, 사설 교육기관도 있다. 기반은 옛날보다 많이 발전되었지만, 아직 많이 모자란다. 단지 양적인 인력이 많아지는 것 만이 중요한 것이 아니라, 그 인력의 각각에 역량도 중요한 법이다.

아마추어 시절에 습작 게임 개발을 겪어보지 못하고 본격적인 현업에 진출한다는 것은 큰 문제라고 생각한다. 기본적으로 몇 번 정도의 습작수준에 게임의 완성 경험이 있어야지, 비교적 그 사람이 현업에서 게임을 개발할 수 있는 능력이 되겠다고 판단할 수준이 되는 것 이라고 생각한다. 지망생 시절, 게임 만든 경험도 없이 달랑 기획서 작성하는 것만 알아서 (사실 그 기획서의 수준도 한심한 경우가 대부분이다.) 게임회사에 온다는 것은 그다지 바람직한 현상은 아니라고 본다.

특히 지금은 VT 통신망을 기반한 동호회들의 몰락으로 인해서, 그 아마추어들을 품고 키워주는 공간이 예전보다 부족하다. 또한 급격한 게임산업의 팽창으로 지망생과 현업 개발자의 중간단계라고 볼 수 있는 아마추어 개발자들이 거의 없다고 알고 있다. 결국 이런 상황이 계속되면, 게임업계는 양질의 개발자를 끌어올 수 있는 베이스를 잃어버리는 셈이 된다.

KGDA 는 이런 상황에서도 지망생들의 좋은 성장의 장이 되어왔다.

필자의 경우에도 KGDA가 있었기 때문에 지금 여기에 투고를 할 정도까지의 능력을 가지게 되었다 (물론 많이 부족하지만) 모든 이들이 마찬가지 라고 생각한다. 그들도 격려를 받고, 관심을 받는다면 무럭무럭 성장할 수 있는 자질이 있다고 생각한다.

하지만 아직 미약한 부분이 너무 많다. 좀 더 발전적인 온라인 및 오프라인 모임, 큰 규모의 한번의 행사보다는 작지만, 내실이 있고 자주 접할 수 있는 행사들이 필요하다고 생각한다. 또한 현업 개발자 들도 지망생들에게 관심을 쏟아야 한다. 개인 대 개인으로 전수되는 게임개발의 지식들, 작업 결과물의 공유와 지망생들의 습작에 관한 평가도 필요하다. 결국 누가 뭐래도 그들이 미래의 한국 게임계를 이끌어나가기 때문이지 않는가?

우리의 장래 기반이라고 할 수 있는 지망생들을 간과하지 말자. 또한 그들이 만들 아마추어 게임 역시 간과하지 말자. 결국 이들이 우리의 미래에 모습이고 우리의 희망이다.
 

마치면서:

저의 글이 누군가에게 도움이 될 수 있을지 의심이 됩니다만, 자신을 가지고 썼습니다. 판단은 역시 읽는 분 들이 하시겠죠. 가장 아쉬운 부분은 제 경험이 정말 미약해서 여러분들에게 크게 도움이 되는 글을 못 썼다는 점 입니다. 1년 후에는 더 노력해서 좋은 모습으로 찾아 뵙겠습니다.

이 글의 핵심적인 기반은 KGDA에서 최주홍(joohong) 님이 쓰신 아마추어 게임제작팀의 미래 -1- , -2- 라는 글에서 얻었습니다.

원문::
아마추어 제작팀의 미래 1
아마추어 제작팀의 미래 2
 

또한 제가 대학시절 친구들과 어설프게 게임을 만들 때의 경험, 그리고 김영환(priling) 님과 아마추어(?) 시절의 체험과 토론에서 나온 내용과 현재 대학에서 청강하고 있는 김광삼(별바람) 교수님에게 배운 내용이 대다수 입니다. 여러모로 저에게 귀감이 되는 안진용(gump)님 을 비롯해서 위에 명시된 모든 분들에게 감사를 표하고 싶습니다. 이로서 저의 첫 번째 KGDC 공개 문서가 끝났습니다. 읽어주셔서 감사합니다.

- 기타 문의 사항 : mal_min99@hotmail.com
- 홈페이지: www.arilab.wo.to

출처 : KGDC 2003 문서강연 참가 글 / 작성자 김의민님 (Nickname : 아리랑피바람 )
:
게임개발 - 개발의 권위 혹은 카리스마
게임을 개발하다보면 게임의 디자인 방향을 두고 개발자들간에 눈에 띄는 알력이 생기기 시작한다. 사람들은 저마다 미적감각, 재미의 기준에 대해 나름대로의 이유를 가지고 있으므로 개발도중에 이런 방향이 한번 충돌하게 되면 여간 곤란한 일이 아니다. 이런 상황이 개발초기라면 문제가 없겠지만 어느정도 개발이 진행되고 있는 도중에 '나는 이런 게임 도저히 못봐주겠다!'라고 배를 까고 드러눕는 개발원이 나오면 참으로 난처해진다. 사실 이런 상황은 개발프로세스의 문제라기보다 조직의 진행에 동조하지 못하는 '개인의 문제'로 볼 수 있겠지만 문제를 만든 그 한 사람이 게임을 즐기는 유저의 목소리가 아니라는 법이 어디에 있는가? 나는 오히려 이런 목소리가 나오지 않는 개발이 더 문제가 있다고 본다. 이 글은 내가 보고 겪은 여러 프로젝트에서 느낀 바를 통해서 '재미있는 게임'을 만들기 위한 마음가짐으로서 삼기위해 적는 글이다.

나를 만족시키지 못하면 남을 만족시키기 힘들다.
게임을 만드는 과정속에 그 게임을 가장 최초로 접하게 되는 사람은 그 게임의 제작자 들이다. 자신이 재미있어야 그 안에 더욱 발전된 내용과 더욱 재미있는 요소를 넣을 수 있지 마지못해서 위에서 시키니까 이거아니면 먹고살거도 없다싶어 마구 만들어내는 게임은 열에 하나도 만족시키기 힘들꺼다. 우선 자신이 만족하는 게임을 만들어야 게임이 재미있어진다. 설사 재미없는 게임이라고 하더라도 자기가 나서서 그것을 재미있게 만들어버리면 된다. 우선은 자신을 먼저 만족시키자.

재미라는 것이 과연 무엇이관데?
김국환씨의 노래 '타타타'중에 '네가 나를 모르는데 난들 너를 알겠느냐'라는 선문답이 있다. 예상해보건데 재미라는 것은 이런게 아닐까. 재미라는 것과 비슷한 것으로 '웃음'이라는 감정표현이있다. 웃음은 어떠한 상황에 대해 경험적인 내용을 되새겨 드러내는 2차적인 표현으로 인간만이 가진 특징이라는 것은 많은 석학들에 의해서 얘기된 바가 있다. 즉, 경험이나 예상할 수 없는 표현이라면 웃을래야 웃을 수가 없다는 것. 이 웃음이라는 감정을 인간끼리 공유하기 위해선 서로가 경험을 공유해야 한다. 그 경험은 언어일 수도 있고 문화일 수도 있는 것이고 여기에 다양한 조건이 융합하여 '웃기는'감정을 만들어 낼 수 있다고 본다. 상대방이 아무것도 모르는 나만이 아는 우스갯소리를 해봤자 상대방이 웃어주지 않는 것, 게임의 재미라는 건 이런점에서 더욱 '공통된 경험'의 요구가 절실하다.

누구의 목소리를 들어줘야 되나.
자 그러면 다시 처음으로 돌아간다. 저마다 자신의 재미를 내세우며 게임의 재미를 두고 각 개발파트(혹은 개인)간에 서로의 목소리를 높이는 지경이 왔다. 이제는 누구의 목소리를 들어줘야 될까? 모두의 목소리를 들어주는것이 가장 이상적이겠지만 그러자면 프로젝트 일정을 연장해야 되고 좀더 많은 리소스, 변경에 따른 지연시간으로 비용이 늘어난다. 당신이 프로젝트를 책임지고 나가는 사람이라면 이 상황을 어떻게 수습할 것인가?

개발사공 집단산행 예방법
우선은 이런 상황을 예방하는 방법이 있다. 게임의 의미를 처음부터 자세하게 설계하고 그 안의 내용을 모두가 합의하여 미리 규정시켜 놓는 방법이다. 군말하는 놈은 이 합의된 사항으로 찍어누르면 된다. 두말하는 소리가 나오지 않기로는 좋은 방법이지만 인원은 수시로 바뀔 가능성이 있고 게임이 나오지 않은 상황에서 게임제작의 진행이 합의한다고 문제가 모두 해결되기는 힘들다. 그러나 적어도 프로젝트 초기에 대다수의 인원이 공감하는 그리고 좀더 확실한 게임의 진행을 미리 합의해놓는 것은 큰 의미가 있다. 개발초기에 정확한 게임내용을 팀원들과 공유하여 그 게임 내에서 표현하고자 하는 의미를 미리 합의해보자.

- 개발헌장 -
프로젝트 초기에 목표하는 내용에 대해 스스로 부여하는 달성목표를 정의하는 것, 개발이 혼선이 오게 될때 그 선택기준이 된다.
[헌장예시] 우리게임은 RPG게임이다. 우리게임은 멀티플레이 중심이다. 우리게임은 다양한 유저층이 축적되어야 한다.
예2) 게임 도중 방향을 슈팅으로 변경하자 -> 기본방향에 위배되므로 다시 생각하라. 정말 재미있는지에 대한 예측은 헌장 작성시에 확정해놓아야 한다.
예3) 멀티플레이에 대치되는 솔로플레이컨텐츠가 필요하다 -> 멀티플중심에서 벗어나므로 우선순위를 미루자


반란, 모반, 합종연횡, 집단항명, 정치공작
그러나 아무리 확실한 기준을 잡았다고 해도 가지는 바람에 흔들리기 마련이다. 그리고 그 양상도 다양하게 드러난다. 개인적인 불만에서 집단적인 반항, 회사에서의 압력, 심지어는 유저들과 연합하여 공격해오는 개발자까지... 이 수많은 사람들을 다 적으로 돌려가며 싸워야 되는 사람, 그는 누구일까. 게임의 본질적인 재미를 목표로 하고 여러 목소리를 아울러서 하나의 돌파력으로 집중시켜야 되는 사람은 누굴까. 그는 바로 '게임디렉터'가 될 것이다.

디렉터가 가져야 되는 개발의 권위
디렉터의 권위는 다소 독재적이여야 한다. 아니 그렇게 되어야 한다고 생각한다. 여러사람의 의견을 모으는 것도 중요하지만 결론은 하나여야 한다. 그것의 선택권을 놓고 많은 개발진들이 파워싸움만 하다가는 프로젝트는 도중에 반파될 것이다. 이런 사람들을 찍어누르고 불만이 있더라도 한곳으로 밀어붙이는 것, 이것이 디렉터에게 필요한 능력이며 앞서 언급한 개발의 위대한 권위, 즉 카리스마이다.

개발의 권위, 카리스마는 어떻게 만드나
게임을 사랑하자. 단순히 사랑하는게 아니라 미치자. 이 게임은 재미있어 재미있어 재미있어~ 하고 세뇌하는 게 아니라 하나에서 열까지, 그리고 그 안의 시시콜콜한 재미까지 모두 사랑할 수 있는 그래서 '아 재미있어서 미치겠다' 라는 감정이 들때까지 게임을 사랑하는 인간이 되자. 지성이면 감천이라 자기가 게임을 사랑하는데 사람인들 안 넘어가겠나. 게임을 사랑하는 사람이야 말로 정말 자기가 사랑하는 게임을 만들 수 있다.
그리고, 오랫동안 게임을 만들자, 그리고 자신의 목소리에 동조하는 개발자, 팬을 많이 확보하자. 오랜 경험을 통해 얻어진 든든한 동료, 그의 게임을 사랑하는 수많은 유저가 존재하면 자연히 자신이 표현하고자 하는 바탕에 큰 힘을 쏟아넣을 수 있다.

( 오랜 경험, 원군없이 개발권위를 획득하는 방법은 없냐고? 로또에 당첨되어서 돈빨로 밀어붙여보라. 그러나 그런다고 과연 재미있는 게임이 나올 수 있을까?)

개발은 수도하는 마음으로
내가 원하는 게임, 내가 만들고 싶어하는 게임이 재미있는건 누구보다 내 자신이 잘 안다. 그러나 자신의 재미가 곧 남의 재미라고 단순하게 대입할 수는 없는 일, 자기가 원하는 게임을 만들기전에 먼저 유저의 입장에서 생각하고 같이 일하는 동료의 마음을 포섭하자. 그것이 포섭이든 세뇌든 공작이든 하나씩 가능한 모든 수단을 동원해서 차츰차츰 자기편을 만들자. 그리고 그들을 모아 '이 사람은 재미에 있어선 확실해', '이 사람이라면 믿고 가도 되겠다'라는 얘기를 듣게 되는 지경이 되면 자연히 개발의 권능은 일어서게 되어 있다. 거기에 더불어 여러 프로젝트 진행을 통해 얻은 직위와 경력이 더해져 있다면 당신은 이미 '위대한 게임개발자'의 길로 들어서게 되는거다. 그때까지는.... 닥치고 게임만들자. 도를 닦는 마음으로 말이다.

위대한 디렉터 미야모토 시게루
그가 만드는 게임은 탁월하다. 그는 어째서 위대한 개발자인가? 이 글을 처음으로 올려 다시금 하나씩 읽어보자. 그러면 그가 왜 위대한 디렉터이고 권위있는 개발자인지가 드러난다. 수퍼마리오, 스타폭스, 마리오카트, 동물의 숲, 젤다의 전설, 이런걸 만든 사람이면 무엇을 하더라도 믿음직하다. 우리나라에 이런 사람이 아직 없는 것이 아쉬울 따름이다. 현실을 탓하지 말고 닥치고 게임만들자. 그것도 아주 재미있게 만들자. 그리고 한국의 미야모토 무사시시게루가 되자. 그래서 전세계의 게이머에게 사랑받자. 나의 인생은 애초부터 게임을 만드는 자체에 있었지 게임으로 부자되는게 아니였다.

출처 : 글로리네 정신병원 ㅡ3ㅢ/( http://psygnus.egloos.com )
:
원출처 : I have no word & I must Design( http://www.teatime.org/article/noword.html )
1차출처 : Flaming Nairrti Astray II( http://nairrti.com/27 )

copyright by Greg Costikyan
translated by Minseok, Lee, Soonmyung. Hong

Last updated on Monday, 07-Jun-1999 14:01:46 PDT

이 기사는 1994년에 영국의 RPG잡지 Interactive Fantasy #2에 게재된 것입니다.

세상에는 다양한 게임이 있다. 그리고 그 종류도 방대하다. 컴퓨터/CD-ROM/네트워크를 매체로 하는 게임, 아케이드 게임, 우편 게임, 전자 메일 게임, 여기저기에 범람하는 성인용 게임, 워 게임, 카드 게임, RPG, 라이브 액션 게임 등등. 그렇지, 서바이벌 게임, 버추얼 리얼리티, 스포츠, 승마도 잊어서는 안된다. 이러한 것은 모두가 게임이다.

그런데 대체 이 모든 것에 공통되는 요소가 있는 것일까? 대체 '게임'이란 무엇일까? '좋은 게임'과 '나쁜 게임'을 어떻게 구분하면 되는 것일까? 마지막 질문부터 말하자면 '좋은 게임과 나쁜 게임을 구별한다'는 것은, 물론 누구나가 항상 하는 일이다.

말 을 타고 장애물을 뛰어 넘었을 때, 보드 게임의 말을 뺏겼을 때, 귀중한 '대지의 정령' 카드를 할 수 없이 넘겨줄 때, 보물을 남들에게도 분배해 주어야 할 때, 당신은 말한다. "좋은 게임이었네, 조" 그러나, 이것은 책의 마지막 페이지를 넘기고 나서 "잘 썼구먼"하고 말하는 것과 다름없다. 그야 틀린 말은 아니지만, 그렇다고 해서 좀더 잘 된 책을 쓰기 위해 쓸모가 있는 것도 아닌 것이다.
그런데 게임 디자이너는 게임을 평가하고, 게임을 이해하고, 그것이 어떻게 기능하고, 왜 재미있는가를 이해하기 위해 게임을 분석할 필요가 있다. 게임이 놀랄만한 성장을 거듭하고 또한 기막힐 정도로 다채로운 형태를 취하고 있다 하더라도, 기본적으로는 새로운 분야이기에 낡은 수법으로 이것을 분석할 수는 없는 노릇이다. 그러므로 이를 위해서는 새로운 분석 기법이 요망된다.









표기법에 대해서
통상 '체스', '바둑', '포커'등의 전통적 게임의 명칭은 보통명사로 다루어지므로 영어에서는 첫글자를 소문자로 표기한다. 반면 새로이 디자인된 게임의 명칭은 고유명사이므로 영어에서는 첫글자를 대문자로 표기하게 된다.

게임의 예술의 일종이며 모든 게임은 그 기원에 관계없이 작품으로서 동등하게 다루어져야 한다는 입장에서 보자면, 그러한 습관은 앞뒤가 맞지 않는 일이다. 그러므로 이 글에서 게임 이름의 첫글자는 모두 대문자로 표기했다.

서사시 '베어울프(Beowolf)'는 특정한 저자에 의해 쓰여진 작품이 아니라 민간 전승의 산물인데도 불구하고, '백년동안의 고독(One Hundred Years of Solitude)'처럼 제목 첫글자는 대문자로 표기한다. 마찬가지로 나는 '체스'가 특정 디자이너에 의해 만들어진 작품이 아니라 민간전승의 산물이지만, '던젼즈 & 드래곤즈'같은 게임과 같이 제목 첫글자를 대문자로 표기하였다. '체스'라는 제목이 고유명사로 취급되는 것은 기묘하다고 생각할지도 모르겠지만, 나는 분명한 이유가 있어서 그러한 표기를 한 것이다.

또한 게임 제목이 처음 등장할 경우 가능한 한 디자이너의 이름을 처음에 표기하기로 했다. 디자이너 이름이 생략되어 있는 경우, 그것은 단지 내가 디자이너의 이름을 모를 뿐이다.
(역주) 번역에서는 게임의 명칭을 전부 작은따옴표로 둘러싸서 표기했다. 또한 게임의 명칭, 디자이너를 비롯한 사람이름, 회사명에 대해서는 한글로 표기하고 처음 나왔을 때 알파벳표기로 병기(倂記)하였다.

역주
하이퍼텍스트(Hypertext)
- 여기서 말하는 '하이퍼 텍스트'라는 것은 독자의 선택에 의해 플롯이나 결말이 변하는 인터랙티브 소설을 말한다. 이른바 '어드벤처 게임 북'도 그 일종.

정치적으로 올바른(Politically Collect)
- 1980년대부터 미국에서 시작된 '차별이나 편견에 기반한 표현이나, 소수민족에게 불쾌감을 주는 표현을 규제하자'는 운동에 따른 표현 혹은 발언을 가리킨다.

모탈 컴뱃(Mortal Kombat)
- 잔혹한 살육을 즐기는 컴퓨터 게임

Tokyo Rose
- Tokyo Rose란 제 2차 세계대전 당시, NHK의 대미선전방송을 담당한 일본계 2세 여성에게 미국 병사들이 붙여준 닉네임.

제로섬형(ZeroSum)
- '제로 섬형'게임이란, 본래 '누군가가 득을 보면, 그만큼 다른 사람이 손해를 보는' 타입의 게임을 가리킨다. 여기서는 '어떤 의사결정에 대해서도, 득을 보는 것은 한 명뿐이며, 상호 이익이라고 하는 요소가 없는' 게임을 말한다.

인터렉티브 TV(Interactive TV)
- '인터랙티브 TV'란 케이블 TV에 양방향성을 갖게 하여, 시청자가 프로그램 내용이나 화면 구성을 조작할 수 있게 만들거나, 쇼핑이나 소프트웨어 판매 등의 새로운 서비스를 가능케 하는 계획을 말한다.

카틀 브라(Quatre Bras)
- '카틀 브라'는 워털루 전투의 전초전이 치러졌던 장소

MUD(Multi-User Dungeon)
- 인터넷상의 서버에서 실행되는 다수참가형 게임 프로그램. 무대는 '로그'처럼 텍스트 그래픽으로 표시되며, 상황은 '조크'처럼 텍스트로 표시된다. 여기서 복수의 플레이어가 상호간에 채팅(온라인 대화)하면서 전투를 벌인다.

원출처 : I have no word & I must Design( http://www.teatime.org/article/noword.html )
1차출처 : Flaming Nairrti Astray II( http://nairrti.com/27 )
:
출처 : Pig-Min : Post Indie Gaming( http://pig-min.com )


금 번 Pig-Min에서는, [다이너 대시(Diner Dash)] 등의 게임으로 유명한 미국 뉴욕 게임회사 게임랩(Gamelab)의 창립자(Founder) 이승택(Peter Lee)씨를 이메일 인터뷰했습니다. 이름에서 아실 수 있듯 이 분은 '한국인'이고, 이 인터뷰도 '번역'이 아닌 '한국어로 작성'되었습니다. 최근 한국에 오셔서 강연을 하신 적도 있고, 여러가지 작업을 병행해 진행하는 대단한 분입니다.

Pig-Min 담당자 입장에서 말씀드리자면... 이 인터뷰에 굉장한 의견 / 사실 / 진행사항 등이 넘쳐흘러, 거의 무릎을 꿇고 눈물을 흘려야 할 지경입니다. 그래서 중요하다 여겨지는 부분은 굵은 글씨 처리를 했고, 올린 후에도 몇 번 더 강조를 위한 편집을 할 생각입니다. 이건 정말로 여러 분야의 분들이 모두 읽어야 할 인터뷰니, 절대 놓치지 말고 단어 하나 하나 모두 신경 써 읽으시길.

현재 이승택님은 대표 역할을 전문 경영인에게 맡기고, 디렉터 오브 플레이어 익스피어리언스(
Director of Player Experience)라는 다소 생소한 직책을 맡고 계십니다. 그게 뭔지에 대한 설명은 원래 인터뷰 내용 안에 넣어야겠지만, 따로 빼 여기에 쓰도록 하죠.

제가 만들어 낸 직함이라 번역이 있는지는 모르겠네요.

저희 회사는 특정 부서나 업무분야의 장들이 Director라는 직함을 쓰고있습니다.

저는 가장 간단히 게임을 이론적으로 소개 할 때에 게임은 Rule과 Play라는 두가지로 이루어져있다고 설명합니다. 게임디자인 작업도 Rule등 수치, 논리적인 분에 중점을 둔 레벨 디자인적인 작업과, 그것을 플레이 하면서 플레이어가 어떤 느낌을 갖게되는가 하는 측면의 두가지가 있습니다.

제가 맡은 Play Experience라는 부분은 개발 과정에서 PLAY의 느낌을 잘 만들도록 힘쓰는 역할 되겠습니다.

바쁘신 와중에도 훌륭한 답변 보내주신, 이승택님께 다시 한 번 감사의 말씀 드립니다.

사용자 삽입 이미지
새로운 역사의 시작 [다이너 대시].



1. 미국 등의 서양 게임 회사에 취업해있는 한국인은 여러분 계신걸로 알고 있지만, 인디 게임 / 캐주얼 게임 회사의 대표까지 하고계신 분은 이승택(Peter Lee)님이 유일할듯 싶은데요. 한국인으로써 미국 게임 시장에서 일하신다는 것, 그리고 뻗어나가는 회사의 공동 창립자가 된다는 것은 어떠한지 알려주실 수 있으신지요?

좋아 하는 일을 찾아 다니다 보니 여기까지 오게 되었습니다.

게 임랩은 직장 생활을 하던 1999년도에, 현재 공동 창립자인 Eric Zimmerman과 함께 주말 - 밤등 여가 시간을 이용해 개발한 퍼즐 게임인 BLiX에서 시작되었습니다. 7개월 정도만에 개발을 끝낸후에 게임 공모전이란 것이 없었기 때문에, 여러가지 디자인 공모전에 Multimedia 분야에 공모했고, 몇가지 상을 타게되었습니다. 그러던 중 마침 2000년 Game Developers Conference 에서 제1회 Independent Game Festival이 시작되어서 공모했고, 최종 후보 열팀에 올랐습니다. BLiX는 Sound부분에서 시상을 했습니다. 이를 계기로 BLiX가 Shockwave.com이라는 포탈사이트에 판매되었고, 그로 인해 생긴 수입으로 2000년 9월에 뉴욕 다운타운에 세명의 직원을 시작으로, 5명이서 게임랩 사무실을 열었습니다.

닷캄버블등의 대형 투자의 폐해를 보아왔기 때문에 회사를 천천히 그러나 탄탄하게 성장시키자는 방향으로 결정을 했고, 지난 7년간 외부 투자 없이 꾸준한 활동으로 게임랩을 알려가며 Organic하게 성장해 왔습니다. 지난 5월 말에는 사무실 여러개를 연결해서 있던 7년간 정들었던 다운타운의 사무실을 정리하고, 미드타운쪽으로 회사를 이전했습니다. 외부 투자 없이 운영하는 것이 여러 가지로 힘들긴 했지만, 7년을 꾸려왔고 꾸준히 성장을 해왔다는 부분은 스스로 자랑스럽게 생각하는 부분입니다.

사실 게임랩은 창업주 둘의 전공이 Design과 Fine Art인지라 경영에 대한 지식이 없던 탓에, 처음에는 실수도 많이 있었지만 일을 해가면서 많이 배웠습니다. (Pig-Min 주 : Fine Art는 조소나 회화 등의 '순수 예술'을 뜻한다고 합니다.)

게 임랩은 미국 경기등 외부적인 요소로 여러가지 고비도 많았습니다. 회사 설립 6개월 만에 인터넷 버블이 꺼지면서 시작된 미국 경기 침체, 그리고 911 사태로 인한 경기 침체와, 게임랩 사무실이 사고 현장에서 5분 거리이던 탓에 2개월간 사무실에 갈 수도 없었고, 그 이후에도 전화와 인터넷이 8개월 이상 복구가 안되는 등, 여러 가지 일들이 있었습니다. 하지만 이런 어렵던 시기에도 저희는 계속 게임일만을 고집해 왔습니다.

사실 회사 설립 이전에 디자인 회사등에서 일하면서, 많은 회사들이 실제는 게임이나 에니메이션 일을 하고 싶어 하지만 수입을 위해 웹디자인이나 광고 등의 일을 하는 것을 봐왔습니다. 그 때 배운것은 지금 하고 싶은 일을 하지 않으면 결국 돈벌어서 나중에 라는 것은 없다는 거였습니다. 돈을 벌게 되면 계속 돈 벌이 되는 일에 매달리게 되는 것이죠. 영어 표현에 You are what you eat.이라는 표현이 있습니다. 웹사이트 디자인을 하면 웹디자이너지 게임개발자는 될수 없는 것이죠. 작은 작업을 해도 '게임개발자는 게임을 만들어 포트폴리오를 늘려야 게임 개발자'라 는 단순한 생각으로 일해 온것이 회사 유지와 발전에 도움이 많이 되었습니다. 또 일반 개발사들이 특정 게임 개발을 목적으로 시작하는 것과는 달리, 게임이라는 새로운 매체의 가능성이라는 좀더 광범위한 회사의 비젼이, 회사의 성장과 홍보 - 우수 인력을 확보하는 것에도 많은 도움이 되었던것 같습니다.  
 

2. 이승택 님은 미국에서 일하시면서도, 영어 이름인 Peter Lee와 한국 이름인 Seung Taek Lee를 같이 사용하시고, '한국인'이라는 사실을 다른 곳의 인터뷰 등에서도 정확하게 밝히고 계십니다. '한국인'으로써 미국 게임 시장에서 살아가신다는 것에 대해, 또한 그에 관련해 품고 있으신 생각과 관련된 에피소드에 대해 알려주실 수 있으신지요?

꼭 한국인임을 밝히는 이유는 제가 한국인이기 때문이라는 간단한 이유입니다. 결국 미국에서 미국인들과 함께 일하고 경쟁할때, 저는 한국인일수 밖에 없으니까요. 뭐 감출수 있는 것도 아니고, 이왕이면 한국 사람도 잘 한다. 미국인들에게 일본인이나 중국인이 아닌 한국인도 크리에이티브한 일을 한다. 이런 것을 알리고 싶기도 했구요.

사실 미국에서 크리에이티브한 분야 일을 하시는 한국분들이 상당히 많이 계십니다. 저는 한국에서 고등학교를 졸업하고 미국으로 유학을 와서 학부와 대학원 과정을 공부했고, 시민권자인 아내와 결혼 그리고 직장을 뉴욕에 구해서 유학생에서 이민자가 되었습니다. 백인 사회인 미국에서 소수민족이라는 것은 여러 가지 어려움이 있습니다만, 다행히 저는 여러가지로 운이 좋았던것 같습니다. 예를 들면 뉴욕이라는 다민족 거주 지역 - 인터넷 - 뉴 미디어 - 게임 분야라는 오픈 마인드의 사람들이 나름대로 많은 분야, 또 실력으로 많이 승부할수 있는 분야, 비교적 젊을때에 와서 문화적 언어적 적응이 쉬웠다는 점 등...

현 재 쓰고 있는 Peter라는 이름은 세례명인 베드로입니다. 교포였던 사촌이 미국 이름이 있어야 한다는 말에 아무 생각없이 쓰기 시작한 이름이었는데, 아마도 제 한국 이름 '이승택' 이 외국인이 발음 하기에는 힘들기 때문에 추천했던것 같습니다. 초기부터 그 이름을 쓴 탓에, 다른 한인 분들은 유학생 시절에도 저를 교포라고 생각 하셨던것 같습니다.  대학교를 다니면서 친하게 지내던 미국인 친구들이 '너는 한국인이니 발음이 어려워도 꼭 한국이름을 불러야 겠다.'고 해서 섞어서 쓰기도 했습니다. 이 때 상당한 갈등이 있었습니다. 이민 2세들이 겪는다던 정체성의 혼란의 경험을 저도 조금은 겪어야 했습니다. 현재는 사업상의 이유로 Peter라는 이름을 일반적으로 쓰고 있습니다. 이승택이라는 미국인들이 발음하기 힘든 이름보다는 한번 들으면 기억하는 이름이 사람을 많이 만나는 일에는 유리하다는 생각을 했습니다.

미국 생활을 하면서 느낀 것 중 하나는 사람 사는 곳은 다 똑같다는 것입니다. 정도의 차이는 있지만 한국에서 있는 문제들이 미국에도 있고, 인맥의 중요함은 세계어디든 마찬가지 인것 같구요. (여기서 인맥은 한국에서 흔히 이야기하는 학연 - 지연이나 줄 잘서기를 말하는 것이 아닙니다. 일이란것은 결국 혼자서 할 수 있는 것이 아니기 때문에 많은 사람을 알아야 한다는 의미입니다.)  미국 사람들의 단점이자 장점인 것 중 하나는 미국 사람은 자기 보다 못 하다고 생각되면 아주 무시한다는 것입니다. 하지만, 그 대신 자기보다 실력이 있다고 생각되면 확실하게 접어 주고 대우해 준다는 것입니다.


3. 게임랩(Gamelab)은 외부의 투자가 없는 독립적인 개발사지만, 각 게임을 만들때마다 펀딩을 받는다고 알고 있습니다. 기존에는 주로 퍼블리셔(Publisher)쪽에서 받으셨지만, 이번 신작 [아웃 오브 마인드(Out of mind)]의 경우 그런 관행을 벗어나 인디 영화를 제작하는 큐리어스 픽쳐스(Curious Pictures)에서 받으셨다고 들었는데요. 캐주얼 게임을 만들며 펀딩을 받는 것, 그리고 기존 게임들과는 다른 방식의 펀딩을 받는 것에 대해 간단히 설명해주실 수 있으신지요?

외부 투자자가 없이 회사를 운영하는 것의 가장 힘든 어려움은 제한된 펀드입니다. 벤처펀드등을 통해 조금 여유롭게 회사를 꾸려 갈수도 있지만,  게임랩은 그 비전과 회사의 컬춰를 유지하는 것을 가장 중요하게 생각했기 때문에 회사에 외부 투자 없이 운영되고 있습니다. 외부투자의 거부는 아니고, 그저 아직까지는 비전이 맞는 파트너를 찾지 못한듯 합니다.

미국 게임 개발사들의 어려움중 하나는, 펀딩 방식이 개발과 배급을 주관하는 퍼블리셔 펀딩이라는 한가지만 존재한다는 겁니다. 펀딩 방법이 한가지라는 것은 개발사가 계약에서 얻을수 있는 IP - 라이센스 - 수익 조건이나, 어떤 게임을 제작 할 수 있는가 하는 여러 가지 면에서 제한을 줍니다.  다양한 펀딩 방법을 통해 개발사의 선택권을 늘려야 한다는 것이 그 목적의 하나였습니다.

그리고 개발사에게 회사 운영에 장기적으로 가장 중요한 개발한 게임의 IP와 라이센스 유지에 있습니다. 퍼블리셔와의 계약으로 개발 펀딩을 받게 되면 기존의 계약 전례에 따르기 때문에, 기존의 조건 이외 것을 기대하기는 어렵습니다. 그런 제한을 풀어 보기 위해서 영화 제작에서 사용하는 프로젝트 베이스 펀딩을 시작한 것입니다. 전혀 전래가 없는 방식이었기 때문에 많은 어려움이 있었습니다만 현재 두개의 게임을 펀딩했고, 계속 퍼블리셔 펀딩과 병행 할 생각입니다.

프 로젝트 방식으로 펀드된 게임중 하나는 현재 출시된 큐리어스 픽처스와 파트너 쉽으로 개발한 [아웃 오브 유어 마인드 (Out of Your mind)]이고, 다른 한가지는 개인 투자자의 펀딩으로 현재 개발의 마무리 단계중인 [미스 매니지먼트(Miss Management)] 라는 게임입니다. 이 두 게임은 게임랩쪽에서 배급 등에 전체적 컨트롤을 가지고 있습니다.

큐리어스 쪽과의 협력은 에니메이션 - 장난감 등, 큐리어스가 기반이 되고 관심이 있는 시장쪽도 진출하기 위해, 게임 제작시 다른 매체로의 캐릭터와 스토리의 확장이 가능하도록 많이 신경써서 제작 했습니다. 

앞으로도 계속 자체 펀딩이나 좀더 다양한 펀딩을 찾는 방향으로 진행할 예정입니다.


4. [다이너 대시(Diner Dash)]는 아주 성공적인 게임으로써, 시리즈가 3개까지 나왔고 심지어 NDS로도 이식되어 발매될 예정입니다. [다이너 대시] 제작에 관련된 에피소드, 고객이나 언론 등에서 받은 긍정적인 반응, 그리고 NDS 진출에 관련된 사항을 간단히 알려주실 수 있으신지요?

다이너 대시는 캐주얼 다운로더블 게임 마켓에 게임랩이 발을 들이면서 첫번째로 제작한 게임으로, 아주 큰 성공을 거두었습니다. 덕분에 게임랩이 기존의 Agency와 병행하던 비지니스 방식에서, Original 게임 제작만의 순수 개발사로 변하는데 도움을 주었습니다. 게임의 인기도는 저희가  우연히 게임과 관련되지 않은 사석에서 만나는 많은 사람들이 다이너대시의 팬인것을 알면서 몸으로 느끼게 되었습니다. 다이너 대시를 소개해준 덕분에 여자친구도 게이머가 되어서 고맙다는 게이머의 감사를 받기도 했습니다.

마켓 성공 이외에도 다이너대시는 케주얼 게임 시장의 변화에 많은 영향을 주었습니다. 다이너대시 이전에는 POPCAP사의 Bejeweled류의 Abstract Puzzle Game이나 카드 게임등이 전체 케주얼 게임 시장을 차지해 왔습니다. 다이너대시의 성공으로 Time management 게임이 한 분야로 자리잡았습니다. 새로운 게임들이 많이 제작되면서, 캐주얼 게임 시장은 여성 리드 캐릭터를 등장시키는 캐릭터 중심과 스토리를 어느정도 가진 게임들로 변화되었습니다.

그리고 기존 게임들에 존재하던 여성 캐릭터가 강인하고 섹시한 여성상이었던것에 반해, 강하고 사회적 능력이 있는 모던한 여성 캐릭터의 등장, 단순하지만 게임 캐릭터들의 감정상태로 게임 상태를 알려주는 시스템등을 통해 사람의 감정을 잘 표현한 게임등으로 언론에서 주목을 받았습니다.

다이너 대시 씨리즈와 NDS 버젼 개발은 직접 하지 않고, 게임디자인 컨설팅 역할만 했습니다.

미국 캐주얼 게임 시장의 장점은, 캐주얼 다운로드 게임 시장이 대중을 위한 게임의 테스트의 장으로 인식되고 있기 때문에, 시장의 히트 작품이 다른 모든 플랫폼으로 넘어가기에 아주 쉽다는데 있습니다. 게임랩이 직접 제작한 다른 게임들도 NDS와 Xbox Live등에 포팅하는 것과 NDS용 오리지널 게임을 만드는 것도 알아보고 있습니다.


5. 게임랩은 단순한 캐주얼 게임 회사가 아니라, 그 외에도 비영리 활동 / 방과후 활동(After school program)에 관련된 일도 하고 계시다 들었습니다. 그에 관해 간단히 설명해주실 수 있으신지요?

게임랩은 일반적으로 게임 개발사들이 특정 게임 개발을 위해 펀드를 받아 회사를 시작하는 것과는 달리, 새로운 매체로서의 게임의 가능성에 흥미를 갖고 그 가능성을 Explore 해 보기 위해서 시작한 회사입니다. 그 일환으로 상업 제품이 갖는 제한을 벗어나기 위해서, 일반적 상업용 게임의 제작 이외에도 여러가지 환경에서 활동을 하고 있습니다.

물론 회사 유지에 중요한 주 수익원은 케주얼 게임 시장용 게임 개발입니다만, 그 이외에 미 술관 전시 작품으로의 게임 제작, 비영리 단체와 함께 사회 문제를 다루는 게임의 제작, 고등학생등 학생들을 상대로한 교육 프로그램, 학사 - 석사 과정에서 게임 개발과 게임 디자인 이론에 관한 강의, 게임 디자인 관련 책과 기타 저술 활동 등을 하면서, 게임의 가능성에 대해 이론적 - 실천적인 여러가지에 힘을 쓰고 있습니다.

작년 5월에 부터 미국 맥아더 재단에서  펀드를 받은 프로그램은, 미래에 필요한 중요한 Media Literacy의 한부분으로 게임플레이를 통해 Game Design을 가르치는 게임을 제작 하고 있습니다. 펀드의 규모는 미국의 재단에서 게임쪽으로 나온 펀드로는 그 규모가 가장 크다고 할 수 있습니다. 의미있는 것은 게임이 단순한 오락물로의 이미지에서 벗어나, 매체로써 갖는 긍정적인 역할에 사회적인 관심과 이해가 생기기 시작했다는 것입니다.

작년에 Global Kids라는 비영리 단체와 협력해 제작한 Ayiti(하이티)라는 게임은 경제적인 빈곤이 인간의 권리인 기본 교육에 주는 어려움에 대해 다룬 게임으로, Games for Change 게임으로  많은 주목을 받았고, 2007년 Games For Change Festival에서 Best Awareness-Raising Game 으로 뽑혔습니다.

매체로서 더 많은 가능성을 찾아보고 활발한 활동을 하기 위해, Gaming Literacy를 핵심으로 한 Gamelab Institute of Play라는 비영리 자매 회사를 올초 설립했습니다. 여기서 한가지 설명드리고 싶은 것은, 저희가 이야기 하는 유익한 게임이라는 것은 에듀테인먼트류의 게임의 형식을 한 교육 매체가 아니라 게임 자체가 가지고 있는 교육적이고 유익한 부분을 게임 그 자체를 통해 전달 한다는 것입니다. 여러 가지 프로젝트를 준비 중인데, 우선적으로 준비하는 프로젝트는 2009년 가을을 목표로 뉴욕에 게임 테마 중-고등학교의 설립입니다. 현재 미국도 주입식 암기식 위주의 교육 방식으로 변화하면서 많은 문제가 발생하고 있습니다. 저희가 준비하는 학교는 게임 개발을 가르치는 학교가 아니라, 게임 디자인을 통해 학습 효과를 늘려 좀더 창의적인 교육을 하는 학교를 만들자는 것이죠.

이런 다양한 활동 덕분에 게임랩은 단순한 케주얼 게임 회사가 아닌 독특하고 미래지향적인 Game Design회사로 자리를 잡고 있습니다. 가 끔 제가 한국을 찾아 한국분들과 이야기를 나누다 보면, '그거 돈은 안되겠네요. 돈은 못벌겠어요...' 라는 말을 많이 들었습니다.  한국 특유의 지금 당장 빨리 뭘 하라는 문화적 차이라 생각합니다. 물론 직접적으로는 연관이 없어 보이기도 하겠지만, 이런 다양한 활동이 타회사와 차별화 시키고 독립적으로 꾸준히 성장하며 현재의 지명도를 쌓는데 도움이 많이 되었으니, 좋은 투자였다고 생각합니다.


6. [다이너 대시]는 한국에서도 어느정도 유명하지만, 아직 게임랩의 다른 게임까지는 잘 알지 못하는 분들이 많습니다. 자사의 게임 중 권해주실만한 작품 3 - 5개 정도 꼽아주시고 간단한 설명 부탁드립니다.

다이너대시가 2005년 출시되면서 케주얼 다운로드 게임의 개발을 시작했고, 그 이전에는 주로 웹게임을 개발했습니다.

[플랜타시아(Plantasia)]
- 다이너대시 다음에 출시된 게임입니다. PlayFirst가 퍼블리싱했습니다. Gardening Action Sim 게임으로 핸드페인팅한 배경과 두남녀의 로맨스 스토리를 케주얼 게임의 소재로 삼은것이 독특하다 하겠습니다.

[숍마니아(Shopmania)]
- 소비주의를 풍자하는 내용을 소재로 삼은 퍼즐게임입니다. iWin이 퍼블리싱을 했습니다. 단순하지만 여러 가지 전략을 세울수 있어서 게이머들의 취향에도 맞는 게임입니다. 

[레고 페버(Lego Fever)]
- 올해가 레고 창사 50주년이 되는 해였습니다. 그래서 아동뿐아니라 성인층에게 향수를 불러 일으키는 레고 게임을 만들자는 취지로 개발되었습니다. 레고와 합작으로 게임랩에서 직접 퍼블리싱했습니다. 블루스브라더스풍의 스토리를 가지고 있고 3가지 각각 다른 게임 모드를 섞어서 진행하는 형식으로 구성되어 있습니다.

[미스 매니지먼트(Miss Management)]
- 한달 정도 후면 포탈사이트에 출시됩니다. 오피스를 배경으로 한 롤플레잉 게임을 만들면 재미있겠다는 아이디어에서 시작되었습니다. 시트콤 스타일의 스토리와 게임 구성에 익숙한 Time Management게임을 Goal중심의 Mission구조 형식으로 만들었습니다. 컷신이 아주 재미있는데 미국 유머라 한국분들께서 즐기실지는 잘 모르겠네요. 올해의 기대작입니다. (좀 두렵긴하지만, 리뷰버전을 곧 보내드리겠습니다 ^^)   

좀 오래되었지만 아직도 인기있는 웹게임으로는 레고사의 의뢰로 만들어진 LEGO World Builder, LEGO Junkbot, LEGO Spybotics등을 레고 웹사이트에서 즐기실수 있습니다.

혹시 미국 게임 개발자 회의에 오시는 분들은 매년 저희가 컨퍼런스용으로 제작하는 수천명이 동시에 하는 Non-Digital 보드게임, 카드게임등도 즐기실수 있겠습니다.


7. 미국을 중심으로 한 서양의 인디 게임 / 캐주얼 게임 시장에 대해 어떻게 생각하시는지요? 또한 그런 부분이 한국에 적용된다면 어찌 될지에 대한 고견도 부탁드립니다.

두가지 질문일것 같습니다.

우선 인디 게임의 정의를 내리는 데 여러가지 방법이 있지만, 일반적으로 생각하시는 인디 영화의 개념으로 말씀드리려 합니다. 서양에서 인디 게임 문화는 사람들의 취미 생활에서 갓 벗어나기 시작한 초기 단계입니다. 물론 개인적으로 뛰어난 분들이 있어서 대형 업체들의 펀딩을 받아 주류로 넘어가기도 하지만, 기본적으로는 개인의 취미 이상의 인디 게임 마켓의 유지를 위한 구체적 펀딩 모델과 게임 제작 이 후에 단계에 대한 구조적인 해결책들이 없습니다. 가장 시급한 것은 1970년대 80년대를 통해 여러 가지 Festival등으로 미국에서 자리 잡은 인디 영화 문화와 시장구조가, 게임분야에도 빨리 형성되어야 한다는 것입니다. 이를 통해서 도전적이고 실험적인 새로운 작업들이 많이 제작될 것이고, 또 그 제작자들이 자연스럽게 주류 게임 시장에 진출하면서 신선한 변화를 몰고 오리라 생각합니다.

캐주얼 게임 시장은, 미국과 한국에서 어떤 것이 캐주얼 게임이냐 라는 기본 개념부터 차이가 있는것 같습니다. 한국에서는 시간적 개념의 빨리 단시간에도 즐길수 있는 게임으로, 한국의 대다수 캐주얼 게임은 미국에서 보면 하드코어 게임입니다. 미국에서의 캐주얼 게임은 그 마켓이라든가 플레이 방식등에서, 하드코어 게임과는 확연한 차이가 있습니다.

현 재 미국 캐주얼 게임 시장은 마켓의 다양화와 확장으로 계속 성장하고 있습니다만, 그 시장 구조는 현재 거대 포탈에 유리한 형식으로 되어있어서 개발자들에게는 불리한 상황이라 변화가 필요합니다. 이런 기본 구조는 다운로드해서 물건을 구입하는 형식이기 때문에, 불법복제가 일반화된 한국에서는 불가능하다고 생각합니다. 현재 미국에 출시된 캐주얼게임의 크랙버전이 몇주 안에 한국 사이트에 뜨는 것으로 알고 있습니다. 아마도 추후에 온라인 게임의 형식으로 변화되면 달라지겠죠. 

한국은 기본적으로 시장의 구별이 거의 없는 단일화된 시장이라 미국과는 접근 방법이 다르리라 생각합니다만, 이미 짧은 시간에도 즐길수 있는 게임의 개념과 그런 상품들이 한국 시장의 큰 부분을 차지하는 것으로 알고 있습니다..
 

8. 현재의 한국 게임 혹은 한국 게임 시장에 대한 개인적인 생각 내지 의견을 알려주실 수 있습니까?

한국의 MMOG 게임들로 인해 최고의 기술과 최고의 시장으로 세계적으로 그 입지가 확고해 졌다고 할 수 있습니다. 해외에 거주하는 한국인으로써 아주 자랑스럽습니다. 

한국의 많은 캐주얼 - 하드코어 멀티 플레이어 게임들이, 기존에 인기가 확인된 게임 방식들에 멀티 플레이어 방식이라는 새로운 것을 접목시켜, 세계 어느 나라보다 빠르게 시장을 형성하고 성장했습니다. 이제는 일본과 미국에서 시장에 뛰어들고 있습니다. 이미 지명도가 많은 게임들을 개발했고, 기획력에서 앞서가는 그들의 도전을 해오고 있습니다. 이제는 '우리 것은 멀티플레이어니까'라는 것만으로는 지속적인 경쟁력을 유지하기가 힘들듯 합니다.

제 가 만나본 게임 관련 종사자분들은, 새로운 게임 기획을 가장 힘든 부분이라 말씀하시더군요. 멀티플레이어 게임 개발에 관련된 서버관련 기술력과 운영 노하우 뿐이 아닌, 새로운 게임 기획력의 개발로 새로운 게임을 만들어야만, 국제적 경쟁력도 생기고 지속적으로 새시장을 확대해 나가고 성장 할 수 있으리라 합니다.

한국에 세계적으로 앞서가고 있는 분야에서 그 리더의 위치를 계속 유지할수 있었으면 하는 바람입니다.


9. 다른 회사에서 나온 권해주실만한 인디 게임 꼽아주시고, 그에 관련된 간단한 설명 부탁드립니다.

[스냅샷 어드벤쳐스 : 시크릿 오브 버드 아일랜드(Snapshot Adventures: Secret of Bird Island)]
- 최근 출시된 뉴욕에 있는 케주얼 게임 개발사인 Large Animal Games의 게임입니다.

[슬레이(Slay)]
- 보드 게임 스타일의 작은 게임을 만드는 개인 개발자가 만든 오래된 게임입니다. 중독성이 아주 강합니다. 간단한 리소스 메니지를 통한 땅따먹기 전략 게임입니다.

[문베이스 코맨더(Moonbase Commander)]
- 출시된지 상당히 오래된 퍼즐같은 느낌의 턴베이스 RTS입니다. 인포그램에서 퍼블리싱 했음에도 거의 마이너제품처럼 마케팅되었지만, 나름의 팬들을 유지하고 있습니다. 스타크래프트 처럼 네트워크 게임이 가능합니다.  

[크레용 피직스(Crayon Physics)]
- 그림을 그려서 물리 퍼즐을 풀어나가는 게임입니다. http://www.kloonigames.com/blog/games/crayon/

이 주소에서 찾을 수 있는 여러가지 굉장한 슈팅 게임들.


10. 끝으로 이 인터뷰를 읽어주신 Pig-Min 방문자들께 한 말씀 부탁드립니다.

게 임은 매체로서의 가능성이 무한하다고 생각합니다. 여러분들 모두가 그런 생각으로 작업들을 하시고 또 흥미로운 작업을 널리 소개하시면, 게임의 앞날은 밝다고 생각합니다. 게임들 즐겨주세요. 그리고 게임을 통해서 행복해지셨으면 합니다.



출처 : Pig-Min : Post Indie Gaming( http://pig-min.com )

:
출처 : 욱이의 자유생각( http://www.freethink.co.kr/entry/일본-게임-유저의-온라인게임을-보는-시각 )


일본에 아는 지인으로부터 들은 일본 게임 유저들의 온라인 게임을 보는 시각을 정리해 봤다.
다들 참고 하시면 좋을 듯 하네요..

가. 일본게임유저들의 게임에 대한 인식
1. 이미지가 좋다.
-> 2D일러스트 및 캐릭터가 좋다. (게임 내 캐릭터가 아님..광고용 일러스트가 이뻐야 게임을 함.)

2. 그래픽이 좋다.
-> 배경 조화랑 잘 움직여서 자연스럽다. (바람이 불 때, 나뭇잎이 살랑살랑 움직이는 것)

 3. 사운드가 좋다.
-> BGM이 좋다. (절대 타격 감 아님)

 4. 아무것도 모른다.
-> 게임 및 컴퓨터에 대한 기본지식이 전혀 없다.
    예) 게임에 접속해서 캐릭터가 나오자 마자 강제적인 설명, 이렇게 해라 저렇게 해라. 혼자서 계속 할 수 있도록 해야 함. 아무리 설명해도 모자르다.

* 결제는 웹에서 아이템은 게임 내에서 구매하는 방식이 좋다.

 
나. 국내 온라인 게임의 일본 진출 성공 사례
1. 붉은보석
: 일본에서 붉은보석이 성공한 이유 중에 게임에 대한 설명이 게임 내에서 잘 되어 있다.보통 게임 내에서 ? or ! 등이 깜박거리면, 일본 게임 유저의 경우는 그게 어떤것인지도 모르며 그 아이콘이 나타나서 클릭하면 큰일 나는 줄 안다.

2. 리니지2
: 사양이 높은 리니지2가 일본 내에서 성공한 이유 중 하나는 게임 광고를 한 것이 아니고, PC광고를 했다. 이 PC를 사면 리니지2가 된다라는 식의 광고를 3년전부터 시작해서, 1년 6개월 후부터 반응이 있었다고 함. 일본에서는 PC 업그레이드 개념이 없다. 게임기(XBOX360, PS2등)들이 한번 사면 그대로 쓰는 것처럼, 국내처럼 필요할 경우, 부품(그래픽카드, 하드, 램등)을 업그레이드를 하지 않는다.

* 특징 : 일본 게임 유저는 자신이 하려고 하는 행동이나, 기능이 게임 내에서 되지 않으면  그냥 조용히 게임을 접는다.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
관심이 있기 때문에 비판을 하는 거다. 관심이 없는데 왜 누가 자신의 시간을 들여 비판을 하겠는가.
국내는 그래도 유저들이 반응을 보이기 때문에 대처가 가능한 것 같다. 유저의 말에 어느정도는 귀을
기울려라.

출처 : 욱이의 자유생각( http://www.freethink.co.kr/entry/일본-게임-유저의-온라인게임을-보는-시각 )
:
■ DS 市場は 淘汰の フェーズへ
■ 사설: DS 시장은 도태의 국면으로?

이번 봄부터 시장의 변화가 표면화 되었습니다.

하나는, 전격 온라인 마케팅실 이 분석하고 있듯이,
3월 이후의 DS 신작 소프트의 매장 소화율이 악화되고 있는 것입니다.

-------------------------------------------------------------------------
3월 이후에 발매된 DS 신작의 매장 소화가 대체로 향상되지 않고 있어, 유통 재고가 증가하는 경향이 있습니다.

금년에 들어와서 발매된 신작 (DS)의 발매된 주의 소화 상황을 월별로 보면,

1월기는 첫주 소화율이 30% 에 이르지 않은 신작이 10개 중 1개 (구성비 10%) 밖에 없었습니다.
그것이, 2월기에는 17개 중 8개 (47%)로 증가,
3월기에는 57개 중 36개 (63%)로 전체의 6할 이상으로 증가.

4월기와 이번주 말 시점에서 17개의 신작이 발매되었습니다만,
그 중 11개 (65%)는 발매된 주의 소화율이 30% 에 이르고 있을뿐입니다.  - 전격 온라인 마케팅실 인용
----------------------------------------------------------------------------

忍之閻魔帳 에서도 DS 신작 소프트의 매상이 악화되고 있다고 말하고 있습니다.

----------------------------------------------------------------------------
4월 26일 발매된 DS 신작 21 타이틀 중 반수 이상에 해당하는 13 타이틀이
판매수 세 자리수 이하로 격침율이 매우 높은 것이 신경이 쓰인다.

지난 주말에는 이러한 신작을 이미 상품 진열대에 늘어놓은 양판점도 있어,

DS 버블에도 드디어 도태의 물결이 밀려 들고 있는 것 같다.  - 忍之閻魔帳 인용
-----------------------------------------------------------------------------

DS 의 판매 대수는 매주 10만대 이상으로 판매되고 있기 때문에,
시장의 활기는 아직 지속되고 있다고 봐도 좋을 것입니다.

그러나 DS 경기가 활성화되고, 타이틀 수가 증가하고 있기 때문에,
신규 타이틀로의 주목이 분산되어, 사실 매상이 무디어지고 있습니다.

또 실용 소프트는 장기적으로 팔리는 경향이 있기때문에, 매장 선반의 어디에 신작을 두어,
롱런 작품을 만드는가 하는 고민도 있습니다.

모두가 DS 에 모여 있다고 말할 수 있는 상황으로, 어떻게 유저의 관심을 모을까.

소프트 메이커 각사의 매장 판촉, 패키지의 차별화가 보다 중요성을 더하고 있습니다.

■ 속편이 팔리지 않는 실용 소프트

한가지 문제는 닌텐도의 터치 제너레이션계 타이틀의 속편의 판매가 좋지 않은 일입니다.

실제 판매량 160만개 이상의 「영어 단련」, 60만개 이상의 「아소비 대전」,
140만개 이상의 「유연한 머리학원」의 속편이 모두 저조한 스타트를 끊고 있습니다.

원래 긴 기간에 걸쳐서 팔리는 타이틀이지만, 누계 판매량이 크고, 인지도 높은 타이틀의 속편이,
첫주 매상으로 전작을 밑돌고 있는 것은 쇼킹한 사태입니다.

「 좀 더 영어 단련」는 발매로부터 1개월이 지났어도, 전작의 첫주 판매량에 닿지 않고 있습니다.
판매 곡선을 그려 보면, 분명하게 전작을 밑도는 꺾인 선 그래프를 그릴 것입니다.

-------------------------------------------------------
★ 첫주 판매량
 
영어 단련             -  23만 1,000개  
좀 더 영어 단련       -   5만개  
아소비 대전           -   6만 5,000개  
Wi-Fi대응 아소비 대전 -   1만개 이하  
유연한 머리학원       -   5만 2,000개  
Wii로 유연한 머리학원 -   4만개  
--------------------------------------------------------

게임 업계에서 전통적으로 속편이 많은 것은, 어느 정도의 매상을 전망할 수 있기 때문입니다.

상승세의 시리즈라면, 전작 대비 2할 증대, FAN이 붙어 있다면 전작과 동수,
넘버를 거듭해 질리게 되면 전작 대비 3할 감소 로 숫자를 예측 하기 쉽습니다.
전작의 6할이라면, 그 시리즈는 쇠퇴했다고 말해져도 이상하지 않은 세계입니다.


물론 실용 소프트는 롱런하여 팔리는 경향이 있습니다.
위의 3 타이틀의, 누계 매상은 첫주 매상의 수배, 수십배에 이르겠지요.
그러나 누계 매상이, 전작의 반에 이른다는 것은 도저히 생각되지 않습니다.

그래도 팔리잖아 라고 낙관론을 펴는 것은 가능하겠지요.

그러나 유통 재고가 급증해, 타이틀이 시장에 넘치고 있는 상황에서,
작은 징조를 놓치는 것은 정말 위험한 자세 입니다.

팔리면 얕잡아 보고, 대량으로 재고를 안으면, 장기간에 걸쳐서 막대한 유통 재고가 발생해,
유통은 자금융통이 악화. 결국은 시장이 정체해 버립니다.

인간이, 일단 성공 방정식을 찾아내면, 거기에 매달려 버립니다.
방정식이 통하지 않게 되어도, 「아니아니, 지금은 약간의 실수일뿐」 「응. 좀 더 두고 봅시다」
「아니, 이것은 내가 잘못하고 있는게 아니다. xxx가 잘못되고 있어」라고 생각하기 쉽상.


예를 들어 10년전, PS1 버블이 붕괴했을때, SCE는 위험한 징조를 놓치고 있었습니다.

라이트 유저의 지지를 얻어 100만개를 판 「파랏파 더 랩퍼」.
그러나 「움재머 라미」가 팔리지 않았을 때, SCE는 적절한 판단을 내릴 수 있었는가.

이후 「파랏파 더 랩퍼 2」를 냈습니다. 그리고…….

인간은 그 정도로, 한 번 찾아낸 성공 방정식에 매달립니다.

2007년도 벌써 3분의 1이 지났습니다.
언제까지 2006년의 이론을 주창하고 있을건지요? 첫장을 리셋하고 시장을 다시 응시해봅시다.


■ 가벼운 게임의 문제점도 표면화

지금 팔리고 있는 것은, 생활에 방해를 하지 않는 간편한 게임입니다.
소비자의 생활 사이클의 변화에 있던 게임 만들기는 매우 중요합니다.

그러나 한편으로, 가벼운 게임은 작품으로서의 강도가 낮고,
작품 그 자체가 후에 남기 어렵다고 하는 결점도 안고 있습니다.

생각해 보면 당연합니다.

나는 영화를 보고, 소설을 읽고, 어느 작품의 열렬한 팬이 될수는 있습니다만,
참고서나 레시피책을 읽는다고 그렇게 될까요?

게임에서도, 뿌리 깊은 인기를 자랑하는 작품은, 스토리성을 가진 게임이나, 장시간 즐긴 게임입니다.

밤을 새서 즐긴 게임이 강한 인상을 남겨,
그 게임에 대해 타인과 이야기를 주고 받는 것으로 게임의 체험이 보강되어 간다.

이것은 패밀리 컴퓨터 세대의 유저에게는, 익숙한 체험이지요.

---------------------------------------------------------------------------
왠지 모르게 신경이 쓰이고 있는 것은,
「DQ 나 FF 나 마리오나 젤다를 즐기고,
장래에 게임을 만들고 싶다고 하는 아이는 있었다고 생각하는데,

터치 제너레이션을 즐기고, 장래에 게임을 만들고 싶다고 하는 아이는
증가할 것 같지 않다」라고 하는 점입니다.
----------------------------------------------------------------------------

그렇다고 해도, 유저가 시간이 없는 현 상황은 바뀌지 않습니다.

아이들 상대라면, 수십 시간 걸리는 게임을 제공해 진득한 게임 체험을
하게 했으면 좋겠습니다만, 어른들은 그렇게는 살지 않습니다.

DS 에 무거운 게임을 내도, 라이트 유저가 즐겨준다고는 생각되지 않고,
최근에는 매니아조차 즐기는 시간이 한정되어 있습니다.

따라서 DS 의 게임이 원래대로의 게임 디자인으로(예전 매니악한 게임 시절),
다시 돌아갈 것이라고는, 생각되지 않습니다. 시대는 역행하지 않을 것입니다.

가벼운 방향으로 너무 치우치면, 역시 언밸런스합니다.

가벼운 게임의 물결은 지금, 그럼 그 다음은? 이것을 생각하지 않으면 안됩니다.

2006년의 성공 방정식을 염불과 같이 주창하고 있으면 안됩니다.

[ゲームの話]

출처 : 루리웹(ruliweb.com)
:
출처 : 플래시노블 제작팀 Mystic...k ( http://cafe.naver.com/flashnovel )

무엇을 말하고자 하는가?


게임을 개발해보고자 했던 분들은 적어도 한 번쯤 아마추어 게임 개발 활동을 해보았거나 해보려고 마음 먹었을 것입니다. 이 글에서는 후자에 해당하는 게임 개발에 거의 경험이 없는 분들을 대상으로 아마추어 게임 개발이란 무엇인지 알려드리려 합니다.

다만, 필자가 성공적인 프로젝트를 참여하지 못해 게임 개발의 정론을 밝힐 수 없다는 점이 못내 아쉽군요. 그렇지만 2년여의 아마추어 프로젝트 경험 동안 어떤 위험 요소들을 피해야 하는지는 나름대로 익혔다고 자부합니다. 이 글이 모든 장애물들을 알려드리진 못하겠지만, 적어도 처음 아마추어 게임을 개발하려는 분들께는 유익한 도움이 될 것입니다. 그럼, 이어지는 본문부터는 경어를 생략하도록 하겠습니다.


프로젝트를 시작하기에 앞서

하나의 팀을 이뤄 게임을 개발한다는 것은 참으로 복잡한 문제가 많이 내포되어 있다. 혼자서 간단한 게임 여러 개를 개발했다고 하는 사람도 팀 활동을 하면 모난 돌이 될 수 있고, 자신도 혼자 만들 때보다 더 힘들게 느껴질 수도 있다.

이는 어려서부터 공동의 프로젝트 활동을 제대로 배우지 못한 교육 방식 때문이기도 하고, 개개인의 경험 부족, 제각기 다른 성격, 각자가 처해있는 환경 등 여러 원인이 있다. 문제는 이러한 마찰 요소들을 프로젝트 초반에 확실히 잡아주지 못한다면 중반, 후반에 가서 상당한 재난을 초래하게 되는 데에 있다. 그럼 어떠한 부분들이 준비되어야 하는지 본문을 통해 살펴보도록 하겠다.


1. Project Manager

프로젝트 매니저란(이하 PM) 간단히 말해 프로젝트 팀을 관리하는 사람이다. 프로젝트의 전체 개발 일정과 세부 일정을 잡고, 기획팀, 프로그래밍 팀 등의 다른 파트에서 나오는 결과물들을 검토하고 조정하며, 프로젝트 활동 중 생기는 다양한 문제점에 대해 적절한 대안을 내놓는다. 때문에 이 일을 맡는 사람은 보통 프로젝트에서 제일 경험이 있는 사람이며, 그 사람은 기획이든, 프로그래밍이든 다른 일을 병행하며 활동해간다.

(그렇다고 PM이 꼭 다른 일을 병행해야 한다는 것은 아니다. 오히려 PM은 PM 자체로 하나의 전문 직업이 되지만, 일반 업계든 아마추어든 인력난이라는 상황에는 어쩔 수가 없다. 또한 전문적인 PM을 영입하기가 쉽지 않은 것 또한 현실이다.)

문제는 대부분의 아마추어 프로젝트가 그렇듯이 PM의 경험이 적다는 데에 있다. 제일 좋은 방법은 이미 한 번 이상의 프로젝트를 마쳐본 사람(PM으로서)이 다른 신규 프로젝트의 PM을 맡는 것이다. 그러나 자신이 동아리나 아는 사람이 있어 경험자를 영입한다면 모를까 보통 아마추어 프로젝트가 친구들끼리 의기투합해서 만들어지다 보니 미경험자가 PM을 맡는 것이 매한가지다. 게다가 아는 사람이 있다고 해서 쉽게 영입할 수 있는 것도 아니니 모두가 신입인 상태로 프로젝트가 만들어지는 일이 많을 것이다.

- PM의 경험이 왜 중요한가?

물불을 안 가리는 열혈 아마추어 개발자들은 이런 생각을 가질지도 모르겠다. 어차피 아마추어 활동이고, 친한 친구들끼리 그때그때의 상황마다 얘기해나가면 되지, 왜 귀찮게 그런 직위가 왜 필요하냐고 말이다. 결론부터 말하자면 천만의 말씀이다.

학교에서 회의를 할 때 회장이 있듯이, 어떠한 일을 공동으로 작업하기 위해선 그 공동체를 이끌어 줄 사람이 필요하다. 그것도 다름 아닌 아마추어 게임 개발 활동에서는 말이다. 그럼 어떠한 이유 때문에 PM의 경험이 중요한지 살펴보겠다. 경험이 없는 PM은 이러한 부분들을 유심히 살펴보아야 할 것이다.

(1) 프로젝트의 미래 진단

PM은 자신의 프로젝트가 어떠한 과정을 거쳐 게임이 만들어지는지 그 과정을 그려낼 수 있어야 한다. 이 그림은 기획자가 상상하는 게임이 만들어지는 모습이 아니다. 게임을 만드는 팀원들의 활동 모습이다.

기획팀에서 기획서가 나오면 프로그래밍팀은 어떻게 작업해야 되는지, 프로그래밍팀이 작업하면서 기획팀은 기획을 어떻게 보완해야 하는지, 그래픽과 사운드팀에는 어떤 작업을 내려줘야 하는지 일일이 정하고 판단하고 이끄는 것이 바로 PM이 해야 될 일이다.

이러한 일들을 제대로 조율하지 못한다면 프로젝트 내부의 각 팀은 서로 일정이 꼬이게 되고, 불필요한 결과물들이 나오기 쉬우며, 심할 경우에는 리셋(초기화)을 감행해야 될지도 모른다. 이 일을 제대로 해내기 위해선 경험을 통한 학습이 가장 확실하나 그렇지 못하다면 적어도 책에 나와 있는 방법들을 숙지하는 것이 거친 바다를 항해하면서 나침반은 갖췄다고 할 수 있다.

(2) 팀원 능력 파악

이 부분도 상당히 중요하다. 기획팀은 객관적인 자료가 없어 곤란하지만, 프로그래밍이나 그래픽팀에 관해선 확실히 판단해야 한다. 그래야 기획팀이 터무니없는 기획안을 내놓았을 때 적절하게 처낼 수가 있다.

비록 기획자 본인은 그렇게 대단찮은 것을 기획했다 생각할지 모르지만 그것을 직접 구현하는 프로그래밍이나 그래픽 작업자 입장에서는 단순한 캐릭터의 스킬 하나에도 이를 뿌드득 간다. 다른 게임에도 구현되지 않았느냐를 따지는 것이 아니라 팀원이 어느 부분까지 구현할 수 있느냐가 중요하다.

(3) 전체 스케줄 관리

프로젝트의 시작부터 완료까지 크게는 두세 달, 작게는 하루 단위(이건 심한가?)로도 일정을 관리해야 한다. 프로젝트 처음에 개략적인 일정을 잡고, 그에 따른 1~2 주 단위의 일정도 미리 나와 있어야 한다. 그런데 보통은 완료 일시와 두리뭉실한 일정(기획서가 언제, 알파 버전이 언제, 베타 버전이 언제라는 등)만 잡혀 있고, 구체적인 세부일정(게임 시스템 설정, 인터페이스, 적 목록, 그래픽 엔진, AI 스크립트 등.)은 그때그때마다 정한다. 이는 미로를 위에서 내려다보는 게 아니고 그 안에서 헤매며 출구를 찾는 것과 마찬가지다. 세부적인 일정도 전체 일정에 포함되어야 차후에 일어나는 일정 지연 문제(반드시 일어난다)를 원활히 해결할 수 있다. 그래도 주먹구구 식으로만 프로젝트를 진행시켜 간다면 겉잡을 수 없이 불어나는 마감 일정에 희열을 느낄지도 모르겠다.

PM 결론

위에 나열한 사항은 본인이 생각하는 대표적인 이유이며, 이것 말고도 많은 일들이 PM에게 중요시 될 것이다. 그리고 이러한 능력을 십분 발휘하기 위해서는 경험이 제일 우선시 된다. 만약 그런 사람이 팀에 없다면 게임을 최대한 단순하게 만들기를 당부한다. 보통의 의욕적인 아마추어팀들은 자신들의 의욕 따라 게임도 거창해지기 마련인데, 그 의욕 속에서 프로젝트의 미래를 현실적으로 바라보는 PM이 없다면 모래를 가지고 레고 놀이를 한다는 것이나 다름 없을 것이다.


2. 게임 규모

아마추어 게임 개발 팀들이 흔히 저지르는 실수의 하나가 게임의 방대한 규모이다. 자신들이 게임을 직접 만드는 만큼 시중에 나온 게임보다는 재미있게 만들어봐야 하지 않겠는가? 슈팅 게임이야 혼자서도 만들 수 있는 것이니 제외하고, 기획 세 명에 프로그래밍도 네 명이나 있는데 어디 멋들어진 RPG나 만들어 보자.

주인공 캐릭터는 한 여섯 명 정도’만’ 잡고 각각 스킬을 8개 정도 두고, 스테이지는 시나리오를 멋들어지게 진행하기 위해 약 30~40정도로 제작하고… 만약, 게임 개발을 처음 해보는 사람들이 모여 이런 생각으로 게임을 만든다면 100에 99팀은 붕괴될 것이다.

그리고 간단한 슈팅이나 액션 게임을 만든 사람이 팀에 한두 명 있어도 10에 9팀은 쓴 물을 마실 것이다. 경험 있는 PM이라면 팀의 능력과 완성 시기를 고려해서 바로 기획안의 실현 여부를 알아낼 것이다. 그러나 PM마저 프로젝트의 들뜬 분위기에 휩쓸린다면, 나이아가라 폭포를 향해 열심히 노를 젓고 있는 모습을 조만간 보게 될 것이다.

(1) 경험 쌓기 최고의 장르는 슈팅

아마 개발해 본 사람은 알겠지만 슈팅만큼 개발하기 쉽고 재미도 쏠쏠한 장르가 없을 것이다. 기획이나 프로그래밍이 그렇게 어렵지 않고(제대로 만들려고 하면 어렵다), 그래픽 작업도 쉽다. 만들어진 게임에 대해서도 쉽게 재미를 판별할 수 있고, 밸런스를 맞추기도 용이하다.

기획자는 시중의 게임들을 분석해가며 참신한 아이디어를 추가시켜 보고, 프로그래머는 엔진 외에 간단한 툴도 만들어 보며 경험을 쌓을 수 있다. 그래픽과 사운드도 작업해야 할 분량을 쉽게 조절할 수 있으며, 여차할 경우에는 샘플을 구해 써도 된다.

처음 프로젝트 활동을 하는 아마추어들은 여기에서 다른 파트의 작업들을 지켜보며 팀 활동을 해야 한다. 아마추어의 흔한 실수 하나가 자신의 작업만 제대로 하면 된다라는 생각이다. 물론 세부적인 부분까지 서로 알 필요는 없다.

다만 다른 파트가 지금 어떠한 일을 하고 언제 그 작업물이 완성되는지를 알아야 팀의 결속력도 커지고 자신이 팀 활동을 통해서 게임을 만들고 있다는 것을 인지하게 된다. 특히 PM은 전체 파트의 업무들이 어떠한 방식으로 진행되는지를 숙지해 마감 일정을 최대한 맞출 수 있도록 일정을 조절해야 한다.

이렇게 초보 모험자들은 약한 몬스터와 싸워야 경험치를 얻어 레벨업을 하지, 처음부터 고레벨 몬스터에 도전했다가는 애로사항만 만발할 것이다.

(2) RTS나 RPG 같은 장르에 대해

팀원 중에 몇몇이 슈팅 게임이나 액션 게임을 만들어 봤기에 보다 광범위한 게임을 만들고 싶다면? ‘스타 크래프트’까지는 안 되도 간단한 전략 시뮬레이션이나 흔하디 흔한 RPG 같은 게임도 까짓 거 못할 건 없지 않겠는가? 만약 내가 그 프로젝트의 매니저라면, 즉시 그만두게 만들던가 아니면, 그 프로젝트를 뛰쳐나올 것이다.

얼마나 간단하게 만들지는 모르겠지만 사람이란 다들 욕심이 있기에 일단 시작하고 보면 굉장히 의욕적으로 작업 분량이 늘어난다. 그리고 그걸 제때 쳐주지 못한다면 프로젝트는 이미 몰락의 길에 들어섰다고 할 수 있다.

그렇다고 기획안들을 계속 잘라주면 기획팀의 의욕 좌절로 팀이 와해되기 쉽다. 물론 불타오르는 태양 같은 정열로 해낼 수 있다고 생각된다면 시간이 왜 약이라는지 직접 느껴보면 된다. 시중에 나오는 게임들은 프로 즉, 돈을 받는 사람들이 만들었기에 끝끝내 만든 작품들이다. 돈의 마력이 있었기에 아무리 궂은 일도 해내게 되지만, 아무런 보상 조건 없이 그저 의욕만으로 규모가 큰 RTS나 RPG 등의 게임을 만들겠다면 어쨌든, 최대한 단순하게 만들기를 부디 당부하는 바이다.

(3) 아마추어는 아이디어에 승부를

만들고 싶은 게임이 꼭 RPG나 RTS 같은 매니악한 장르만 있지는 않을 것이다. 설혹 누군가는 그렇다고 하더라도 팀 활동을 위해선 그러한 생각은 양보해야 한다. 이스 같은 게임이 단순해 보인다고 해도 그런 게임을 지금까지 아마추어 팀이 만들지 않았다는 점을 깊게 생각해봐야 할 것이다.

어쨌든 아마추어는 간단한 게임에 다른 게임들과 차별화된 참신한 특징이 있으면 그만이다. 경험을 쌓기로는 제일 처음에 슈팅을 들었는데, 말이 쉬울 뿐이지 만들다 보면 여기서도 고려해야 할 부분이 상당히 많음을 알게 될 것이다.

그리고 그 중에서 가장 중요한 작업은 밸런싱이다. 게임에 특별한 특징이 없더라도 레벨 및 벨런스 디자인이 완벽(적절한 도전과 보상)하다면 그것만큼 플레이어의 흥미를 끄는 요소도 없을 것이다. 마지막으로 사족을 하나 덧붙이자면 게임은 재미있으면 된다. 단순한 시스템이든 복잡한 장르든 게임을 하는 플레이어들이 재미있게 받아들이면 그만인 것이다.


3. 팀을 만들 때의 고려점

아마추어 팀들은 의욕을 중심으로 모이다 보니 각양각색의 사람들이 팀원을 이루게 된다. 주로 편성되는 구성은 친한 친구들끼리이고, 학교 모임(서클, 동아리, 소모임 등)의 선후배, 온라인 상으로 만들어지는 게 그 다음일 것이다. 문제는 아는 사람이고 의욕적이라고 해서 마음대로 끌어들이다간 자칫 낭패가 될 수 있다.

(1) 실제로 개발이 가능한 사람과 함께하라

이건 학교 모임이나 온라인 상에서 결성된 팀에게 중요하다. 특히 학교 모임에서는 제 각각의 사람들이 모여 팀이 이뤄지는데 여기서 주의할 점은 팀의 목표를 명확히 하는 것이다. 팀이 아무것도 모르는 후배들을 게임 개발에 대해 가르치기 위함이라면 프로젝트라기 보단 스터디 형식으로 진행되어야 하고, 뭔가 실질적인 게임을 만들어 보겠다면 아무것도 모르는 사람들은 되도록 포섭하지 않는 것이 현명하다.

앞서 말했듯이 아마추어 팀이란 의욕만으로 뭉쳤기 때문에 자신의 의욕이 어떠한 사건에 의해 공격 받아 꺾이게 되면 순식간에 팀의 붕괴로 이어진다. 약간 경험이 있는 아마추어는 같이 작업하는 팀원이 조금이라도 프로젝트에 기여하길 기대한다. 그러나 그 팀원이 전혀 경험 없는 초심자일 경우 그 사람을 우선적으로 가르쳐야 되는 입장에 놓이게 된다.

처음 프로젝트팀을 만들 때 팀의 방안에 그런 사항(초심자 교육)도 있다면 별탈 없이 알려주겠지만, 문제는 이 초심자들이 그 내용을 제대로 이해하지 못 할 때에 있다. 초심자들은 말 그대로 아무것도 모르기에 배우려는 의지가 남다르다. 그러나 경험 있는 아마추어는 프로젝트 활동에서 교육보다는 작업 활동에 더 치중하려 한다. 때문에 가르친다기 보다는 작업 방향을 제시하게 되고, 그것을 제대로 이해할 수 없는 초심자들은 작업률 0%일 수밖에 없다.

결국 초심자는 뭐 하나 배우지도 못하고 팀에 기여도 못 하기에 의욕이 저하되고, 경험 있는 아마추어도 기본 작업 지연에 잘 이해하지 못하는 초심자를 가르치느라 이중고를 치르게 된다. 그렇게 서로의 작업물이 지연되고 어긋나게 된다면 결국 사기 저하와 함께 팀이 몰락한다.

(2) 서로 마음이 맞아야 한다

게임 개발이라는 공동의 목표를 향해 의욕을 불태우는 것은 기본이고, 좋아하는 게임 성향, 작업 스타일, 성격 등도 고려해야 한다. 자신은 플레이어가 깊게 생각하는 전략적인 게임을 좋아하는데 팀은 단순 액션 게임을 만든다고 한다면 작업을 하기가 꽤나 고역일 것이다.

작업도 한 사람은 꾸준히 정기적인 보고를 하는데 다른 한 사람은 필(feel)이 받을 때마다 한다며 펑펑 놀다가 어느 날 갑자기 왕창 올리는 식의 보고도 팀을 우왕좌왕 흔들리게 만든다. 또한 동상이몽이라고 모두가 같은 취향의 게임을 좋아하긴 힘들 것이다. 그러니 서로 자신의 취향을 조금씩 양보해 팀 작업을 최우선시 하는 원활한 성격도 필요하다.

(3) 각 파트 별 팀원 고려 사항
1) 기획팀

메인과 보조를 확실히 나눠라. 아이디어는 다같이 낼 수 있어도 게임의 전반적인 모습에 대해서는 한 명의 메인 기획자가 책임을 져야 한다. 만약 기획자들의 목소리가 서로 똑같다면 이야말로 배타고 하늘나라 간다 할 수 있다. 사람이란 자신의 의견이 남에게 받아들이기를 원하고 그 의견이 무시되면 상처 받는다.

그렇기에 동등한 입장에서 자신의 의견이 타인에게 받아들여지지 않는다면 그것만큼 답답한 일이 없고, 자신은 자신대로 자신의 의견을 고수하기 위해 고집 부리기, 딴청 피우기, 딴지 걸기 등의 행위에 손길이 가게 된다. 이것을 다른 기획자가 논리적인 근거로 잘 설득을 할 수 있다면 모르겠지만, 기획이 완성되기까지 내내 그러기가 쉽지는 않을 것이다. 그렇기에 모든 기획의 흐름을 제어할 수 있는 메인 기획자가 한 명 필요하다.

자신들은 죽마고우라 90% 이상의 동기화를 이룬다는 등의 상황이 아니라면, 공동으로 메인 작업에 들어가는 우를 범하지 말기 바란다.

2) 프로그래밍팀

일단 신입들의 교육과 함께 게임 개발을 해 보겠다는 생각만 하지 않는다면, 전부 실제 개발에 투입될 수 있는 팀원으로 구성해야 된다. 아마추어인 이상 교육자의 기질이 없다면, 자신이 게임을 만들면서 신입들을 가르친다는 것이 여간 귀찮은 일이 아닐 것이다. 그렇기에 메인 프로그래머는 건성으로 가르쳐주기 쉽상이고, 신입들은 겉핥기로 배운 탓에 주어진 과제에 대해 막막한 감정만을 가지게 된다. 결국 신입들은 의욕 좌절로 떨궈지고 아마추어 경력자는 괜한 시간만 허비하는 결과를 초래한다.

3) 그래픽

그래픽도 역시 바로 투입 가능한 인원이어야 한다. 또한 그림 성향이 비슷해야 하며 실력차가 너무 벌어져서도 안 된다. 그래픽은 무수히 반복되는 작업이 많기에 편집하는 능력과 그림 성향이 비슷해야 하며, 그렇지 않다면 전부 다른 파트를 맡아야 한다. 한 명은 일러스트, 한 명은 인터페이스, 한 명은 캐릭터 이런 식으로 말이다. 다만 한 가지 유의해야 할 점은 모든 그래픽 작업물들이 게임의 분위기에 적절히 융합될 수 있어야만 한다.


4. 팀의 운영 방법

아마추어 개발팀에서 가장 유의해야 할 점 하나가 바로 작업 보고이다. 자신에게 주어진 과제물을 팀 일정에 맞춰 보고를 해야 하는데 그게 생각처럼 쉽지가 않다. 프로 개발자처럼 회사에 다니며 정해진 시간에 작업을 하는 것이 아니라 생각날 때마다 하니 기복이 심하다. 게다가 시험과 같이 강압적인 것이 아니니 긴장감이 쉽게 풀어진다. 이런 식으로 각 팀원 별 작업 보고가 뒤죽박죽 뒤섞이고 어느새 팀이라고 볼 수 없는 이상한 집단에 자신이 속해 있음을 깨닫게 된다.

(1) 강제적인 제제

프로젝트의 팀원이 특별한 사정(회사를 다닌다거나 군인이라는 둥…)이 있지 않다면, 모두 잘못한 일에 대한 제제를 받아야 한다. 그 사항으로는 작업 보고 무시, 특별한 사정 없이 회의에 지각 또는 결석 등이 있다. 제제는 팀원 모두 동의 하에 결정되어야 하며, 필자가 맡았던 팀은 벌금형을 택했다.

아마추어 팀 자체가 의욕만으로 똘똘 뭉쳐있기에 각 팀원에 대한 관리를 소홀히 했다간 금새 팀의 의욕 좌절로 이어진다. 어차피 그 사람도 저번에 작업을 안 했는데, 내가 이번에 안 한다고 해서 뭐 큰일날 게 있겠는가?라는 생각이 팀원 사이에 당연시하게 여겨지고 있다면 팀은 벌써 큰 종양을 앓고 있다고 봐야 한다. 그래서 팀원 사이에 이런 생각이 들지 않게끔 효과적인 제제가 모두의 동의 하에 도출되어야 한다.

(2) 세부적인 스케줄

프로젝트 완료 일시까지 큰 그림과 작은 밑그림이 빼곡히 그려져 있어야 한다. 엔진과 툴은 언제까지 완성되고 전체 기획서와 게임의 알파버전은 언제 나오는지 미리미리 정해두고 각 사항에 대해서도 세세한 일정이 나뉘어져야 한다. 보통은 한 주 단위가 적당하며 2 주가 넘는 세부 일정은 팀원의 긴장감을 늦춰 작업 보고를 지연시키게 만든다.

필자가 맡았던 팀은 하루 단위, 1 주, 2 주, 한 달 등 여러 가지 시도를 해 보았는데 그 중에 가장 괜찮았던 방법은 2주 작업에 3일 보고제였다. 우선 2주간 작업할 내용을 미리 정해주고, 그 작업 내용을 3일마다 온라인으로 보고하는 방법인데 팀원에게 적절한 압박을 가하면서 진행 과정을 보면서 결과를 수정하기가 용이했다. 그렇지만 이건 각 팀과 만드는 게임에 따라 여러 가지 방향이 나올 수 있으며 딱 하나의 정답이 있는 것은 아니다.

(3) 회의

회의는 반드시 오프라인으로 해야 하며, 온라인은 어쩔 수 없을 때(팀원들이 전국방방곡곡에 산재한 경우)를 제외하곤 지양해야 한다. 회의 자체가 자신이 직접적으로 관여되지 않은 이상 지루해지기 쉽고 그렇다 보니 자신이 말할 때가 아니면 자신도 모르게 딴 생각을 하게 된다. 그래서 온라인으로 회의를 할 경우 게임을 하면서 회의를 하는 멀티 태스킹에 각성을 하게 된다. 또한 온라인으로는 보여줄 수 없는 밑그림이나 손짓 발짓 같은 부가 설명을 해줄 수가 없어 회의 시간도 길어지게 된다. 팀원이 모두 모이는 전체 회의는 2 주에서 한 달 정도가 적당하며, 각 파트별로 필요한 회의는 수시로 가져 다른 팀원이 어떠한 작업을 하고 있는지 명확히 알아야 한다.

(4) 작업 보고

기획뿐만이 아니라 프로그래밍이나 그래픽도 작업물에 대한 부가 설명을 달아주어야 한다. 프로그래밍의 경우로는 어느 부분까지 구현이 되었는지, 지금 상태에서 어떠한 일들이 가능한지, 다음에 작업할 내용은 무엇인지 간략하게 기술하면 된다. 그래픽의 경우도 작업물에 대해 어떠한 부분에 초점을 맞춰서 작업했는지 기술하고, 디자인에 대한 장점이나 보완점을 첨부시킨다면 더 좋을 것이다. 특히 모든 팀원들은 자신의 한 작업물이 한번에 통과할 것이라는 아집을 버리고 다른 사람들의 평가를 객관적으로 받아들이고 수용해야 한다.


글을 마치며

처음 이 글을 쓰려는 의도는 많은 신생 아마추어 게임 개발 프로젝트가 잘못된 길로 들어서지 않도록 필자의 실패담을 통해 알려주려 함이었다. 그러나 글을 쓰다 보니 사족이 늘어나고 글도 명확한 논점 없이 하나하나의 글감들에만 의존된 것 같다. 이런 어줍잖은 글을 밝힌다는 것이 못마땅하고 부끄럽지만 몇 일간 노력한 흔적을 지우기가 아쉬워 이렇게 공개를 한다. 부디 아마추어 개발자 분들은 이 글에서 작은 것 하나라도 취하여 재미있는 게임을 만드는데 보탬이 되었으면 하는 바람이다.

출처 : 플래시노블 제작팀 Mystic...k ( http://cafe.naver.com/flashnovel )
:
출처 : Tzvi freeman

나는 제품을 내놓아야 한다. 공포와 졸음 속에, 내 머리는 CRT에 처박히고 그 다음으로 내가 아는 것은 동으로 연기 속에서 지니가 램프 밖으로 나와 세가지 소원을 들어준다고 했다. 곧바로 나는 대답했다.

“나는 …… 재능 있는 ‘그래이트’한 팀, 숙련되고 헌신적인 엔지니어와 아티스트 (이해심 많은 아내를 포함해서)를 원해”
“충분한 시간과 돈”
“일류의 디자인 문서”

옛날 옛적에, 한 명의 프로그래머가 게임을 코딩하던 (어쩌면 아티스트 겸직의) 시절에, ‘네 맘대로’ 예산과 늘어지는 일정으로 일을 할 때. 문서는 심각하게 받아들여 질 필요가 없었다. 당신은 무엇을 만들 지를 알 수 있었고 그 것을 만들었다. 개발 도중 주요한 변화가 있었다면 불평할 사람은 당신 밖에는 없었을 것이다. 현재는, 완벽하고 읽기 쉬운 문서가 예산부족의 지옥과 천국의 길을 갈라놓을 수 있다.


시스템이 작동하는 방법

대부분의 게임은 개념과 디자인, 제작의 세 단계의 개발단계를 거친다. 이 단계들을 “번뜩이는 아이디어”, “문서” 그리고 “연마”로 생각해 보라.

첫 번째 단계에서는, 개요 문서는 당신에게 쓰는 편지 – 당신의 목표를 명확하게 잡아주어 초점을 잃지 않게 해준다. –와 시장에 판매할 사람들에게 보여주는 판매 도구의 두 가지 역할을 한다. 때때로, 이 단계는 실험할 기회를 주고 당신의 아이디어를 수정할 수 있는 프로토타입 같은 것을 포함한다.

디자인의 중간 단계는 아티스트, 애니메이터, 음악가, 그리고 기술자와의 무수한 회의를 포함한다. – 모든 것을 시도해 보고, 아이디어를 조직화하고 실현할 방법을 찾는다.

최종 단계에서, 제작 관리는 종종 특별한 대립이 없어도 유행에 상관없이 전문가에게 맡겨진다. 디자이너는 팀에서 빠질 수 없는 존재일지도 모르지만, 많은 사례에서 – 특별히 큰 회사에서 – 디자이너의 일은 외부 고문 정도로 끝나게 된다.

분명히, 디자인 문서는 프로젝트의 성장 방향에 지대한 영향을 미치는 부모와 같다. 비록, 디자이너가 프로젝트 매니저의 역까지 하기로 결정했더라 하더라도, 프로젝트를 마음대로 주무를 수 있다고 착각하지 말아야 한다. 대형 프로젝트는 재능을 가진 사람들이 많이 필요하다. 숙련된 프로그래머와 아티스트들은 자신들이 바라는 것을 게임에 넣으려는 경향이 있다. 만약 말을 만들 작정이라면, 아티스트는 유니콘을 생각할 지도 모르며, 프로그래머는 다양한 효과를 내는 낙타를 만들 생각을 할 수 있다. 좋은 문서는 당신이 계획한 것을 확실하게 말해 줄 수 있다. ‘그레이트’한 문서는 모두가 같은 느낌을 공유할 수 있게 해준다. 많은 사람들이 모여 만든 큰 재즈 밴드를 생각해보라 – 모든 사람의 생각이 일치하더라도, 애드립을 할 수 있는 기회는 충분하다.

문서는 일종의 현실과 상상 사이의 매개체이다. 그 것은 상상 속의 무엇인가를 현실에서 제어 가능한 것으로 바꾸어 주며, 그 결과물이 원래 생각했던 것이 될 것이다.

결론적으로, 신랄한 게이머가 입증할 속담을 기억하라 :

“그레이트한 예술은 디테일에 있다.”

눈부신 디테일은 처음 생각했던 대로 자연스럽게 일반적인 게슈탈트(경험의 통일적 전체)로 흘러간다. 그러나 한번 실천하려고 하면, 쉽게 활기를 잃을 수 있다.


도전

프로토타입을 만드는 것은 분명히 좋은 생각이다. – 하다못해 러프 스캐치라도. 더욱이 그런 세부 사항은 가치가 있다. 상상에 디테일을 좀 더 가질 수 있다면, 더더욱 훌륭한 작품이 될 것이다.

문서를 보며 일을 하는 것은 두 가지 면이 있다. 재미있는 게임의 개발은 재미있을 것이다.
많은 프로젝트의 가장 좋은 부분은 마감 공포의 열기 속에서 발견되었다. 진실로, 예산과 시간의 압력은 끊임없는 컨셉의 반복을 허락하지 않는다. 그러나 대작 게임이 건조기에서 나오듯, 예측할 수 있는 일이라는 것을 기대할 수는 없다. 디자인 문서를 만드는 도전은 프로젝트가 갑작스런 변경에도 원래의 방향과 목표를 잃지 않도록 해준다.
 
문서화의 3가지 단계

내용 목적
1. 개요문서 장르; 목표 계층; 묘사;
가장 특징적인 기능; 시장 정보;
개발에 소요되는 기간과 비용
컨셉, 범위, 가치와 가능성을 정의;
고객, 퍼블리셔, 고용주,
그리고 밴쳐 캐피탈에 아이디어를 판매
2. 디자인문서 프로젝트의 디테일을 첨가하여 모든 것을 서술,
게임의 요소를 구현할 방법을 서술
만들고 싶은 제품
그대로 제작할 수 있게 해준다.
3. 제작문서 일정 관리표 (개인적인 스케쥴까지);업무 데이터베이스;
예산 스프레드시트; 기술적 사양서; Q/A 데이터베이스
디자인 도큐먼트를 시간과 예산에 맞추어 진행되도록 한다.


  내용 목적
1. 개요 문서 장르; 목표 계층; 묘사; 가장 특징적인 기능; 시장 정보; 개발에 소요되는 기간과 비용 컨셉, 범위, 가치와 가능성을 정의; 고객, 퍼블리셔, 고용주, 그리고 밴쳐 캐피탈에 아이디어를 판매
2. 디자인 문서 프로젝트의 디테일을 첨가하여 모든 것을 서술, 게임의 요소를 구현할 방법을 서술 만들고 싶은 제품 그대로 제작할 수 있게 해준다.
3. 제작 문서 일정 관리표 (개인적인 스케쥴까지);업무 데이터베이스; 예산 스프레드시트; 기술적 사양서; Q/A 데이터베이스 디자인 도큐먼트를 시간과 예산에 맞추어 진행되도록 한다.


성공적인 디자인 문서를 위한 열 가지

1. 외관만을 설명하지 말고, 내부도 설명하라. 게임 개발이 자동 입/출력으로 만들어 지는 것이라면 – 코드를 짜서 그것이 어떻게 작동할 것인 지를 예견하는 것처럼 – 건조한 문체로 설명된 문서로 작업을 할 수 있을 것이다. 실제로 개발은 자신의 신념을 가진 많은 창조적 인재들이 이루어나간다. ; 대부분의 사람들은 자신의 신념을 자신이 하는 모든 것에 남겨 놓으려고 할 것이다.

작업의 진행은: 아티스트에게 스펙들을 제공해주고 그에 대한 토론을 한다. 그리고서는 프로그래머를 만나 그들에 스팩에 대한 일들을 처리해야 한다. 두 그룹은 모두 동의할 것이다.

그 날 밤, 새벽2시 쯤 되어서, C++의 성운이 서쪽에서 떠오를 때, 프로그래머들은 중년의 위기를 느끼며 생각을 시작할 것이다. “나는 이 짓을 계속해야 되나? 이것이 엄마가 나에게 원한 것인가? 왜 나는 다른 사람보다 디자인을 잘 하지 못하는 것일까?” 그리고서는 코딩작업을 계속할 것이다.

같은 시간에, 아티스트는 자신의 머신 앞에서 방금 일을 끝낸 상태일 것이고, 복잡한 3D 랜더링이 끝날 때까지 깊은 혼수 상태에 빠져들 것이다. Unsure and not really caring whether he's dreaming or is actually getting paid for all this, immersed in that wild world of artistic genius where fantasy and reality blend as one, the phosphors come together in ways previously unimagined - certainly not by you. (번역 안된 부분)

다음 날 아침까지, 말(馬)은 두 개의 낙타 혹을 가진 유니콘이 되어 있을 것이다. 창의적인 사람들에게는, 설명은 좋지 않다. 영감을 주는 것이 필요하다.

디자인 문서에서, 모든 문장과 뉘앙스에 들어있는 자세한 묘사에 대해서 스스로 만족하지 말아야 한다. 여유를 가지고 게임이 가져야 할 느낌을 묘사해야 한다. 각 요소의 뒷면에 숨겨진 용도와, 각각의 유저들이 가질 게임 경험, 그리고 다른 관점에서 게임의 내면(魂)을 상상하고 설명할 수 있어야 한다.

예를 들어, 당신이 슈팅 게임을 디자인한다고 했을 때, 확실한 도전에 직면하기 전에 플레이어를 훈련시키고 싶어할 것이다. 그래서 최소한의 위험성을 갖는 작은 도전들을 점점 커나가게 한다. 당신은 개발 팀 전체에게 이 것을 설명해야 할 것이다. 그리하면 그들은 왜 그런 방식으로 일을 진행시키는 지 이해하게 될 것이다. 그렇게 되면 설령 팀이 문서에 있는 당신의 아이디어들을 분해하고 가지고 놀 더라도, 결과물이 같은 느낌이나 비슷한 느낌으로 나올 것이라는 기대를 할 수 있다. 어쩌면 더 나를 지도 모른다.

2. 읽을 수 있도록 해라. 계속해서, 10포인트의 글자 크기와 라인당 80글자의 sans serif 폰트의 문서를 개발자들에게 제공하고, 그 것을 읽도록 요구하라. 문서와 함께 아스피린을 주고 싶을 지도 모른다. – 주문에 맞게 제작하려고 머리가 아픈 사람들을 위해서

아래는 좋은 페이지 레이아웃을 위한 지침이다.

많은 공백
본문에 Serif 폰트
제목은 Bold 폰트
단락 마다 공백을 넣는다.
글은 짧은 줄로
중요한 요소는 눈에 들어오도록 배치
계층적인, 2D 포맷을 사용하라


많은 사례들이 테이블, 스프레드시트, 차트로 표현될 수 있다. 그 것을 이용하고 확실히 눈에 띄도록 만들라.


3. 우선순위를 정하라. 이제는 또 다른 자아와 일하고 있다는 사실을 알아차렸을 것이다. 집요하게 확정된 게임 요소들에 테그를 붙이는 것의 진가를 무서울 정도로 알게 될 것이다. 실제로 게임제작에는 어떠한 보증도 없다, 그러나 테그를 적당히 드문드문하게 사용한다면, 그 항목을 주의를 끌 수도 있다. 그리고, 여기서 멈추지 않고. 아이디어에 테그를 붙이는 동안, 또한 하려고 마음먹은 일과 시간과 예산, 기술이 허용되면 할 일을 구분하고 싶을 것이다.

휴지통이 있다. – 훌륭한 듯 보였지만 대의를 위해 버려진 것들. 그 것을 명쾌하게 조사하고, 버려진 이유를 설명해라. 그렇게 하지 않으면, 그 것들이 되살아 날 수 있다. 여기에 테그의 리스트가 있다.

필요 불가결한
중요한
가능하면
기각된


이 것들을 나타내기 위해 시각적 심볼을 사용하고 싶을 지도 모른다. 문서가 언제나 컬러로 인쇄되는 것이 아니라면, 컬러에 의존하지 말아라.


4. 세부사항을 가져라. 세부항목이 없는 문서는 쓸모 없다. 일반적인 것은 누구에 의해서든 좋을 대로 해석할 수 있다. “살인하지 말지어다.”는 모세와 스페인 정복자들에게 서로 다른 의미가 되었다. 죽이지 말아야 할 사람과 상황을 세세하게 알려주는 것이 더 좋았을 것이다.

같은 이유로 문서도 그래야 한다. : 실제적인 디테일을 설명하고 예를 준다면, 아이디어는 더욱 구체적이 될 것이다-그리고 아이디어가 망가지는 일도 없을 것이다.

예를 들어, “청동으로 만든 새는 무적이다.”라고 말만하지 말고, 그것이 공격 당했을 때에 대한 모든 예에 대해 무슨 일이 이 창조물에 일어났는지, 그 후에 어떻게 회복되는 것인지 정확하게 설명해야 한다. 만약 애니메이터가 활기 없고 관록이 없는 사람이라면, 그가 기획서를 따르지 못할 것이란 걱정을 하며 지내야 할 것이다. 그러나 적어도 그가 명확하게 당신이 하려는 일을 알고 있다면 그가 변형시킨 부분은 게임의 다른 부분에 심각한 영향을 미치지 않을 것이다.

“여기서는 유저들이 벽을 오르기 위해서 점프 키를 방향키와 같이 눌러야만 한다.”라고 말만 하지 말아라. 플레이어들이 다른 일을 시도 했을 경우에 대해 벌어질 일을 설명하라. 왜 유저들이 당신이 제공한 콤비네이션(조작)을 알아낼 수 있을 지 당신이 생각하는 바를 표현해야 한다.

또 다시, 아티스트들은 다른 무엇인가를 완성해 낸다, 어쩌면 원래 상상했던 것보다 더 어울리는 무엇일지도 모른다. 그 것이 진정한 성공이다: 개발자들의 결과물이 문서에 표현할 수 있었던 처음의 생각에 비슷할 때. 그러나 이런 일은 먼저 명쾌하게 구상을 설명하지 않으면 일어나지 않는다.

그저 “Bongo Man은 Bongo Boy보다 힘이 세고, Bongo Boy는 빠른 반사신경을 가지고 있다.”라고 말하지 말라. 테이블, 스프레드시트, 차트를 사용하여 캐릭터의 실제적인 값(캐릭터의 움직임의 속도, 캐릭터의 체력, 공격력 등)들을 분배해라. 이 스프레드시트는 Q/A와 미조정(微調整) 단계에서 상당한 값어치를 지닌다.

그저 “모든 사람들이 게임을 쉽게 해결한다”고 말하지 말아라. 게임을 하는 집단에서의 예상되는 제품의 생명을 어떤 시점에서 다양한 기능들이 발견될 지를 나타내는 차트로 만들어라. 유저 테스트는 다음 게임을 디자인하는 데에 훌륭한 피드백을 제공해 준다.


5. 어떤 것은 반드시 증명되어야 한다. 가끔은 약간의 러프 스케치로도 충분하다, 그러나 아이디어가 당신의 프로젝트의 컨셉에 정말로 중요한 것이라면, 러프 애니메이션을 만들고 싶을 지도 모른다. 구성요소의 작용이 문서에 설명하기 너무 복잡하고 모호한 경우는, 프로토타입을 만들고 싶어 질 것이다. 프로토타입을 만드는 일은 프로젝트를 더 단순하고 훌륭하게 만들어 주는 좋은 솔루션이다.

애니메이션과 프로토타입을 만들었어도, 컨셉을 글로서 표현하라. 애니메이션은 기가바이트의 문자의 값어치를 가지지만, 글은 애니메이션으로는 불가능한 방법의 커뮤니케이션 방법이다. 글은 애니메이션을 보면서 놓칠 수 있는 중요한 뉘앙스를 전달해 줄 수 있다.


6. “WHAT”만이 아니라 “HOW”까지. 현실 세계에서는, “how”가 “what”을 결정한다. 예를 들어, 클레이 애니메이션을 만든다고 생각해보자. 이미지가 캡쳐되고 기록되는 과정을 살펴보자. 어떤 재질과 색갈이 배경이 될 것인가? 어떤 카메라가 왜 사용되어야 하는가? 캡쳐된 프레임을 가공하는 것은 어떤 단계인가? 그리고 계속되는 작업. 만약 당신이 질려버렸다면, 이러한 요소들이 결과에 심각한 영향을 미칠 수 있다는 것을 알게 될 것 이다.

또는, 모터 사이클 경주 게임을 만든다고 생각해 보자. 당신은 모터 바이크들의 pros와 cons를 다르게 하여 균형을 맞춰야 한다. 그리고 모터 바이크들의 밸런스를 보여주는 차트도 만들어야 한다. 그리고 나서 그런 조정이 필요한 지 발표해야 한다. 어떻게 조정을 할 것인지 발표하라-과정은 무엇인가? 게임의 메인 캐릭터가 오페라의 유령이라고 생각 해보자. 플레이어의 키보드가 어떻게 파이프 오르간처럼 배치되어야 할 것인지 설명하라. 각각의 키의 배치도를 제공하라. 얼마나 많은 채널의 사운드가 가능할 지 명확히 하라. 프로그래머와 이 문제를 끝까지 이야기하고 ‘어떻게’에 대한 모든 디테일을 작업하라. 그리고 그 것을 문서화하라. 두 가지 다른 “how”는 매우 다른 두 결과로 나타난다.


7. 대안을 제공하라. 프로젝트 관리자는 많은 시간을 간트 차트(간트가 발명한 일정표)와 퍼트(계획,조직의 관리기법)를 보며 지낸다. 개인적으로 필자는 이 일들이 게임 개발에 대체적으로 효과적이라고는 말할 수 없다. 왜냐하면 게임 개발에는 알 수 없는 것들이 많기 때문이다. 좀 더 근본적이고 선구적인 게임 테크놀러지는, 예측할 수 있는 개발 흐름이 될 것이다. 팀이 스케쥴의 마일스톤을 지켜나가기 위해서 당신이 할 수 있는 일은 한 가지 이상의 방법을 제공하는 것이다.

파이프 오르간’으로 돌아가보자. 당신의 기술자는 당신에게 사용자들(-한 시간을 준 50명의 사람들)의 마음에 깊이 다가갈 수 있는 파격적이고 장엄하며 거대한 힘을 가진 궁극의 방식을 말해줄 것이다. 모든 것이 우리가 검토한 것과 같을 때, 당신의 문서는 완벽한 것이 된다.

여기서 멈출 수는 없다. 이렇게 질문하라, “우리가 원하던 대로 정리된 다면, 어떤 것을 취해야 할까, 8채널 파이프오르간? 그리고 우리가 최소로 노출되기 위해 취해야 할 행동은 무엇인가? 또한 이것을 하기 위해 어떤 보조를 해야 하는가?” 그리고 나서 그 것들을 문서화하라.
FedEx 트럭이 마지막 수화물을 배달하려 도로를 달릴 때, “OK, C계획이다!” 하고 무사히 도망칠 수 있을 것이다.

내가 제품 디자인에서 범한 가장 큰 실수 중의 하나는 엔지니어들에게 “할 수 있겠어?”라고 물어본 것이다. 일류의 프로그래머에게 묻는 것이 아니라면 이런 질문은 쓸 모 없다. 좀 더 자세하게, 대답을 세가지 부류로 나누어 보겠다.

(형편없는 프로그래머) “물론, 문제 없습니다.”

(2류의 프로그래머) “아니오. 그렇게 되진 않습니다.”

(일류 프로그래머) “이런 식으로 할 수 있을 것 같습니다. 그리고 2주일이 걸릴 것 같습니다. 아니면 이런 식의 조그마한 변화를 만들어 낼 수 있을 것 같습니다. 이 것에는 5시간이면 됩니다.”

항상 한가지 이상의 대안을 요구하고 얼마의 시간이 걸릴지를 예측하라. 그런 다음 당신이 선호하는 것을 가리켜라 – 이런 일을 할 때는 시간이 많거나 그렇지 않을 때이다.


8. 생명을 주어라. 필자는 이미 영감을 죽이는 것과 당신 손에 살아 움직이는 재미있는 자발적인 창의력에 대해 경고했다. 당신은 문서를 변화에 적당하게 만들어야 할 것이다 – 당신이 고치던 (바라 건데 똑똑한) 다른 사람들이 고치던.

필자는 이 교훈을 British Columbia 대학의 음악 전공 과정에서 배우게 되었다. 수많은 삽질을 해대가며, 자랑스럽게 여기는 neo-renaissance 금관 악기의 5중주를 작곡했다. 담당교수도 그 것을 좋아했다. 우리가 리허설에 그 작품을 들고 갔을 때, 나는 공포와, 불신, 분노와, 의기소침의 계단을 10초간 걸어 올라갔다. 5중주 연주는 시작되었고, 곧바로 튜바 연주자의 신호에 의해 중단되었다. 녀석은 연필을 꺼내서 악보를 약간 고치고 나서, 모두들 연주를 계속했다. 그런 일은 여러 번 있었다.

담당 교수는, 갑작스런 내 건강 악화를 적어두며, 나에게 돌아서서 말했다. “걱정하지 말고, 그들은 모차르트 만큼 잘하고 있어. 그리고 그들은 항상 잘해왔지.”

사실은, 종이 위에서 좋아 보이는 것은 아무 것도 아니었다. 위대한 전문가는 객관적인 인지가 생길 때, 일을 수정한다. 그럼에도 불구하고, 당신은 디자인과 꿈이 무참히 강간 당하는 것을 목격하고 싶지는 않을 것이다. 오히려, 당신은 유기적인 성장을 기대할 것이다 – 아이디어는 외부에서 접목된 줄기나 가지 없이도 자연스럽게 당신이 심은 씨앗에서 자라날 것이다.

원래의 아이디어를 해치지 않고 개발 프로세스를 파괴하지 않고 변화를 받아 들일 수 있는 문서 만들 수 있는 팁들을 소개한다:

게임의 개념에 본질적인 관계를 지녀 절대로 변하지 말아야 하는 외관이 있다면 돌에 조각한 듯이 명확하게 해야 한다.
게임이 가져야 하는 필과 각각의 디테일의 목적에 대한 모두의 이해를 확실히 하라.
정보가 반복되었다면, 그것은 반드시 상호참조 되어야 한다. 그렇지 않으면, 변경 사항이 있을 때, 자가당착에 빠져 일을 끝내지 못할 것이다.
그리고 실제적인 실행을 위한 팁들을 소개하겠다:

변경사항이 암시 되었을 때, 디자인 문서를 다시 검토하여 게임의 ‘영혼’과 일치하는 지 보아야 한다.
이 것이 고립된 변화인지 아니면 주요하고 광범위한 효과를 가지는 것인지 검토해라. ("The Ecology of Improvement"를 보라) 작업 후반에 나온 사항이라면, 다음 프로젝트를 위해 모아 놓아라.
변화의 이유를 포함해서 디자인 문서를 업데이트 시켜라. 또는 변화가 없었다면, 왜 변화가 기각되었는지를 적어놓아라.변화와 삭제, 그리고 기각된 아이디어들은 같은 문제가 두 번 일어나는 것을 피하기 위해 마스터 문서에 보존되어야 한다.

모두가 같은 비전을 가지고 일해야 한다. 지나간 버전은 폐기 되어야 한다.
결정적이고, 중대하고, 긴급한: 디자인 문서는 한 사람의 관리하에 있어야 한다.


9. “어떠한 참고 사항도 찾을 수 없었기 때문에 이런 식으로 작업했다.”라는 말이 나와서는 안 된다. 필자는 페이지 수도 적혀있지 않은 문서를 보아 왔다. 그리고는 (그들은-문서작성자) 다른 사람들에게 지침을 따르지 않았다고 불평한다. 좋은 워드프로세서라면 자동으로 패이지 수를 매겨주고 문서에 인쇄해 줄 것이다. 어떤 것은 자동으로 장(章)이 바뀔 때 헤더를 바꾸어 주는 것도 있을 것이다. 중요한 부분에는 bold체를 사용해 바로 눈에 들어오게 해야 한다. 반복해서 읽고 싶은 만큼 문서의 다른 부분들을 읽고, 상호 참조하여 모든 내용을 골고루 업데이트 할 수 있어야 한다. 철저한 내용의 표를 만들어라.

어쩌면 HTML을 이용해 문서를 작성하고 링크를 제공하고 싶을 것이다. 어떤 혁신적인 워드프로세서들은 HTML 없이도 링크를 제공하는 기능을 가지고 있다. 그러나 대개 사람들은 오히려 하드 카피를 좋아한다는 것을 기억하라. (빈번한 시스템 충돌 후의 리부팅 시간에 읽을 수 있다.)
 

10. 좋은 조건으로 전달하라. 요컨대, 어떤 수단이던지 읽기 편하고 쓰기 쉽게 해주는 것이라면 해야 할 필요가 있다. 파일로 된 문서는 읽히지 않는다-별로 중요하게 보이지 않기 때문이다. 하드 커버로 장식되어 있는 것이 중요하게 보일 것이다.

복사를 필요로 할 것 같은 사람들의 명단을 만들고 보관하고 있어라. 각 페이지마다 날짜를 찍어서 인쇄해라. 구멍을 뚫고 바인더에 넣어 두어라. 책의 등과 커버에 라벨을 인쇄해라. 그것들이 업데이트 되었을 때는, 개정된 페이지를 모두에게 제공하도록 하라. 같은 관점에서 헌 책을 버리고 새 책을 제공해 주어야 할 필요가 있을지도 모른다.
 

정리

영화 제작자들은 대본을 사용한다. 건축가들은 청사진을 사용한다. 음악가들은 악보를 사용한다. 오래된 증거에 따르면, 우주의 창조자도 디자인 문서를 만들었다고 한다. – 나중에 그는 몇몇 예언자들에게 살짝 보이게 해주었다-태초에 “빛이 있으라!” 그래서 게임 개발자들은, 천상의 모델을 본떠, 똑 같은 일을 할 수 있게 되었다. 지금 실천하고 남은 여정을 순탄하게 하라.


Tzvi Freeman은 캐나다, 밴쿠버에 있는 디지팬 컴퓨터 게임 스쿨에서 게임 기획과 문서작성을 가르치고 있다. 그는 몇몇 상업적 게임을 디자인했으며, 다른 많은 게임의 컨설턴트를 하기도 했다. 그의 연락처는 TzviF@aol.com이다.


출처 : Tzvi freeman
: