생산성 = 툴 이 아니다.

앞선 글에서 생산성으로 시작해 툴에 대한 이야기를 했고 또 툴 계획을 짜라고 시키긴 했지만..... 미안하다. 내가 살짝 사기친거다 :-p

진짜로 아무 개념 없이 툴 계획부터 세우는 것 보다 사실 먼저 해결해야 할 더 중요한 문제가 있다.

도대체 생산성이 뭔가?

(항상 말하지만  ~ 성, ~ 감 같은 말은 스스로 객관화 하기 전까지는 남발할 말이 되지 못한다.)

어쨌든 말을 봐서는 많이/빨리 만들 수 있도록 보조하는 것으로 보이는데, 도대체 어떻게 해야 생산성이 늘어날까? 생산성에 대해 언급할 때 다들 툴에 대한 이야기를 먼저 하는데, 툴만 있으면 되는건가? 그것도 WYSIWYG(What You Seeing Is What You Getting : 보이는대로 얻게 된다)의 원칙에 입각해 우아한 UI까지 뽑아내면 좋은 생산성을 갖춘 것일까?



언제 생산성의 문제를 겪게 되는가

당연한 이야기지만 인력이 애초에 부족하다면 당연히 생산이 불가능하다. 아아, 중국에다가 외주 주면 된다고? 외주의 단어 정의를 잘못알고 있나 본데, 여기 위키피디아에 걸어놔도 부끄럽지 않을 용어 풀이를 하나 해 주겠다.

외주
원하는 기한에 원하는 품질대로 물건이 납품될 수 없는 행위.
기한이나 품질 둘 중 하나를 포기하면 당연히 나머지는 얻을 수 있다. :-p

처음 만드는 프로젝트라면 죽어도 외주 줄 생각을 말도록. 관리가 어려운 나머지 스스로 그 물량을 다 채워 넣는게 더 빠르고 품질도 좋은 경우도 많다. 망할.

어쨌든 외주도 인력인 건 확실한데, 왜 인력이 있는데도 생산성이 낮은 경우가 있을까?



해결책은 관리다?

외주일 경우도 마찬가지지만, 보통은 게임 만들 때 각각의 개발자들에 대해 관리자(각각의 팀장이라고 보자)라는 사람들이 있다. 가능한한 원하는 시간 내에 원하는 품질의 물건을 얻기 위해 들어가는 사람들인데 당연히 필요한 사람들이며 이들의 가치를 의심할 필요는 없다. 원래대로라면 가장 중요한 내용들을 결정해 주는 사람들이니까.

그런데 자세히 보면 진짜로 중요한 것만 결정하는 관리자는 드물다. 주변 사람들이 보기에는 워커홀릭이나 각종 디테일한 것들에 대해서 까지 신경쓰는 관리자나, 아예 아무것도 결정하지 않는 관리자도 있다. 전자는 반감을 얻거나 스스로 일에 치여 죽을지경에 이르게 되고 개발 파이프라인을 동결시킨다. 후자는 관리자 기능을 제대로 하지 못한다.

일단 관리자 기능을 못하는측의 문제를 차치해 두고 전자쪽의 문제를 살펴보자. 확실히 후자쪽이 어쨌든 전자쪽 보다는 문제가 적다. 품질은 저하되어도 생산성을 직접 저하시키지는 않으니까.

그런데..... 개발 파이프라인을 동결시킨다고? 그럼 생산성이 저하 되잖아. :-(

더군다나 특정 작업이 다른 작업에 대해 시너지를 발생시키는 경우가 발생하면 사태는 더 심각해진다. 그래픽 작업이 완료되지 않으면 게임상에 띄우고 테스트를 못해본다던지, 무기를 하나 고쳤더니 스킬 체계를 다 뜯어고쳐야 한다던지 하는 사태 말이다. 생산성이 낮은 수준이 아니라 병목으로 인해 책임감이 강한 관리자는 노이로제에 걸리기 쉬워진다. 알아 누워버리면 저절로 해결될 것도 아니고......

(물론 개중에는 가장 올바른 관리자의 모습 - 애초에 원하는 품질을 명확히 제시하고 대부분 실무자에게 맡겼다가 돌아온 품목이 자신이 제시한 형태에 맞으면 무조건 OK 하는 것 - 을 갖추는 경우도 있지만, 세상이 다 그렇듯 좋은 사람은 정말 없다.)



원래 인간은 믿을 수 없다! 개발 시스템만이 해결책이다?

음. 그럼 그 개발시스템을 어떻게 만들어야 되는지 나에게 설명해 주면 참 좋겠다. :)

