싼 만큼 의미도 없다.

어제 오전에는 새로 오픈 한 아기자기한 온라인 게임 하나를 잠깐 둘러봤습니다. 예전에는 아무것도 안 알려 주고 대뜸 ‘알아서 게임 해라’라는 식으로 게임이 덤벼들었지만 요즈음은 어떻게 하면 게임 하는 방법을 사람들에게 잘 가르칠 수 있을지를 고민하는 분위기입니다. 콘솔 기반의 싱글 게임에서는 튜토리얼을 간지 나게 내가 직접 조작하게 해 주고 진행하는 동안에 스탭 소개를 띄우기도 합니다. 내가 튜토리얼을 다 끝내면 대문짝만한 게임 로고가 ‘콰쾅!’ 하고 나타나는 식입니다. 물론 이건 게임을 하기 위해 유저가 배워야 하는 것들이 아주 많지는 않은 게임에 한합니다.

그렇다고 온라인 게임을 즐기려면 훨씬 많은 것을 배워야만 하는 상황이 정상이라는 것은 아닙니다. 온라인 게임은 상대적으로 훨씬 더 많은 인터페이스와 훨씬 더 많은 게임 흐름을 알아야 원활한 진행이 가능하지만 잘 만들어진 온라인 게임이라면 특별한 튜토리얼을 거치지 않아도 한 번에 배워야 하는 만큼씩만 컨텐츠가 개방되어 새로 개방된 컨텐츠를 한 가지씩 익히다 보면 게임 전체를 익힐 수 있도록 디자인 됩니다. 그러면 굳이 모든 것을 처음부터 알기 위해 고생하지 않아도 되고, 개발자는 굳이 유저가 단 한 글자도 읽지 않고 그냥 넘길 바보 같은 설명 윈도우를 만드는데 애쓰지 않아도 됩니다.

물론 현실은 시궁창입니다. 게임은 튜토리얼을 고려하지 않은 채 만들어지고 유저에게 게임을 시작하자 마자 게임 전체를 구성하는 모든 시스템을 쏟아냅니다. 게임을 시작하자 마자 이동, 대화, 퀘스트, 상점, 사냥, 스킬, 채팅, 파티, 길드, 레벨, 성장 … 늘어놓기도 어려운 이 모든 것들을 한 방에 습득해야 합니다. 안 그러면 게임을 진행하는데 애로사항이 꽃피거든요. 물론 개발자들 스스로 이런 상황을 알기 때문에 어떻게든 새로운 요소가 등장했을 때 이 요소에 대한 설명을 하려고 바둥거립니다. 처음부터 컨텐츠를 차례대로 개방하면 됐을 일인데 말입니다.

하지만 컨텐츠 배치가 엉망이라고 해도 조금 신경 쓰면 게임의 구성 요소에 대한 설명을 잘 할 수도 있었습니다. 하지만 가장 싼 방법을 고민하다 보면 알고도 바보 같은 방법을 고르게 되는데요, 오늘 한 게임에서 본 바보 같은 튜토리얼은 게임 인터페이스를 스크린샷으로 찍어 그 스크린샷에 대한 설명을 하는 형식입니다. 스크린샷을 못 찍었으니 예를 들어 설명하자면, 유저가 상점에 가서 물건을 사오는 퀘스트를 하게 됐다고 칩시다. 이 유저는 이제 게임을 시작해서 처음으로 상점에서 물건을 사야 합니다. 개발자에게는 두 가지 선택이 있습니다. 상점 경험을 신중히 디자인하거나, 별 고민 없이 만들어진 상점의 사용 방법을 눈 아프게 설명하는 방법입니다.

