NDC Replay

인디게임 프로젝트 중도에 포기하지 않는 방법
원창현
인디 개발자
2006년 버디게임즈 RD Studio 프로그래머 2007 대한민국 인디게임 및 게임 아이디어 공모전 PC부문 은상/기획상 2007 대한민국 게임 동아리 캠프 대상 2007년 ~2012년 MAIET entertainment 건즈2, 레이더즈 개발 참여
인디 게임들을 개발하면서 시기별로, 제작을 배우기 위한 게임, 특별한 장면을 게임으로 만들어보고 싶어 만든 게임, 어떤 상황의 간접 경험을 전달하기 위한 게임, 특정 형식을 실험해보기 위한 게임 등을 만들어왔습니다. 큰 회사의 팀원으로 소속되어 제작한다면, 회사로부터 급여를 받고, 나와는 잘 맞지 않는 개발 업무는 팀 내의 담당 동료가 대신 작업해주는 좋은 조건의 환경에서 개발했을 것입니다. 그래도 자유롭게 만들어보고 싶은 게임들을 만들 수 있다는, 무엇과도 비교할 수 없는 장점이 있기 때문에 많은 분들이 인디 게임 개발에 관심을 둔다고 생각합니다. 하지만 저의 인디 게임 개발 과정은 순탄치만은 않았습니다. 어떤 게임의 제작 과정은 즐거웠지만, 어떤 게임의 제작 과정은 지루하거나 괴로웠던 적도 있었습니다. 그래서 어떻게 하면 제작 과정이 괴로운 상황을 줄이고 즐겁게 개발할 수 있을까를 계속 고민하고 탐구하고 있습니다. 이 세션에서는 제가 인디 게임들을 개발해왔던 경험들을 공유하고 즐겁게 인디 게임을 개발하려면 어떻게 해야 할지에 대한 탐구 내용을 공유합니다.
[새 창에서 슬라이드 보기]
안녕하세요, 반갑습니다. 저는 쓰여있는 대로 아직 소속이 없고요, 인디게임 개발자고요, 정식 소개는 다음 슬라이드에 있을 텐데, 제가 사실 지금은 손이 하얗습니다. 제가 백수라고 쓰고 다니면 여기 보안 요원들이 이거 만든 건 줄 알고 잡아갈 까봐 일단 인디 개발자라고 쓰고 다니고 있습니다. 이번 시간에는 제가 인디게임 프로젝트 중도에 포기하지 않는 방법이라는 제목으로 강연을 진행해 볼 건데요, 진행하기 전에 혹시 개발자 분들 손 한 번만 들어봐 주시겠습니까? 역시 많네요. 혹시 인디게임 프로젝트를 시작을 해봤다. 그러면 시작하시고 3개월 이르렀다. 1년 이 흘렀다. 1년이 흐른 분들 중에 최근 일주일간 개발을 한적이 있다. 꼭 완성하시길 바라겠고요, 그럼 발표를 시작해보겠습니다. 저는 원창현이라고 하고요, 06년도에 다들 아시는 버디버디 메신저 자회사 버디 게임즈에서 서버 프로그래머로 현업에 들어갔고요, 이 전까지 MAIET entertainment에서 5년동안 근무를 했고요, 역시 프로그래머 포지션으로 이것저것 여러 가지 일을 했고, <Gunz2>프로젝트와 <RaiderZ> 프로젝트 개발에 참여했었습니다. 그리고 04년도부터는 아마추어 게임들을 계속 만들면서 음지에서 야금야금 계속 인디게임을 만들어왔고요, 몇 가지 상도 탄 적이 있고 우리나라에서는 PC게임을 만들어서 자유롭게 뿌리면 범법자가 되는 나라잖아요? 그래서 저는 해외 포탈에다 몰래 몰래 올리는 식으로 인디게임을 개발해왔습니다. 최근에 여러 가지 인디게임들의 성공 사례가 뉴스로나 이런 매체를 통해서 보도가 되면서 플레이어들 사이에 인디게임에 대해서 관심이 커지는 것 같고요, 개발자들 사이에서도 마찬가지고 인디게임에 대한 관심이 커진다고 알고 있습니다. 특히나 개발자들 입장에서는 저렇게 나만의 아이디어를 직접 구현한다거나 메시지를 직전 전달한다거나 개발 연습을 한다거나 아니면 거대 자본으로부터 독립을 해서 내가 스스로 수익을 낸다거나 하는 식의 그런 목적성을 띄고 인디게임에 많은 관심을 가지고 있다고 보입니다. 저기 보이는 스크린샷 게임들 전부다 국내 인디게임들 스크린샷들이고요. 그래서 저도 정말로 인디게임들 좋아합니다. 사실 인디게임 프로젝트라는 게 정말 클릭 몇 번이면 바로 시작을 할 수 있죠. 유니티로 프로젝트를 만든다거나 비주얼 스튜디오 클릭 몇 번이라거나 이렇게 금방 쉽게 만들 수가 있는데, 사실 정말 잘 망하더라고요. 저도 워크 스페이스 폴더에 앞에 꺾쇠 열고 동결 혹은 드랍 쓰여있는 폴더 볼 때마다 참 가슴이 아픈데요, 이것 사실 실제로도 제가 시작한 프로젝트 중에서도, 사실 이 파란색 파이가 더 작아야 좀 더 현실성이 있는데요, 중단한 프로젝트가 압도적으로 많았습니다. 사실 여러 가지 문제점들이 있죠. 시간적인 문제도 있고요, 여러 가지 문제점들이 있는데요. 이 시간에 그래서 이렇게 인디게임을 만드는 도중에 포기하게 만드는 여러 가지 원인들과 예방법에 대해서 매우 주관적으로 제 경험담 위주로 풀어보려고 합니다. 사실은 의지력이나 실행력 관한 얘기는 안 나올 거고요, 보통 저는 프로그래머로 주로 활동을 했지만 게임 기획 쪽에도 계속 관심을 가지고 봐왔기(?) 때문에 이번 시간에는 개발적인 측면에서 이런 원인들에 대해서 얘기를 해보려고 합니다. 크게 3가지 주제로 준비를 해봤습니다. 처음은 인디게임 프로젝트를 시작하시려는 분들을 위해서 제 경험담을 들려드리려고 합니다. 간단한 케이스를 하나 보면서 이야기를 진행을 해볼게요. 보통 인디게임을 처음 개발하시는 분들은 되게 원대한 아이디어를 상상을 합니다. 그래서 보시면 <Grand Sid Meier’s World of Heroes Manager Plus>이런 여러 가지 게임 짬뽕해서 이런 것들 만들면 완성만 해서 배포만 하면 제 2의 모장(MOJANG)이다 이러면서 상상을 하죠. 그러면서 핵심 매력들 열심히 정리를 합니다. 기획서도 써보고 문서도 써보고 그러면서 주위 사람들 괴롭히기 시작해요. “이 게임 나오면 재미있을 것 같지 않냐?” 이러면서 나오면 꼭 사달라고 그러고. 그런 다음에 노긍정 선생님의 긍정적인 마인드를 바탕으로 삼아서 언젠가는 만들자 그리고 같이 만들 사람을 찾으면 그때부터 다시 시작을 하겠다 라고 하면서 사실상 동결이죠. 매우 오랜 기간 동결하기도 합니다. 사실 게임 개발이라는 게 기획이 나오는 것이 아니라 결과물이 나와야 하는 생산 프로젝트잖아요. 너무도 당연한 얘기입니다. 그렇기 때문에 나 혼자 혹은 내가 속한 팀의 기술로 완성할 수 있어야 하는 그런 계획이 필요한 거죠. 그래서 프로젝트 시작하기 전에 마음가짐 점검이 분명히 필요합니다. 이럴 거면 타지를 말았어야지 얼마나 비싼 기계인데. 어쨌든 만들 결심을 했어요. 그래서 계속 개발을 재개한다고 가정을 해봅시다. 그렇다고 해도 분명히 아까 봤죠, 그랜드 시드마이어스 어쩌고... 만들 게 많아요. 그리고 바빠요 일단. 저번 주에 못 본 미드도 봐야 하고, 헬스장도 가야 되고, 치맥도 한 잔 해야 겠는데. 하긴 해야 하는데, 의지가 안 생깁니다. 그러다가 또 긍정의 힘으로 “정말 많을 걸 배웠다” 프로젝트를 하면서, 그러면서 준비가 더 잘되면 나중에 3년 5년 더 경력이 쌓이고 실력이 쌓이면 더 잘 만들어보자 라는 생각으로 다시 또 동결하는 사태가 발생합니다. 사실 이게 원인이었죠 <Grand Sid Meier’s World of Heroes Manager Plus>. 궁금하기는 합니다. 나오면 어떤 모습일지. 근데 이런 걸 잘 알고 있죠. Masterpiece Syndrome 이라고 많이 들어요. 대작병이라고 많이 부르는데요, 여러 가지 증상들이 있습니다. 여러 가지 증상들이 있는데, 사실 무서운 것은 이거에요. 치료제는 없어요. 재활훈련으로 증상을 완화시킬 수 있다 라고 대대로부터 내려오고 있습니다. 사실상 되게 많은 것 같아요. 해외에도 검색해 보면 프로젝트 시작했다라는 글은 엄청 많아요 검색 결과는. 근데 완료했다 라는 결과는 별로 없어요. 꽤 많은 분들이 앓고 있는 것 같아요. 다음으로 또 작은 사례 하나를 더 얘기를 해볼게요. 이번에는 대작병을 어느 정도 이겨낸 분들에 대해서 이런 분들이 보통 많이 가는 케이스라고 생각을 하는데요, 개인적으로는 프로그래머로 게임 개발 시작하신 분들이 많이 밟게 되는 케이스라고 생각을 합니다. 이런 분들은 보통 이런 매우 좋은 교훈들을 학습을 많이 했어요. 사실 이런 교훈들은 굉장히 많잖아요. GDC에서도 많이 나오고, 포스트모템이나 책이라든가 개발 실용 서적들에서 아주 많이 나오는 교훈들이죠. 그래서 이런 교훈들을 잘 답습을 해서 보통은 이렇게 시작을 합니다. 만들기 쉬워 보이는 잘 알려진 게임을 모방을 하는 거죠. 보통은 이런 식으로 많이들 시작을 하시더라고요. 저도 그랬고요. 근데 여기서 +α를 해요. 그러면서 차별화를 시도를 하죠. 나만의 게임이다 이러면서. 실제로 구글에서 큰따옴표를 양쪽에 치면 저 단어가 모두 포함된 검색 결과를 보여줘요. 그래서 보시면 지구상에 중복을 포함한 자작 슈팅 게임이 12만개가 존재하는 것을 알 수가 있죠. 분명히 똥 피하기 같은 것은 더 많을 거에요. 어쨌든 정말 지구상에 수많은 게임들이 존재합니다. 총알피하기, 테트리스, 두더지잡기, 가위바위보, 같은 카드 찾기, 뱀 게임 이런 것들. 물론 저도 이 게임들 하나씩 개수를 늘리는데 일조를 했어요. 저도 프로그래밍 배우면서 하나씩 다 만들어봤어요. 어쨌든 실제로 제 주위에서 요즘에 창업 붐이잖아요. 실제로 창업을 하시거나 아니면 병행을 하면서 요즘 좋은 툴 많잖아요. 그래서 이런 것들로 첫 프로젝트로 인디게임을 만드시는 분들이 이렇게 생각을 하세요. 작고 빠르게 프로젝트를 한번 해보자 라고 시작을 하시는데, 사실 이런 이유 때문에 시작을 많이 하시죠. 바로 뭔가 옛날 고전 게임에서 감동받았던 대작을 만들고 싶은데, 바로 만들기엔 부담스럽고, 또 내가 팀을 바로 구했기 때문에 개발력 검증도 필요하기 때문에 이렇게 시작을 하십니다. 분명히 이런 팀에서는 도움이 될 거라고 저도 생각을 합니다. 근데 분명히 또 문제점도 있겠죠. 제가 생각했을 때 문제점들은 이런 거였어요. 일단은 당연히 중단 가능성이 여전히 존재한다고 볼 수 있죠. 제가 경험했던 가장 큰 원인은 이런 거였어요. 제가 뭔가 프로그래밍도 배우고 예를 들어, 아카데미를 나오거나 아니면 정말 오랜 시간을 공부를 했는데 내가 지금 만들고 있는 것은 똥피하기야. 이러면 아무래도 그렇겠죠 기분이. 그래서 다시 긍정적인 마음으로 “또 많은 걸 배웠다. 이거는 취업용 포폴에나 써야지” 이러면서 다른 좋은 회사 찾아가시게 되죠. 근데 저는 의문이 들었어요. 이렇게 작은 프로젝트를 시작하실 때 정말 많은 걸 배우게 될까? 그렇게 생각을 했을 때 좀 의문이 들었습니다. 예를 들어서 정말 만들고 싶은 게임은 RTS였어요 스타크래프트 같은 임진록이나 이런 명작들 많잖아요, 그런데 내가 이걸 만들기 위해서는 부담이 되니까 작은 프로젝트로 2D 슈팅 게임을 만들어보자 라고 계획을 했습니다. 분명 둘 다 똑 같은 게임 소프트웨어 개발이에요. 똑 같은 기술이 필요할거고요. 그런데 저는 좀 의문이 들었어요. 정말로 경험이랑 역량이랑 팀워크에 도움이 될까 의문이 들었습니다. 사실 가장 좋은 작은 프로젝트는 만들고 싶은 게임 작게 만들면 되는 거잖아요. 근데 이런 문제들이 있었기 때문에 한번 그런 교훈들을 답습을 해서 작은 게임을 만들어 보려고 했던 건데, 그래서 제가 경험해봤던 그런 것들에 대한 얘기를, 이런 좋은 교훈들을 버무려서 공유를 해드리려고 합니다. 그래서 준비한 게 시작 가이드인데요, 정말 주관적인 이야기에요. 참고만 해주셨으면 좋겠습니다. 세 가지 순서로 준비를 해봤습니다. 첫 번째로는 일단 게임을 구성하는 게임 메카닉스들을 리스팅을 하시는 거에요. 메카닉스라는 단어는 게임 기획 쪽 용어인데요, 사실 구글링 해보시면 이런 식의 정의들이 나옵니다. 게임 메카닉스란 시스템으로서의 게임을 설명하는 공식적인 규칙들과 개념들이라고 이렇게 구글링을 해보면은 친절하게 나오죠. 예를 들어서 이런 게 있어요. 다들 아시는 슈퍼마리오죠. 여기서의 메카닉스를 뽑아보면 플레이어는 좌우로 이동하고 점프를 한다는 규칙이 있죠. 그리고 위에서 적을 밟으면 처치할 수 있고요, 위가 아닌 방향에서 닿으면 처음부터 해야 하고, 성까지 도착하면 다음 스테이지 넘어가는 이런 메카닉스가 있습니다. 이렇게 내가 만들려는 게임을 구성하는 메카닉스들을 충분히 정의할 수 있을 정도로 디자인을 일단 구체화를 하시는 거에요. 이런 단계까지는 보통 하시리라고 생각을 합니다. 그 다음에 그 메카닉스들이 정말 많을 거에요 사실. 정말 디테일하게 메카닉스들을 뽑아내면 꽤 긴 리스트가 나온다는 걸 알 수 있을 겁니다. 보통은 그런 것들을 만들고 싶기 때문에 개발을 시작하시죠. 근데 우리는 만들려는 게 작은 프로젝트잖아요, 그렇기 때문에 핵심 메카닉스 한 개만 선택을 하는 거에요. 보통 게임의 볼륨이 커요. 근데 그 경우에는 보통 복합 장르일 경우가 많습니다. 이럴 경우에는 핵심 메카닉스가 좀 많아요. 핵심 메카닉스가 많다는 얘기는 즉, 복합장르라는 얘기죠. 단순하게 예를 들어도 이런 것들 다 복합 장르죠. RTS 조차도 복합장르에요. Real Time Strategy죠. Real Time 이랑 Strategy 복합이에요. SRPG도 마찬가지죠. Strategy랑 RPG의 복합입니다. 더 구체적인 예를 들어볼게요. 얼마 전에 스타크래프트2 군단의 심장이 발매를 했죠. 블록버스터 게임이죠. 그래서 대충 러프하게 어떤 핵심 메카닉스들이 있나 하고 정리를 해봤습니다. 일단 첫 번째로 유닛 특성을 살린 전략적 전투가 있죠. 가장 베이스에 깔린 핵심 메카닉스라고 생각을 해요. 그리고 두 번째로 실시간 전투랑 전장 연출 같은 게 있어요. 이펙트 막 터지죠. 그리고 세 번째로 자원 채취와 유닛 생산 관리를 합니다. 분명히 서로 분리할 수 있는 메카닉스라고 볼 수 있습니다. 그리고 건물도 지어야 하죠. 어디다 지어야 할지 정말 중요하죠 전략상. 그리고 미션 포인트를 줘요. 캠페인을 진행하게 되면 포인트를 얻어요. 그리고 그 유닛들을 업그레이드를 시키죠. 그 다음에 미션 클리어할 때마다 굉장히 아름다운 수려한 영상들로 스토리텔링을 마구마구 해줍니다. 이렇게만 봐도 블록버스터라 할만 하죠. 정말 다양한 핵심 메카닉스들이 섞여있다고 봅니다. 이 중에서 딱 한 가지만 선택을 하는 거에요. 이 부분에서 디자이너의 성향이 많이 드러난다고 할 수 있는데요, 저는 일단 이거를 선택을 해보겠습니다. 유닛 특성을 살린 전략적 전투. 그 다음에 세 번째입니다. 세 번째로는 핵심 메카닉스를 정했으면 그 메카닉스 하나로만 만들어진 참조 게임을 찾는 겁니다. 카피할 게임 찾으라는 얘기가 아니에요. 좋은 메카닉스는 역사적으로 계속 발전하면서 반복해서 사용되어 왔습니다. 그런 메카닉스를 하나로 만들어진 참조 게임을 찾는 거에요. 여기서 하나로 만들어졌다라는 게 중요한데, 아까도 얘기했듯이 메카닉스가 적을수록 볼륨이 작습니다. 그리고 이것은 제가 찾아보다가 느낀 건데, 메카닉스가 적으면서 잘 만들어진 게임이 고전게임 중에 굉장히 많더라고요. 고전게임 잘 만든 것을 찾아보면 메카닉스는 별로 없는데, 디자인이 굉장히 잘된 사례가 많았습니다. 그래서 아까 선택했던 ‘유닛 특성을 살린 전략적 전투' 라는 메카닉스를 가진 고전게임. 중요한 것은 실시간 처리와 자원관리가 없다는 점이죠. 그랬을 때 저는 이게 떠올랐어요. 장기랑 체스죠. 유닛 특성이랑 전략적 전투가 있더라고요. 그래서 이걸 골랐습니다. 그렇다면 이 게임에다가 아까 선택하지 않은 핵심 메카닉스를 몽땅 더했을 때 분명히 테마는 다를 수 있죠. 테마는 핵심 메카닉스에 제가 설정을 안 했습니다.  테마는 다를 수 있지만 스타크래프트2와 거의 유사한 경험을 플레이어들한테 전달해줄 수 있을 거라고 생각을 합니다. 그렇다면 맨 처음으로 돌아와서 원래 만들려던 게 RTS죠. 그리고 연습하기 위해 작은 프로젝트로 2D 슈팅게임을 만들어요. 그랬을 때 경험과 역량과 팀워크가 정말 도움이 될까 라고 생각했을 때 저라면 이걸 만들겠어요. 저걸 만들고 아까 나머지 메카닉스를 포함하는식으로 점점 발전시켜 나가면 원하는 게임을 만들 수 있을 거라고 생각합니다. 정리해 볼게요. 일단 작은 프로젝트 만드실 계획이 있으시다면 제가 추천 드리고 싶은 방법은 첫 번째로 만드시려는 게임을 구성하는 메카닉스 리스팅을 충분히 하시고, 그 다음 그 중에서 하나만 선택을 하십시오. 그 다음에 그 하나로만 만들어진 참조게임을 찾아서 참조해서 만드시면 좋을 것 같습니다. 그래서 충분히 디자인 하시고 핵심에 집중하면서 작게 개발하시면 작은 프로젝트가 곧 만들고 싶은 게임 프로젝트로 점점 변해가는 모습을 경험할 수 있을 거라고 생각합니다. 여기까지가 파트1이었고요, 두 번째 파트는 제가 즉흥적인 프로젝트라는 이름으로 정해봤습니다. 제가 제일 마음고생을 심하게 했던 그런 경험담이기도 합니다. 한번 진행해보겠습니다. 보통 인디게임 개발하시는 분들이 학생에서 바로 시작하시는 분도 있고 현업에서 근무를 하시다가 시작하신 분도 많죠. 보통은 프로그래밍 언어를 공부를 하시거나 아니면 게임 제작 도구들 게임메이커, 유니티 등 많죠. 그런 것들을 학습을 하시게 되면, 그 때 되면 굉장히 업 돼요. 만들 수 있게 되니까 내가 만들면 바로 시작할 수 있겠다 라는 생각이 듭니다. 그러면서 프로젝트를 시작을 합니다. 그래서 이때는 본격적으로 창작욕 해소를 하기 시작하죠. 여러 가지 데모도 만들어보고 시뮬레이트도 해보고, 그래서 작게 사례를 하나 들어보면서 진행해보겠습니다. 처음은 비슷해요. 아이디어를 발상합니다. 그러고 나서 굉장히 매력적인 플레이 장면들을 머리 속으로 떠올리죠. 이 장면을 플레이 하면 정말 매력적이고 재미있겠다. 이거는 약간 제 취향인데 재미있을 것 같아요. 이렇게 매력적인 장면들을 구성한 다음에 굉장히 의욕적으로 시작을 합니다. 그래서 구성했던 장면에 핵심 기능까지 보통은 다 완성들을 하시는 것 같아요. 이런 장면은 이랬으면 좋겠고, 이런 핵심 기능들이 필요하다는 것을, 핵심 기능까지는 보통 추진력 있게 밤도 새고 주말 버려가면서 회사 퇴근하고서도 새벽 2시까지 개발을 하시는 분도 많이 봤습니다. 저도 그랬고요. 그랬는데 이렇게 되면 거의 다 만든 것만 같은 기분이 들어요. “이제 콘텐츠 채우고 다듬기만 하면 완성이다” 그렇게 생각을 했는데, 이건 진짜 함정이죠. 콘텐츠랑 폴리싱이 반인데, 일단 시스템만 개발하는데 다 만들었다는 생각이 드는 거죠. 사실상 보통 게임 프로젝트를 진행 하시다 보면, 시스템, 핵심 시스템을 다 만들었다 그러면 사실 저쯤, 보통 저쯤 되더라고요. <그녀의 기사단>, <혈십자> 만드신 개발자로 유명한 1인 개발자 별바람님은 “다 만들었다 생각들 때가 겨우 절반 완성한 시점” 라고 얘기하신 적이 있습니다. 어쨌든 계속 개발을 진행한다고 해볼게요. 이렇게 되면 일단 핵심 시스템을 만들었어요. 근데 수많은 고민거리가 생기기 시작합니다. 예를 들면 이런 거죠. 승리조건 어떻게 하면 더 재밌어질까, 패배조건 어떻게 하면 재밌어질까 뭔가 시스템이 부족한 것 같은데 어떤 걸 추가해야 재미있어질지 여러 가지 이런 고민들을 리스트 하게 됩니다. 그래서 게임을 난도질하기 시작합니다. A를 추가해봐요. 그 다음에 일부분을 B로 바꿔보고 “C가 좀 식상해, 재미가 없어 보여” 제거하고 D를 포함해요. 이걸 계속 반복합니다. 추가하고, 고치고, 빼고. 이 과정이 굉장히 괴로워요. 그래서 이제 “아 이게 바로 창작의 고통이구나” 하면서 괴로워합니다. 시간도 굉장히 빨리 가요. 저 같은 경우는 방금 그 과정을 한 1년반정도 겪어본 적이 있었어요. 특히나 개발 기간이 길어지는 프로젝트들 대부분이 이런 부분 때문에 길어지는 것 같습니다. 저도 회사 다닐 때 한 번 경험해 본적 있고요, 어쨌든 이렇게 되면 보통 프로젝트 방향성은 이상해져요. 우리가 맨 처음에 뭘 만들려고 했는지 잘 모르겠고, 일단 어떻게든 완성만 하고 싶고, 재미가 있는지도 잘 모르겠고. 이때 주위에서 누가 “진짜 재미있다” 이러면 절친이 돼요. 너무 고마워요. 이때 또 노홍철 선생님의 긍정적인 마인드로 “정말 많은 걸 배웠다. 나는 핵심 시스템까지 만들어봤어” 이러면서 또 프로젝트를 동결하는 사태가 발생하는 것 같습니다. 그러면서 어떻게든 또 의지를 가지고 완성까지 가져가시는 분들이 있어요. 그러면 제 경우에는 이렇더라고요. 결국에는 얼렁뚱땅 마무리한 거에요. 되게 익숙한 메카닉스들 있잖아요, 시간제한 넣어서 게임오버 시켜버리고, “고득점 넘으면 알아서들 재미있게 하겠지” 넣어버리고, 오래 버티기 만들어서 게임오버 넣어버리고 이러면 재미있게 하겠지 이러면서 얼렁뚱땅 마무리를 합니다. 여기까지만 해도 참 흐뭇해요. 만약 온라인 게임이라면 이러면 또 기대를 하게 되죠. 소셜 요소가 들어가면 재미있어질 거야. 접속자가 많아지면 애들이 창발적으로 플레이 하면서 놀 거다 기대를 하죠. 이러면서 개발팀의 신앙심도 올라갑니다. 신앙심 개발이라고 불러요. 어쨌든 여기까지 이야기 했던 게 제가 즉흥적으로 프로젝트를 시작 때 다 경험을 하고, 충분히 일어날 수 있는 일이라고 생각을 합니다. 경험담이기도 하구요. 그러면 고민을 해봤어요. 이렇게 계속 즉흥적으로 만들기를 시작했었는데 문제들이 많았는데, 어떻게 하면 이런 문제점들을 해결할 수 있을까 고민을 해봤는데, 사실은 너무 뻔해요. 너무 뻔한 대답이죠. 사실상 굉장히 프로토타이핑에 대해서는 장점에 대해서 굉장히 많이 언급이 됐다고 알려져 있습니다. 몇 년 전부터 이미 알려졌었죠. 하지만 현실은 안 쓰죠 다들. 활용도도 낮고, 효율성도 의심이 되고. 일단 그런 거 할 시간이 없다는 게 가장 크죠. 저도 회사에 있을 때 많이 써보려고 했었는데 힘들더라고요. 일단 프로토타이핑 해야 하는데 야근 합시다 하면 누가 좋아하겠어요. 나오는 것도 없는데. 그래서 제가 한번 프로토타이핑을 해봤습니다 인디게임 만들면서. 회사에서는 좀 힘들었고요. 먼저 이것은 제가 만들었건 게임 중에 하나인데, 물리가 들어가요. 마녀가 하늘을 날아다니는 물리가 들어가고요, 그리고 배경이 여러 개 레이어로 있어가지고 그런 것들을 실험해보고 싶었어요. 플래시로 간단하게 물리를 실험해봤는데, 이때 썼던 펙터를 완성할 때까지 그대로 썼어요. 그리고 이건 버렸죠. 이거는 이걸 테스트 하기 위한 프로토타입이었으니까. 그리고 이거 같은 경우는 보드게임으로 만든 건데요. 종이컵이 플레이어고, 이거가 몬스터들이에요. 이걸 쓸어담는 게임이에요. 웨이브가 몰려오고 쓸어담는 게임이에요. 마법으로. 그래서 카드들이 두들갓처럼 원소 조합하는 그런 카드들이고, 마법을 조합해서 얘네를 쓸어 담는 그런 게임이에요. 그래서 만들어서 한 8번 정도 패치를 하면서 진행을 해봤고요. 그리고 이거 같은 경우에는 각 카드들이 각 플레이 시간에서 이루어질 수 있는 시스템적인 이벤트들이었습니다. 그래서 전체 게임이 흘러가는 플로우를, 이게 타임라인이고요, 이렇게 또 검증을 해봤고요. 해봤더니 괜찮더라고요. 만드는데 하루도 안 걸렸어요. 반나절 만에 다 만들어버리고 취할 것은 취하고 굉장히 도움을 많이 받았습니다. 그래서 실험이 필요할 때 이렇게 디지털이나 아날로그 가리지 않고 유연하게 사용해 봤어요. 굉장히 좋더라고요. 그렇다면 즉흥적인 프로젝트를 예방하기 위해서 어떻게 프로토타이핑하면 될까? 그래서 제가 좀 더 고민을 해봤습니다. 문제를 해결하려면 문제점을 정의를 해야겠죠. 제가 정의한 문제점은 이랬어요. 일단은 게임에서 메카닉스가 아니라 장면을 핵심으로 했다는 게 저는 제일 큰 문제라고 생각했습니다. 거기다가 이 장면은 또 실제 존재하는 장면이 아니잖아요. 머릿속으로만 생각한 장면입니다. 그렇기 때문에 수려한 그래픽, 조화로운 사운드, 역동적인 연출 이런 것들로 머릿속이 포장이 된 거죠. “나는 <블레이드 앤 소울> 같이 멋진 그런 장면이 들어있는 게임을 만들 거야” 이러면서. 그리고 그 장면을 얼추 구현함과 동시에 방향성이 희미해져 버립니다. 장면이 핵심이었으니까요. 핵심을 만든 거에요 지금. 그래서 진단을 해봤어요. 그렇다면 진단해보니까 멋진 장면은 일부분이죠 분명히. 게임은 게임으로서 존재를 해야 합니다. 그렇지만 멋진 장면은 일부분의 연출일 뿐이라는 사실이 진단 결과였고요, 그리고 일단 핵심 메카닉스가 많이 부족했다 라는 부분도 진단 결과였고요. 그리고 가장 중요한 게임으로 성립하기 위한 목표가 불명확했다라는 문제점이 있었죠. 그래서 이걸 어떻게 하면 프로토타이핑으로 잘 풀어볼 수 있을까를 삽질을 많이 하다가 좋은 솔루션에 해당하는 슬라이드를 하나 보게 됐어요. 이 슬라이드인데요, 인용을 해봤습니다. 보시면 아시겠지만 우측 하단에 GDC2013이라고 써있죠. 이 슬라이드가 숫자만 바껴요. 몇 년째 숫자만 바뀌고 있어요. 매 년마다 GDC에서 하는 보여주는 슬라이드인데요, 지금 이런 식의 강의 형태가 아니라 워크샵이에요. 이렇게 워크샵 형태로 진행이 되고, EA/Maxis의 Creative Director인 Stone Librande 이 사람이 만들고 진행한 워크샵입니다. 제목은 ‘Paper Simulations of Digital Games’에요. 예측이 되시죠. 보통 디지털 게임을 갖다가 페이퍼로 시뮬레이트를 해보는 거에요. 한번 같이 보시면 일단 디지털 게임을 하나 선택을 합니다. 어떤 게임이든 상관없어요. 디지털 게임을 선택하고, 조이스틱을 제거해요. 그리고 사운드 음악도 제거를 합니다. 그 다음에 마지막으로 그래픽까지 제거를 합니다. 이렇게 되면 아까 문제점이었던 포장된 연출이 몽땅 제거가 되는 거죠. 연출들이 전부 다 제거가 됩니다. 그랬을 때 남는 것은 이런 게 남겠죠. 미학이라는 것은 사실 좀 약간 생소한 분도 있을 텐데요, 이 부분은 사실상 재미에 유사한 부분이죠. 보통 라프 코스터의 재미이론이라든지가 아니면 마크 르블랑이 정의한 8 Kinds of fun 이라는 그런 것들로 대체할 수 있을 것 같고요. 플레이어들이 겪게 되는 경험이죠. 추상적인 개념이고요. 메카닉스는 아까 위에서 얘기했죠. 실제로 GDC에서, 이 사진은 GDC2012을 다녀왔던 어떤 분의 블로그에서 발췌한 사진들인데요, 여기 보이시는 슬라이드가 우리가 아까 봤던 그 슬라이드고요, 이 슬라이드를 보고 참석한 분들이 이런 컴포넌트를 가지고서 실제로 디지털 게임을 보드게임으로 만들어보고 실제로 그 미학과 메카닉스들이 살아있는지를 검증해보는 그런 워크샵이에요. 매년마다 열리고 있고요. 이렇게 미학과 메카닉스들이 유지된다는 걸 알 수 있고요, 실제로 이 슬라이드를 진행한 Stone Librande가 이런 얘기를 합니다. “개발할 때 이 기법들을 활용해봐요. 빠르고 저렴하고, 제일 중요한 것은 프로그래머, 아티스트가 없어도 가능합니다.” 그리고 코스티켄의 게임 이론으로 유명한 Greg Costikyan 아저씨가 이런 얘기를 해요. “전자게임의 구조도 보드게임의 규칙과 같은 방식으로 플레이어의 행위에 영향을 미칠까? 그랬을 때, 의심할 필요도 없이 그렇다” 라고 얘기를 합니다. 결국은 전자게임의 구조와 보드게임의 규칙이 똑같다 라는 얘기에요. 구글링을 또 해봐요. ‘Game Paper Prototype’이라는 제목으로 구글링을 해보시면 이런 사진들이 어마어마하게 나옵니다. 전 세계적으로 이런 사진들이 어마어마하게 나오는데요, 이렇게 다양한 방식으로 활용을 한다는 것을 알 수가 있죠. 그래서 다 빼고 남은 미학과 메카닉스를 담아서 보드게임으로 프로토타입을 제작을 해보는 겁니다. 처음부터 끝까지 플레이 가능, 저도 이게 제일 중요한 장점이라고 생각하는데요, 보드게임으로 게임을 만들어보면 일단 내가 만들려는 게임을 처음부터 끝까지 한번 플레이 해볼 수가 있어요. 한 사이클을 돌아볼 수가 있습니다. 아무것도 없이도. 그렇게 되면 디자인 문제점이 나와요. 나올 수밖에 없어요. 처음 디자인 하면 문제점이 나올 수밖에 없더라고요 보통은. 그리고 내가 개발하면서 역량을 집중할 부분이 어디일 지를 가늠할 수가 있게 돼요. 이런 장점들이 있습니다. 그래서 다시 한번 제가 또 직접 해봤습니다. 이 게임 같은 경우는 포커 같아 보이지만 굉장히 건전한 학교 야자 탈출하기 게임이에요. 그렇게 안보이시겠지만, 이 포커 카드들이 교실과 교문 사이의 거리를 나타내고요, 플레이어들마다 포커카드를 덱을 하나씩 손에 들고 특정 규칙에 따라서 한 장씩 버려요. 다 버리면 탈출하는 거에요. 그런 식의 게임이었고요. 이거는 온라인 게임 만들어보려고 프로토타이핑 해봤던 건데, 캐릭터 시트가 4개죠, 4명 접속해있는 그런 서버가 아주 한가한 상황이고요, 가운데 임무 카드들이 있고, 여기는 아이템 카드들이 있고, 이거는 주사위 대용으로 아이패드로 주사위 어플을 받아서 한 거고요. 이거 같은 경우는 우주 배경의 시뮬레이션 게임이에요. 빨간색 진영과 파란색 진영이 전쟁하는 그런 게임인데, 보시면 이거 다 종이로 만들었죠. 카페에서 혼자 종이 자르고 있으면 옆에서 쳐다봐요. 되게 부끄럽기는 합니다. 이런 것도 집에서 해본 거에요. 제가 지금 회사로부터 독립된 몸이잖아요. 그래서 회사를 다니고 있을 때 컴퓨터로 제가 만든 게임 제가 테스트 하고 있으면, 제가 어머니 모시고 살고 있는데, 어머니가 지나가시면서 “또 게임하냐” 이러세요 내 직업인데. 근데 이제는 이런 거 하고 있으면 아무 말씀도 안 하세요. 보기에 좀 그래요. 근데 마지막으로 이거는 화투패에요. 이것도 집에서 해본 건데, 이불 깔고 이렇게 화투패로 또 놀고 있으면 어머니께서 한번 또 쳐다보시죠. 이 게임 같은 경우에 이 뒤집힌 화투패가 안 밝혀진 지역들 약간 워포그같은 그런 느낌이죠. 어미 새가 여기 둥지에 있는 아기 새에게 먹이를 물어다 주면서 키우는 프린세스 메이커 새버전 그런 느낌의 게임이었습니다. 이런 게임들을 해보니까 처음부터 끝까지 모두 진행이 가능했어요. 그러면서 빠르게 이터레이션 돌면서 빠르게 수정이 가능했고요, 이렇게 디자인을 검증해볼 수 있었습니다. 이렇게 해보다니까 몇 가지 유의사항들이 생각이 나서 정리를 해봤습니다. 첫 번째는 실험 목적을 꾸준히 확인하는 거에요. 지금 내가 게임을 처음부터 끝까지 확인하기 위해서 프로토타이핑을 하는 건지, 아니면 특정 시스템을 프로토타이핑을 하고 싶어서 하는 건지 목적을 꾸준히 확인할 필요가 있고요. 종이로 만든 거잖아요. 그렇기 때문에 일단 이건 쓰고 버릴 거에요. 쓰고 버릴 거. 빠르게 빠르게 수정, 반복이 중요하다 라는 것도 유의사항이 될 수 있겠고, 그리고 디지털 아날로그 가리지 말고 유연하게 라는 부분도 제가 프로토타이핑 할 때 플래시도 쓰고 종이도 쓰고 그랬잖아요. 제가 최근엔 또 시뮬레이션 게임을 만들고 있는데 엑셀VBA로 주로 열심히 프로타이핑	만들고 있습니다. 유연하게 이렇게 사용하는 것도 좋고요. 또 모든 것은 임시일 뿐입니다. 절대로 디테일 하게 프로토타이핑 하지 마시고요, 시간 아까우니까. 모든 것은 임시일 뿐이라고 생각하시고 하셨으면 좋겠고요. 그리고 프로토타입 하나에 모든 걸 담으려고 하지 마세요. 힘듭니다. 액션 게임 같은 경우는 특히 힘듭니다. 어떻게 종이게임으로 액션게임을 만들겠어요. 그런 것들 여러 개로 나눠서 프로토타이핑 하는 것도 방법이라고 볼 수 있겠습니다. 이런 질문들도 있었어요. 시각, 청각적 미학은 어떻게 프로토타이핑 하냐. 사실 저도 이런 걸 깊게 실습 해본 건 없는데, 이런 대안들이 있겠더라고요. 비슷한 미학을 담은 그림, 음악들을 활용하는 거죠. 가령 컴포넌트를 만들 때 그림 출력해서 카드로 만든다거나 아니면 Youtube 동영상 정지해놓고 특정 조건이 만족되면 보여주는 거에요 플레이어한테 그리고 테스트 플레이 할 때 BGM이나 이런 거 깔아서 적절하게 써주는 방법도 있고요. 그리고 두 번째로 이런 것은 저도 궁금했어요. 실시간 처리 프로토타입은 어떻게 만드느냐. 보면 게임 디자인 실용 서적으로 유명한 <The Art of Game Design>이죠. 이 책을 쓴 Jesse Schell 교수가 이런 얘기를 했어요. “FPS 게임도 페이퍼 프로토타입이 가능하다” 라고 얘기했는데, 어떻게 되는지 궁금했어요. 다음 장 넘겨보죠. 이걸 쓰더라고요. 아마 많은 분들이 뭔지 아실 거에요. 악기 연주할 때 박자감을 도와주기 위해서 틀어놓는 거에요. 1초마다 똑딱거리는 거죠. 이렇게 똑딱똑딱. 시간도 정할 수 있고요. 웹버전 소프트웨어도 있어요. 그래서 5초 간 똑딱거리기를 할 수 있고요, 이런 식으로 활용합니다. 그래서 이거를 어떤 식으로 쓰냐 하면, 5초마다 똑딱거리게 셋팅한 다음에 진행자들이 컴포넌트 하나씩 들고서 똑딱할 때마다 동시에 움직이는 거에요. 그러면 게임 자체는 약간 슬로우 모션처럼 보일 수 있겠지만 그 순간순간에 그런 의사선택을 하는 플레이 양상은 테스트해볼 수 있겠죠. 사실 실시간 처리를 원한다면 직접 해보는 게 제일 편하겠죠. 저도 만들던 게임 중에 야구 배팅하는 그런 게임을 하나 만들었었는데, 그 게임의 최고의 프로토타입은 동네에 있는 실내 야구연습장이었어요. 그걸로 모든 프로토타입이 끝나더라고요. 사실 결론은 이거라고 생각해요. 테마파크의 놀이기구를 만든다는 생각으로 만드시면 될 거라 생각해요. 결국은 테마파크의 어트랙션도, 게임도 플레이어에게 좋은 경험을 전달해주기 위한 엔터테인먼트잖아요. 그리고 또 <The Art of Game Design>책을 쓴 Jesse Schell 교수도 실제로 디즈니파크에서 어트랙션 디자이너로 일한 경험도 있고요. 그래서 정리를 해보겠습니다. 본격적으로 개발을 시작하시기 전에 일단 멋진 장면은 게임의 일부일 뿐이다 라는 사실을 꼭 기억하셨으면 좋겠고요. 그 다음에 종이와 펜과 주사위를 준비하시고 게임의 시작부터 끝까지 꼭 한번 보드게임으로 시뮬레이션 해보셨으면 좋겠습니다. 그렇게 하시면 구상했던 그런 멋진 플레이 장면들을 내가 만드는 게임 속에 성공적으로 담으실 수 있을 거라고 생각합니다. 여기까지가 Part2 였고요, 마지막 Part입니다. 마지막 Part는 만들어졌으면 하는 게임 이라는 제목으로 제가 준비를 해봤습니다. 제가 요즘에 가장 고민을 같이 하고 있는 그런 내용을 담기도 했습니다. 보통 인디게임을 만드시는 분들이 이런 목적으로 게임 개발을 시작하신다고 알고 있어요. 저도 그렇고요. ‘이런 게임이 이랬으면 좋겠다, 이런 게임이 나왔으면 정말 재미있겠다’ 라는 생각으로 게임 개발을 시작을 하시죠. 사실 저도 이게 가장 큰 장점이라고 생각을 해요. 제가 회사를 다니면서도 인디게임을 만들었던 큰 장점이라고 생각을 하고요. 근데 개발자가 신은 아니잖아요. 빛이 있어야 한다고 뚝딱하고 나오는 게 아닌 것처럼 너무 당연하게도 정말 길고 긴 개발 과정을 견뎌내야 합니다. 보통 MMO같은 거 만들 때도 다 5년 6년 걸리잖아요. 저도 전 회사 <RaiderZ>만들 때, 들어갈 때 20대 초반이었는데 지금. (껄껄) 그래서 이번 Part에서도 케이스 하나를 예를 들면서 이야기를 진행해 보겠습니다. 앞에서 나왔던 장점들을, 교훈들을 다 답습을 해서 방향성과 메카닉스를 구체적으로 잘 정의했어요. 그래서 디자인도 만족스럽게 나왔어요. 그리고 처음부터 끝까지 프로토타이핑 다 해봤어요. 게임이 돼요. 게임으로써 성립이 돼요. 기쁘죠. 만들면 돼요. 그래서 앞에서 나왔던 장점들을, 교훈들을 다 승화를 시켜서 진행을 합니다. 그래서 개발을 본격적으로 시작을 하게 됩니다. 김디자이너님과, 김프로그래머님, 김아티스트님 다들 경력이 빠방하시죠. 그래서 개발을 시작을 해요. 방대한 퀘스트 콘텐츠가 필요하고요, 다양한 AI NPC가 필요하고, 그 다음에 실사 컨셉의 멋진 아트가 필요한 이런 프로젝트를 시작을 합니다. 진행을 해보는데, 문제가 생겼어요. 기획자기 스토리를 못써요. 재미없대요. 쓸 수는 있겠는데, 이게 뭔가 자꾸 재미가 없대요. 그리고 프로그래머도 경력이 빠방한데 지루하대요. 자꾸 다른 작업을 하고 싶어해요. 자꾸 AI만들다가 렌더러 고치고 있어요. 셰이더 만지고. 그리고 아티스트도 실사 컨셉 멋진 아트 그려야 하는데, 귀여운 걸 좋아해. 실사가 재미가 없대요. 귀여운 거 그리겠대요. 재미가 없어요. 괴롭죠. 재미없는 작업하는데. 재미없는 거 시키는 거만큼 괴로운 일이 없잖아요. 그러면서 계속 이런 생각을 하게 되죠. ‘이걸 계속 만들어야 하나?’ 라는 생각이 들면서 일이라는 글자와 집이라는 글자가 떠오르고, 계속 자기 자아 성찰하는 시간이 길어집니다. 그러면서 긍정적인 마음으로 인디게임 프로젝트를 하면서 다시 또 한번 많은 걸 배웠다 라는 생각으로 프로젝트를 동결하게 되죠. 무엇이 문제였는지 물어보면 명확하죠. 게임 디자인도 괜찮았고요, 개발팀도 괜찮았어요. 짱구 아빠 스펙 좋잖아요. 모든 상황이 괜찮은 것 같았어요. 그런데 문제는 성향이겠죠. 성향이 안 맞았어요 개발팀과 프로젝트의. 성향이 맞지 않으면 이렇게 되게 재미없는 작업을 계속 하게 될 수 있고 괴로운 기간이 길어질 수 있습니다. 그래서 자신의 제작 성향을 객관적으로 파악할 필요가 있다고 생각합니다. 그리고 자신의 이런 개발 성향을 파악한 이후에는 당연히 프로젝트의 제작 과정도 파악을 해야 하죠. 내 성향과 맞는지 비교를 해야 하니까. 그래서 저는 또 고민을 해봤어요. 이거를 어떻게 하면 내 성향이랑 프로젝트 과정이 맞을 수 있는지를 알 수 있을까 그렇게 고민을 해봤더니 또 같은 대답이 나왔어요. 프로토타이핑을 활용하자. 그래서 개발 과정을 시뮬레이션 해보자 라는 결론이 나왔습니다. 사실 앞에서 얘기했던 프로토타이핑의 포커스는 메카닉스와 미학 검증이 있었죠. 게임으로서 이게 존재 가능한가. 이번에는 바꿔서 제작 과정에 포커스를 두는 거에요. 사실 같이 할 수는 있겠죠. 다만 포커스를 한번 노리는 거죠. 그래서 제가 한 번 또 경험을 해봤습니다. 이것은 제가 2012년도에 제가 짧게 만들었던 게임인데요, 포인트 앤 클릭 방식의 되게 짧은 플레이 타임을 자랑하는 어드벤처 게임이에요. 완성한 게임인데, 시작은 되게 간단했어요. 제가 컴파일이나 Rebuild All 걸어놓고 시간이 오래 걸리잖아요. 그러면 옆에 있던 A4용지, 이면지를 꺼내서 그림을 그리기 시작합니다. 근데 점점 그리면 그릴수록 고양이가 많아지죠. 고양이 그리는 게 재미있더라고요 귀엽고. 그래서 이러다가 작년 이맘때였어요. 작년 이맘때 NDC2012에서 이은석님이 키노트로 화이트데이 포스트모템 강연을 했죠. 제가 이거를 가운데 자리에 앉아서 들었는데, 강연 내용 중간에 이런 어드벤처 게임을 제작하는 과정이 굉장히 디테일 하게 다뤄졌어요. 다시 한번 찾아보셔도 굉장히 디테일 하게 나와 있는 것을 알 수 있어요. 캐릭터 상의 인물 관계도 이런, 월드에 대한 설계도, 관문 배치 어디에 어떤 관문이 배치되고, 어떤 식으로 풀어야 하며, 열쇠는 어떻게 있고, 다음에 어떤 것이 있다 이러 것들이 디테일 하게 나와있는데, 저는 이게 너무 재미있었어요. 이 과정이 너무 재미있어 보였어요. 사실 화이트데이 저는 많이 못했어요. 무서운 거 싫어해서. 근데 이 과정이 너무 재미있어 보이는 거에요. 그래서 귀가를 해서 너무 재미있겠다 생각이 들어서 따라 해봤어요. 게임 만들어지기 전이에요 아직. 사이툴을 켜서 대충 그려봤어요. 고양이가 이렇게 있고 고양이가 탈출해서 이동을 하면 재미있겠다 라는 생각이 든 거에요. 막 그렸어요. 프로토타입까지 만들어봤어요 간단하게. 이런 것들 다 오브젝트들이겠죠. 관문들 만들어 봤어요. 너무 재미있는 거에요 만드는 게. 이 과정이 너무 재미있어요. 그래서 만들었어요. 프로토타입 만들고 첫 번째 마일스톤 버젼 나오고요, 그 다음에 다듬고 광을 내서 완성을 했어요. 한 달 걸렸어요. 이 기간 동안에 회사가 되게 바빴어요. 온라인 게임 회사였고요, 온라인 게임 회사가 바쁜 경우는 다들 상상되시죠. 그리고 저는 서버 프로그래머였어요. 그리고 퍼블리셔 담당이었어요. 정말 바빴거든요. 근데 어떻게든 되더라고요. 잠자는 시간 줄이고 주말 쓰고 그러니까. 괜찮더라고요. 만드는 과정이 재미있으니까 사실 고생한다는 느낌도 안 들었고요, 회사에서 쌓였던 스트레스가 만들면서 풀리더라고요. 그 다음에는 이거는 제가 가장 최근에 만들었던 게임인데요, 이 게임 같은 경우에는 마녀가 날아다니면서 마법을 쓰는 게임이고요. 특징으로 말하면 NPC가 굉장히 많이 나옵니다. 아군 NPC도 많이 나오고, 적군 NPC도 많이 나옵니다. 굉장히 쓸어 담는 그런 게임이에요. NPC들도 날아다니고. 이 게임도 시작이 간단했습니다. 언젠가 한번 마녀가 나오는 그런 게임을 만들어 보고 싶었어요. 마녀가 주인공이고 마녀가 나오는 컨셉의 게임을 만들어보고 싶었어요. 그래서 또 이렇게 끄적끄적 같이 만들었던 친구와 같이 그림을 그려보다가 뽐뿌를 받았죠. 그래서 만들기 시작했습니다. 진행했어요. 설계도 그려보고, 첫 번째 마일스톤버전까진 빨리 나왔습니다. 나왔는데 이 게임이 웨이브가 있었어요. 웨이브 단계가 1단계부터 30단계까지 있었고요, 몬스터들이 종류별로 섞여서 바리에이션을 치면서 몬스터들이 등장하는 게임이죠. 그래서 이번에 파워포인트로 웨이브 단계들을 목업을 해놓은 거에요. 일종의 프로토타입을 만들어 본건데, 첫 번째 웨이브에서 이런 애들이 어떻게 나오고, 두 번째에서 어떻게 나오고 이런 것들을 목업해본 거죠. 목업을 열심히 했습니다. 일주일 해보고 계속 밤에도 작업을 하고 했는데, 재미가 없는 거에요. 제가 스토리가 있고, 이런 스토리가 있는 게임을 만들어가는 건 참 재미있게 할 것 같은데, 뭔가 웨이브 만드는 것은 원인은 잘 모르겠지만 재미가 없었어요. 그래서 괴로운 과정이 이어집니다. 이러면서 한 달 두 달 시간이 흐르고 있어요. 만들어야 하는데 만들어야 하는데 이러면서. 한 달 두 달 시간을 까먹다가 생각을 바꿨죠. 작업할 게 많으니까 일단 보스 AI를 먼저 만들어 놓고 그 다음에 완성을 하자 라고 해서 보스 AI를 만드는데, 재미있는 거에요 보스 AI 만드는 게. AI 만드는 게 재미있는 것을 새삼 깨달았어요. 그래서 게임을 한 번 수정해봤어요. 게임을 수정해서 웨이브 같은 걸 빼버리고 아예 개발 과정 자체를 바꿔버리자 라고 생각을 했는데요. 최대한 제가 표현하려고 했던 미학은 유지를 하면서 게임을 수정했습니다. 웨이브 관련 모듈을 전부다 빼버렸고, 그 다음에 적 NPC타입과 AI타입을 추가했고, 아군 NPC AI 다채롭게 보강을 했고, 원래 한 마리였던 아군 NPC를 5마리로 늘렸고, 보스의 AI를 확 보강했어요. 웨이브 관련 모듈이 빠졌으니까 보스가 알아서 인공지능으로 소환을 하게 하자 라고 바꾼 거죠. 그래서 보스의 AI 관련 클래스가 늘어났어요. 바꾸고 나니 만들기 괴로운 작업이 전부 제거가 되고, 그리고 만들기 재미있는 작업이 늘어난 거죠. 그래서 작업을 했습니다. 이렇게 변경한 디자인 대로 빠르게 프로토타이핑을 해봤고요, 그랬더니 바로 이거야. 너무 재미있는 거에요 만드는 게. 그래서 2주만에 만들었습니다. 계속 고생하던 걸, 너무 기뻤어요. 정말 좋더라고요. 그래서 이렇게 경험을 해보고 나니까, 이렇게 프로타이핑으로 제작 과정을 간접적으로 경험해본 것이 정말 의미 있는 일이다 라고 깨달았어요. 여러 가지 프로토타이핑을 해본 것이 참 의미가 있구나 라고 생각을 하고, 이런 생각이 든 거죠. 여러 가지 정말 많은 작업들이 있잖아요. 사운드도 붙여야 하고, 여러 가지 그림들도 그려야 하고, 기능도 다 만들어야 하고 아이템도 추가해야 하고 많은데, 이런 것들이 나의 개발 성향이랑 맞는지를 검증을 빨리 해보는 게 중요하다 라고 깨달았죠. 어떤 작업은 정말 재미있고 매력적이고 남들이 우러러볼만한 좋은 작업이라고 생각을 해서 직접 해봤는데 재미가 없어요. 어떤 작업은 좀 어려워 보이고 힘들어 보이는데 직접 해보니까 재미가 있어요. 이런 경우가 있을 수 있는 거죠. 그리고 그런 작업들이 또 이 게임을 만드는데 어느 정도 시간이 투여될 지가 중요한 거죠. 정말 재미있는 작업들이 있긴 있는데 그 시간은 하루밖에 안되고 나머지 작업이 재미없는 작업이 90% 이상이다 이러면 못만들겠죠. 그래서 이렇게 검증을 한 번 한 이후에 그렇게 프로타이핑 하면서 만드는 과정이 재미있었다 그러면 이건 내 게임이에요. 내가 만들 수 있는, 내 성향에 맞는 프로젝트라는 거죠. 그리고 그 반대라면 제작과정이 괴로울 수 있고, 기간이 아주 길어질 수 있다라는 것을 반드시 인지해야 합니다. 그렇다면 만약 이렇게 반대인 과정이 프로토타입 결과가 나왔다 그랬을 때, 여러 가지 해결책들이 있겠죠. 제일 쉬운 것은 동료 영입이죠. 사실 좀 인도적으로 안 맞기는 해요. 나는 재미없는데 내 재미없는 작업을 대신해줄 친구를, 동료를 영입한다는 거니까. 이런 방법도 있고요. 그 다음에 제가 경험했던 방식으로 디자인을 수정해서 제작 과정을 변경하는 거죠. 이런 방법도 있을 수 있고요. 세 번째는 모두 의지로 극복하는 게 방법일 수 있고요. 의지를 가지고 파이팅 해서 만드는 거죠. 마지막으로는 조심스러운 발언일 수 있는데요, 내가 사실 이 게임을 직접 개발하고 싶은 것은 아니고, 이런 멋진 게임의 개발자라는 명함이 필요한 것은 아닌지를 한번 스스로 질문을 해볼 필요가 있다고 생각을 합니다. 사실 욕심이잖아요. 이거는 얼마 전에 유나이트 코리아라는 유니티 엔진 행사가 있었어요. 거기서 <언데드 슬레이어> 개발자 김동규님이 얘기했던 내용인데요, “만들면서 재미가 없었으면 게임이 잘 나올 수가 없었겠죠”라고 얘기를 하셨는데, 이분은 강연 내내 그 얘기를 했어요. 나 재미 있으려고 시작한 프로젝트다 라는 얘기를 많이 하셨고요, 그리고 슬라이드에는 없지만 어제 키노트에서 서민 대표님이랑 같이 나오신 허영만 작가님도 마지막은 재미있게 살자라고 얘기를 하셨었죠. 어제 들으신 분들 계실지 모르겠지만 이은석님 강의 마지막에서도 내가 좋아하고 내가 잘 만들고 남이 내가 만들기를 원하는 그런 것들을 만들어라 라고 얘기를 하셨었죠. 정말 공감이 많이 되는 내용이었습니다. 그래서 정리를 해보겠습니다. 게임 소프트웨어 개발 기술이 있어도 개발 완주는 여전히 어려운 일인 것은 사실이죠. 그래서 디자인만큼 개발 과정도 중요하다라는 걸 깨닫게 됐고요, 그리고 프로토타이핑으로 개발 과정을 시뮬레이션 해서 검증해보는 것도 의미 있는 작업이라는 것도 깨닫고, 나의 성향과 잘 맞는지 그 프로젝트에 대한 궁합을 확인을 하는 게 정말 의미 있는 일이라는 것을 깨달았습니다. 이렇게 검증을 하면 만들어졌으면 하는 게임의 개발자가 될 가능성이 충분히 올라갈 거라고 생각을 합니다. 결론입니다. 3분 남았는데요. “이 게임의 개발자가 되고 싶다”라는 생각을 하신다는 것은 결국 이 말과 똑같은 얘기죠. “직접 만들어야 한다” 정말 길고 험난한 개발 과정이 될 거에요. 이런 개발 과정 잘 하기 위해서 핵심 메카닉스를 찾아서 작게 시작하시고, 시작과 끝을 충분히 프로토타이핑 해서 검증해보시길 바라고, 그리고 개발 과정과 나의 성향에 궁합을 반드시 한 번쯤은 확인해보시길 추천 드리고 싶습니다. 그래서 즐겁게 개발을 했으면 좋겠습니다. 감사합니다. 
(질문자)_궁금한 게 인디게임 개발을 한다고 하면 보통 혼자서는 쉽지가 안잖아요. 그래서 팀을 꾸리기 마련인데, 항상 궁금했던 것이 아이디어를 먼저 정하고 그걸 같이 만들 팀을 모으는 것이 맞는 것인지 아니면 팀을 먼저 만들고 난 뒤에 그 안에서 아이디어를 정하는 게 맞는 건지 궁금합니다.
(발표자)_저도 예전에 정말 많이 고민했던 문제인데요, 이건 제 스타일이에요. 제 스타일을 말씀 드리면 저는 지금 가지고 있는 철학 중에 하나가 팀을 먼저 모으지 말자라는 게 제 철학이거든요. 아직 디자인도 시작하지 않은 상태에서 팀을 모아버리면 굉장히 민주적인 게임이 나오더라고요. 모두의 아이디어를 반영해서 민주적인 게임이 나오는데, 저도 지금 신작을 디자인 하고 있어요. 그러면서 프로토타이핑을 충분히 하고 있습니다. 아까 슬라이드에 나왔지만 프로토타이핑은 그래픽 다지이너가 없어도 되고요, 프로그래머 없어도 됩니다. 물론 있으면 편하기는 하겠죠. 어쨌든 그렇게 충분히 프로토타이핑을 해요. 그래서 누군가에게 이 게임이 프로토타입으로서 돌아간다는 걸 보여줄 수 있을 만큼 프로토타이핑을 충분히 한 다음에 사람을 모으는 거죠. 그렇게 되면 여러 가지 장점이 있는데 제가 생각하는 큰 장점은 게임을 보고 모인 사람이잖아요, 그렇기 때문에 마지막 Part3처럼 괴로운 개발 과정이 있다면 없어질 것 같고요, 무엇보다도 이것을 즐겁게 만들 수 있는 사람들을 찾으려면 일단 아이디어만 가지고 사람을 찾기보다는 프로토타입을 충분히 만든 다음에, 사실 얘기하고 보니까 투자자 찾는 거랑 비슷하죠. 그렇게 작업을 하면 좋을 것 같습니다.
TITLE	TITLE	TITLE	TITLE
TITLE	TITLE	TITLE	TITLE
전체보기