세상에 황금 열쇠는 없다.

병목이 발생하면 발생하는 거고, 몇 명의 관리자가 세부 결정까지 한다면 관리자가 수십명이 되어봤자 개발자 전체가 다 놀고 있는 사태가 발생할 수가 있다. 관리자들의 능력 신장이 발생해 중요사안이 아닌 모든 것을 무시하고, 무엇이 중요사항인지 판단할 근거가 명확히 공유하지 않는 한, 어떤 시스템도 생산성 문제를 해결해 주는 것이 되지 않는다.

자, 여기서 '중요사항이 무엇인지 판단할 근거 공유.' 우선 이게 중요하다. 철칙. 철칙을 정리한 바이블. 그러니까 기획서라는 이야기인가? 디테일이 너무 잘 정리되어서 완전한 기획서가 있으면 된다고?



게임은 개발 과정에서 끊임없이 변해간다.

아무리 잘난 기획자라도 프로젝트가 크면 진짜로 게임이 완료된 모습의 디테일 전체를 처음부터 상상하지는 못한다.
온라인 게임이면 사태가 더 심각하며 매일같이 버그픽스만 하는 것이 아니라 UI 개선이나 밸런스 패치, 신규 컨텐츠 업데이트 등등을 하게 된다. 그래서 그놈의 기획서는 결국 조금씩 고쳐지고 누구도 고쳐진 '문서' 따위에는 관심 없기 때문에 정확한 판단기준 없이 작업하게 되는 경우도 많다.

그러나 다시 생각해 보도록.

잘난 기획자는 프로젝트가 커도 대충의 그림을 끝까지 유지시킬 수가 있다.

여기서 대충의 그림이라는 건 가능한한 적은 금칙과 명확하되 앞으로 절대로 수정할 일이 없는 몇 가지 짧은 규칙(물론 외압(윗분)에 의해 변경 되는 경우가 많아서 돌아버리겠지만. 그건 뭐 둘째치고)을 의미한다. A4 용지 200장짜리 기획서는 어디서 누가 뭘 고쳤는지도 모르지만 A4 용지 5장 짜리 '중점 기획서'는 금방 외울수가 있다. 어쩌면 외주하는 사람도 외울 수 있을지도 모른다. :)

그리고 이 규정만 맞다면 나머지는 서로간에 전혀 신경쓸 필요가 없는 파트로 나뉘어져 다시 각각의 파트에 맞는 20장씩의 애드온만 붙이면 충돌 없이 개발하는게 가능한 해피한 상황을 만들 수도 있다. 관리자가 원하는대로 제때에 찍혀 나오는 물품을 상상해 보라. 생산성에 대해 말하자면 세상에 그보다 더 해피한게 어디있나. :)

그런데 도대체 어떻게 해야 '중점 기획서'를 A4용지 5장으로 축약해버릴 수가 있지? MMORPG인데? 그냥 '와우처럼 만들어요.'라고 써있는 문서 한장을 가져가면 된다는 소리인가? :-(



생산성 = 직교성

중점 기획서는 얇게. 부분 기획서(본인의 경우에는 이를 레퍼런스 가이드라 지칭한다.)는 두껍게.

이 묘기를 위해서 꼭 필요한 부분이 직교성의 유지다. 역시 ~성 의 단어이므로 단어풀이를 뒤에 더 해야겠지만 내가 하는 것 보다 더 좋은 것은 책이겠지.

프로그래밍 관련 책자를 읽는 취미가 있어 직교성이라는 단어에 대해 아는바가 있다면 이 말 뜻을 이해하기 쉬울 것이다. 특히 문법형 스크립트랑 관련 있다면, Code Complete(2판)라는 책자를 반드시 읽어보도록. 아니, 문법형 스크립트를 절대로 사용하지 않을 기획자도 좋다. 무조건 읽어라. 프로그래밍 언어 아무거나 하나 알고 읽으면 더 좋지만 몰라도 읽어라. 읽어서 익혀라. :)

그 중 생산성에 직결되는 부분만 추가로 풀어 설명하자면 다음처럼 축약 된다.

