꽃미남 프로그래머 김포프가 창립한 탑 프로그래머 양성 교육 기관 POCU 아카데미 오픈!
절찬리에 수강생 모집 중!
프로그래밍 언어 입문서가 아닌 프로그래밍 기초 개념 입문서
문과생, 비전공자를 위한 프로그래밍 입문책입니다.
jobGuid 꽃미남 프로그래머 "Pope Kim"님의 이론이나 수학에 치우치지 않고 실무에 곧바로 쓸 수 있는 실용적인 셰이더 프로그래밍 입문서 #겁나친절 jobGuid "1판의내용"에 "새로바뀐북미게임업계분위기"와 "비자관련정보", "1판을 기반으로 북미취업에 성공하신 분들의 생생한 경험담"을 담았습니다.
Posted by ozlael


들어가며

이번에는 레벨 디자인에 관한 말씀을 드려보고자 합니다. 일개 코더 나부랭이가 기획에 대해 뭘 아냐구요? 죄송합니다 꾸벅 ㅠ 제가 뭐 이렇다 저렇다 할 철학이 있는건 아니고, 괜챦은 내용을 듣게 되서어 여러분께 소개해드리고자 합니다. 이번 GDC 2012때 레벨 디자인에 관한 세션인 "Level Design Case Studies: Trainyard and Cut the Rope"를 들었는데, 내용이 참 좋았습니다. 거기서 배운 교훈들을 여러분과 공유하고 싶어서 키보드를 끄적(?)거립니다. 


자료가 배포 되었네요.

http://www.gdcvault.com/play/1015344/Level-Design-Case-Studies-Trainyard


제목에서 이미 나와 있듯이 트레인야드와 컷더로프란 두 퍼즐 게임의 레벨 디자인에 관한 포스트모템입니다. 혹시 이 두 게임을 모르신다면 말로 설명드리는 것 보다는 아래 두 동영상을 보시는게 나을 것 같습니다.

