GameMook

기획자가 되기 위해 GM/QA를 하려고 해요. 에 대한 결론.

현업 기획자 분이 자신의 블로그에 경험을 기초로 한 좋은 글을 쓰신게 있어서 소개합니다.
기획자를 지망하는 취업준비생들에게는 도움이 될 경험담이라고 생각하는데, 저는 기획자도 아니고 GM이나 QA는 해보지 않았지만 제 생각과도 크게 다르지 않습니다.

사실 기획자가 되기위한 가장 좋은 수련방법은 게임을 만들어보는 것이지만 그게 쉽지는 않죠.

저도 잠깐이나마 GM업무와 QA업무를 해본적이 있는데 어떤 경험이든 게임개발에 도움이 되는 것 같긴 합니다만 역시 추천하고 싶지는 않습니다. 그럴 시간에 게임을 만드는게 10만배쯤은 본인에게 이득이 될테니까요. 한달씩만 경험삼아 해보신다면 말리지는 않겠습니다. 하지만 그 경험이 기획자나 프로그래머로 입사하는데 도움이 되지는 않을겁니다.

한동안 루리웹, 블로그등을 달구었던 주제가 있는데, 4차 장려상을 수상한 '흑설공주와 일곱드워프'라는 게임이 PSP용 게임인 용사주제에 건방지다를 그대로 베꼈다. 라는 것이었습니다.

흑설공주와 일곱드워프 플레이 영상

용사주제에 건방지다 or 2 스크린샷


게임구성을 그대로 가져다 썼고, 음악리소스 같은 경우엔 다른 게임에서 그대로 가져다 썼다고 하더군요.

심사위원의 성토부터 개발자의 옹호 까지 다양한 의견이 나왔는데 결론은 이미 수상취소가 이루어졌습니다.

홈페이지는 그대로 있지만 게시판으로나마 KGDA가 입장을 밝혀서 다행입니다.
그러면 왜 이런 일이 일어났을 까요.

가장 큰 이유는 개발자의 모랄 해저드 입니다.

 이해하기 힘들지만 개발자들을 옹호하는 분들도 계십니다. 첫번째 논리는 인디게임개발은 힘들다. 두번째 논리는 외국에서도 비슷한 게임은 계속 만들어지고 있다.  입니다.
착각하시고들 계시는데 그렇다고 표절을 해도 되는건 아닙니다. 마치 불법복제를 남들도 다 하니까 해도 괜찮다는 거랑 똑같은 논리죠. 게다가 음악등의 외부 리소스를 그대로 사용한 것은 분명히 문제입니다.

만약에 습작으로 만든 게임이라면 문제가 되지 않습니다. 다만 위와 같이 표절한 게임을 공모전에 수상을 목적으로 낸다던가, 돈을 받고 파는등의 행위를 하는것은 문제가 됩니다. 둘다 자신의 이익을 위해 남의 것을 훔쳐썼기 때문이죠. 특히 인디게임 공모전의 경우는 창의적인 게임을 발굴한다는 점에서 아이디어의 도용은 치명적입니다. 저 게임에서 용사주제에 건방지다보다 더 나은 플레이를 제공하기 위해 어떤 고민을 했는지 저는 알수가 없군요.

그렇다고 이 문제를 개인에게 다 덮어 씌우고 네가 문제야. 라고 할수는 없습니다. 오버하시는 분들은 한국게임이 다 이렇지 까지 비약하시는데 그건 명백히 오버죠. 사실 이런 게임이 장려상을 수상하기전에 사전에 막을수도 있었을 것입니다. 심사위원의 자질문제를 이야기하시는 분도 계시지만 심사위원들이 모든 게임을 다 해볼수는 없으니까 놓칠수도 있다는 것은 저도 인정하겠습니다.

근데 가장 큰 문제는 우리는 저 게임을 심사한 심사위원이 누군지 모릅니다.
저 게임을 만든 제작자도 모릅니다. 정말 가난한 인디게임 개발자인지, 현업에 종사중인 개발자인지, 아니면 학생들이 만든건지도 알수가 없습니다.
심지어 저 게임을 해볼수도 없습니다. 스테이지 2부터는 뭔가 혁신적으로 다를지도 모릅니다. 어쨌든 해볼수가 없으니 알수가 없습니다.

인디게임공모전에서 수상한 작품인데도 불구하고 말이죠.
무슨 밀실정치를 보는 느낌입니다.

만약에 공모한 게임 리스트들이 공개되거 해볼수 있게 했어도 이런 일은 벌어지지 않았을 겁니다.
분명히 인디게임 공모전에는 문제가 있었습니다.

마지막으로 리소스 사용말인데, 젤다의 배경음악이 쓰였습니다. 이건 명백하게 저작권문제에 걸려드는데요. 사실 한국에서 영세하게 혹은 습작으로 게임을 만들면서 공개된 리소스를 찾아서 쓰기는 외국에 비하면 굉장히 어렵습니다. 그런 부분을 주최측에서 지원해주거나, CCL등으로 접근하기 쉽고 사용하기 있는 리소스들이 모여있는 곳이 있으면 좋겠지만 아쉽게도 한국에는 그런게 없습니다.

이런 부분이 보완되면 좀 더 많은 게임을 볼 수 있지 않을까요.