모든 생산성의 원칙이 시작되는 장소에는 직교성의 원칙이 있다. 그리고 직교성의 문제가 해결되면 생산성은 인력 수에 정비례하여 증가하게 된다.

(물론 이런 말이 직접 쓰여있지는 않다. :-p 그렇다고 내가 완전 쌩 개사기를 치는 건 아니니 꼭 읽도록. 아니 내가 사기치는 거면 어떤가. 책은 읽으면 무조건 도움이 되는데. 어쨌든 여기에 대한 해설은 직교성에 대한 언급과 함께 나중에)

물론 싱글 플레이 게임을 만든다면, 완제품을 그냥 닥치고 만들어버려 완성하는데에 소요되는 비용이 툴을 만들고 그에 상응하는 길이만큼 만드는 비용 보다 쌀 가능성이 있으며, 그렇다면 별 생각없이 만드는게 정답이다. (폭포식의 개발방식을 확실하게 규정하고 계획 수정이 없도록 해야 하지만)

근데 메이져한 변화 없이 후속작을 만들려고 생각한다면? 또는 온라인 게임이라면?

우리나라는 온라인을 기반으로 하고 있다보니 오히려 다른 나라들 보다 '툴'의 사용 시간이 더 길며, 실질적으로 패치의 서비스를 고려하지 않고 게임을 만드는 건 미친짓이 된다.

게임 다 만들었다고 땡 치고 파티 열고 난리 부르스를 떠는게 아니라 오픈베타하면 서버가 터질까 조마조마하는 경험이 더 많은 나라이니만큼 하나의 완제품 보다는 서비스 진행 중인 상황에 더 신경써야 하며 그만큼 유지보수와 컨텐츠 추가를 무지 중요시 해야 했을 건데.......

GPG에 가 보면 프로그래머가 툴을 만들고 툴을 사용한다는 소리가 나온다.
프로그래머가 스크립트를 도입시키고 프로그래머가 스크립트를 사용한다는 소리도 나온다.

이 뭐임미?!

아니, 툴 계획을 세우고 스크립트 사용 계획을 세운 사람들은 어쩌고?

....... 아니 잘 읽어보면 뭔가 이야기의 앞뒤가 맞는 것 같다. '쉽고 편하게 만들지 않으면......' 이라는 전제가 붙는다. 그렇구나. 쉽고 편하게 만들지 않은 툴은 결국 프로그래머만 쓸 수 있는게 되는 구나. 당연하지.

잠깐. 도대체 왜 프로그래머가 계획을 세우는 거지?!!!!!



툴이나 스크립트의 중요성은 상당히 당연한 것이다.

블리자드가 강력한 컨텐츠를 다른 MMO들 보다 훨씬 빠른 속도로 제공하는 건 그놈의 생산성이라는 걸 보장했기 때문이며 그 사실은 그들 스스로도 자랑스러운 부분이라 밝힌 내용이다.

자. 60명의 컨텐츠 기획자가 있다고 해보자.

모두 모여서 퀘스트를 만드세요 하고 내버려두면 뭐가 나올까?

