[Development] 아마추어 게임 제작

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