개인적으로는 정말 아쉬운데, 저정도의 게임을 완성시킬 능력이 있는 사람들이, 게임표절, 리소스 도용 등으로 자신들의 손을 더럽혔다는 점입니다. 다행히도 정체가 드러나지는 않았으니 반성하고 다음엔 참신한 오리지날 게임을 들고 나왔으면 좋겠네요.
글쓴이 : 이후

루리웹에난 보도자료

한국 국제게임 컨퍼런스 2009 가 10월 7일부터 10월 9일까지 코엑스에서 개최한다고 합니다.
지스타와 함께 일산으로 가서 많은 개발자들을 망설이게 만들었는데.
4년만에 다시 코엑스로 돌아오는군요.
코엑스로 오니 멀다고 고민하는 개발자는 좀 줄어들지 않을까 싶습니다.


KGC 공식 홈페이지  - 아직 공식홈페이지는 2008 그대로입니다.

일정 부분만 인용합니다.

 올해 전문가 강연 모집은 3월 16일부터 6월 31일까지 KGC2009 공식 홈페이지(www.kgconf.com)를 통해 실시되고 프로그래밍, 컴퓨터그래픽, 게임디자인, 게임프로듀싱, 오디오, 비즈니스, 게임운영, 모바일, 학술/정책 등 9개 분야에서 공개 모집해 대상자를 선정한다. 

  참가를 원하는 사람은 KGC2009 공식 홈페이지(www.kgconf.com)에서 강연신청서를 작성, 제출하면 되고 결과는 심사를 통해 7월경 발표될 예정이다. KGC2009는 10월 7일부터 9일까지 서울 코엑스 그랜드볼륨 및 2층 회의실, 오디토리움에서 개최된다.

Play Station 3 로 나온 게임중에 이슈를 끌었던 Little Big Planet 이란 게임이 있습니다. 일본뿐만 아니라 전 세계적으로도 주목을 받았는데, 실제 게임이 나온 후에도 게임안에서 제공하는 툴과 정교한 물리엔진으로 사람들이 이리저리 가지고 놀았습니다. 아직도 가지고 놀고 있겠죠.

이 게임의 일본 CM에서 사용된 노래가 일본의 밴드인 Beat Crusaders[footnote][/footnote]의 PHANTOM PLANET 입니다. 그런 탓인지 PAHNTOM PLANET 의 공식 PV는 리틀 빅 플래닛을 이용해서 만든 것 같습니다. 100% 게임으로 만들지는 않고, 실사와 섞어 쓴것 같네요. 중간에 약간 실사보다 못한것 같은 부분은 100% 게임으로 만들지 않았을까 싶네요. 실제로 저런게 다 게임에서 가능하거든요.

공식 PV에 게임화면이 들어간 경우는 예전에도 있어왔지만, 게임으로 PV를 만들었다는 점에서 게임업계 사람으로서는 굉장히 흥분됩니다.

Beat Crusaders는 언제나 얼굴에 자신들의 흑백사진을 붙이는데 (심지어 공연마저도! ) 저걸 리틀빅플래닛 인형에 붙여서 PV를 만들 생각을 하다니 정말 재밌네요. :)

PHANTOM PLANET PV



리틀 빅 플래닛 일본 광고

미국의 유명한 게임디자이너 크리스 크로포드가 게임디자인을 지망하는 사람들에게 주는 글이 번역된게 있어 소개합니다. 사실 올라온지는 좀 된 글이군요.

크리스 크로포드는 한국에선 그다지 알려져있지 않지만 컴퓨터 게임의 태동기부터 게임을 만들어온 기획자여서 그런지 글에 연륜이 묻어나는군요. 그의 자세한 약력이 궁금하시면 wikipidea나 mobygames의 약력을 보시면 될 것 같습니다.

크리스 크로포드의 저서인 The Art of Computer Game Design 도 국내에 들어와있으니 비록 너무 오래된 글이다라는 평가가 있지만 관심있으신분들은 찾아보시는 것도 좋을것 같습니다.

원문 : The Education of a Computer Game Designer
번역본 : 크리스 크로포드가 게임 기획자 지망생에게 말하다 via 경험주의자의 유전자

서관희님 블로그에 팡야와 화이트데 포스트 모템이 공개되어 있습니다.

http://kwanny.ntreev.net/tt/index.php?pl=132 

팡야는 '캐주얼 게임 서비스와 해외 개발' 글인데 해외에서도 찾아보기 힘든 케이스의 포스트모템이라 읽을 가치가 높은것 같습니다.

게임 개발은 복잡하고 큽니다.
여러가지 이슈가 발생하고, 그 것을 효율적으로 관리하기 위해 여러가지 툴이 개발되어왔는데요.

버그나 이슈들을 관리하기 위해 어떤 것을 쓸까 고민하시는 분들을 위해 wikipidea에 이슈트래킹, 버그트래킹 도구들의 기능을 비교해놓은 표가 있어 소개합니다.

Comparison of issue tracking systems from wikipidea

고민하는 시간을 줄이는데 도움이 되었으면 좋겠습니다.

저도 답변을 했지만 엄님에게도 부탁해서 또 다른 관점에서 질문에 대한 답을 얻어보았습니다. :)


 IT밸리에 게임 개발/기획 관련 설문 해도 되겠습니까? 에게 트랙백.

1. 단순히 게임에 관심이 많은 매니아가 혼자 직접 게임을 제작하여 성공할 수 있다고 생각하십니까? 그렇다면, 어떻게 가능합니까? 그렇지 않다면, 왜 그렇다고 생각하십니까? (성공사례를 들어주시면 감사하겠습니다)