음...... 모여서 업무 시간에 스타크래프트를 너무 한 나머지 프로게이머가 나올 수도 있고 혈맹을 만들어 리니지 군주라도 하나 나올 수 있겠지만......
아마 퀘스트는 안나올 것이다. :-(

여기에 등장할 것이 스크립트나 툴. 아니면 계획인데...... 아까 60명이라고 했으니 틀림없이 계획은 아니다.
60명의 기획자는 절대로 계획을 세울 수 없다. (싸움나거나, 같이 놀거나지.)

스크립트를 준다면 한 사십명이 일을 안한다.

슬프게도 이건 사실이다. 맙소사. 스크립트 언어를 구사할 줄 아는 기획자가 얼마나 없는지 gpg에서 스크립트 언어하나 다룰 줄 아는 기획자를 만나면 행운이라고 생각하라는 소리가 돌아다닌다.

툴이 준비된다면 그제서야 작업이 돌아갈 수 있다. 음....... 그럼 툴을 만들어야 겠군?



근데 왜 툴 계획은 없지?

근데 툴을 어떻게 만들지? 워 쓰리 툴이 짱 좋다고 들었으니 그냥 프로그래머 에게 던져주고 '베껴 주세요' 하고 말하면 되나? 근데 우리 게임은 액션 아니었어?

다시 gpg를 돌다 보면 프로그래머들이 툴의 사용 편의에 대해 고민하는 웃지 못할 모습들이 보인다.

세상에.

게임 내부의 실행 로직에 대해 고민하고 게임의 프레임과 네트웍 레이턴시를 걱정하며 실제 게임을 만들어가야 할 고급 인원들을 그들 스스로가 사용하지도 않을 - 근데 안타깝게도 그들이 직접 사용하고 있는! - 툴의 사용 편의 때문에 고민하게 만들다니. 이런 낭비가 있나.

고객을 개발에 끌어들인다는 XP의 방식은 전체가 허황된 것은 아니며, 꼭 진짜 사용자가 아니더라도 계획을 세울 수 있는 입장에 있는 사람이 필요하기에 성립되는 방식이다.

XP 전체를 할 필요도 없고, 그저 우리 스스로가 진짜로 고객인 상품을 만들어야 할 건데, 왜 그 계획을 프로그래머들이 만들어 줄 때 까지 병아리처럼 입을 벌리고 있는 건가?

기획자라는 건 게임이 완성된 상황을 상상하고. 그 편의에 대해 예측하여 과정을 설계해야 하는 건데,
아니 세상에, 외부 공개를 할 것도 아니고 자기 스스로가 사용할 툴의 청사진 조차 예측하지 못할 거라면......

자기가 할 것도 아니고, 남들이 할 게임은 도대체 어떻게들 계획한거지?!

믿어지진 않지만 낭비라고 생각하는 경우

"구조를 알고 있는 건 프로그래머니까, 내가 세우는 것 보다 프로그래머들이 세우는게 낫지 않겠어?"

구조를 가장 잘 알고 있는 건 프로그래머가 맞는데, 툴에서 설정해야 할 규칙은 기획자도 알고 있는게 당연하다. (그래픽 툴이야 물론 제외되겠지만) 게임의 골격을 이루고 조절해야 할 핸들을 모두 알고 있는 상황일텐데 프로그래머가 뭘 더 안다는 건가? 툴의 계획을 세울 때 D3D 레퍼런스 출력 구조에 대해 고심부터 해야 하는 건가?

"난 왠만큼 후진 툴도 잘 사용할 자신 있으니까 그냥 프로그래머들이 계획을 세워도 돼"

내부에서 사용되는 어플리케이션이 당연히 유저들이 쓸 것 처럼 쉽고, GUI에 의존해 구성될 필요따위는 없다.
(나중에 설명하겠지만, 계획을 세우더라도 이런 계획을 세우라는 것이 아니다.)

오히려 GOMS 분석 결과에 따라 각종 핫키들로만 채워진 계획을 세우는 것이 월등히 효율적이다. 심지어서는 있는 기능들이 따로 적혀있는 referrence.txt 파일을 한 부 동봉해도 문제될 건 없다. 어차피 툴 쓸 건 스스로 교육시켜야 할 다른 기획자 아닌가?

목표는 생산성이며, 가장 높은 생산성을 낼 방안을 마련할 수 있는 건 툴의 사용자지 가끔은 단순히 code넘버에 따라 핫키를 배치하는 프로그래머가 아니다. 키보드 자판이 qwer순으로 되어 있다는 걸 유심히 관찰하고 어느 키가 가장 빨리 눌릴 수 있을지 고민하던 기획자란 말이다. (잠깐, 거기 그거 하나 고민 안하던 기획자는 머리박고 50초 동안 반성해라.)

"중요성은 알고 있지만 난 다른 계획을 세워야지. 내가 계획을 세울 동안 프로그래머들이 세워줄거야."

솔직히 말해, 기획자의 시간보다는 프로그래머의 시간이 더 중요하다. 그리고 안정적인 툴 계획은 프로젝트의 완성 뿐만이 아니라 앞으로 확장될 컨텐츠의 미래까지도 책임질 수 있는 툴이라는 물건에 들이 붓는 시간은 결코 낭비가 될 수 없다.



"미안하게도 난 감이 안와요. 죄송해요 프로그래머님. 만들어 주세요:-("

이런 케이스라면, 다음의 내용을 잘 생각해 보길.

● 툴을 사용할 사람은 누구인가.
  - 전혀 감이 안온다면 처음부터 킹왕짱 범용 툴 따위를 생각하지 말고 사용자별로 나뉘어진 기능을 먼저 고려해라.
   도대체 누가 사용할 툴인가?
  - 깔끔하게 정리된 범용 툴이 오히려 그 무거움 때문에 생각지도 못하게 시간을 잡아먹을 수도 있다. 또 하나의 파일에 작업물을 몽땅 저장하려다가 나누어 작업할 때 방해가 될 수도 있다. 무리하게 통합 같은 걸 미리 고민하진 말기를.
  - 우선은 하나의 작고 견고한 데이터를 나누는 것 부터 시작하고 데이터 관리자 구분을 생각하면 어떤 툴과 어떤 툴을 쪼갤 수 있을지를 알아보기 쉬워진다.

● 그가 직접 조절할 '핸들'은 어디부터 어디까지인가.
  - 데이터가 아날로그적이며 직관에 의존해 넣는 편이 좋은 정보인가
  - 그렇지 않고 디지털 적이며 차라리 핫키로 선언 되거나 숫자를 넣는 편이 더 좋은 정보인가
  - 당연히 이걸 분류하려면 당연히 어떤 핸들이 툴에서 조절 되어야 할 것인지 구분해야 한다. 제발 부탁이니 이걸 미리 알아두지 못했다는 소리는 하지 말도록.
  - 만약 여기에 대해서 도저히 감이 안잡힌다면 생산성과 직교성의 원칙의 다음 글 쯤에 추가 설명을 좀 해보겠다.
  - 꼭 필요한 핸들을 누락시켰다면 뻗게 만들어도 된다. 이런 예외 처리 하나하나를 안할 때 마다 프로그래머들이 좀 더 편해진다. (뭐 해주면 좋고 :))

