여러분은 대격변에서의 치유 방식이 달라질 것이라는 소식을 들어보셨을 겁니다. 치유 역할의 난이도가 다소 높아지는데요, 특히 자원을 관리하는 측면에서 그렇습니다. 토론장을 통해 관련 내용을 접하셨던 분들께는 그다지 새로운 소식이 아닐 수 도 있겠습니다만, 그 동안 “치유 직업들을 왜 하향시키나요?”라는 문의가 있었던 만큼, 관련 내용에 대해 말씀 드리고자 합니다.

대체로 리치 왕의 분노에서는 치유 역할 담당자들은 마나를 고려할 필요가 없었었습니다. 물론 때때로 마나가 바닥나는 경우도 있었습니다만, 리치 왕의 분노 이전과 마찬가지로, 마나 소모량을 고려해서 치유에 사용할 주문을 선택하지는 않았었지요. 하지만 개발팀은 마나가 보다 중요하고 민감한 요소가 되어야 한다고 생각합니다. 많은 게임들이 제한된 자원을 관리하도록 유도하고 있으며, 전략 게임에서는 베스핀 가스를 관리하고, 1인칭 슈팅 게임에서 탄약을 관리하며, 심지어 퍼즐 게임에서는 시간을 관리하도록 하도록 하고 있습니다.

자원을 관리함으로써 실력을 향상시킬 수 있습니다. 만약 자원의 한계를 없앤다면 잠시 동안 강해졌다고 느낄 수 있지만, 이는 규칙을 깸으로써 느낄 수 있는 것입니다. 실제적으로 시간이 흐르고 나면 이에 대한 흥미를 곧 잃게 될 것입니다. 게임 내 무한한 힘에 대한 재미는 오래 지속될 수 없습니다.

이제 다른 직업보다 치유 직업에게 자원 관리가 큰 비중을 차지하게 되었습니다. “이건 불공평해!” 하고 불만을 가질 수도 있습니다.이 비유를 전에도 사용했고 많은 분들이 이미 보셨을 수 있지만, 다시 한번 말씀 드리자면, 공격 직업은 전력질주와 같습니다. 기본적으로 공격 직업은 있는 힘을 다해 달리는 직업입니다. 하지만 치유는 전력질주가 아닙니다. 오히려 조심 조심 던져야 하는 다트 게임과 같죠.

치유 직업은 최대한 정확하게 다트를 던져야 합니다. ‘때에 맞춰 적절한 주문을 사용해야 한다’라는 명제는 치유 역할 담당자에게 중요합니다. 각 도구를 사용하는 데에 자원이 얼마나 드는지에 따라 치유 직업의 개성이 나타나기도 합니다. 자원의 제약을 없애면 이러한 도구를 구별 짓는 요소 중 하나가 없어지는 것입니다. 한때 마나가 바닥나지 않고도 모든 동료를 살리는 것은 치유 역할 담당자들의 실력을 판가름하는 요소였습니다.

몇 가지 이유로 리치 왕의 분노에서는 치유 직업들의 마나 재생이 과도한 수준이었습니다. 과도한 마나 재생으로 인해 발생한 상황들을 살펴보겠습니다.

우선, 비용이 비싸고 시전 속도가 빠른 치유 주문을 어려움 없이 사용하게 되었습니다. 자원을 신경 쓰지 않을 때 많은 자원이 소모되는 치유 주문은 그저 빠른 치유 주문일 뿐입니다. 마나를 신경쓰지 않는다면 빠른 치유 주문을 마다할 이유가 있을 까요? 이런 이유로 치유 직업의 선택의 폭은 줄어들었습니다.상황에 맞는 치유 주문을 사용하는 대신, 모든 치유 직업들이 신의 권능: 보호막, 빛의 섬광, 회복 등의 주문만을 사용했습니다. 거듭 고민한 끝에, 흥미로운 선택을 하는 과정이 게임을 더욱 재미있는 만든다는 결론을 내렸습니다. 지금 같은 경우 시전 속도가 느린 치유 주문이나 단순히 비용만 높은 치유 주문은 아예 후보에서 제외될 정도입니다. 여러분이 사용할 수 있는 도구가 너무 적다면, 여러분은 흥미로운 선택을 할 기회가 그만큼 줄어드는 셈이죠.

둘째로, 치유 역할 담당자들이 마나를 걱정할 필요가 없기 때문에, 처음에 의도했던 것보다 공격대 전투를 더욱 어렵게 만들었어야 했습니다. 이 때문에 종종 방어 직업이나 공격대 전체에 매우 큰 피해를 입히는 식의 전투가 진행되었습니다. 그래서 치유 역할 담당자들은 어떤 치유 주문을 사용할지에 대한 선택의 여지가 없을 뿐만 아니라, 전역 대기 시간이 돌아올 때마다 치유 주문을 사용하지 않으면 동료를 죽일 수 있는 부담도 함께 가지게 되었습니다. 이런 방식 때문에 치유 역할을 한다는 것은 기지 넘치는 역할이 아닌 단순 작업을 지속하면서 부담감이 더해지는 상당히 괴로운 일이 되었지요. 만약 여러분이 잘못된 대상을 치유 하거나, 잠시라도 머뭇거리거나, 회선이 잠깐 불안정해지면, 그것은 바로 동료가 죽는다는 것을 의미했으니까요.

세 번째로, 마나 관련 특성이나 정신력, 혹은 마나를 회복시켜주는 발동 효과처럼 마나 재생에 관여하는 능력들이 별 의미가 없게 되었습니다. 게다가 마나가 큰 문제가 되지 않았기 때문에 아무렇지도 않게 치유 주문을 난사하였고 모든 치유 주문들이 대상의 생명력을 초과하여 치유하여, 주문 극대화의 가치도 줄어들었습니다.