단순히 게임에 관심이 많은 매니아라면 불가능합니다. 공부할 것이 많으니까요. 진지하게 게임 제작에 투신해서 게임을 만들기 위해 필요한 스킬을 알아두고 자기가 익힐 것을 정해서 연마해야 합니다. 물론, 단순한 게임 매니아라도 이러한 과정을 거친다면 혼자서 게임을 개발할 수도 있고 성공할 수도 있습니다. 게임을 제작해서 성공하느냐 마느냐는 게임에 관심이 많은가가 아니라, 게임 제작에 관심이 많은가가 좌우하겠죠.
1인 개발팀 성공의 최대 관건은 배포입니다. 자신이 만든 게임을 어떻게 배포할 수 있느냐가 최대 문제죠. 다행히 소프트웨어 업계에는 아주 오래전부터 셰어웨어라는 훌륭한 배포 형식이 존재합니다. 존 카맥이 회고하기를 "셰어웨어로 판 둠의 수익금으로 집과 스포츠카를 장만했죠"라고 쓴 걸 본 적이 있습니다. 인터넷과 웹서비스가 그때보다 1000배쯤은 더 발달한 것을 감안하면 셰어웨어 형태의 배포도 가능성이 있을 것 같네요. 혹은, 프리웨어로 배포한다고 하더라도 명성이 쌓이면 이것이 바로 개발자의 자산이 됩니다. id소프트가 둠을 공짜로 배포했다고 하더라도, 존 카맥의 지금의 명성이 덜해지거나 하진 않았겠죠.

2. 그러한 아마추어 프로그래머들을 제한하는 것이 있다고 생각하나요?

시간. 시간이 가장 제약이 심한 요소입니다. 1인 개발팀이라고 하면, (엄마친구아들이 아닌 이상) 다른 일로 생업활동을 하면서 남는 시간에 게임 개발을 위한 작업과 연구/개발을 해야 할 텐데, 생각만큼 쉽지가 않습니다. 하루종일 일하고 돌아오면 녹초가 되기 십상이죠. 시간 안배가 가장 중요합니다. 시간을 많이 쓸수 없기 때문에 진전이 더디고 진전이 더디면 조급하고 초조해지죠. '어차피 안될거'라는 생각이 들면서 그냥 잊어버리고 살수도 있죠. 작더라도 눈에 띄는 결과를 계속해서 만들어내는 것이 중요합니다. 1인개발은 시간과의 싸움입니다.

3a. 게임 개발/기획 경험이 있으신가요? (없으시면 4로 넘어가주세요)

현업 프로그래머입니다.

3b. 어떻게 하여 게임 개발/기획을 하게 되었나요?

어렸을 때 게임을 하면서 게임을 만들어 보고 싶다고 결심을 했죠. (자세한 내용은 여기로.)


3c. 개인적인 경험이 있으시면 말씀해주실 수 있나요?

말씀해 드릴 수 있지요. (자세한 내용은 여기로)

3d. 게임에 대한 설정 (세계관, 캐릭터 등)은 무엇으로 시작하게 되었나요?

지금은 직업 프로그래머로서, 개인적인 세계관이나 설정으로 작업하고 있지는 않지만, 혼자서 독립게임을 만든다면 감명깊게 읽은 소설이나 재미있게 플레이한 게임, 과거에 흥미롭게 읽었던 논문 등에서 힌트를 얻어 구상을 시작하겠죠.

3e. 게임을 만들기 위해 프로그래밍을 배우셨나요? 아니면, 프로그래밍을 이미 알고 있어서 게임을 만드셨나요?

게임을 만들기 위해서 프로그래밍을 배우기 시작했습니다. (자세한 내용은 여기로)

3f. 게임 개발/기획 과정 중에 어떤 걸 배우셨나요? 혹은, 이 과정에서 어떤 지식을 이미 알고 계셨나요?

의견을 조율하는 것이 중요하다는 점을 배웁니다. 다른 스킬은 혼자서 계발해야 할 몫입니다.

3g. 혹시 게임 기획/제작에 영향을 끼친 다른 게임이라던가, 작품이 있나요?

많습니다. 주로 마이크로프로즈와 오리진, 불프로그의 게임들이 영향을 줬지요.

4. 10년 전 (90년대) 보다 최근에 들어서 이렇게 아마추어 게임 제작이 더 쉬워졌다고 생각하십니까? 그 이유는?

더 어렵습니다. 참고할 자료를 찾는 것도 쉬워지고 체계를 갖춘 개발 툴도 나오긴 했지만 10년 전과 비교하면 공부할 양이 훨씬 더 많습니다. 물론, 90년대에 쓰던 로우레벨 스킬(인터럽트, 메모리 매핑, XMS/EMS관리, 스캔컨버전 등등등)은 알 필요가 없어졌지요. 하지만 하드웨어가 엄청나게 발전했습니다.  그래픽 코어의 발전은 프로그래머가 셰이더를 알 것을 요구하며, CPU코어의 증가는 프로그래머가 병렬프로그래밍을 알 것을 요구합니다. PC/게임콘솔을 막론하고 이런 식의 발전이 프로세서/그래픽/사운드/입력/네트웍 등 전방위적으로 벌어지고 있습니다.
물론, 1인 독립 게임에 이러한 복잡한 스킬을 사용하여 제작할 필요가 있느냐를 묻느냐면 '경우에 따라 다르다'는 게 정답이지만, 프로그래머 스스로가 경쟁력을 갖추려면 반드시 알아야 하는 기초 지식입니다. 고성능의 하드웨어는 프로그래머가 100% 활용할 것을 요구합니다. 그리고 하드웨어와 시스템의 성능을 100%까지 끌어내는 것이 프로그래머의 신성한 의무죠.