컷더로프는 아이폰과 안드로이드용이지만 웹브라우져에서도 맛볼 수 있습니다 (http://www.cuttherope.ie/)

트레인야드는 현재 아이폰용으로만 출시되었습니다 ( http://itunes.apple.com/app/id348719156 )

보셨다시피 룰 자체는 매우 간단한 게임입니다. 컷더로프는 그냥 로프를 자르면 되고 트레인야드는 그냥 길만 만들어주면 되지요. 하지만 그 단순한 룰을 가지고 레벨을 잘 만들어 놓음으로써 많은 재미를 안겨다 주고 있는 게임들입니다. 바로 이 두 게임이 말하는 레벨 디자인의 원칙에 대해 정리를 해 볼까 합니다. 두 게임의 철학이 비슷해서 이야기 하는 순서가 원본과는 다를 수 있습니다. 게다가 제 사견도 섞어서 말씀드리고 있으므로 왜곡 없이 받아들이시려면 원본 자료가 공개되면 한번씩 보시길 추천드립니다.



요소 추가

새로운 퍼즐 요소를 추가하게 되는 경우 한 레벨에서 두 개 이상 한번에 추가하지 않습니다. 우리 모두 잘 알고 있는 앵그리버드를 예로 들자면 새의 종류를 한번에 모두 등장시키지 않지요. 처음에는 빨갱이만 등장시키고 게임 사용법을 가르치고 레벨을 넘기고 난 뒤에야 노랭이를 등장시키고  그 다음이 되어서야 깜댕이 등등을 차례 차례 등장시키지요. 모든 종류의 새를 한번에 등장시키고 컨트롤 하게 한다면 플레이어는 매우 힘들어 했을것입니다. 한번에 모든 요소를 등장시키지 않는 것은 난이도를 낮추고 사용자에게 게임을 가르치는 의미도 있지만, 요소를 조합함으로써 다양한 재미를 느낄 수 있는 레벨을 제공 할 기회도 되겠지요.

그럼 요소를 추가할 때도 그냥 한 레벨 당 하나씩 그냥 추가하면 되는 것일까요? 요소를 하나 하나 추가한다면 다음과 같이 순차적으로 추가를 하게 될 것입니다. 첫 레벨에는 A만 사용하고 다음 레벨에서는 B를 추가하고 그 다음 레벨에서는 C를 추가하겠지요.

A    →    + B    →    + B + C

하지만 다음과 같이 다양한 조합을 사용하면 더 효율적으로 사용을 할 수 있지요. 플레이어는 난이도가 급진적으로 올라는 것이 아니라 비슷한 난이도를 유지 하면서도 많은 요소를 접하게 되기 때문에 게임에 적응하는데 어려움이 없게 될 것입니다. 초반이나 튜토리얼 뿐 아니라 레벨을 계속 진행함에 있어서도 이러한 요소들을 조합함으로써 난이도를 제어하는 것이 가능합니다.

A    →    B    →    B     →    C    →    A + C    →    B + C    →    B + C



설명

튜토리얼 레벨이거나 새로운 요소가 추가되는 레벨이라면 반드시 그 원리를 설명해주어야 하지요. 다만 그때 그때 필요한 정보만 알려주어야 합니다. 2단계에서 B요소만 추가되었으면 B요소에 관한 설명만 해야지 쓸데없는 다른 요소들에 대하여 알려줄 필요도 없거니와 플레이어는 알고 싶지도 않을 것입니다. 

요소를 설명 해 줄 시 텍스트보다는 그림으로 설명 하는 것이 좋습니다. 앵그리버드는 새로운 새를 등장 시킬 때 마다 글자 하나 없이 이미지로 설명을 보여줍니다. 글자 하나 없어도 그 그림이 너무나도 명확하기때문에 바로 이해가 되게 설명을 해주고있습니다. 플레이어에게 정보 전달을 쉽게 할 수 있는 장점 외에도 개발자 입장에서는 로컬라이징에 대한 신경을 떨 써도 된다는 장점도 있겠지요.

사실 이미지에 대한 중요성은 게임 뿐 아니라 어느 분야에서나 공통적으로 하는 이야기입니다. 브레인 룰스의 저자인 존 메디나 박사는 여러 연구에 의해서 그림에 대한 인식룰은 글자의 두 배에 달하는 것이 증명되었다고합니다. 스티브잡스도 프레젠테이션에서 글자보다는 그림을 선호합니다. 글자를 사용하게 되더라도 최소한의 단어만 사용하지요.

설명해줘야 할 것이 복잡해서 그림만으로는 설명이 불가능하다면 글자가 필요하긴 하겠지만 최소한으로 줄여야 할 것입니다. 플레이 되는 과정을 동영상 등으로 보여준다면 금상첨화겠지요.



난이도

플레이어가 레벨을 넘기고 나면 다음 레벨을 기대하며 항상 배고픔을 느끼게 해 줘야 합니다. 이런 퍼즐류의 게임은 플레이어가 레벨 하나 하나 해결 할 때 마다 자신이 영리하다고 느끼게 되고 그로 인해 재미를 느끼게 됩니다. 그렇기 때문에 플레이어가 퍼즐을 풀고나서 "내가 어떻게 깬거지?"라는 생각을 갖도록 구성해서는 안됩니다. 그냥 "이것 저것 막 하다보니까 어찌어찌 되더라" 라는 느낌을 주는 것이 아니라, 퍼즐을 보고 플레이어가 해결 시나리오를 구성 할 수 있어야 합니다. 그렇기 때문에 레벨의 해결책은 논리적이고 명쾌하고 재현가능해 보여야 합니다. 그리고 실제 가능해 보이는 레벨을 구성해야 하겠지요.

장애물 역시 명확해야 합니다. 아래 그림을 보시면 사탕이 장애물을 피해서 어디로 가야 할 지 확실히 각인이 됩니다. 가시 장애물의 간격이 애매하게 좁아서 사탕이 지나갈 수 있을지 없을지 모르는 애매한 간격이 아니라 누가 봐도 지나 갈 수 있다고 판단되는 간격으로 설치 되어 있지요.

플레이어에게 지루함 대신 이러한 퍼즐을 해결하는 즐거움을 부여하기 위해 게임 레벨을 진행 할 수록 난이도가 증가합니다. 하지만 그 난이도의 증가를 무조건 일정하게 증가하게 두는 것 보다는 적당한 텐션을 두며 증가시기는 것이 좋습니다. 계속 계속 난이도가 높아지기만 한다면 플레이어는 그 난이도에 적응하지 못하고 쉽게 지쳐버릴 것입니다. 한 고비를 넘기고 나면 그 다음 레벨은 난이도를 조금 낮추어 플레이어가쉽게 지치지 않고 플레이를 진행 할 수 있도록 난이도가 구성되어야 합니다.

또 한가지 주의해야 할 점은 플레이어가 극악의 난이도에 좌절하게 두어서는 안된다는 것입니다. 가끔 어떤 게임을 보면 캐쥬얼 유저와 하드코어 유저를 모두 커버하기 위해 처음 난이도는 쉽지만 끝에는 거의 깨기 불가능한 난이도의 레벨을 두기도 합니다. 오로지 1%만이 클리어가 가능한 레벨을 게임 진행 과정에 두어서 나머지 99%가 플레이 진행을 못하도록 두는 것은 어리석은 짓입니다. 많은 플레이어가 마지막까지 진행을 해 볼 수 있도록 해야 합니다. 그리고서는 더 많은 레벨을 해 보고 싶은 배고픔을 느끼게 해야할 것입니다. 앵그리버드가 시즌을 지나 스페이스까지 나올 수 있는 이유중 하나가 그것에 있지 않을까 싶습니다.

하드코어 유저를 위한 레벨을 원한다면 보너스 레벨의 개념으로 두어야 할 것입니다. 플레이어가 "내가 똑똑해서 보너스 레벨을 깼어"라고 느끼는 것과 "내가 멍청해서 게임 진행이 안돼"라고 느끼는 것은 천지차이겠지요. 

또한 별점 및 랭크 개념을 두어 플레이어 스스로가 난이도를 조절 할 수 있게 두는 것도 좋은 방법입니다. 캐쥬얼 유저는 별점을 다 모으지 않더라도 레벨을 넘기는 것에 재미를 느끼며 진행하겠지만 하드코어 유저는 별점을 모두 모으려 노력하며 스스로의 난이도를 높이며 재미를 느끼겠지요.  



디바이스에 대한 고려

게임 엔진이나 하드웨어의 약점이 영향을 미치게 디자인 해서는 안됩니다. cut the rope는 안드로이드와 아이폰 뿐 아니라 PC에서도 플레이가 가능한 멀티플랫폼으로 제작되었습니다. PC에서는 마우스로 로프를 끊으면 되므로 섬세한 제어가 가능합니다만 스마트폰에서는 손가락으로 끊어야 하므로 PC처럼 섬세한 제어가 불가능합니다. 그렇기 때문에 애초에 로프를 충분히 길게 설치하여 플랫폼과 상관 없이 원활한 플레이가 가능하게 두었습니다. 

최근에는 대부분이 이러한 플랫폼에 대한 약점을 고려해서 개발을 하고 있습니다만 스마트폰 초창기에는 이에 대한 약점이 많이 발견이 되곤 했지요. 피쳐폰의 게임들을 그대로 포팅하면서 화살표 버튼을 화면에 올려버리는 바람에 손가락이 게임 UI를 가리게 되는 상황이 허다했습니다. 특히 감압식 디바이스가 존재하는 시기에는 게임 한판 하고나면 손톱이 빠질 것 같은 통증이 몰려오곤 했습니다. 망할 옴레기 요즘에는 그런 극단적인 현상까지는 찾아보긴 힘들지만 태블릿 폰 기준으로 만들어서 작은 스마트폰에서는 버튼 누르기가 힘든 게임들은 종종 보이곤 하지요.



데이터 기반

논쟁이 많긴 하지만 최근 게임 디자인들은 데이타 주도 개발에 많은 비중을 두고 있습니다. 테스터를 통해서 플레이어들이 어떤것을 힘들어하고 어떤 것을  재미있어 하는 지를 조사해야 합니다. 이미 많은 게임들이 포스트모템을 통해서 이러한 철학을 채용하며 개발을 하고 있습니다. 하프라이프의 개발사인 밸브의 경우는 테스터의 표정 변화까지도 기록을 하며 재미를 분석하기도 하고, 어쌔신크리드의 개발사인 유비소프트는 테스터의 이동 경로를 기록으로 남겨 레벨 디자인에 반영하기도 합니다. 건즈와 레이더즈의 개발사인 마이에트엔터테인먼트의 경우는 플레이어들의 케릭터가 죽은 위치를 히트맵으로 남겨 난이도 조절에 반영하기도 합니다.

하지만 플레이어의 피드백을 받을 시에는 주의 사항이 있습니다. 항상 플레이어들의 의견을 주시하고 피드백을 받고 개발을 해야 하는 것은 당연하지만 피드백을 생각없이 액면 그대로 받아들이면 안된다는 것입니다. 플레이어의 피드백을 받아들임에 있어서도 무엇이 본질인지 곰곰히 생각하고 반영을 해야 합니다. 이에 관하여 박일 저 위대한 게임의 탄생 2권에서는 가와사키 제트스키의 일화를 소개하고 있습니다. 

제트 스키를 개발한 가와사키(Kawasaki)사는 제트 스키 경험을 개선하기 위해 무엇을 해야할지 사용자들에게 물었다. 사용자들은 측면에 여분의 패딩을 추가해서 제트 스키를 서서 탈 때 자세가 더 편안하기를 원했다. 회사는 고객들이 요청한 것을 제공하는 데 집중을 했다. 그 동안 다른 제조사들은 앉아서 타는 모델을 개발했고, 가와사키를 시장 최고 자리에서 끌어내리게 되었다. 고객들이 원한 것은 제트 스키 이용시 더 편한 기립 자세였지만 그들은 앉아서도 탈 수 있다는 생각은 해내질 못했다. ‘앉아서 타는’ 모터싸이클 제조 업체였던 가와사키까지도. [내용출처link]



마치며

하드웨어 및 소프트웨어 기술은 눈이 부시게 빠른 속도로 발전하고 있습니다. 그리고 이에 맞게 게임 산업 역시 다른 산업 못지 않는 빠른 속도로 발전을 하고 있습니다. 하드웨어 기술이 발전함에 따라 게임을 즐길 수 있는 플랫폼의 영역이 넓어지고 있고 그 성능 또한 빠른 속도로 증가하고 잇습니다. 그 성능에 맞춰서 소프트웨어 역시 높은 퀄리티를 뽑아 낼 수 있게 진화하고 있습니다. 하지만 게임의 본질은 이런 하드웨어나 소프트웨어가 아니라 컨텐츠일 것입니다. 재미 요소를 찾아내고 재미있는 컨텐츠를 제작하는 능력이야 말로 제일 중요한 기술이 아닐까 싶습니다. 이런 디자인 기술은 직렬 직군 상관 없이 게임 개발자라면 항상 관심을 가지고 봐야한다는 생각에 여러분께 소개를 해드렸습니다만 재미는 있으셨는지 모르겠습니다. 지루한 글 끝까지 관심가지고 읽어주셔서 감사합니다. 


반응형
,