출처 : KGDC 2003 문서강연 참가 글 / 작성자 김의민님 (Nickname : 아리랑피바람 )

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



도입:

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


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

비주얼노벨 툴 ‘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 : 아리랑피바람 )

출처 : 플래시노블 제작팀 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 )