5. 게임산업에서 게임 콘솔(Xbox360, PS3, Wii 등)이 창의성을 제한하고, 이익을 더 내려고 한다고 생각하십니까? 예를들어, 한 게임이 성공하면 그 시리즈로 2, 3 등등 계속 만들고 있는데 그러한 것들이 새롭고 참신한 게임 주제들이 못 나오게막고 있다고 생각하시나요?

각 게임 자체는 문제가 아니지만, 그러한 울궈먹기 게임을 골라서 출시하려는 플랫폼 홀더는 1인 독립의 출시는 리스크가 크기 때문에 플랫폼 라이센스를 주지 않으려 하는 경향이 있을 수 있습니다. 게임콘솔 업체들은 아직도 아타리 쇼크를 기억하고 있을 테니까요. 물론, 명망있는 개발사에서 새로운 시도를 한다면 들어줄 지도 모르겠군요.

6. 갓 프로그래밍에 입문하는 뉴비에게 할 조언이 있으신가요?

오래된 지식들이 가장 빛나는 무기가 됩니다.
현재에 와서는 셰이더니, 멀티코어니, 물리/수학이니, 스크립트니 하는 것들이 최신 기술인양 소개되고 있지요. 하지만 이들은 모두 최소한 30년전부터 교과서에서 기술해온 기술들입니다. 하드웨어의 발전으로 이제서야 대중적으로 쓰게 된 것 뿐이지요. 셰이더는 새로운 것 같지만 이를 쓰려면 70년대에 제안된 조명/셰이딩 과정을 알아야 하죠. 멀티코어 프로그래밍은 컴퓨터의 태동기부터 아주 깊이 연구된 주제입니다. 스크립트 언어 역시 컴퓨터의 태동기부터 문제해결을 위해 사용돼 온 도구이구요. 물리/수학이야 말할 것도 없이 수백년의 역사를 가진 학문이죠.
3D렌더링 하나만 보더라도 DOS시절의 소프트웨어 렌더링, 부두와 함께 등장한 서드파티 래스터라이징 API, 지포스와 함께 등장한 하드웨어 T&L, DX8과 함께 등장한 셰이더 어셈블리, DX9과 함께 등장한 셰이더 랭기지를 거쳐 DX10의 통합 셰이더까지 왔습니다. 이러한 변천의 과정에서 3D렌더링을 구현한 껍데기는 계속 바뀌어 왔습니다. 하지만 그 속의 알맹이인 핵심 개념은 30년동안 변치 않고 남아있죠. 개발자가 껍데기에만 집중한다면 문제입니다. 앞으로 기술적 대세가 어디로 갈 지는 아무도 모르기 때문이죠. 껍데기는 항상 변하는 기술이며, 조엘이 말한 "쏘며 달리기" 전략의 구현물입니다. 껍데기에 째빨리 적응하는 것도 중요하지만, 껍데기를 만지작거리면서 알맹이를 파악해야만 합니다.
껍데기가 변하더라도 항상 알맹이는 남아있습니다.
그리고 그 알맹이는 아주 오래된 지식들이죠.
답변자 : 엄

경력 6년차의 게임 프로그래머. geek의 화신이며 포스를 수련한다는 소문도 있습니다.
언제나 후배들에게 포스의 어두운면에 대한 주의를 설파하는 뼛속까지 프로그래머.

Visual Studio의 MSDN 도움말에서 F1을 눌렀을 때 이미 도움말 창이 열려있을 경우 기존 탭에 해당 도움말 이 보여집니다. 하지만 기존에 열려있는 탭은 그대로 둔 채 새 탭에서 도움말 내용을 보여줄 수 있습니다.

메뉴의

Tools -> Option -> Help -> General -> Reuse Topic window  의 체크를 해제 해주시면 됩니다.

 IT밸리에 게임 개발/기획 관련 설문 해도 되겠습니까? 에게 트랙백.

이글루에서 흥미로운 글을 보았습니다. 다른 분들에게도 도움이 될까 싶어서 저도 한번 답변해보겠습니다. :)
이글루가 아니니 상관없겠죠.

1. 단순히 게임에 관심이 많은 매니아가 혼자 직접 게임을 제작하여 성공할 수 있다고 생각하십니까? 그렇다면, 어떻게 가능합니까? 그렇지 않다면, 왜 그렇다고 생각하십니까? (성공사례를 들어주시면 감사하겠습니다)

답 : 단순히 게임에 관심이 많기만 하다면 당연히 게임을 제작할수 없습니다. 그러니 게임제작에 대한 능력 혹은 지식을 갖출의향이 있는, 혹은 어느정도 프로그래밍에 익숙한 사람으로 가정해도 되리라 생각합니다. 

성공을 상업적인 성공. 즉 다음 게임을 제작할수 있을 만큼 (혹은 먹고 살만큼) 이라고 말한다면 성공사례가 있습니다. 한국안에는 없지만, 해외에서는 인디게임을 혼자서 제작하여 수입을 얻는 개발자들이 있습니다. 혼자는 아니지만, 소규모의 인원이 만들어서 게임을 만든 후 대기업의 지원을 받아 게임을 판매하는 경우도 많습니다.