네 번째로 플레이어간 전투 균형에도 문제가 생겼습니다. 치유 역할 담당자들은 마나 걱정 없이 또는 체력을 초과하여 치유하는 것에 대한 염려 없이 마음껏 치유하였기 때문에, 전투가 지루해 졌습니다. 상대방을 죽이던가, 죽이지 못하던가 둘 중 하나죠. 부상을 입은 상태는 결코 오래 지속되지 않았고, 전투의 판도가 바뀐다거나 상황을 역전하는 일도 벌어지지 않았죠. 첫 서브만으로 승패가 결정되는 테니스 경기를 상상해 보시면 이해가 빠를 겁니다. 이러한 상황은 생명력을 증가시킴으로써 개선해볼 수도 있었습니다. 대격변에서 그렇게 된 것처럼요. 하지만 무한정한 마나는 공격대 전투를 쉽게 만들 뿐이었습니다.

정리하자면, 저희는 치유 역할 담당자들이 계속 마나 부족에 허덕이기를 바라는 것이 아닙니다. 다만, 역할을 제대로 해내지 못했을 때 마나가 부족해지는 상황에 놓이도록 하고자 합니다. 또한 여러분이 항상 마나 관리에 어려움을 겪기만을 바라는 것도 아닙니다. 대신 도전해볼 만한 상황과 마주하고 이를 이겨냈을 때 성취감을 느낄 수 있게 되기를 바랍니다. 동료가 부상을 당한다면, 치유 역할 담당자들은 상대방이 즉시 죽지 않을 것이라 예상하고 느리고 효율적인 치유 주문을 사용할 것인지, 혹은 이어지는 공격에 바로 죽을 위험이 있으므로 빠르고 자원 소모가 많은 치유 주문을 사용할지 판단을 해야 합니다. 이는 치유 우선순위 판단이라고 하며, 리치 왕의 분노에서와 같은 치유 환경에서는 존재하지 않던 개념입니다. 개발팀은 치유 우선순위를 판단할 때 치유 활동이 좀 더 재미있을 거라 생각합니다. 이러한 변경 사항을 통해 치유 역할 직업들을 약화시켜 슬프게 만들려는 것이 아니며, 치유 역할 담당자들이 게임을 좀 더 재미있게 즐길 수 있도록 돕고자 합니다.