● 그 핸들은 각각 어떤 식으로 조절하는게 좋은가.
  - 그 망할 그래프나 마우스를 아무데나 쓰지 마라. 차라리 뉴메릭 키패드로 숫자를 입력할 수 있도록 만드는 것이 훨씬 빠를 수도 있다.
  - text를 입력해 이후 개변할 때 가독성을 유지해야 할 수도 있다. 주석이나 노트 기능은 정말로 유지할만한 가치가 있는 내용이다.
  - 아니, 사용자가 '유저'나 '그래픽 디자이너' 혹은 '사운드 디자이너'가 아니라면 그래프가 좋은 경우따위는 없다.
  - 사실은 '그래픽 디자이너'들 조차 그래프를 쓸 필요는 없다.
  - 진짜는 '유저'도 그래프 때문에 귀찮은 경우가 더 많다. :-p



지독한 완성도를 지닌 상용 툴을 만들어 달라고 할 필요는 없다. 기능이 너무 많아 보통 사람들은 도무지 알아먹지 못해도 상관 없다. 어차피 내부 레퍼런스 가이드를 써야 하는 건 우리가 할 일이며 신입의 교육도 우리 몫이다.

실수가 있어서 크게 뜯어 고칠 일이 발생하더라도 좋고 확장 과정에서 누더기가 되어도 좋으니 절대로 스스로가 사용할 툴의 기획을 프로그래머들에게 맡기지 말라. '저장할 데이터의 목록'을 미리 생각해 보지 않았다면 당연히 어쩔 수 없이 프로그래머들에게 맡기에 되기가 쉽지만 애초에 저장할 데이터의 목록을 모른 채 게임을 만들려는 생각은 좀 버려라.

기획적으로 반드시 필요한 저장 정보를 구분하는 법에 대해서는 따로 언급을 하겠지만.......

어쨌든 이 글을 보았는데도 여태 툴 제작 계획을 세우지 않았다면,

일단 툴 계획을 세우기 위해 노력해 보라. 툴에 필요한 것은 어차피 게임에도 필요한 것으로 자동으로 확장 된다!

그러나 Simple을 강조한 게임은 기초 메커니즘이 단순하기 때문에 동일 시점에 유사 게임이 만들어지기가 쉽다는 문제점을 안고 있으며(경쟁을 사서 할 필요는 없지 않은가?:-p),