해외 사례중에 Wolrd of Goo의 경우 Steam이라는 밸브에서 제공하고 있는 게임 다운로드 판매 서비스에서 꽤 많이 팔린 것으로 알 고 있습니다. 이런식으로 인디게임쪽을 공략하고, 배급을 온라인으로 할 경우 아직 국내에서 시도된바는 없지만 해외에서는 성공한 사례가 충분히 많습니다.

2. 그러한 아마추어 프로그래머들을 제한하는 것이 있다고 생각하나요? (예제: 자금 부족으로 인해 포기)

답 : 시간과 열정입니다. 현실적인 부분도 포함하죠. 첫 게임이 나올 때까지는 수익을 얻을 방법이 아무것도 없습니다. 특히 한국에서는 알바만 하면서 혼자서 집에서 게임을 만든다. 라는 것은 거의 불가능합니다. 그부분을 열정과 노력으로 커버한다고 치자면 굉장히 힘든길이 될 것입니다.
그리고 멘토입니다. 프로그래머가 벽에 부딫치는 경우는 문제가 생겼고 해결방법을 찾지 못할 때이죠. 좋은 멘토가 옆에 있다면 그런 때 하는 삽질과 시간을 줄여줍니다.


3a. 게임 개발/기획 경험이 있으신가요? (없으시면 4로 넘어가주세요)

답 : 있습니다.

3b. 어떻게 하여 게임 개발/기획을 하게 되었나요?

답 : 당연히 게임을 만들기 위해 게임개발을 시작했죠. 저같은 경우는 전공이 컴퓨터는 아니지만 대학교 때부터 꾸준히 프로그래밍을 공부해서 회사에 취직했습니다.

3c. 개인적인 경험이 있으시면 말씀해주실 수 있나요?

답 : 발행단계까지는 이르지 못했지만 gp32등으로 게임을 제작한다던가 하고, 그러면서 얻은 기본적인 프로그래밍 스킬을 회사에 가서 다듬었다고 해야할 것 같군요.

3d. 게임에 대한 설정 (세계관, 캐릭터 등)은 무엇으로 시작하게 되었나요?

답 : 그런건 하지 않습니다. 물론 그런 디테일한 설정 같은 것이 필요할 경우도 있을 수 있겠지만 1인 게임제작에 가장 필요한 것은 어떻게 구현 할 것인가. 뭘로 구현 할 것인가. 입니다. 물론 '이 게임은 어떤 게임이다' 라는 기본적인 뼈대는 잡고 시작합니다.

3e. 게임을 만들기 위해 프로그래밍을 배우셨나요? 아니면, 프로그래밍을 이미 알고 있어서 게임을 만드셨나요?

답 : 상당수의 게임 프로그래머들이 게임을 만들기 위해 프로그램을 시작합니다. 저 같은 경우엔 만들고 싶은 게임이 있었고 그 것을 구현하기 위해 당연히 프로그래밍을 공부했습니다.

3f. 게임 개발/기획 과정 중에 어떤 걸 배우셨나요? 혹은, 이 과정에서 어떤 지식을 이미 알고 계셨나요? (3e와 약간 비슷한 질문입니다.)

답 :  기본적인 지식들은 책에서 배울수 있지만 실무에서 쓰는 것과는 레벨차이가 많이 납니다. 또한 공동작업 역시 혼자서는 경험하기 힘들기 때문에 그런 것들은 주로 회사에서 배웠죠. 이미 알고 있던 지식은 기본적인 프로그래밍 개념 뿐이었습니다. 물론 회사에서 가장 많이 사용하는 것도 이 기초적은 프로그래밍 지식입니다.

3g. 혹시 게임 기획/제작에 영향을 끼친 다른 게임이라던가, 작품이 있나요?

답 : 지금까지 해온 모든 경험과 게임이 영향을 끼치겠죠.


4. 10년 전 (90년대) 보다 최근에 들어서 이렇게 아마추어 게임 제작이 더 쉬워졌다고 생각하십니까? 그 이유는?

훨씬 쉬워졌습니다. 정보도 많고, 쓸수 있는 것들도 늘어났습니다. Direct X 프레임워크는 초등학생도 쓸수 있을 것 같다는 기분이 들었었죠. (물론 그 초등학생이 C++을 해야겠지만 말이에요.)
게다가 90년대를 지내온 프로그래머의 경우를 보면 정말 지금의 환경은 편합니다.


5. 게임산업에서 게임 콘솔(Xbox360, PS3, Wii 등)이 창의성을 제한하고, 이익을 더 내려고 한다고 생각하십니까? 예를들어, 한 게임이 성공하면 그 시리즈로 2, 3 등등 계속 만들고 있는데 그러한 것들이 새롭고 참신한 게임 주제들이 못 나오게막고 있다고 생각하시나요?

플랫폼홀더^[각주:1]가 창의성을 제한하지는 않습니다. 이익을 더 내는 것은 당연합니다. 게임이 많이 팔리면 좋기 때문에 참신한 게임 잘 팔릴것 같은 게임이라면 당연히 플랫폼홀더가 막을 이유가 없죠. 게다가 게임이 너무 참신해서 팔리지 않아도 플랫폼홀더가 손해보는 것은 없습니다. 오히려 마이크로소프트나 소니 같은 경우 온라인 다운로드 스토어에 해외의 창의적인 인디게임을 배급하려고 인디게임쪽에 많은 지원을 하고 있습니다. 다만 완성도가 낮은 게임이라면 막는 것이 맞습니다.