출처: 와우플포(http://www.playforum.net/wow)

---------------------------

유저와 소통하고 공감을 얻어내려는 걸까요? 아니면, 그냥 이슈를 만드려는 것일까요?

어쨌든 내용을 떠나, 이런식의 글은 좋네요.

악마의 아이폰 게임 하나 소개하려고 합니다.

바로!!

최근 친구들과 모임에서 당구나 볼링을 치고 있는데요.

그 동안 잘 하지 않았던 "놀이 문화"라서 그런지, 재미에 푹 빠져 있습니다.

오늘은 노는 중에 문뜩 이런 생각이 들더군요..

"왜 재미있을까?"

이 의문에 대해 다시 한번 생각해 봤습니다.


먼저, 재미있는 이유를 정리해 보면,

  1. 사람들과 함께 플레이하면서 협동 or 경쟁하며, 즐거운 커뮤니케이션을 하게 됩니다.
  2. 승리 시 게임비가 현금(게임비)를 아낄 수 있다는 보상이 주어집니다.
  3. 볼링에서 스트라이크나 스페어, 당구에서 점수를 낼때 뭔가 해냈다는 "즐거움(성취감)"을 느낍니다.
  4. 조금씩 배우고 성장하면서 실력이 늘어가는 학습의 즐거움이 있습니다.
  5. 게임 후에도 게임의 경과/결과에 대해 애기하며 커뮤니케이션하는 즐거움이 있습니다.

정도가 될 것 같습니다.

반대로 재미없다고 느껴지는 경우도 있죠.
다음과 같습니다.

  1. 숙련도(실력)가 너무 낮은 상태에서 성장하는 느낌을 받지 못하면 재미 없어집니다.
  2. 간혹, 게임에 몰입이 안되거나, 운이 따라주지 않아 평균이하의 성적을 보이면, 흥미가 떨어집니다.
  3. 경쟁하는 대상(또는 팀)이 월등히 높은 숙련도를 가졌다면, 흥미보다 자괴감이 큽니다.
  4. 패배 시 페널티가 크거나 기분 나쁘다면, 다시 게임을 하려고 하지 않을 수 있습니다.


뭐.. 의도적으로 게임에서 사용되는 용어를 사용하긴 했습니다만,

무시하더라도 게임에서 유저가 재미를 느끼는 것과 재미를 잃는 것에 한 측면을 볼 수 있는 것 같습니다.

그냥 그렇다구요..

WoW 수석개발자, 퀘스트 디자인의 실수와 교훈

제프리 카플란(Jeffrey Kaplan)은 월드오브워크래프트(이하 WOW)의 퀘스트 디자인을 하면서 몇 가지 실수를 했으며, 거기에서 교훈을 배웠다고 한다.

WOW의 전 수석 디자이너였던 그는 현재 블리자드의 미공개 차기작을 맡아 일하고 있다. 그는 2009년 게임 개발자 회의(GDC;Game Developer Conference)에 참석해, 'WOW에서의 의도된 게임 플레이(Directed Gameplay Within World of Warcraft)'라는 세션에서 토론 시간을 가졌다. 이 세션에서 그는 주로 퀘스트 디자인과 관련해 저질렀던 실수와, 여기에서 배운 교훈에 대해 이야기했다.

아래는 게임 개발 전문 매체 Gamasutra에 보도된 토론 내용 일부를 발췌한 것이다.


크리스마스 트리 효과

크리스마스 트리 효과에 대해 카플란은 이렇게 말하고 있다. "이는 퀘스트가 많은 지역에서 퀘스트를 승인하고 나면, 미니맵이 퀘스트 표시 때문에 크리스마트 트리처럼 빛나는 것을 의미합니다. 이 때 생기는 문제점은 디자이너들이 플레이어들로 하여금 재미있는 경험을 하도록 유도하지 못하게 된다는 것입니다. 이는 경험들이 일직선 혹은 기차 선로와 같은 구조로 되어 있거나 선택의 여지가 없어야 한다는 의미가 아닙니다. 플레이어들이 좀더 좋은 선택을 하게 해주고 싶을 뿐입니다."


문제는 플레이어들이 지금 무슨 내용을 진행하고 있는지 알지 못한 채, 닥치는 대로 퀘스트를 쓸어담는다는 것이다. 이 때문에 게임은 더 어려워지고, "만들어진"것 처럼 보이게 된다.


너무 길어서 읽지 않음

이는 퀘스트 디자인에 대한 문제인데, 블리자드에서는 퀘스트 내용을 약 한글 255자(영문 511자)로 제한하고 있다. 카플란은 게임 디자이너들이 글을 쓰고자 하는 열정을 이렇게 묘사한다. "우리들 중 비디오 게임 텍스트를 쓰는 누구라도 겪는 실수입니다. 겉으로 표현하자 마자, 사람들은 모두 우리가 너무 자기 세계에 빠져 있다는 사실을 깨닫게 될 것입니다.." 자신의 글에 너무 집착하지 말고, 실제로 게임을 플레이 하는 유저들의 입장에서 생각하라는 것이다.


"때때로 우리 게임도 그렇지만, 너무나 많은 게임들이 자신이 아닌 모습이 되려고 하는 모습은 안타깝습니다. 예술, 문학, 드라마, 영화, 노래는 모두 일정한 맥락 안에 있고 자신만의 방식으로 이야기합니다. 우리는 게임 속에 빌어먹을 책 쓰는 일을 그만해야 하는데, 왜냐하면 아무도 그것을 읽고 싶어하지 않기 때문입니다. "

미스테리

카플란은 좀더 복잡한 문제에 대해 이야기했다. 퀘스트 디자인에 있어 "미스테리"같은 막연한 개념을 집어넣는 것 말이다. 이는 대단히 구체적인 결과를 낼 수가 있다.


"때때로 제가 이것을 망쳐버리곤 합니다." 카플란이 고백했다. "이는 미스테리가 들어 있는 이야기가 나쁘다는 말이 아닙니다. 미스테리가 문제되는 이유는, 미스테리는 절대 플레이어들이 해야 하는 행동에 들어가 있어서는 안되기 때문입니다. 우리의 퀘스트 철학은 심지어 미스테리가 들어있다 해도, [숲 속에] 뭔가 나쁜 것이 있다. 가서 밝혀내가.' 라는 식으로 만들어서는 안 된다는 것입니다. 마지막에 가서는 '이놈을 죽이고, 아이템을 가져와라'라는 식으로 되어야 합니다. 심지어 유저가 [따로 웹사이트나 자료를 사용]하는 성격이 아니더라도, 내키지 않지만 퀘스트 설명에서 [해답]을 찾아낼 수 있어야 합니다."


연계 퀘스트의 배열이 좋지 않음

카플란은 그런 퀘스트 디자인이 명백히 끔찍하다고 느낀다. "우리는 플레이어들에게 신뢰를 잃습니다. 게임 개발자로서 우리가 해야 하는 일은, 신뢰를 쌓아 유저들을 재미있는 경험으로 이끄는 것입니다. 유저가 레벨이 낮아 당장 수행할 수 없는 퀘스트나 잡을 수 없는 몹을 만나자 마자, 우리는 신뢰를 잃습니다.


좋지 않은 흐름

카플란은 퀘스트의 흐름도를 보여주었는데, 한번에 몹을 4마리 잡은 다음 다시 한번에 아이템을 4개 수집하는 퀘스트였다. 그가 말하기를 이는 좋지 않은 디자인인데, 다음 번 패치에서 다시 설계될 거라고 했다. 목표를 이루기 위해서는 다양한 방식을 사용할 수 있어야 하고 만약 가능하다면, 일반적이지 않은 (그러면서도 만들다 만 쭉정이가 아닌)요소도 포함할 수 있어야 한다. "이는 유연성을 지니면서도 언제나 되돌아갈 수 있도록 유도하는 것입니다."


수집 퀘스트에서의 실수

"저는 수집 퀘스트들이 망했다고 생각하지는 않지만, 종종 수집 퀘스트를 엉망으로 디자인하긴 했습니다." 예를 들면 다음과 같다.


- 좋지 않은 흐름
- 퀘스트 몹 밀도와 관련된 이슈
- 한 가지 아이템을 너무 많이 모아야 함
- 다양한 아이템을 모아야 함


"WOW같은 게임을 플레이 하는 플레이어들이 겪어야 하는 세금 같은 것 중 하나는, 인벤토리 관리입니다. 기본적으로 모든 플레이어들은 가방 안에 무엇을 넣을 지 결정을 해야 합니다."


내가 왜 이따위 것들을 수집하고 있나?

"당신은 결코 플레이어들이 게임을 만든 누군가를 떠올리는 것을 원하지 않을 것입니다. 당신은 플레이어들이 자기 자신만을 생각했으면 하고 바랄 것입니다." 아이템을 수집하는 것은 때때로 극도로 강압적이고 무의미해 보일 수 있습니다. 하지만 만약 수집하는 행위가 스토리에 영향을 끼친다면, 더 좋은 효과를 불러올 것입니다. 환호할 만한 순간이 있기만 하다면, 당신이 [플레이어들을] 어떤 과정에 몰아넣어도 좀더 순응하게 될 것입니다.


"짜증나는 노가다"는 아이템 수집 퀘스트에서도 문제가 됩니다. 리치 킹에서 WOW는 향상된 확률 시스템을 도입했습니다. "수집퀘스트의 대상이 되는 몹은 모두 퀘스트 아이템을 100% 가지고 있습니다. 하지만 우리는 플레이어가 그 몹을 몇 마리나 죽여야 아이템을 얻는지에 대한 향상된 시스템을 사용하며, 계속 추적합니다."


비록 숫자들이 정확하지는 않지만 시스템을 수치화하면 다음과 같다. : 몬스터를 처음 잡을 때에는, 아이템을 얻을 확률이 16%이다. 두번 째는 32%, 세번 째는 48%, 그리고 결국에 100%가 된다. 하지만 이렇게 경고하고 있다. "이 때문에 좋은 노가다 까지 묻혀버릴 수 있습니다. 기본 드랍율을 더 높혀야 합니다."


질문과 답변

퀘스트 테스트에 대해 묻자 카플란은 모든 스튜디오가 그런 것은 아니지만, 특히 블리자드에서는 모든 디자이너들이 반드시 게임을 해 보아야 한다고 답했다.


"플레이 테스트는 누군가 게임 내에 추가할 때마다 시작됩니다."


어떤 질문자는 왜 그가 WOW에 접속할 때마다 10분 동안 세계를 날아다니냐고 물었다.


카플란은 이것이 초보 디자이너 시절의 흔적이라고 설명한다. "진짜 발전한 모습을 볼 수 있을 것입니다. 만약 당신이 오리지널 컨텐츠를 보고 불타는 성전과 비교한 다음, 다시 리치 왕의 분노 컨텐츠와 비교한다면, 리치 왕의 분노는 우리가 가고싶어 하는 방향이라는 사실을 알 수 있을 겁니다.


오래된 퀘스트들이 개선될 계획이고, 여행 시간은 점점 단축될 것입니다. 게임이 발표되기 전에, 우리의 철학은 플레이어들이 이 크고 아름다운 세상을 좀 더 여행하도록 만드는 것이었습니다.... 우리는 여러분을 너무 멀리 보내는 우스꽝스러운 퀘스트를 많이 만들었습니다. 우리는 후에 이것들을 "경로 유도" 지침에 따라 재설계했습니다."


누군가 카플란에게 출시일에 대한 공식 지침이라던가 플레이어의 지루함 척도가 있냐고 묻자, 카플란은 이렇게 답했다 "전투만큼은 확실히 지침이 있습니다. -- 우리는 전투가 1분 정도 지속되길 바라며, 그리고.... 지금은 조금 빠릅니다. 다른 것들에 대해서는, 그때그때 다릅니다."

------------------------------------------------------------------------------------------

주석 : 이 가르침들은 기본적으로 큰 뜻을 품은 게임 디자이너들을 위한 것이지만, 여기에서 다루고 있는 많은 개념들은 게임 산업에서 다른 형태로 종사하는 사람들에게도 적용될 수 있다. 이 가르침들은 변경되고 개선될 수 있으며, 독자들의 의견은 환영하는 바이다. 특히, 나는 내가 게임 산업에서 쌓은 20년이 넘는 경력 때문에 다소 “지긋지긋한” 사람으로 인식되는 경향을 극복하기 위해 아직도 노력중이다. 어떤 부분이 너무 부정적인지를 내게 알려준다면, 내가 그 부분을 완화시키겠다. 이 얘기는 이번 과 뿐만 아니라, 앞선 과들에게도 적용되는 말이다.

게임 업계에서 일을 시작하려면 테스터라는 일이 좋다는 말을 분명히 들어보셨을 것입니다. 부정적인 의견도 함께 들으셨을 것입니다. 하지만, 말씀 드리건대 그런 부정적인 말들은 죄다 틀린 것입니다. 물론 테스트는 하위 보조 업무이고, 밑바닥 일입니다만, 매우 중요한 일입니다. 또한 게이머들에게 즐거운 경험을 선사하며, 게임을 빛나게 하는 생명 같은 일입니다.

테스터는 훌륭한 취직의 길이기도 합니다. 이번 글에서 그 이유를 많이 찾을 수 있을 것입니다.

용어 해설 : 테스트팀은 "품질보증(Quailty Assurance)"부서로 불리기도 합니다. QA라는 약어로서 테스트과 관련된 업무나 처리를 나타냅니다. 본문에서 "테스트"와 "QA"가 같이 쓰이고 있습니다.

주석 : 본문의 테스터는 상근직을 지칭합니다(즉 생업으로서 회사에 테스트 결과를 보고하는 고용인). 자원봉사자, 즉 "베타 테스터"(집에서 게임을 해보고 이메일로 보고하는 무급 테스터)는 이 글과 무관합니다. 테스터로 취직하는 것은 게임 업계에 종사하는 좋은 방법이지만, 베타 테스터는 일반인이나 다름없습니다.

최종 단계로서의 테스트

액티비젼(Activision)같은 대형 개발사에서 QA는 프로젝트의 최종 과정입니다. 이런 곳에서 테스터는 게임의 대부분이 완료될 때까지 투입되지 않습니다. 이는 테스터들이 기획 과정에 참여할 수 없고, 관련 사항을 알려주지도 않기 때문에 불행한 일입니다. 하지만, 소규모 회사에서는 개발에 참여하는 팀원이 테스터 역할도 겸합니다. 따라서 그들은 관련 사항에 대해 잘 알고 있으며 프로젝트에 관련된 결정에도 참여합니다.

일반적으로 테스터는 프로젝트의 최종 단계에 투입되므로, 게임의 주요 기획에 영향을 미치지 못합니다. 그러나 게임을 망칠 수는 있습니다. 군사적으로 보자면, 테스터는 병사입니다. 기획/개발팀은 장교입니다. 좀 과장되었지만, 그렇게도 볼 수 있습니다. 그러나 테스터를 하게 될 여러분이 게임 개발 현실에 적용하기에는 무리가 있군요.

전장에서 장군은 모든 병사를 바라보지 않습니다. 병사는 지시 받은 대로 행동해야 합니다. 모든 병사에게 전략을 설명할 시간이 없기 때문이죠. 가능한 저는 게임 제작 과정에서 테스터들과 함께 전략을 공유하려고 합니다. 그러나 모든 기획자나 개발자가 그렇게 하지는 않습니다. 자신의 아이디어를 게임에 반영할 수 없다는 사실을 납득하지 못하는 테스터도 있습니다. 유감스러운 일입니다.


테스트는 정말 중요합니다

기획자 겸 개발자로서, 자기가 만든 게임이 쉽고, 친숙하고, 재미 있다는 점은 중요한 일입니다. 그만큼 단점을 찾는 것도 어렵습니다. 저 또한 테스트 중에 많은 버그를 찾지만, 테스터들이 발견한 버그를 "그건 버그가 아닙니다" 또는 "원래 기획에 있던 것입니다"라고 거절하기도 합니다. 몇 번 거절 당한 테스터는 반감을 갖기도 합니다. 그러나 편을 가르면 안됩니다. QA팀과 저는 같은 목표를 공유하니까요. 즐거운 게임을 만드는 겁니다.

확실하게 재미있는 게임을 만드는 방법은 오로지 꼼꼼한 테스트 뿐입니다. 여러 사람의 눈으로 보고, 여러 사람의 손으로 해보세요. 저의 플레이 방식은 하나 뿐입니다. 하지만 다른 사람은 그 사람만의 방식이 있습니다. 어쩌면 제가 상상도 하지 못했던 방식일 수도 있습니다. 그런 식으로 게임이 출시되기 전에 모든 문제점을 찾아내야 합니다.


테스트는 쉽지 않습니다

어떤 사람은 "테스트"가 온종일 게임만 하는 일이라고 생각합니다. 재미있고 쉬워보이죠.
그렇지 않습니다. 오랫동안 재미 있을 수도 있습니다(재미 있는 일이 될 수도 있습니다). 하지만 업무라고 느끼면 절대 그렇지 않습니다.
게임을 하는 것은 즐겁습니다. 그러나 어렵죠. 게이머에게 물어보세요. 쉬운 게임은 재미가 없습니다.
게임이 재미없다면(균형 잡힌 게임이 아니라면), 계속 반복해서 하기란 정말 고역입니다. 당신의 업무가 테스트라면, 설령 재미없다 해도 계속 해야 합니다. 그래서 정말 어렵죠!

테스트를 반복하다 보면 똑같은 부분을 수십 번 해야 할 때도 있습니다. 게임의 재미는 점점 사라져갑니다.

테스터는 컴퓨터에 능숙해야 합니다. PC 게임을 테스트한다면, 각종 카드(역주: 그래픽/사운드 지원 카드)와 조이스틱, 드라이버를 설치해야 합니다. 설치/제거하는 것이 가능해야 하고, OS를 다시 설치할 수도 있어야 합니다. 플레이스테이션 2, 게임보이 어드밴스 게임이라고 해도, PC로 보고서를 써야 합니다.

테스터는 의사소통에 능통해야 합니다. 회사 내에서 놀라운 능력으로 버그를 찾아낸다 해도 팀원들에게 버그를 어떻게 찾았고, 버그가 무엇이고, 무엇이 발생했고 할 것인지, 코드에서 잘못 돌아가고 있는 것이 생각한 바를 표현할 수 없다면, 전혀 소용이 없습니다.

"녹색 검을 집고 파란 물약을 마시니까 게임이 깨짐" 훌륭한 테스터는 버그를 찾아 보고하는 것으로 끝내지 않습니다. 좋은 테스터는 깊게 파고 들어 갑니다. 게임이 어떻게 돌아가는지는 알고 있고, 이를 바탕으로 버그가 어떻게 발생했는지 고심해봅니다. 그리고 무엇이 정말 잘못되었는지 생각합니다. 다시 "녹색 검을 집고 파란 물약을 마신다"를 하면 버그가 안 나올 수도 있습니다. 다른 요인이 있을 수도 있습니다. 좋은 테스터는 불독과도 같습니다. 끈질기게 버그를 찾아 이빨을 쑤셔 넣으세요. 그 이유를 찾을 때까지 절대 놓치면 안됩니다.

테스트는 재미를 쫓아다니는 미숙련자가 할만한 일은 절대 아닙니다.


현장 학습
테스트 업무는 게임 산업을 배우는 좋은 방법입니다. 여러 가지를 접할 수 있습니다 (직접 그 일에 관여하지 않아도 상관없습니다). 여러 게임에서 테스트를 하면서, 산업 전반에 대해 많이 배울 수 있습니다.


개발 측면
(여기서 쓰는 '개발'은 프로젝트에서 '제작 전 단계'를 지칭합니다. 즉 기획을 언급합니다. '제작'은 프로그래밍, 미술, 음향 등을 만드는 것을 지칭합니다) 테스트를 하는 동안, "왜 이렇게 기획했지?"라는 의문이 떠오를지도 모릅니다. 세부 사항을 구현하는 방법은 여러 가지가 있으며 또한 테스터는 게임을 가장 빨리 접합니다. 테스터는 시시각각 변하는(또는 변하지 않는) 기획의 측면에 노출됩니다.


제작 측면
테스터는 버그를 찾아 보고합니다. 대부분은 수정하고 끝나는 간단한 문제입니다. 그러나 어떤 경우 QA와 제작팀 사이에 토론이 필요한 복잡한 문제일 수도 있습니다. 그 동안, 테스터는 제작팀이 무슨 일을 하는지 파악할 수 있습니다. 그러면서 전체적인 제작 과정에 대한 넓은 시야를 가질 수 있습니다.


마케팅 / 판매 측면
테스터에게 테스트가 전부는 아닙니다. 패키지와 매뉴얼 문구를 살피기 위해서도 불려집니다. 하드웨어 사양은 정확해야 하고, 요구 사항 또한 표기되어야 합니다(특히 게임의 특징이 묘사되어야 합니다). 이런 사항들을 파악하여 실제로 제품을 살 사람들이 어떻게 제품을 보게 될지 식견을 가질 수 있습니다.

선적 기일 같은 끔찍한 최종일자는 버그 수정을 불가능하게 합니다(버그의 우선순위가 낮을 수록). 몇 번의 게임 프로젝트를 거치는 동안, 테스터는 버그의 우선 순위를 정하는 것이 매우 중요함을 알게 됩니다. 회사는 테스터의 월급을 주기 위해서라도 게임을 출시해야 합니다. 언제까지 테스트만 할 수는 없겠죠. 제작 과정에 몇 차례 참여하면서, 이익을 내야 하는 현실을 깨닫습니다. 또한 버그의 우선 순위를 정하는 중요성에 대해서도요.


고객 지원 측면
게임을 면밀히 테스트하는 일은 당연합니다. 그러나 게임이 시장에 출시되었을 때부터 문제가 발생합니다. 고객은 잔인합니다! 게임에서 할 수 있는 방법을 모두 시도해보고 제작이나 QA에서 결코 생각하지 못한 것들도 있습니다. 고객 지원팀으로 전화가 옵니다. 보통 첫번째 고객 지원 전화는 QA쪽으로 연결됩니다. QA팀과 고객 지원팀 간의 관계는 그래서 중요합니다. 할 일을 다했다고 생각한 테스터에게 이제 "이 하드웨어 사양으로 게임을 해보세요. 그리고 무슨 일이 일어나는지 살펴보세요" 하고 서비스 업무 지원 지시가 내려집니다. "어떻게 이걸 놓칠 수가 있습니까?"라며 시비를 걸 수도 있겠죠. 이 방면으로 테스터의 실제 업무는 별로 없지만, 고객 지원 측면의 주요 이슈에 대해 배울 수 있습니다.


생산 측면
생산 또한 게임 제작에 참여함으로써 배울 수 있는 것 중의 하나입니다.

- 프로젝트를 끝마치기 전에 최종 확인을 위해 테스터에게 패키지와 매뉴얼을 줍니다. 명심하세요. CD를 꺼내 실행하는 것보다 박스와 매뉴얼을 찍어내는데 더 시간이 걸린다는 점을요.

- 게임기용 CD라면(PC 용보다 낫습니다), 테스터는 플랫폼을 확인해야 합니다. 그리고 패치가 불가능하다는 점도 잊어선 안되겠죠. 게임기용 CD는 첫 출시 때 잘 작동해야 합니다. 가끔 드물게 생산 과정에서 문제가 발생하기도 합니다. 그러면 테스트를 다시 하는 것은 당연하고 재출시까지 경험할 수 있습니다. 설령 이런 일이 없다 해도 매일매일 겪는 일상을 통해, 게임을 출시하기 위해 겪어야 하는 일들이 얼마나 고통스러운지 느낄 수 있을 겁니다(플레이가 지긋지긋하게 느껴지겠죠).

- 프레스 되는 CD와 골드 CD(CD-R로 만들어지는 CD)는 제작 방법이 다릅니다. 제가 만든 게임 중 하나는, "레드북 스탠다드(redbook standard)"에 따른 자체 음악 트랙이 있었습니다. 테스트할 때는 물론 잘 돌아갔습니다. 공장으로 게임을 보낼 때까지 몰랐지만, 그 CD 제작기는 음악 트랙 사이에 매우 짧은 공백을 넣는다는 것이었습니다. 이런 CD로 게임을 했다면, 아마 모든 음악이 하나의 트랙으로 플레이 되었을 겁니다. CD 헤드가 트랙을 인식하려 할 때마다, 시작 부분을 찾지 못하니까요(다른 곡 시작을 할 때 눈깜짝할 사이에 실패가 발생합니다). 결국 우리는 마스터 작업을 다시 했습니다. 각각의 트랙 사이에 공백을 넣어서 말이죠. 저는 여기서 뭔가 배울 수 있었습니다. 여러분 역시 그럴 거라고 생각합니다.


게임 산업을 배우는 방법에 대해 살펴보셨는지요? 그러나 여러분이 생각하는 테스터는 매일 게임만 하는 사람입니다.


테스트는 디딤돌입니다 ...더 큰일을 얻어내려는 사람들을 위한


좋습니다. 제목에 충분히 설명이 되었습니다. 그렇다고 테스터보다 더 중요한 일을 하기 위해 그만둘 필요는 없습니다. 열심히 일하고 성과가 좋고, 그리고 훌륭한 애사심을 보여주면, 의사를 효율적으로 잘 전달한다면 더 높은 위치로 발전할 수 있을 것입니다.

여러 프로젝트에서 훌륭한 테스트 성과를 올리면, 수석 테스터로서 올라갈 수 있습니다.

여러 프로젝트에서 수석 테스터로서 실적을 올리면, 테스터 팀장이 될 수 있습니다. 또는 개발 스튜디오의 일원으로 참여하길 요청 받을 수도 있습니다. 개발 진행 책임자나 부 프로듀서, 초보 기획자로 말이죠.

그냥 보여주세요. 승진 기준이 될 만큼만 일하지 마세요. 당신은 빛나야 합니다. 다른 사람보다 더욱 활활 불타야 합니다. 거둔 대로 뿌립니다(영원히 승진에서 누락되는 사람들에게 불평을 듣는다 해도).

어디서 들은 지 기억은 나지 않지만 적당한 문구가 있습니다.

"영리한 자는 능력을 발휘하는 방법을 배운다. 행복한 자는 결점을 이해하는 방법을 배운다"

당신에게 재능이 있다면, 게임 산업에서 중요한 역할을 하게 될 테스트 업무를 기꺼이 맡을 것입니다.


QA 용어 해설
'A' 버그 A 버그는 최악의 버그입니다. 이 종류의 버그는 "고치지 않고 출시하면 잊지 못할 끔찍한 화를 불러올 버그"로 설명됩니다. 예를 들어 :
  - 게임 파손
  - 바이러스 감염
  - 명백한 오자
  - 명백한 그래픽 / 오디오 문제
  - 기능(메뉴나 버튼를 사용하여 작동할 수 있는)이 작동하지 않음
  - 저작권 표시가 없을 경우
  - 게임이 재미없을 때
이런 결점을 안고 출시를 한다면, 형편없는 대중의 반응, 언론의 혹평을 얻거나, 심지어 회사가 당신을 고소할 수도 있습니다.


'B' 버그 B 버그는 A 버그보다는 낫습니다. 이러한 버그는 " 게임은 그럭저럭 괜찮지만, 출시하면 안 좋을 평판을 얻게 될" 버그로 요약될 수 있습니다. 재정난 등에 시달려서 게임을 출시해야만 할 때, 고객 지원팀, 판매팀, 마케팅팀, QA팀과 경영진이 모두 동의하면 테스트과 버그 수정을 중지한 채 게임은 작은 오류를 갖고 출시될 수 있습니다. 예를 들면:

  - 게임 플레이를 망치지않는 버그
  - 명백한 그래픽 / 오디오 문제(눈/귀에 띄일만큼)
  - 독창적인 기능 제거(그리고 그에 대해 게임 내에서 언급하지 않음)

B 버그는 잡지 기사에서 언급될 것입니다. 이것들을 고치는 것은 어려운 일입니다 (많은 대가를 치루게 합니다). 게임을 하는 사람들은 이런 문제가 달갑지 않을 테지만 전체적인 게임 진행이 이런 문제로 망쳐지지는 않을 것입니다.


'C' 버그 C버그는 "고치면 게임이 더 나아질" 버그로 요약됩니다. 테스터는 자신이 발견한 문제를 심각히 생각하는 경향이 있습니다. 그러나 회사가 출시의 필요성을 더 강하게 느끼고 저울질한다면, 그 버그는 의사 결정자에게는 중요하게 생각되지 않습니다. 출시하기 위해, C 버그는 포기될 수도 있습니다.(고치기 어려운 문제라면, 그렇게 되겠죠 -- 중요도가 낮은 C버그는 간단히 고쳐질 것 같지만 생각대로 진행되는 일은 없습니다)


'D' 버그 "이것까지 고치면 금상첨화입니다." 테스터 과정에서 늦게 발견되면, D 버그는 수정되지 않을 수도 있습니다.

"모든 버그를 고칠 것" 이상적으로는 옳은 이야기지만 어떤 게임은 너무 크고 복잡해서 수정하는 것이 결코 끝나지 않을 수도 있습니다. 가능한 회사에 있을 때 출시되기 전에 모든 사항을 체크하고 균형을 맞춰야 합니다.


"알파" "알파"와 "베타"라는 용어는 회사마다 달리 쓰입니다. 개발사에서 유통사까지 정의가 다릅니다. 어떤 개발자는 "게임을 할 수 있는 단계"를 알파라고 부릅니다. 그러나 대부분의 유통사(특히 유통사의 QA 부서에서)는 이렇게 정의합니다. "모든 기능이 구현되어 있지만 버그도 있고 균형도 잡아야 하는 상태"

"베타" 어떤 개발자는 베타를 이렇게 생각합니다. "기획한 모든 것이 구현되어있습니다. 그러나 버그가 있고 게임플레이는 주의할 필요가 있습니다" 하지만 대부분의 유통사(혹은 QA 부서)는 베타를 이렇게 언급합니다. "모든 것이 다 되고 개발사가 아는 것과는 달리 버그가 없고 게임 플레이도 완벽히 돌아간다."


"재현 불가" 테스터는 분명 발견했지만, 다시 보여줄 수 없는 버그가 발견될 때도 있습니다. 프로그래머가 디버거를 갖고 코드를 면밀하게 탐색해도 그 문제를 다시 밝혀낼 수 없다면, 수정하는 작업은 불가능할 것입니다. 재능 있는 테스터라면 더욱 끈질기게 노력해보고, 왜 발생했는지 추리해 내야겠죠.

"골드 마스터" CD 또는 DVD로 QA팀을 거쳐 생산되는 제품입니다. 이 디스크는 실행 확인 및 바이러스 검사를 해야 합니다. 더불어 출시하기 전에 상세한 검사 목록을 통과해야 합니다.

"어색함" 테스터에게 최대의 칭찬은 "버그 없음"과 "기획한대로 작업됨"입니다. 때때로 테스터는 게임에 자신이 원하는 바를 삽입하려고 보고서를 임의로 쓸 때도 있습니다. 보고서를 받아본 기획자는 이렇게 답하겠죠. "버그가 아닙니다. 기획한대로 작업된 겁니다. 이게 여기 있는 이유를 말씀 드려보자면..." 라고요. 만일 테스터가 발견한 것이 어색하다는 점을 확신 있게 설득한다면, 바꿔질 수도 있습니다.

"더 많은 정보 필요" 이 문구는 프로그래머에게 버그가 어떻게 반복되는지 충분한 정보를 제공하지 않을 경우 자주 보게 될 겁니다. 또는 테스터가 그걸 버그라고 느낀 이유를 밝히지 않을 때도 마찬가지입니다.

"버그 아님" "어색함" 부분을 보세요.

"비정상 플레이" 이 용어는 합당치 않은 사용자 입력을 이유로 발생되는 문제를 가리킵니다. 예를 들어 "F10, ESC를 한 줄에 30~40번씩 누르면 게임이 깨짐"같은 것입니다 이유 없이 사용자는 이렇게 할 수도 있습니다. 그리고 누구라도 할 수 있습니다. 그리하여 예기치 않은 게임 오류가 발생합니다. 그런 문제가 고치기 어렵고 프로젝트가 막바지에 다다르면, 간단히 논의에서 제외되기도 합니다.


"완성" QA팀은 게임에 사인하고 확인 도장을 찍은 후, 생산하기 위해 게임을 보냅니다.

"선적" 이 말은 테스트 과정의 끝 부분에서 듣습니다. 테스터 팀이 터널의 끝에서 불빛을 보게 될 때이기도 합니다.

  - 테스터: "버그를 찾았어요"
  - 수석 테스터: "어떤 버그인데?"
  - 테스터: "C버그예요. 대단치는 않아요. 비정상 플레이 때 나타나요"
  - 수석 테스터: "무시해!"

완료된 게임(테스트, 품질 확인)은 수송업체(가끔 중요하고 급해서, 직접 나를 수도 있습니다)에 의해 생산 설비로 수송됩니다. 대량으로 생산되어 매장 트럭에 실립니다. "수송"은 게임을 바깥 세상으로 보내고 테스트를 끝마치는 중요함을 보여주는 주문입니다.


"변경(Tweak)" 조정과 같은 뜻

"수정 중지" 시간이 촉박할 때, 작은 버그는 보고되어도, 프로그래머나 기획자, 개발자는 버그 보고서의 이런 모호한 글을 남겨 놓을지도 모릅니다. 하지만, 모든 버그는 게임이 출시 전에 "해결" 되어야 합니다.

"기획대로 작업됨" '어색함'을 보세요(위에 있습니다).


테스터로서 직업을 구하고 싶습니까? 여기 준비하는 방법이 있습니다.

저는 학사 학위를 갖고 테스터에 지원하기를 추천합니다. 그러나 그것 없이도 지원할 수 있죠. 그러나 생각해보세요 -- 당신의 최종 목표는 무엇입니까? 만일 기획자나 프로듀서 혹은 마케팅으로 이동하기를 원한다면, 대학 학위는 명백히 도움을 줍니다. 만일 그냥 테스터가 되고 싶다면(그 이상으로는 아무 목적도 없다면), 그대로 좋습니다. 고등학교 졸업으로 충분합니다. 그러나 테스터가 되기 위해 무엇보다도 먼저 필요한 기술이 무엇인지 추측해보세요.


o 의사소통 능력

* 쓰기. 버그 리포트를 써야 합니다. 그 내용이 분명하고 명료해야만 합니다. 테스터는 충분한 문장력을 갖고 있어야 합니다

* 의사소통 능력. 테스터는 말도 잘 해야 합니다. 그의 말을 다른 사람이 충분히 이해할 수 있어야 합니다. 아래의 두 가지 훈련을 해보면 테스터가 의사소통 능력을 기르는데 도움을 줄 것입니다. 훈련을 통해 어떻게 의사 소통 능력을 향상시킬 수 있을까요? 먼저 아래 연습은 작은 방에서 하는 것이 가장 좋습니다 -- 두 사람이 연습에서 대화하고 쉽게 담화할 수 있는 역할을 맡되 다른 사람이 무엇 하는지 볼 수 없게 해야 합니다.

- 페이퍼클립 훈련 이 훈련에서 테스터는 펜과 종이를 가진 상대에게 임의로 구부러진 페이퍼 클립에 대해 설명해야 합니다. 구부러진 모양대로 듣는 이가 그려내면 성공입니다. 단, 테스터는 "페이퍼클립"이라든가 이 물체가 뭘로 만들어졌고 원래 무슨 용도로 사용되는지 말하면 안됩니다. 다만 페이퍼클립의 지금 상태에 대해 설명하세요. 테스터는 듣는 이가 올바른 페이퍼 클립 모양을 그리도록 설명해야 합니다. 훈련이 끝나면 테스터는 자신의 설명에 대해 생각할 계기가 마련됩니다. 이 훈련은 파이프 청소 도구나 묶인 줄로 가능합니다. 클립은 2차원으로 구부리세요. 2차원인 종이에 그리기 때문에 3차원 모양은 좀 어렵습니다.

- 블록 쌓기 훈련 이 훈련은 닌텐도 아메리카의 직원들과 소속 고객 지원 팀원들을 훈련시키는데 이용했습니다. 제 생각에는 테스트에 필요한 의사 소통 기술을 잘 적용될 것 같습니다. 훈련하는 양 팀은 동일한 나무 빌딩 블록 상자를 가집니다(레고 같은 걸로 해도 됩니다). 테스터는 블록을 이용해 구조물을 쌓고 훈련하는 다른 참가자에게 구조물에 대해 설명합니다. 테스터가 잘 설명한다면, 두개의 구조물은 동일해질 것입니다. 두 개의 구조물이 다르다면, 무엇을 잘못했는지 배울 수 있습니다.


o 컴퓨터 상식. 테스터는 컴퓨터를 분리하고 그것들을 원래대로 하는 방법을 알고 있어야 합니다. 인터넷 탐색하는 법이나 이 메일, 인스턴트 메시징, 채팅룸 네티켓에 대해서도 물론입니다. 또한 인스톨 하다가 발생하는 문제도 해결할 수 있어야 합니다. 드라이버를 다운로드 하거나 바이러스 데이터파일을 갱신하거나 컴퓨터를 업그레이드 지식도 필요합니다. 또한 워드 프로세서나, 이미지 프로그램, 스캐너, 모뎀에 관련된 지식도 필요하죠.

o 게임 상식. 할 수 있는 한 많은 게임을 해보세요. 그리고 그것들의 장단점을 비교해보세요. 게임 잡지를 읽어보고, FRP와 RTS가 뭐가 다른지 알아두세요. 온라인게임, 콘솔 게임, 핸드헬드 게임, 보드 게임, CCG 등에 대해서도요.

이미 말했지만 반복하자면, 게임 산업에 종사하기 위한 최선의 방법 중의 하나는 테스터입니다. 다른 비관론자들이 테스트가 밑바닥 업무라고 해도 무시하세요. 대부분 테스트가 얼마나 중요한지 깨닫지 못합니다. 더불어 게임 제작과정에서도 테스트가 얼마나 중요한지를요.


[원문] http://www.sloperama.com/advice.html
저자 : Tom Sloper

번역 : 이웅주
----------------------------------------------------------------------------------------

아주 잘 정리된 글입니다. QA는 물론 PM이나 PD, 기획자도 한번씩 읽어보면 좋을 듯 싶네요.

나중에 시간이 되면 제 생각도 한번 정리해 볼께요.