들어가며
최근에 게임 디자인 관련 Game Maker's Toolkit 채널에서 '게임 디자이너가 부정적인 피드백을 경청해야 할까?'라는 영상을 봤다. 해당 영상의 영문 제목은 'Should Designers Listen to Negative Feedback?'이다.
Game Maker's Toolkit
Game Maker's Toolkit is a deep dive into game design, level design, and game production, hosted by Mark Brown. BEFORE YOU EMAIL: - I do not do sponsored videos, ad reads, or paid integrations on GMTK. - Do NOT email me about NFTs, blockchain, or Cryptocurr
www.youtube.com
최근 Bridge에 제안했던 <Lost In Hope> 프로젝트의 팀 결성이 완료되었다. 이번 프로젝트를 통해 내가 얻고자 하는 것은 '팀원의 의견을 수용할 수 있는 유연함'과 '방향성을 지키기 위한 확고함'인데, 정리하자면 게임이 유저에게 보여주고자 하는 방향성을 지키면서도 팀원의 의견을 적극 수용하여 함께 게임을 만들어가기를 바랐다.
팀 결성 이후, 첫 회의에 들어갔는데 [프로젝트/Lost In Hope] - 포스트 아포칼립스 배경, 덱 빌딩 마피아 게임 제안서 글에서 확인할 수 있는 밤 시스템의 규칙이 복잡하고, 플레이 타임이 너무 길어질 가능성이 있다는 이야기가 오가서 이를 어떻게 할지 논의했다.
당시 나왔던 의견에는 밤 시스템을 보완하기 보다는 새로운 디자인에 대한 의견이 많았는데, 이야기를 들으면서 '제안 발표 때 함께 게임을 만들어가자고 해놓고, 내가 생각했던 방향성과 다르다고 의견을 쳐내는 게 맞을까?'라는 생각이 들었다.
따라서 회의 이후, 방향성이란 무엇인지, 피드백에는 어떻게 대처하는 것이 현명한 지 찾아보던 중, 내가 자주 보는 GMTK 채널에서 '게임 디자이너가 부정적인 피드백을 경청해야 할까?'라는 영상을 보게 되었다.
결론부터 말하자면 내가 고민한 것에 대해 완벽한 답을 찾을 수는 없었다. 영상에서 다루는 내용은 개발사와 유저 간의 피드백이지, 개발자와 개발자 사이의 피드백이 아니었기에 내 상황에 완전히 적합한 영상이라고 볼 수는 없었다.
하지만 그럼에도 '피드백'에 대해 다루는 만큼 어느 정도 비슷한 부분이 있었고, 특히 최근 이슈가 된 우마무스메 마차 시위를 비롯하여 게임사와 유저 사이에 소통 문제를 어떻게 해결해야 하는지 그 핵심을 관통하는 영상이었기에 충분히 정리하고 고민해 볼 가치가 있다고 판단했다.
따라서 본 글에서는 아래와 같은 목차로 내용을 정리하고자 한다.
- 피드백이란?
- 규모에 따른 피드백의 성격
- 개발사가 플레이어 피드백을 살필 때 명심해야 하는 4가지
- 열성적인 소수의 의견에 현혹되지 말자
- 해결책이 아닌 문제를 식별하자
- 변화로 인해 게임이 지루해지지 않게 주의하자
- 개발자와 유저 사이의 소통을 이어가자
- 피드백 반영의 긍정적인 사례와 부정적인 사례
- 결론
자! 그럼 오랜만에 정리 드가자~
피드백(Feedback)이란?
게임 디자이너가 부정적인 피드백에 어떻게 대처해야 하는지 알아보기 전에, 피드백이란 무엇이고, 어떻게 동작하는지 알아보자.
네이버 영어 사전에 따르면 피드백(feedback)이란 소비자의 반응, 의견, 감상이며, 조사를 통해 얻은 결과나 평가 정보를 의미하기도 한다고 명시되어 있다. 풀어서 이야기하자면 어떠한 상품이나 서비스를 제공했을 때 이것이 어떤 반응을 자아냈는지, 그리고 내가 원하는 반응을 이끌어내기 위해 어떻게 하면 좋을지 소비자 층의 의견을 구하는 것을 말한다고 볼 수 있다.
여기서 제공하는 서비스를 게임이라고 했을 때 피드백의 중요도는 한 층 높아지는데, 게임의 주목적이 '유저에게 재미를 주는 것'이기 때문이다. 따라서 개발사 입장에서 자사의 게임을 플레이하는 유저의 의견, 즉 피드백은 매우 소중하고, 이를 잘 해석하고 다루기 위해 끊임없이 노력할 수밖에 없다.
유저와 개발사 사이에서 피드백이 이루어지는 과정은 아래와 같다.
- 유저가 제공된 게임을 플레이한다.
- 플레이를 하며 느낀 점과 불편 사항이 있고, 이것이 개인의 기호에서 기인한 문제가 아닌 다수가 느낄 수 있는 문제, 즉 정당한 의문이라고 판단되면 게임사에게 답변을 요구한다.
- 유저들의 의견을 인지한 개발사는 각자의 방식에 맞게 고객 대응에 나서며 문제 해결을 진행한다.
그런데 대부분의 유저는 패치가 이루어져도 피드백이 반영된다는 느낌을 받지 못한다. 그 이유가 뭘까?
피드백이 반영되지 않는 것 같은 이유
먼저 생각해 볼 수 있는 것은 피드백의 '규모'다. 앞서 피드백을 정의할 때 소비자 층의 의견을 구하는 것이라고 했는데, 이 의견은 많아지면 많아질수록 처리하는데 인력이 소모된다.
물론 작은 유저 풀을 보유한 게임사의 경우, 피드백의 수가 한정적이기 때문에 피드백을 게임에 적용하는 데 걸리는 시간이 짧아 피드백이 활발하게 이루어진다. 하지만 큰 유저 풀을 보유한 게임사의 경우, 당연하게도 모든 피드백을 하나씩 처리하기에는 한계가 있기 때문에 이를 수집하고 정리할 수 있는 시스템을 구축한다.
예를 들어, 커뮤니티 매니저(CM)나 게임 매니저(GM)를 고용하여 게임사와 유저 사이의 원만한 소통을 이어가거나, 고객 대응(CS) 팀을 만들어 난잡한 피드백을 정리한 뒤 보고 받는 방식으로 수많은 피드백에 대응해볼 수 있다.
하지만 이런 경우 중간에 최소 한 가지 단계가 추가됨에 따라 피드백을 주고 받는데 걸리는 시간이 늘어나고, 우선적으로 처리해야 될 피드백도 많기 때문에 즉각적인 대응이 어려울 수밖에 없다. 따라서 더 많은 시간과 자원을 할당하지 않는 이상 피드백에 대한 답변은 차일피일 미루어질 수 밖에 없고, 이에 따라 유저는 피드백의 경과를 알 수 없기에 답답함을 느끼고 '게임사가 답변을 회피한다.'라고 생각하게 된다.
이에 따라 유저들은 자연스럽게 고객 센터의 매크로 답변이 아닌 게임을 운영하는 사람들에게 직접적인 소통을 요구하기 시작한 것이고, 이것이 쌓이고 쌓여 2021년 <Fate/Grand Order> 트럭 시위 사건을 시작으로 지금까지 마차 시위를 비롯한 소통을 요구하게 된 계기라는 생각이 든다.
이런 관점에서 스마일게이트 사의 게임 <LostArk>의 대외적인 이미지가 좋아지고 많은 유저의 유입이 있었던 이유를 생각해보면 쉽게 답이 나온다. 당시 대부분의 게임사들이 공지하는 방식은 상호 소통보다는 일방적인 통보에 가까웠는데, 이런 점에 불만을 가지고 있던 유저들에게 디렉터가 주도적으로 소통을 이끄는 <LostArk>는 말 그대로 이단아이자, 한 줄기 빛이었을 것이다.
<LostArk>는 단순히 소통만 잘해서 이미지가 좋은 게 아니다. 피드백이라는 건 유저의 의견이기 때문에 단순히 게임 내적인 부분을 떠나 유저가 활동하는 다양한 곳에서 이루어질 수 있는데, 게임사에서 이를 잘 이용하면 유저들이 직접 요구하지 않아도 게임사가 참고하기 좋은 자료들을 얻을 수 있다.
예를 들어 어떤 패치가 있었을 경우, 커뮤니티 인기글이나 인터넷 방송 등 다양한 곳에서 이번 패치에 대한 의견을 얻을 수 있는데, 이를 잘 참고하여 소통하는 모습을 보이면 유저 입장에서 '게임사가 유저에게 관심을 가지고 있다'는 인상을 받게 된다. 이로 인해 게임의 팬덤이 견고해지고, 유저 이탈을 줄일 수 있으며, 게임사는 이를 바탕으로 성과를 올리고 게임을 발전시킬 원동력을 얻을 수 있다.
<LostArk>는 이런 점을 정말 잘 이용했다. 루테란 신년 감사제, 로아온, 로아온 미니, 로아온 윈터, 디렉터의 개인 방송 등 다양한 이벤트를 통해 디렉터가 직접 '유저의 의견을 잘 듣고 있다.'는 인상을 심어주었고 이로 인해 유저는 디렉터를 믿고 게임을 즐길 수 있었다.
이때 나도 로스트아크를 한창 플레이했었는데, 로아온 윈터 때 금강선 디렉터님의 소통에 감탄하여 그 소통하고 전달하는 방법을 배우고자 발표의 구성과 내용을 일일이 정리했던 경험이 있다. 블로그에 정리하려고 했었는데 결국 word 정리로 끝났지만 아까워서 이렇게 했다는 것만 올려본다.
피드백이란 말 그대로 서비스를 개선하기 위한 의견에 불과하지만 이를 잘 다룰 경우, 유저와 게임사 간의 신뢰 관계를 형성할 수 있다는 배움을 얻었다.
그런데 이런 좋은 점에도 불구하고 많은 게임들에서 피드백이 반영된다는 느낌을 받지 못하는 이유는 무엇일까?
바로 게임 시장의 경쟁이 과열됐기 때문이다. 국내 게임 시장은 1990년대 즈음, PC방이 생겨나면서 본격적으로 활성화되기 시작했는데, 이때는 유저 풀도 점점 커지던 시기였기에 경쟁이 과하지 않았다. 하지만 최근의 게임 시장은 한정된 유저들을 유입시키기 위해 경쟁이 과하게 이루어지고 있는데 각 게임사들은 더 많은 콘텐츠를 더 빨리 만들어내기 위해 개발진을 독촉하고 있다고 한다.
이것 자체만으로는 '회사 입장에서 당연한 거 아닌가?'라는 생각을 할 수 있지만, 주어진 자원과 시간이 게임사가 원하는 결과물에 비해 턱 없이 모자라다는 게 문제이다. 따라서 당연하게도 개발자는 게임이 기획 의도대로 만들어지고 있는지, 버그나 오류는 없는지 신경 쓰지 못해 놓치는 것들이 많아지고, 유저와의 소통 또한 자연스레 후순위로 밀렸다고 생각한다.
그래도 이를 그대로 두지는 않았는데, 알파 테스트 단계에서 전문가들의 피드백을 받거나, 베타 테스트를 다회 진행, 얼리 액세스를 통해 선 출시, 후 보수 형태로 작업을 진행하는 등 더 좋은 게임을 만들기 위해 노력을 하는 경우를 많이 볼 수 있다.
물론 이런 방식을 통해 개발 시간을 줄이고, 빠른 업데이트를 이끌어내며, 유저에게 만족감을 주겠다는 의도는 좋다. 하지만 앞서 말했듯이 게임의 주목적은 '유저에게 재미를 주는 것'이기 때문에 효율만 생각하여 유저의 의견을 경청하고자 하는 노력을 너무 소홀히 하지는 않았으면 하는 마음이다.
이제 게임 업계로 가고자 준비하는 입장에서 게임 시장이 어쩌니, 유저는 어쩌니 하는 것도 웃기지만 효율과 성공 사례만 생각하며 도전을 하지 않는다면 고이고, 고이다 못해 게임이라고 부를 수 없는 것들만 남지는 않을까 염려될 뿐이다. 우리나라의 게임 문화가 성장하며 필연적으로 겪을 수밖에 없는 성장통이라고 생각하기는 하지만 주의해서 나쁠 건 없지 않나.
게임이 종합 예술이라고 불리는 만큼, 많은 것을 배울 수 있고, 울림을 전할 수 있으며, 늘 새롭다는 것이 좋아서 힘들어도 게임 업계를 희망하는 건데, 막상 갔더니 항상 똑같은 디자인에 똑같은 BM, 똑같은 결과물만 보게 되면 게임에 대한 열정을 유지하기 힘들 것 같다.
아무튼 정리하자면 게임사 입장에서 수많은 피드백에 대응을 해야 하고, 이번 대응이 어떤 영향을 미칠지, 최선의 판단이 맞을지 고민해야 하기에 오래 걸리고 힘들다는 건 알지만 이 과정을 유저와 '공유'하지 않는다면 유저는 게임사가 피드백을 확인한 게 맞는지 알 길이 없다.
따라서 피드백을 확인했다면 유저의 피드백을 확인했다는 표현을 할 필요가 있으며, 가능하다면 그 과정을 공유하는 것이 필요하다. 피드백은 단순히 의견으로써의 피드백으로 있을 때보다 게임사와 유저가 서로 주고받으며 신뢰의 표현으로 존재할 때 가치를 갖는다고 생각한다.
개발사가 플레이어 피드백을 살필 때 명심해야 되는 4가지
게임을 개발하고 운영하다 보면 버그나 기술적 결함을 고치라는 피드백이 아닌, 유저들의 주관적인 기호에 따라 디자인을 바꾸라는 피드백을 받기도 한다. 그렇다면 개발자들은 이런 게임의 메커닉을 바꾸라는 부정적인 피드백에 대해 어떻게 반응해야 할까?
영상에서는 이 질문에 대한 답을 내리기 위해 몇 주간 개발자들과 인터뷰를 했다고 하는데, 그 내용을 부정적인 피드백을 포함하여 유저들의 피드백을 살필 때 명심해야 할 점 4가지로 정리했다. 이 4가지 항목은 앞서 언급했던 내용들과 달리 유저를 위한 피드백 대응 방법보다는 게임사 혹은 게임 팀을 위한 피드백 대응 방법에 가까워 게임을 개발하는 입장에서 꼭 살펴볼 필요가 있다고 생각했다.
그럼 한 번 같이 확인해보도록 하자.
열성적인 소수의 의견에 현혹되지 말자
<Marvel's Spider-Man>의 개발사 Insomniac Games의 브랜드 책임자, 라이언 슈나이더는 아래와 같이 말했다.
Just because you see it online and you see it in the forums, that doesn't necessarily represent the majority viewpoint.
- Ryan Schneider -
이는 '온라인과 포럼에서 본 의견들이 반드시 다수의 관점을 대변하는 것은 아니다.'라는 내용인데 대다수의 비판이라고 생각했던 내용이 사실은 아주 작은 하위 집단에서 나온 것일 수 있다는 것을 의미한다.
따라서 우리는 피드백을 수용하기에 앞서 다음 2가지 점을 확인해야 한다.
- 얼마나 많은 이들이 말하고 있는가?
- 그들은 어떤 종류의 사람인가?
이점들을 잘 확인하지 않아 소수의 의견에 휘둘리게 될 경우, 포럼이나 여타 피드백 소스에서 활동하지 않는 캐주얼한 유저들을 소외시킬 수도 있다. 특히 개발자들이 유저들로부터 피드백이 나오는 경우에 대해 분석을 한 결과, 의견을 많이 내는 사람들이 일반적으로 더 어렵고 복잡한 게임을 원한다는 사실을 발견했는데, 이러한 점이 별 다른 의견을 내지 않는 캐주얼한 유저와 대비되어 착각을 일으키기 쉽다고 말한다.
그럼 어떻게 해야 소수의 의견에 현혹되지 않을 수 있을까? 그 답은 데이터를 수집하고 활용하는 것이다. 대부분의 라이브 게임들은 엄청난 양의 플레이 정보를 추적하고 있는데, 이 데이터를 통해 유저가 직접적으로 피드백을 제공하지 않아도 게임을 하는 유저가 어떤 선택을 하는지, 그리고 어떤 결과를 낳는지 파악함으로써 게임을 개선하는데 필요한 정확하고 객관적인 데이터를 얻을 수 있다.
하지만 이러한 데이터는 조심히 사용해야 한다. 영상에서는 이에 대한 예시로 <Slay the Spire>를 소개했는데 개발사인 메가 크릿에서는 절대 다수의 승리 덱에 '광기'라는 카드가 있다는 사실을 발견했다. 그럼 광기 카드가 사기적인 성능이어서 절대 다수의 승리 덱에 포함이 된 것이냐고 묻는다면 그건 아니라고 할 수 있다. 광기 카드는 게임 후반에 너무 자주 주어지기 때문에 이 카드를 사용하는지 여부에 관계없이 게임 후반부의 덱에는 이 카드가 포함될 가능성이 높을 뿐이다.
이처럼 데이터만으로 무언가를 섣부르게 판단해서는 안 된다. 데이터는 단지 정보의 한 원천으로 개발사가 어떠한 통찰을 얻기 위해 활용해야 하는 것이지 그 자체로 근거가 돼서는 안 된다. 이에 대해 유비 소프트의 <레인보우 식스 시즈> 팀에서는 '데이터에 좌우되지 말고, 데이터를 이해해야 한다.'라고 말했다고 하는데, 말 그대로 데이터 자체에 게임이 휘둘리지 않도록 주의할 필요가 있어 보인다.
해결책이 아닌 문제를 식별하자.
대다수의 유저 피드백은 문제점을 제기하기보다는 변경 사항을 제안하는 형식이라고 한다. 이런 피드백에 대한 예시로는 이거는 하향해야 하고 저거는 상향해야 한다, 이건 삭제해야 한다 등의 말들이 있는데 라이엇 게임즈의 <League of Legends>를 비롯하여 다양한 게임을 플레이하면서 늘 하게 되는 말이다.
영상에서는 유저의 입장에서 이런 제안들을 실제로 이행했을 때, 어떤 연쇄 반응을 일으킬지 알기 힘들기 때문에 이런 피드백이 정답이 되는 경우는 극히 드물다고 말을 한다. 따라서 게임 디자이너라면 유저의 입장에서 판단을 하는 것도 좋지만, 원인이 되는 문제가 무엇인지 깊게 고민하여 실제로 작동하는 잠재적인 해결책을 찾을 수 있어야 된다고 한다.
이에 대해 <슈퍼 미트 보이>의 개발자 에드먼드 맥밀란은 아래와 같은 말을 했다.
If people don't like how your game controls, this could mean one of hundreds of things, from how things move in the game to what buttons it uses. When responding to feedback, ask specific questions and try to find the root of the problem.
- Edmund Macmillen -
이는 직역하자면 '유저가 게임의 컨트롤이 마음에 들지 않는다고 하는 말에는 물체가 움직이는 방식부터 사용하는 버튼에 이르기까지 수 백 개의 의미가 있을 수 있으니 피드백에 응답할 때는 구체적인 질문을 던지고 문제의 근본 원인을 찾아야 한다.'는 내용이다.
단순히 피드백을 요구하기보다는 구체적인 질문을 준비하고, 그 문제가 발생하게 된 원인을 찾는 것. 이것이 피드백에 대응할 때 필수적으로 취해야 되는 태도 중 하나라는 생각이 들었다.
그리고 <인왕>의 디렉터 야스다 후미히코도 피드백 대응에 대해 아래와 같은 말을 했다.
플레이어 의견이 해결책을 찾는데 쓰여서는 안 되고, 개발자들 스스로에게 물어볼 수 있는 질문을 만드는 데 쓰여야 한다.
- 야스다 후미히코 -
이 부분은 일본어 표기를 그대로 적기 힘들어서 그냥 번역한 내용을 적었다. 영상에서는 이런 질문을 만들기 위해서는 게임의 메커닉 자체보다, 그 메커닉이 불러일으킬 감정을 고려하는 게 더 중요하다는 말을 했는데, 그 예시로 <둠 이터널>의 머라우더를 소개했다.
<둠 이터널>의 머라우더는 기존의 적과는 다른, 유저의 입장에서 이질적이라고 느낄 수 있는 적인데 이 때문에 유저들로부터 둠의 디자인 목표와 상반된다고 평가받았다. 하지만 여기서 유저가 머라우더를 처음 조우할 때 느낄 이질감을 고려했다면 사전에 머라우더를 상대하기 위한 방법을 튜토리얼이나 다른 전투를 통해 넌지시 안내할 수 있었을 것이고, 그렇다면 그 이질감을 조금이나마 완화하고 유저는 당혹감을 줄일 수도 있었을 거라고 말한다.
따라서 피드백의 내용, 그 자체를 해결책으로 삼는 것은 근시안적인 문제 해결에 불과하기에 오랫동안 질 좋은 서비스를 제공하기 위해서는 피드백에서 근본적인 문제를 식별하고 해당 문제를 해결하기 위한 방법을 고민해 적용해야 한다.
변화로 인해 게임이 지루해지지 않게 주의하자
피드백을 수용하여 게임에 변화를 이끌어 낼 때, 그 결과는 긍정적인 방향으로 나아가야 한다. 하지만 때때로 피드백을 수용했음에도 게임성이 오히려 떨어지는 결과가 발생하기도 하는데, 이는 피드백에 신경을 쓰느라 게임의 핵심 방향성을 지키지 못했기 때문이다.
이에 대해 Xbox의 산하 개발사, 레어의 테크니컬 디렉터인 숀 데이비스는 아래와 같이 말했다.
If all you do is respond to feedback, then you end up converging on a fairly middle of the road [game] and you don't surprise people
- Sean Davies -
직역하면 '그저 피드백에 대응할 뿐이라면, 결국 어중간한 게임을 만드는 데에 그치고 사람들을 감탄하게 할 수 없다.'는 내용인데 유저를 재밌게 해야 할 게임사 입장에서 어떤 충격이나 울림을 전하지 못한다는 것은 사실상 사형 선고나 다름이 없다.
영상에서는 피드백은 그저 게임의 가장 거친 면을 다듬는 것이지, 게임을 흥미롭게 만드는 모든 것을 제거하는 계기가 되면 안 된다고 말한다. 이에 추가로 <더스크>의 프로그래머, 딜런 모리스는 아래와 같은 말을 했다.
The point of all of this is that devs need to be careful not to let their own fans ruin their games.
- Dylan Morris -
이는 '개발자들은 팬들이 게임을 망치지 않게 주의할 필요가 있다.'는 내용으로 팬들의 피드백을 신경 써서 그들의 의견을 무조건적으로 반영하기보다는 이 피드백을 수용함으로써 게임이 어떻게 달라질지 고려하며 게임의 전체적인 방향성을 잃지 말라는 것으로 해석할 수 있다.
영상에서는 추가로 <리스폰>의 게임 디자이너 데이비드 보섹의 말을 인용했는데 이는 아래와 같다.
As a designer at some point you just have to be brave. You can't shy away from making any major changes just because a subset of players may dislike it, or you will never ship anything interesting and your game will become stale
- David Bocek -
'디자이너로서 어느 순간에는 용감할 필요가 있다. 일부 유저들이 싫어한다고 해서 중대한 변화를 회피한다면, 그 어떤 흥미로운 것도 남지 않을 것이고 게임은 도태될 것이다.'라는 내용이다. 즉, 내가 필요하다고 느끼고 있고, 이것이 기존의 방향성과 상충하지 않는다면 마땅히 행할 필요가 있다는 말이다. 쏟아지는 피드백과 평가에 의해 게임의 컨셉과 의도가 변질되는 것을 방지하기 위해 게임을 디자인하기에 앞서 방향성에 대해 깊은 고민을 아끼지 말아야겠다는 생각이 들었다.
개발사와 유저 사이의 소통을 이어가자
이 부분은 앞서 유저를 위한 피드백 대응 방법과 같다. 개발사와 유저가 소통을 이어가는 것은 유저뿐만 아니라 개발사에게도 큰 이득이 되는데 단순히 유저의 피드백을 받아 무슨 의도인지 고민하기보다는 직접 소통함으로써 유저의 생각과 의도를 더 잘 파악할 수 있고, 유저들의 요구를 잘 충족하여 게임의 성과를 높일 수 있기 때문이다. 심지어 문제가 생겼을 때도 내부적으로 처리하기 위해 침묵하기보다는 유저에게 상황을 잘 설명하고 전달하는 것이 더 효과적일 수도 있다.
<필라스 오브 이터니티>의 내러티브 디자이너 크리스 아발론은 아래와 같이 언급했다.
Once you explain why a certain feature is a certain way and make a very structured argument for it, we find that generally that level of frankness causes a lot of buy-in.
- Chris Avellone -
직역하면 '일단 어떤 기능이 왜 그렇게 작동하는지 설명하고, 그 논거를 탄탄히 제시한다면, 그 솔직함은 많은 구매로 이어진다는 것을 알게 되었다'라는 내용이다. <필라스 오브 이터니티>는 킥스타터 기간에 유저들이 개발을 이끌 수 있게 끔 했는데 어떤 시스템이나 상황에 대해 논쟁할 여지가 생겼을 때 개발사가 직접 나서 게임의 메커니즘이 포함된 이유와 동기를 설명하면 이를 더 쉽게 납득했다고 한다.
이로 말미암아 생각해봤을 때 유저에 대한 투명하고 솔직한 설명은 실수라 할 지라도 인과 관계의 설명과 앞으로의 개선 계획을 전달함으로써 오히려 좋게 해석되고 신뢰받는 경향이 있다고 이해할 수 있었다. 물론 말로만 개선을 약속하고, 실수가 반복되면 약속에 대한 책임을 지지 않는 것이니 지탄받아야 마땅하지만, 충분히 납득할만한 실수이고 이전까지의 약속을 잘 이행했다면, 실수를 바로 잡고 개선하겠다는 약속이 유저에게 신뢰와 호감으로 다가올 수 있겠다는 생각을 했다.
최근에는 주간 트위치 스트림이나 커뮤니티를 통해 디자이너들이 직접 나서 소통을 하는 것을 심심치 않게 확인할 수 있는데 이로 인해 유저와 개발자가 비전을 공유할 수 있고, 이를 통해 게임에 애정을 가지고 개발진에 대한 신뢰감을 형성할 수 있어 보였다.
피드백 반영의 긍정적인 사례와 부정적인 사례
영상에서는 피드백을 수용한 여러 사례를 소개했는데 위에서 언급하지 못한 사례들과 다른 영상에서 참고한 사례들을 합친 뒤 소개할 만한 것들을 골라 긍정적인 사례와 부정적인 사례로 나눠 정리해봤다. 그 내용은 아래와 같다.
긍정적인 사례
사우스포게임즈, <Skul : The Hero Slayer>의 운이 행사하는 과도한 영향력
<Skul : The Hero Slayer>는 2020년 2월, 얼리 액세스 당시 운의 영향이 너무 강하다는 피드백을 받았다. 피드백을 받고 검토한 개발진은 이듬해 1월, 게임을 정식으로 출시하면서 운 적인 요소를 줄이는 시스템을 추가하는 등 노력을 기울이는 모습을 보여 좋은 평가를 받았다.
클레이 엔터테인먼트, <Don't Starve Together>의 유저의 의견에 따라 추가한 멀티 플레이 기능
<Don't Starve>는 2013년 출시한 싱글 플레이 생존 게임이다. 개발자는 개발 당시 멀티 플레이를 구현할 자신이 없다며 <Don't Starve>에 멀티 플레이를 지원하지 않겠다고 밝혔는데, 생존 게임에서 함께 플레이하는 동료의 존재는 매력적이었고, 유저들의 성원에 마음을 바꾼 개발자는 익스펜션 개념의 <Don't Starve Together>에 멀티 플레이 기능을 지원하기로 결정했다. 그 결과 <Don't Starve Together>는 2018년, 2019년 스팀 최고 판매작 목록에 오르는 등 큰 성공을 거두고 현재까지 많은 유저들에게 좋은 평가를 받고 있다.
부정적인 사례
레드 훅 스튜디오, <Darkest Dungeon>의 시체 시스템
레드 훅 스튜디오의 <Darkest Dungeon>은 크툴루 신화를 배경으로 한 로그라이트 롤플레잉 게임이다. 레드 훅 스튜디오는 <Darkest Dungeon>의 얼리 액세스 중에 적을 죽이면 그 시체가 남는 메커니즘을 도입했는데, 이를 통해 전투의 깊이를 더하면서 고정된 전략을 없애고 다양한 파티 구성을 하도록 유도할 수 있으리라 생각했다.
<Darkest Dungeon>의 디자이너는 시체 시스템이 훌륭한 시스템이라 생각했지만, 일부 유저들이 이를 극도로 혐오스러워했고, 이로 인해 게임에 대한 잘못된 이야기가 퍼져 문제가 되었다. 이 과정에서 욕설과 협박, 평가 테러가 포함된 공격적인 피드백이 계속 생겨났다.
결국 <Darkest Dungeon> 디렉터인 타일러 시그먼은 스튜디오가 게임의 변화를 더 잘 전달할 수 있었다는 걸 인정하고, 사람들의 요구에 따라야만 게임에 돈을 지불할 것이라는 우려에 공감했다. 그러나 타일러는 어느 순간 자신이 유저들의 피드백에 사로잡혀 있다는 느낌을 받았고 아래와 같이 언급했다고 한다.
We decided [the corpse mechanic was] right for the game. So we were in this weird dilemma of do we remove this and make what we consider a 'worse game' to make people happy?
- Tyler Sigman -
'시체 시스템이 게임에 적합하다고 결론을 내렸지만, 유저의 피드백으로 인해 딜레마에 빠져버렸다. 과연 우리는 우리가 더 나쁘다고 생각하는 게임을 만들어서 유저들을 즐겁게 해줘야 하는걸까?'. 레드 훅 스튜디오의 이러한 의문에 고민했고 결국 아래와 같은 해결책을 내놓는다.
- 시체 시스템을 선택할 수 있게 만든다.
- 커뮤니티 매니저, 존 린드베이를 고용한다.
레드 훅 스튜디오는 유저가 직접 시체 시스템을 선택할 수 있게 함으로써 불만을 잠재웠고, 커뮤니티 매니저를 통해 게임을 만드는 사람과 게임을 플레이하는 사람의 관계를 재정의했다.
기존의 레드 훅 스튜디오가 'help us make the best version of the game.', 즉 최고의 게임을 만들도록 도와달라고 했다면, 관계를 재정의한 이후에는 'help us make the game we're aiming for.', 즉 우리가 목표한 게임, 우리의 방향성에 맞는 게임을 만들도록 도와달라는 방식으로 바뀌었다.
미묘한 차이이지만 각자가 생각하는 '최고'는 다르기에 개발사가 창의적인 비전을 가지고 방향성을 제시하면, 유저들이 이를 돕는 방식으로 그 관계를 재정의 하였다.
인디 게임사 Sloth, <Zero Day>의 자동 사냥 시스템
2017년 3월 출시한 <Zero Day>는 TCG와 RPG가 합쳐진 게임으로 자동 사냥이 없다는 특징으로 인해 신선하다는 평가를 받았다. 하지만 RPG의 특성상 반복되는 전투에 지친 일부 유저들이 자동 사냥 기능을 요구하는 일이 생겼다. <제로 데이>의 개발진은 자동 사냥 기능을 추가하지 않고 기존 방향성을 유지하고 싶어 했지만, 유저들의 요구에 결국 자동 사냥 기능을 추가했다.
하지만 이로 인해 자동 사냥 기능이 없어 차별점이 되었던 컨셉이 무너졌다는 질타를 받게 되었다. 유저 편의를 위해 본래의 방향성에 어긋하는 선택까지 했는데 개발사와 유저 모두 만족하지 못했던 좋지 않은 사례였다.
결론
이번 영상을 보고 다른 영상들이나 자료를 찾아보며 기존의 내 생각을 정리해봤는데 결국 나온 결론은 '핵심이 되는 방향성에 대해서는 프로젝트가 엎어지는 일이 있더라도 타협하지 말자.'이다. 핵심 방향성이 어긋날 바에는 차라리 프로젝트가 취소되는 것이 낫다는 생각을 했다. 괜히 이도 저도 아닌 결과물에 공수를 낭비하면 결국 모두가 힘들어질 뿐이다.
또한 피드백을 수용함에 있어 유저들에게 피드백을 받았고, 처리하고 있다는 걸 어떤 방향으로든 표현해야 할 필요성을 느꼈으며, 피드백을 받았다고 무조건 그대로 따르기보다는 피드백을 문제 식별을 위한 도구로써 활용하여 근본적인 문제 해결을 할 수 있게 생각을 넓히자고 다짐했다. 겸사겸사 이 과정에서 데이터를 활용할 때 데이터가 갖는 의미를 생각해야지 그 자체에 휘둘리지 말아야겠다는 생각을 했다.
그리고 피드백은 그 특성상 유저 개인이나 소수 집단에 의해 만들어지는 경우가 잦기에 한 집단에 편향되어 서술하는 일이 생기거나, 서로 다른 피드백끼리 충돌하는 일이 생기지 않게 주의할 필요성을 느꼈고, 결국 게임 디자이너의 역할이란 문제에 대해 깊게 고민하고 파고들어 마침내 게임 방향성에 맞는 해결책을 찾아내는 것이기에 고민하는 것에 시간을 아끼지 말아야겠다고 생각했다.
마지막으로 피드백이 없는 게임이란 죽어있는, 발전 가능성이 없는 게임이라는 이야기를 듣고 격하게 공감했다. 피드백이 없다면 다양한 방법으로 유저의 관심을 끌어 피드백을 이끌어내야 하며, 이 피드백을 잘 해석하고 다루어 유저와의 신뢰 관계를 구축할 수 있는 운영해보고 싶다는 작은 바람을 가지게 되었다.
마치며
이번에 과거 작성했던 글들을 한 번 다시 살펴보는 시간을 가졌다. 이 과정에서 6시간에 걸쳐 작성하였기에 길다고 생각했던 글이 생각보다 짧다는 것과 이후 작성하는데 들인 시간은 점점 짧아졌음에도 내용이 풍성해지고 퀄리티가 좋아진 것을 봤을 때 체감되는 것과 달리 글을 작성하는 기술이 성장하고 있다는 게 느껴졌다. 하지만 여전히 부족함이 느껴졌기에 이번 정리 글은 이전보다는 조금 더 체계적으로 작성해보고자 노력했다.
우선 기존에는 영상의 내용을 정리하고 바로 글을 쓰며 그 과정에서 추가와 편집, 삭제가 이루어졌는데 시간도 오래 걸리고, 내용이 어지러워 '과연 사람들이 이 글을 편하게 읽을 수 있을까?'라는 의문이 들었다. 표현이 꼬이고, 어휘도 일반적인 대화에 사용하지 않는 어휘를 사용하다 보니 더더욱 읽기 어려워 보였다.
따라서 이번에는 기존 방식대로 영상의 내용을 먼저 정리하되, 다른 영상을 참고하며 나의 생각을 함께 정리하였고, 그 뒤 글의 핵심적인 부분과 근거를 나누어 꼭 넣고 싶은 내용들을 선별했다. 마지막으로 이 내용들을 읽기 편하게 순서를 정해 목차를 구성했고 이렇게 글을 작성했다.
하지만 생각처럼 잘 되지는 않았던 것 같다. 핵심 내용과 근거는 확실하게 나누지 못해 잘 구분이 되지 않았고, 계획과는 다르게 작성하면서 추가, 편집, 삭제가 이루어진 부분도 있다. 추가로 다른 영상들도 참고하며, 내 생각을 넣으려고 했던 것이 기존의 영상과 잘 연결되지 않아 이럴 거면 차라리 다른 글로 정리하는 게 맞지 않을까라는 생각도 계속 들었다.
그리고 무엇보다 너무 힘들다. 확실히 체계적인 것도 아니고, 기존의 방식도 아니다 보니 다뤄야 하는 양은 많아지고, 그 방식은 꼬여 이번 글을 보고, 정리하며, 작성하는 시간을 다 합치면 한나절은 족히 걸린 것 같다. 심지어 기존에 비해 다루는 내용이 방대하여 작성하는데 엄두가 안 나서 의욕도 잘 안 생기고 띄엄띄엄 작성하기까지 했다.
이렇게 조금씩 미루다가 이러면 결국 블로그 포스팅에 흥미를 잃을 것 같아 어떻게든 작성을 해봤는데 중간부터는 정신이 나가서 제대로 작성했는지 모르겠다. 나중에 한 번 퇴고해봐야겠다.
그래도 어떻게든 글을 잘 작성했고, 올렸으니 이 또한 경험이 되어 다음 글을 작성할 때는 보다 쉽게, 좋은 퀄리티의 글을 가져올 수 있을 것 같다. 긴 글 읽어줘서 고맙고, 이 글이 여러분의 미래에 도움이 되기를 바란다!
피드백과 좋아요, 댓글은 언제나 환영! 최근에 방문자 수 전체 1200을 찍었는데 다음 검색으로만 접근이 가능하고, 지인 위주로 보다 보니 조회 수가 저조하다 ㅠㅠ 구글에 검색 가능하도록 작업해봐야겠다.
그럼 끝~!
추가로, 이 글을 작성할 때 유튜브 영래기 채널의 '게임사는 유저들과 소통을 해야할까?' 영상을 참조했다. 가볍게 보기 좋은 영상이니 식사할 때나 심심할 때 보면 좋을 것 같다! 그럼 진짜 안뇽~~
'게임 디자인 > 게임 디자인 이론' 카테고리의 다른 글
| [GMTK] '피드백 루프는 어떻게 쓰이는가' 정리 (0) | 2023.05.23 |
|---|---|
| [GMTK] 'How To Steal Like a Game Designer' 정리 (0) | 2023.02.20 |
| [Riot Games] 'So You Wanna Make Games?? | Episode 10: Game Design' 정리 (2) | 2022.09.18 |
| [GMTK] 'How To Combine Video Game Genres' 정리 (2) | 2022.09.12 |
| [GMTK] '무엇이 좋은 추리 게임을 만드는가?' 정리 (2) | 2022.09.10 |