6. 갓 프로그래밍에 입문하는 뉴비에게 할 조언이 있으신가요?

필요한것을 직접 만드세요. 프로그래밍은 많이 만들고 많이 실패해볼수록 실력이 늡니다. 혹시 기획을 지망하시더라도 자기가 직접 게임을 만들수 있는 능력이 있다면 그 가치는 올라갑니다. 주변에 멘토가 있으면 더 좋고. 가능하면 게임을 직접 만들어본 사람의 조언을 구하세요. 인터넷에는 경험도 실력도 없는데도 자기가 모든 것을 알고 있다고 착각하는 사람이 많습니다. :)
답변자 : 이후 (After)

GameMook의 편집장입니다. 사람이 없어서 다합니다.
호러게임을 제외한 대부분의 게임을 좋아하지만 실상 요즘은 바빠서 다양한 게임을 못하고 있습니다. 인디게임과 게임개발방법론에 관심이 많습니다.

2009 보드게임 창작 활성화공모전 시행안내

기묘하게 KOGIA도 자신들의 홈페이지를 안쓰고 gitiss를 통해 공지를 하는군요.
상금은 2000만원씩 두개의 게임을 선정해 지원한다고 합니다.

지원도
독일 보드게임 참가지원시 부스 지원.
게임산업 병역지정업체지원시 가산 등의 회사라면 괜찮은 지원들이 나옵니다.

저작권도 별다른 말은 없고, 대신 게임을 제대로 만들지 않으면 지원금을 회수한다고 하는군요

한국 게임산업진흥원과 한국 게임개발자 협회에서 한국 개발자들을 위해 2009 GDC 할인을 한다고 하더군요.

그런데 한국게임산업진흥원 공지에 따로 나와있지는 않습니다. 한국게임개발자 홈페이지는 왜있는지 모르겠구요.

어쨌든 GDC 2009 에 참가할 의향이 있으신분들에겐 절약을 위한 좋은 기회가 될 것 같습니다.

나는 이렇게 게임 프로그래머가 되었다 -1-
나는 이렇게 게임 프로그래머가 되었다 -2-

게임을 만들고 싶다고 해도, 우리나라의 학생들은 반드시 공부를 해야만 합니다. 우리나라는 일단 대학을 안나오면 제대로된 대접을 받기 힘든 사회이기 때문이죠. 부조리한 건 맞지만, 내가 속한 사회가 그러하다면 어쩌겠습니까. 공부를 해야죠.

그런데 학교 공부가 마냥 게임 제작과 관련이 없는 것만은 아니더군요.

앞에서 썼듯이, 저는 원래 비행시뮬레이션 등의 3D환경을 구현한 게임을 좋아했습니다. 그리고 제 고등학교 시절은 매년 DirectX의 새 버전이 나와서 새로운 기능을 가진 Direct3D를 쓰면 3D환경을 아주 쉽게 구현할 수 있다고 MS가 뭇 사람들을 현혹하던 시기였습니다. 그런데 당시에 Direct3D를 설명했던 책이나 잡지 기사를 보면 일단 '아주 쉽게'란 말은 사실과 아주 거리가 먼 표현이었습니다. 어떤 과정을 거쳐 이미지가 완성된다는 식으로 설명을 잔뜩 해놨는데, 솔직히 그때에는 하나도 이해를 못했습니다.

학교에서 진도를 나가면서 관련 내용이 나오자 아주 반가웠죠. 고등학교에서 수학 진도를 절반쯤 나갔을 때 벡터를 배운 것 같습니다. 벡터를 배우고, 도형을 벡터방정식으로 표현하는 것을 알자 3D 프로그래밍을 설명할 때 봤던 듯한 내용들이 쏟아져 나오는 것이었죠. 너무 마음에 들었습니다. 세상에 저렇게 간결하고 일관성있는 식이 있을 수가. 원래부터 이렇게 하는 것이 올바른 방식이었던 것처럼 느껴졌죠. 이렇게 간단한 방식을 더 일찍 가르쳐 주지 않는 학교 교육 과정이 오히려 불합리하게 느껴질 지경이었습니다.

그리고 수학을 웬만큼 배우고 나자 물리에선 모호한 표현으로 가르쳤던 것들이 사실은 그냥 단순하고 기초적인 벡터연산이었다는 점이 분명해졌습니다. 이를테면, 물리과목에서는 플레밍의 왼손법칙/오른손법칙 등으로 그냥 외웠던 물리현상들이 알고보면 간단한 벡터의 외적에 불과하다는 사실이나, '물체의 운동방향으로 작용한 힘'이라는 모호한 표현 대신 '물체의 변위와 힘의 내적'이라는 명료한 표현으로 쓸 수 있다는 점 등이 물리와 수학이 사실은 연결되어 있다는 깨달음을 주었죠.

물론, 이런 정신적 감흥을 느끼는 사람은 매우 적다는 건 저도 알고 있습니다. 하지만, 이런 감동의 순간 순간이 결국엔 도움이 되었죠. 지금 게임계의 가장 큰 화두는 바로 수학과 물리니까요. 어렸을 때 흥미와 감동을 느꼈으니 예습은 제대로 한 셈이죠.