내부 개발자들이 대부분 하드코어 게이머나 하드코어 유저들인 관계로 Strategy가 얇은 게임에 대해 게임플레이를 실질적으로 검증하기가 너무 어렵다는 문제가 있고(내부 테스트를 강제로 시키지 않는 한, 충분한 양의 테스트에 절대로 동참해 주지 않는다. 또는 '성공할 게임이 확실한 게임'에 대해서도 스스로의 잣대로 부정적인 피드백을 던지는 경우조차 있다. :-( ),

결정적으로 그 게임이 제공할 수 있는 Strategy가 Steady To Master를 성립시키지 못할 수준이라면 수명의 한계가 지나치게 빨리 찾아 올 수가 있다. (Gathering의 강조로 이 상황을 벗어나는 것이 가능하나 (디아블로와 포스트 디아블로들) Gathering 자체는 따로 포스트 했던 것 처럼 Strategy와 섞어 사용하면 더 큰 효과를 줄 수가 있다.)



물론 역효과는 주의해야 한다.

Strategy를 또 너무 강조한 나머지 역시 Steady To Master를 해하게 되면 위험하므로 역시 조심해야 한다.

가장 쉽게 생각할 만한 케이스는 당연히 기존 멤버들의 실력이 지나치게 상승하여 이들 스스로가 초심자들에 대한 진입 장벽이 되는 경우다. 요즘 어디 스타 초보자가 배틀넷 함부로 들어가서 1승이라도 챙기기가 가능하던가? :-(

위와 같이 Strategy의 추구 과정에서 특히 도무지 답이 나오지 않는 경우도 있을 수 있다. 쉽게 발생하는 케이스는 다음과 같다.

● 단독 개체를 조작하는 게임의 경우
 - 지나치게 많은 행동,
 - 너무 많은 동적 팩터(스탯)
 - 엄중한 운동 능력 본위의 실력 격차 효과

● 소수의 복수 개체를 조작하는 게임의 경우
 - 지나치게 많은 개체 타입
 - 복잡한 내부 지식의 강요
 - 과도한 마이크로 매니지먼트 요구

● 다수의 개체를 조작하는 게임이나 운영형 게임의 경우
 - 복잡한 내부 지식의 강요(지나친 자동화로 인한 문제도 포함)
 - 불명확한 피드백



음? 그럼 어쩌라고?

사실 주의하라고는 했지만, 아무리 프로토타입이 거칠고 끔찍하게 하수와 고수의 격차가 끔찍한 Strategy 수준을 갖췄다고 해도 MPOG의 테두리에 있는 한 개선의 여지는 있다.

또 Simple을 보조하는 방안은 이미 다른 게임들에서 보강 된 선례가 많으니 여건이 닿는다면 프로토타입에서 부터 Simple을 보강할 여력을 갖출 수도 있다. (이 포스트는 Simple의 추구에 대한 내용이 아니므로 이에 대한 글은 다시 나중에.)

결정적으로는, 왠만해선 그런 물건이 나오기 힘들다는 점이다. :-) 어차피 한 껏 개겨봐야 사람 머리에서 Strategy를 꺼내 오는 것이 쉽겠는가. 우연에 의존해 만들어진 게임플레이가 주 무기인 게임이 실제 게임들 - 히트작들도 포함해서! - 의 대부분을 차지하고 있다는 건 당연한 거다.



즉, 닥치고 매니악하게 만드는 건 사실은 큰 문제가 되지 않는다. :-p

유저는 개발자를 뛰어 넘는다는 말이 있다. 꼭 당연하다는 듯이 원래 발생할 것 처럼 하는 말인데......

이건 사실 그냥 '충분히 생각치 못한 기획자의 변명' 이상의 것이 아니다. 그게 실력이며 경험이니 원래 그러려니 하고 도망치지 말도록. :-(

만약 발생한다고 해도 관제가 가능한 수준으로 만들 것인가 그렇지 않은가는 크게 차이가 발생할 수 밖에 없으며, 이를 하나라도 경험으로 만들고자 하는 기획자와 그렇지 않은 기획자는 다른 개발자들의 신뢰에 대해서도 큰 차이를 가질 수 밖에 없다.

뭐, 그래도 패키지라면 사실 그딴 짓을 저질러 놓고도 '혼자 하는 거니까 뭐 어때? 재미있으면 된 거지.'하고 넘어가도 되니 그 게임 하나에 대해서는 사실 문제가 그리 크진 않은데......

MPOG 에서 개발자의 의도를 넘어간 게임플레이 발생 문제는 끔찍하다. 플레이어가 기획자를 뛰어 넘어 생각했다면 OverLeveling이 가능하게 된다는 뜻이며 컨텐츠를 너무 빠른 속도로 고갈 시키고 불필요한 인플레이션을 조장해 신규 유저의 진입에 장벽을 만들 수가 있다는 이야기다.

아니면 지독한 꽁수를 발생시켜 모든 플레이어가 한 가지 타입의 게임플레이만을 경험하게 되고 다른 컨텐츠를 없는 것이나 다름 없도록 만든다는 뜻일 수도 있고. (나중에 설명하겠지만, 이건 밸런스의 문제를 말하는 것이 아니다. 애초에 Strategy를 잘못 이해하여 설정할 경우에도 자주 발생하는 사태다.)

변명을 준비하지 말고 일단 '좋아, 내 계산 대로 될거야!' 하고 떵떵거리며 스스로에게 배수진을 쳐라. 플레이어가 선택할 최선의 수를 생각하고 그에 대해 대처 방안을 준비하며 최악의 경우를 대비해 캡을 걸어라.

그리고, 그렇게 하기 위해 다른 게임들의 Strategy를 모조리 분석하고 자신의 것으로 만들어라.



다른 게임을 분석하기

사실 본인이라고 뭐 잘나서 완전히 관제 된 범위 내의 플레이를 만들 수 있는 것은 아니다. 그 정도의 수준에 올라갔는데도 실효가 없었다면 아마도 이미 방향을 선회해 다른 내용에 더 중점을 두기 시작했을 것이며, 예상대로의 실효를 거둘 수 있었다면 극히 성공적인 게임을 만들어 잘 먹고 잘 살고 있었을 것이다. :-p

그러나 당장에 완성 되어 있지 않기에 Strategy를 얻어내기 위한 노력에 포커스를 맞추고 있다는 점에서는 꽤 당당히 말할 수 있다.

이를 위해 지금껏 행하던 내용들은 다음과 같다.

● 일단 다른 게임들을 접한 후 게임플레이의 핵심을 알아내거나 유추하기를 반복한다.
  - Simple에 대해서도 신경을 많이 쓰긴 하지만 특히나 Strategy에 중점을 둔다.

● 그런 게임들에 숨겨져 있는 '개발자의 의도'따위에는 눈길을 주지 않고, 실제로 발생하는 게임플레이에만 집중한다.
  - 개발자의 의도와 결과적인 게임플레이가 일치하는 게임은 물론 기획자의 예측 능력이 뛰어나다는 뜻이니 그 게임의 개발자를 존경하기 위한 근거 정도는 되겠지만......
  - 아무리 그래도 의도 따위는 아무런 가치가 없다. 실제로 발생하는 게임플레이가 남는 것이다.

● 기간이 길게 소요되는 게임이거나 스스로 해 보기에 어려운 게임이라면 커뮤니티의 공략글에만 중점을 두고 사례를 수집한다.
  - 리뷰, 프리뷰 등등의 내용은 기록자가 개인인 만큼 당연히 조금의 가치도 없다.
  - 윗 내용의 예외. 물론 시각이 비슷한 리뷰어가 있다면 그의 리뷰를 자주 읽고 같은 예측을 해 보는 것은 나쁘진 않다. :-)
  - 하지만 그것이 진짜 결과 - 판매고 - 와 연관이 없다면, '자신의 시각'을 때려 고쳐야 한다. :-(
  - 어쨌든 공략글의 경우에는 특별히 그 글을 남긴자가 권위자 따위가 아니더라도 실효를 가지기에 진짜로 구체적인 사례가 된다. 이를 잘 읽어 두고 실제로 이 게임플레이를 발생시킨 요소 자체를 분석하는 것은 분명히 자산이 될 수가 있다.

● 그리고 스스로의 가설에 맞춰 게임의 수명을 책정하고 실제 결과와 비교한다.

더 나아가서는 실패했을 때의 쪽팔림에 대해서는 신경쓰지 않고 주변에 공언을 한 뒤 결과를 기다리는 것도 있을 수 있지만 (어차피 변명해 봤자 도움이 안되니 제대로 된 배수진의 효과를 가진다:-) ) 이건 뭐 거칠게 사는 본인 같은 케이스에서나 택하는 방식이니 꼭 흉내낼 필요따윈 없다. lol