아쉽지만 대부분의 국산 온라인 게임은 프로덕션 스테이지의 후반에 후반 까지 가서도 인터페이스에 대한 경험을 디자인 하지 않기 때문에 하는 수 없이 + 알고서도 상점 사용 방법을 눈 아프게 설명할 수밖에 없습니다. 그러면 설명이라도 잘 해야 하는데, 며칠 째 밤을 꼴딱 세웠기 때문인지 모르겠지만 판단력은 흐려지고 대강 팝업 윈도우에 상점 스크린샷 하나 넣고 몇 글자 적어 넣으면 설명이 될 거라고 생각하게 됩니다. 그리고 게임에 이런 설명 윈도우가 정말 나오고 맙니다. :(

네. 오늘 본 상점 설명 윈도우에는 상점을 연 상태의 스크린샷 한 장이 덜렁 들어있고 옆에 설명이 적혀있습니다. … 물론 그 윈도우가 열리자마자 한 글자도 안 읽고 그냥 닫았습니다. 이 윈도우는 세 가지 문제가 있습니다. 일단 글자가 너무 많습니다. 그리고 저는 상점 윈도우를 한 번도 본 적이 없고, 저는 상점 윈도우를 어디서 어떻게 여는지 모릅니다. 그런 상태의 제게 상점 윈도우 스크린샷과 함께 상점 사용 방법에 대해 설명해도 알고 싶은 생각도 없었습니다. 그때서야 저는 이번 퀘스트가 상점에 가서 뭔가를 사 오는 것이 목표라는 사실을 화면 한쪽 구석에서 더듬더듬 인지하고 있었기 때문입니다.

이 상점 설명 윈도우가 주는 교훈은 하나입니다. 처음부터 상점을 잘 만들자~ 가 아니라, “싼 방법은 싼 만큼 의미도 없다”는 것입니다. 튜토리얼이든 뭐든 급하게 싼 방법을 선택해 대충 만들어야 하는 상황이 왔다면 그냥 만들지 않는 쪽이 낫습니다. 개발자 자신이 급하게 대충 만든 무언가가 유저에게 영향을 줄 거라고 믿느니 유저들 스스로가 게임을 탐색하는 것이 더 효율적이라는 사실을 깨달아야 합니다.

2010/01/15 00:06 2010/01/15 00:06

트랙백

답글

  • kirrie | 2010/01/15 10:00 | 답글 | 수정

    매우 공감하는 이야기입니다. '직관적'이란 수식어가 붙는 인터페이스를 만들기란 참 어렵죠.

    그런데 한가지 짚자면, 이건 개발의 문제라기 보다는 기획의 문제인 것 같습니다. 물론 그 모든 제반사항을 통칭해서 '개발자'라고 하셨지만, 구체적으로는 '기획' 혹은 '기획자'의 고민이 부족했다고 해야 할 것 같습니다.

    사실 개발자는 기획된 내용을 구현하는 것 뿐이거든요.

  • 답글: Milfy | 2010/01/15 10:31 | 답글 | 수정

    기획자와 개발자가 서로 다른 의미인가요. 일단 개발자를 '프로그램 만드는 사람'으로 보고 계신 것 같습니다. 글에 제 시각은 '개발자'는 '게임 만드는 사람' 정도의 의미입니다. 저는 기획자이고 기획자가 웬만한 이슈에 일관된 판단력을 유지할 수 있으면 좋겠지만 상당수 경우 그렇지 못합니다. '개발자' 전체가 적당한 판단을 통해 안전망을 유지하지 못하면 결코 제대로 된 게임을 만들 수 없다고 생각합니다. 만약 '프로그램 만드는 사람'이 정말로 기획된 내용을 구현하기만 한다면 그 게임은 결코 성공할 수 없다고 봅니다.

    제가 생각하는 '개발자'는 '게임 만드는 사람 모두'를 말합니다.

  • 아라 | 2010/01/15 13:14 | 답글 | 수정

    일반적으로 (게임이 아닌)소프트웨어를 만드시는 분들 사이에서는
    개발자 = 프로그래머라는 등식이 성립되어 있더군요.
    저는 예전에 기획자와 개발자의 협업에 대한 주제의
    애자일 강연을 들었을 때, 어렴풋이 추측하며 알게되었어요.

    개인적으로 어떤 일을 맡고 있던간에 소프트웨어의 생산자는
    모두 [개발자]가 되는 게임계의 이해관계가 더 마음에 듭니다. :)

답글을 남깁니다.

[로그인][오픈아이디란?]


[요즘에 쓴 글] [예전에 쓴 글]

(C)Milfy / neoocean.net, milfy@neoocean.net