다음에 계속
필자 : Uhm

경력 6년차의 게임 프로그래머. geek의 화신이며 포스를 수련한다는 소문도 있습니다.
홈월드나 토탈어나힐레이션, COH 같은 RTS와 FPS를 좋아하지만 요즘은 아내와 함께 기타히어로를 하는 가정적인 남편이기도 합니다.

언제나 후배들에게  포스의 어두운면에 대한 주의를 설파하는 뼛속까지 프로그래머.

나는 이렇게 게임 프로그래머가 되었다 -1-

게임을 만들기 위해 공부할 것은 지나치다 싶을 정도로 많습니다. 진심입니다. 진심으로 공부할게 너무 많습니다. 아마 단일 소프트웨어로는 운영체제, DBMS 다음으로 복잡한 물건이 아닌가 싶을 정도입니다. 아마 모두 다 공부하려고 책을 쌓아놓는다면 미리 포기부터하게 될 겁니다. 따라서 흥미가 있는 부분을 하나씩 파헤쳐보는 점진적인 과정이 중요하죠.

옛날 얘기를 좀 해보지요.

제가 게임 프로그래밍을 본격적으로 공부한 것은 94년부터입니다. 그때부터는 게임 프로그래밍에 필요한 것이 뭔지 닥치는 대로 찾아봤죠. 우선 대부분의 게임을 C로 만든다기에 C언어 부터 공부했습니다. 한동안 (한 반년쯤?) 포인터에서 딱 막혀서 탱자탱자 (게임하며) 놀던 기간도 있었지만 대개는 책 보면서 닥치는 대로 짜 봤습니다. 포인터의 개념을 터득한 후에는 책에 나온 도서관리 프로그램 따위의 예제를 짜봤죠.

C로 기본적인 것들을 대충 익히고서는 본격적인 게임에서 많이 쓰이던 그래픽을 어떻게 구현하는지가 궁금했죠. 당시 대부분의 게임이 320*200*8bpp^[각주:1], 혹은 640*480*4bpp의 그래픽 품질로 구현되고 있었고, 일부 고사양게임들은 640*480*8bpp의 그래픽 품질을 보여주던 시절이었습니다. 그리고 그중에서도 극히 고사양을 요구하는 (윙커맨더^[각주:2]와 같은) 게임들은 640*480*8bpp에서 3D 렌더링을 구현하고 있었습니다. 당연히 이러한 그래픽을 어떻게 구현하는지가 궁금했죠. 그때까지 쓰던 터보 C++ 2.0 에서 제공하는 그래픽 라이브러리(BGI)에서는 저런걸 할 수 없었기 때문이죠. 하더라도 끔찍하게 느린 속도를 감수해야 했죠. 게임에서 쓰던 방식은 아니란 걸 알았습니다.

그 답은 PC통신의 프로그래밍/게임제작 동호회 등을 뒤져가며 인터럽트란 것에 대한 개념을 주워들으면서 얻을 수 있었죠. 하드웨어에 인터럽트를 날리면 하드웨어에서 특정한 동작을 수행하며, 그래픽스 하드웨어에 인터럽트를 날리면 그래픽에 관한 원하는 동작을 수행할 수 있다는 것 정도가 파악되었습니다. 그때부터 여기저기서 찾아본 정보로 (지금도 업데이트되고 있는) Ralph Brown's Interrupt List 라는 것의 존재를 파악했습니다. 거의 모든 하드웨어의 인터럽트 펑션에대한 자세한 정보가 기술되어 있는 리스트였죠. 당시에 조금이라도 프로그래밍을 한다 싶은 사람들은 저마다 하나같이 RalphBrown's Interrupt List가 중요한 참고자료 중 하나였을 겁니다. 저도 DOS에서 그래픽스 라이브러리를 구현해 보는 데에 RBIL이 매우 좋은 참고자료가 되었습니다.

옛날 DOS게임을 할 때 궁금했던 것 중 하나는 게임을 실행하면 (DOOM같은 것들) 프롬프트에 스크롤되어 올라가던 다음과 같은 문구였습니다.
약간 설명을 하자면, 당시 640*480*8bpp 이상의 그래픽 품질을 구현하고자 했을 때 가장 걸림돌이 되었던 것은 16비트 운영체제였던 DOS의 64kb 세그먼트^[각주:3] 제한이었습니다. 단순 산술계산으로도 640 * 480 * 8bpp = 2457600bit = 300kb 이기 때문에, 5개의 세그먼트를 오가며 메모리에 접근해야 했죠. 비디오 메모리의 접근 세그먼트를 변경하는 것도 비디오 하드웨어의 인터럽트 펑션중 하나였습니다. 저는 당시 게임에 많이들 쓰고 있던 DOS/4GW의 정체가 이러한 제약과 관련이 있다는 것을 알아낼 수 있었습니다. 이러한 제약은 DOS가 인텔계열 CPU의 리얼모드만을 이용하는 OS이기 때문이며, 이를 보호모드로 전환하면 주소공간이 32비트로 확장되어 최대 4gb에 이르는 메모리를 세그먼트전환 없이 사용할 수 있게 되는 구조였죠. 즉, DOS에서 보호모드를 사용할 수 있게 해주는 실행환경이 바로 DOS/4GW였던 것입니다. DOS/4GW는 당시 최적화가 잘 되기로 소문이 나 있던 Watcom C++과 함께 배포되어 WC의 기본 프로젝트 세팅중 하나로 선택할 수 있었죠. 저는 '세그먼트 전환이 없는 그래픽 라이브러리'를 목표로 어렵사리 (당당하지는 못한 방법이었지만) Watcom C++ 의 한 카피를 구해서 구현 해보았죠.

