클리프 블레스진스키의 게임 개발자 플래시카드

작성자: 클리프 블레스진스키(Cliff Bleszinski)
작성일: 2012년 7월 5일

이번 가마수트라 특집에서는 에픽 게임스(Epic Games)의 설계 디렉터 클리프 블레스진스키가 개발자들에게 공통적으로 나타나는 행동 양식을 정리한다.

내가 게임을 전문적으로 제작한지 올해로 20년이 되었다. 그 동안 캐릭터 마스코트 플랫폼 게임, 1인칭 슈팅 게임, 싱글 플레이어 게임, 멀티 플레이어 게임 등등의 기획을 맡아왔고 아주 뛰어난 프로그래머, 아티스트, 애니메이터, 작가, 프로듀서들과도 작업을 했다. 그러면서 창의력을 바탕으로 하는 우리 업계 사람들 에게 특유의 커뮤니케이션 패턴이 있다는 걸 깨달았다.

개발자들은 놀라울 정도로 똑똑하지만, 함께 일하는 사람들에 비해 자신들이 얼마나 똑똑한지 모를 때가 가끔 있는 것 같다. 나는 온라인 개발자 게시판에서 사소한 문제를 지나치게 분석하며 물고 늘어지면서 십억 달러짜리 프랜차이즈부터 우수한 인디 업체에 이르기까지 모두를 완전히 찢어갈기는 걸 여러 차례 목격했다. 우리는 언제나 제일 먼저 아이디어를 떠올렸다는 걸 입증하거나 어떤 아이디어를 시도했거나, 성공했거나, 실패 했거나 어쨌든 써먹은 사례를 이야기하고 싶어한다.

간단히 말해 이 글은 게임 개발자들이 토의, 토론, 논쟁에서 ‘승리’하기 위해 종종 사용하는 커뮤니케이션 기법에 대한 글이다.

이런 관찰 결과나 내가 붙인 이름들에 악의는 전혀 없다. 실제로 여기에서 언급하는 일부 접근법은 단지 타당한 논리적 추론을 위해 사용한 것이다. 예를 들어 패턴 매칭(pattern matching)은 파생상품을 만들지 않기 위한 좋은 방법이다. 사실 어떤 극단적인 사례가 확고한 아이디어를 무너뜨리기도 한다. 그래서 게임 개발자의 커뮤니케이션 ‘플래시카드’를 소개한다.

“패턴 매칭으로 묵살(Pattern Match Dismissal)”

개발자가 어떤 아이디어를 묵살하기 위해서 머리 속 게임/대중문화 라이브러리에서 가장 비슷한 것(대개 나쁘거나 실패한 사례)을 찾아내는 것을 말한다.

예를 들어, <아바타(Avatar)>에 대해 “시퍼런 사람들이 숲 속에서 살면서 나쁜 군대, 기계와 싸우는 영화를 만들겠다고? 뭐야, <푸른 골짜기 에일리언 스머프(Smurf Ferngully Aliens)>야?”라고 하는 것이다. <기어스 오브 워(Gears of War)>도 삐딱하게 보면 80년대 싸구려 공포 영화 <C.H.U.D.>나 별반 다르지 않다.

“극단적 사례로 막기(Edge Blocking)”

극단적 사례로 기막히게 좋을 수 있는 아이디어를 묵살하는 걸 말한다. 일례로 왔던 길을 그대로 돌아가야 해서 지루할 수 있다는 이유로 <스카이림(Skyrim)>의 거인 세계(giant world) 아이디어를 거절한 사람이 있었다. ‘빠른 이동(fast travel)’ 같은 확실하고 분명한 수정방법으로 문제를 쉽게 해결해 훨씬 큰 세계를 구현할 수 있는 데도 말이다.

극단적 사례로 막기의 변종으로 다음과 같은 것들이 있다.

“네트워커(The Networker)”: 극단적 사례나 코옵(co-op) 상황에서 제대로 되지 않을 거라며 아이디어를 묵살하는 걸 말한다. 이것도 극단적 사례 막기다. “<맥스 페인(Max Payne)> 슬로 모드를 어떻게 코옵에 포함시킬 수 있겠어?

불가능해!”

“완벽주의자(Perfectionist)”: 극단적 사례로 막기와 비슷하다. 개발자가 어떤 멋진 기능이 전적으로 완벽하게 보이지 않는 사례를 찾았을 때 나타난다. 예를 들어 아수라장 장면에서 일부 캐릭터가 서로 겹쳐 잘릴 거라고 하는 것이다.

“잘 될 리가 없어(Ne’er Do Well)”

혹은 “그런 기능을 본 적이 없어. 또는 그런 기능이 잘 되는 걸 본 적이 없어. 그러니 하면 안 돼.”하는 것이다. 굳이 따로 설명이 필요가 없는 항목이다. 사실 이게 바로 어떤 아이디어를 반드시 실행에 옮겨야 하는 ‘이유’가 될 수도 있다. 이런 식의 논리를 따르자면 다른 사람의 성공을 모방할 수밖에 없다.

<기어스 오브 워>의 지하에서 온 로커스트(Locust) 족은 여러 역할을 하지만 꼭 필요한 것은 아니다. 하지만 결국 로커스트 덕분에 흔한 외계인을 내세운 다른 프랜차이즈와의 차별화에 도움이 되었다.

“일부러 반대하기(Devil’s Advocate)”

개발자 대부분은 아이디어가 마음에 들어도 빠져나갈 구멍을 마련하려고 이렇게 행동한다. 변호사들이 대개 그렇듯.

“그냥 두 개 합친 거네(It’s just X+Y)”

개발자가 어떻게 구성되어 있는지 쉽게 파악이 된다는 이유로 성공한 제품에 대해 별거 아니라고 말하는 것이다. 먹지 못하는 포도가 실 거라고 말하는 여우와 같다. 사실 간단하고 명백하기 때문에 성공하는 제품이 많다.

예를 들어 <워즈 위드 프렌즈(Words with Friends)>에 대해 이렇게 말하는 것이다. “그냥 비동기식 스크래블(asynchronous Scrabble)이잖아.” 그렇다. 그래서 대단한 거다.

“나중에 넣자(Future Release)”

개발자가 좋든 나쁘든 아이디어를 듣고 후속 버전이나 속편에 잘 맞겠다고 하는 경우다. 사실 이 말의 속뜻은 “해볼만한 가치가 있는 아이디어 같지 않기 때문에 나중에 출시하겠다고 말해서 상대방 기분을 상하지 않게 하겠다”는 것이다.

“넘어뜨리기(Toppling)”[”바벨탑(Tower of Babel)”]

간단했던 기능에 개발자가 지나치게 많은 부가 기능을 넣는 바람에 결국 기능 자체가 제대로 발휘되지 못하는 경우다. 기능이 결국 스스로의 무게를 이기지 못하고 ‘넘어지는’ 것이다.

※ 자세한 내용은 첨부(PDF)화일을 참고하시기 바랍니다.