위의 이야기들은 옛날 이야기고, 지금에 와서는 전혀 쓸 일이 없는 기술들이고, 제가 왜 아직까지 이런 것들을 기억하고 있는지가 신기할 지경인 일들입니다. 하지만 남은 것도 좀 있지요. 인터럽트와 보호모드는 모두 현대 CPU와 OS의 구조를 이해하는데에 결정적인 키워드입니다. 인터럽트 리스트를 뒤져가며 그래픽 라이브러리를 구현해본 것도, 개발툴 매뉴얼을 보며 보호모드 전환을 해본 것도, 모두 현대 컴퓨터의 구조를 이해하는 데에 매우 큰 도움이 된 것 같습니다.
물론, 위의 과정을 거치면서 얻은 가장 큰 소득은, 앞으로 프로그래밍이란 작업을 어떻게 해야 하는 지를 몸으로 익혔다는 점입니다. 바로, "한가지씩 해본다"는 철학이죠.


다음에 계속
나는 이렇게 게임 프로그래머가 되었다 -3-
필자 : Uhm

경력 6년차의 게임 프로그래머. geek의 화신이며 포스를 수련한다는 소문도 있습니다.
홈월드나 토탈어나힐레이션, COH 같은 RTS와 FPS를 좋아하지만 요즘은 아내와 함께 기타히어로를 하는 가정적인 남편이기도 합니다.

언제나 후배들에게  포스의 어두운면에 대한 주의를 설파하는 뼛속까지 프로그래머.

욕망.
게임을 만들기 위해서 가장 중요한 덕목입니다. 게임을 만들고 싶은 욕망이 없는 사람은 게임을 만들 수가 없죠. 저는 현재 31살의 게임프로그래머로서, (웬만한 게이머들은 이름을 대면 알 거 같은 느낌이 드는 게임의) 프로그램팀장을 하고 있습니다. 저 역시 게임을 만들고 싶은 욕망 때문에 일을 시작했죠.

게임을 접하고 좋아하는 거야 아주 어렸을 때 일이지만, 본격적으로 게임을 만들어야 겠다는 생각이 든 것은 고1때의 일입니다. 중3때 접한 듄2^[각주:1]를 보고, 나중에 저런 게임을 만들면 정말 멋진 사람이 될거 같은 느낌이 들었죠. 이리저리 PC통신으로 (93년 당시) 알아본 결과, 요즘 게임은 보통 C로 만든다는 것을 알아냈고, 서점에서 찾아볼 수 있었던 책 중에서 가장 얇은 C언어 입문서를 사들고 왔습니다. 그게 94년, 고1때의 일이죠.

물론, 그 전, 초등학교(저는 국민학교를 다녔습니다만) 때 다들 하듯이 GW-BASIC^[각주:2]등으로 기본적인 프로그래밍은 익혔죠. 컴퓨터학원 다니면서 심심풀이로 테트리스나 15-퍼즐이나 오목같은 간단한 게임을 만들면서 지내곤 했습니다. 하지만, 거기까지가 전부였죠. 베이직의 파일입출력을 끝끝내 이해할 수 없었기에 그보다 대규모의 프로그램은 만들 수가 없었습니다. (지금 생각해도 베이직의 파일입출력 라이브러리는 괴악하기 그지없습니다) 베이직으로는 고등학교때 컴퓨터동아리에서 '땡겨^[각주:3]'내기 테트리스 짜기나, Dragon Curve^[각주:4](쥬라기 공원의 각 장 앞부분에 나온 그 드래곤 커브)를 Q베이직^[각주:5]으로 구현하며 논 것이 거의 마지막이었습니다.

베이직의 한계를 느낄 무렵, C라는 언어의 존재를 알게 되면서 C언어 책을 고를 때, 가장 중요한 기준은 (위에서도 썼지만) '얇은 책'이었습니다. 저는 나름 독서광이었고, 새로운 것을 접할 때는 간략하게 개괄적으로 설명한 책이 더 나에게 적합하다는 것을 알고 있었으니까요. 자신에게 무엇이 가장 적합한지를 아는 것이 중요했던 것 같습니다. 만약 C언어의 모든 면을 자세히 설명한 TCPL^[각주:6]같은 책을 골랐더라면 인내심이 한없이 0에 가까운 저는 이내 포기하고 말았겠죠.

제 인내심은 욕망을 지지할 정도로 견고하지는 못하다는 점을 알고 있었습니다. 게임 제작을 하고 싶다고 하더라도, 자신의 특성을 파악해야 했던 것이죠.

(다음에 계속)
나는 이렇게 프로그래머가 되었다 -2-


필자 : Uhm

경력 6년차의 게임 프로그래머. geek의 화신이며 포스를 수련한다는 소문도 있습니다.
홈월드나 토탈어나힐레이션, COH 같은 RTS와 FPS를 좋아하지만 요즘은 기묘하게도 와우를 하는 시간이 더 많은 게이머입니다.

언제나 후배들에게  포스의 어두운면에 대한 주의를 설파하는 뼛속까지 프로그래머.