Dec 3, 2024

Thronefall 개발자가 게임을 만드는 방법

디자인 프로세스

디자인 프로세스는 모든 곳에 적용된다.

1. 목표 정하기

달성하고 싶은 것에 대해 아주 잘 이해해야 한다.
스팀에서 잘 팔리는 게임을 만들고 싶다, 내가 재밌는 게임을 만들고 싶다,
특정한 레벨에 어울리는 음악을 만들고 싶다, 사운드 효과랑 어울리는 음악을 만들고 싶다 같은 명확한 목표.

→ 목표와 제약 조건을 정한다

2. 조사하기

해당 최적화 문제에 대해 내가 처음 생각한 게 최선의 해결책이 아닐거라고 가정한다.
목표와 제약 조건은 본질적으로 고유한 최적화 퍼즐이며, 거기엔 해결책이 있을 거다.
몇 가지 다른 방향들을 실험해본다. 그러다보면 경험도 쌓이고 올바른 방향을 더 잘 수립할 수 있게 된다.
처음엔 시간이 걸리겠지만, 한 번 방향을 좁히고 나면 빠르게 작업을 진행할 수 있다.

프로토타입 만들어야 한다는 얘기만 듣고 하나만 만들고 사람들한테 보여준 다음에
”오 나쁘지 않네” 얘기 듣고 그대로 개발 시작하면 안된다.
뭐가 나은지 비교할 수가 없기 때문이다.

→ 1개의 선택지만 있는 것과 10개 중에 최선의 선택지를 고르는 것 중에 후자가 무조건 좋다

디자인 프로세스 자체도 디자인 프로세스를 거쳐서 변화를 거쳐야 한다.
내 방식이 정답은 아니고 당신의 프로세스가 좋다고 생각하면 그걸 믿으면 된다.
좋은 프로세스는 일반적으로 좋은 결과로 이어질 것이다.

얼리 액세스

얼리 액세스는 조금 미흡하게 출시해도 되는가? 아니면 완전하게 만들고 출시해야 하는가?

얼리 액세스에 대한 의견은 분분하다.
출시 기회는 한 번 뿐이라고 하는 사람도 있고, 얼액까지 포함해서 두 번이라고 하는 사람들도 있다.
근데 나는 출시 기회는 한 번 뿐이라고 생각한다. 얼액 단계에서 망하면 정식 출시 때 잘 될 가능성이 낮다.

thronefall은 얼액 때 레벨 3개밖에 없었는데도 굉장히 성공했다.
얼액으로 던져보고 얼마나 여기에 자원을 쏟을지에 대한 판단 기준으로 삼을 수 있다.
그래서 얼액은 규모만 작고 굉장히 polished된 상태로 출시했었다.

어떤 게임이 얼리 액세스에 적합할까?

얼리 액세스는 유저들과 활발하게 소통하면서 개발할 수 있다는데 장점이 있다.
근데 반복 플레이가 가능한(replayable) 게임이어야지 유리할듯.

thronefall 얼액 때 후회하는 점

플레이어 의견에 좀 더 귀기울였어야 했다.
사람들이 무한(endless) 모드 좀 만들어달라고 아우성쳤는데
디자인 철학과도 맞지 않고 어떻게 만들어야 할지도 모르겠어서 안 만듬.
근데 최근에 무한 모드 프로토타이핑 해보니까 너무 마음에 들었음.

테스트 해본 친구가 미니맵 만들어달라고 했었는데 별로 중요하지 않다고 생각했었다.
근데 막상 만들어보니까 어떻게 이거 없이 플레이했을까 생각이 들 정도로 필수적이었다.

물론 사람들이 우리 일정에 안 맞거나 전혀 도움이 안 되는걸 요구하는 것들도 많았다. 너무 사소하고 드물게 일어나는 버그 fix를 요구한다던가.

피드백

가족, 친구, 스팀 커뮤니티, 유튜브, 트위터 등 여러 테스터 집단이 있는데, 누구의 의견을 듣는가?

깊이 생각해본 적은 없지만, 일단 게임을 만들고 나면 가장 먼저
성공한 게임을 만들어본 적이 있는 사람들에게 가서 의견을 묻는다.
일반 유저들이 항상 그들이 원하는 걸 아는 건 아니기 때문.

아까 유저들 의견 더 들어야 했다고는 말했지만,
사람들 의견을 너무 듣다보면 게임이 원하는대로 만들어지지 않을 수 있으니 조심해라.

개발자들은 프로토타입 단계의 의미를 알고, 유저가 어떤 것에 어떻게 반응하는지 잘 이해하고 있다.

그 다음으론 실제로 게임에 관심이 있고, 플레이를 해주는 유저들의 의견을 듣는다.
아마 사람들이 말하는 의견에 생각보다 훨씬 더 귀기울여야 할 거다.
조금 어려운 점은, 행간을 읽어야 한다는 것.

플레이어들이 겪고 있는 문제를 듣고, 플레이어의 해결책은 듣지 마라.
예를 들어, “이 레벨에 적을 더 추가해주세요!”라는 피드백을 들었다면
실제 문제는 레벨이 충분히 흥미롭지 않다는 것일 수 있다.
그러면 어떻게 해야 효율적으로 레벨을 흥미롭게 만들 수 있을지 고민하면 된다.

피드백을 필터링하는 방법

초기 단계에서 너무 많은 피드백을 받는 것은 위험하다.
그때 자신이 무슨 게임을 만들지에 대한 비전을 수립하기 때문.
견고한 비전이 없으면 사람들의 피드백을 필터링할 수가 없다.

두 문장으로 정의된 게임의 비전을 갖고 있으면 좋다.
thronefall 같은 경우엔 “왕국을 건설하고 지키는 미니멀리스트 게임”이었다.

이런게 있으면 “마우스로 유닛을 조작하게 해주세요”라는 피드백이 들어와도
우리의 비전과 맞지 않으니 필터링할 수 있다.

피드백을 두려워하지 마라

부정적인 피드백에도 포기하지 않고 계속해서 나아가야 게임 개발자로써 장기적으로 성공을 거둘 수 있다.
다른 사람들은 그런 걸 듣고 다들 포기하기 때문.

많은 게임 개발자들이
”이 부분은 아직 개발이 덜 됐으니까 피드백 받고 싶지 않아"
"내 게임은 피드백 받을 준비가 안됐어. 그러니까 모든 걸 폴리싱해야돼."
"내가 이미 알고 있는 피드백은 들을 필요 없어”
같은 생각을 하는데,

그냥 입 닫고 펀치를 좀 얻어맞아라. 그래야 성장을 한다.

부정적인 피드백이 많아서 해당 게임의 개발을 포기할지 고민이 될 때 어떻게 결정하는가?

굉장히 어려운 문제다. 당신은 두 가지 오류를 범할 수 있다.

나는 여기에 너무 많은 시간을 쏟았으니까 반드시 끝내야돼. (사실 처음부터 다시 만드는게 나음)
계속해서 프로젝트를 접으면서 이것도 아니야 저것도 아니야. (아무것도 완성하지 못하고 있음)

둘 다 위험하다. 이런 실수들을 피하는 가장 좋은 방법은 매우 구조화된(structured) 디자인 프로세스를 가지는 것이다.

프로토타입 단계에서 여러 아이디어를 시험해본다면
여러 아이디어를 짧게 시도해보는 것이니 첫 번째 오류도 피할 수 있고,
여러 아이디어를 이미 시험해봐서 이게 최선의 아이디어라는 걸 알고 있으니 두 번째 오류도 피할 수 있다.

개발을 많이 진행한 상태에서 피드백을 너무 늦게 들으면 펀치가 굉장히 아프게 들어올 수 있다.

게임 디자인 문서 (Game Design Document)

1인이나 작은 팀이라면 게임 디자인 문서가 굳이 필요 없다고 생각한다.
목표와 제약 조건을 명시화하는 건 도움이 되긴 했다.

게임 디자인 문서를 너무 한 번에 쓰려고 하지 마라.
그렇다고 아무때나 막 수정하라는 건 아니고,
쓸 때 신중하게 쓰되 한 번 쓰면 되돌리지 말아야 한다고 생각한다.

게임 설명은 왜 단순해야 하는가?

단순하게 설명 못해도 상업적으로 성공할 수 있지 않나? 꼭 두 문장으로 설명해야 하는가?

스팀에서 기대 관리(expectation management)는 굉장히 중요하다.
내 게임을 원하는 사람들이 다운로드를 받아야 하고,
내 게임을 원하지 않는 사람들은 다운로드를 받지 않게 해야 한다.
기대랑 맞지 않는 게임을 하게 되면 리뷰를 안 좋게 줄 거다.

한 두 문장으로 게임을 정의하게 되면 소비자들도 당신의 게임을 더 잘 이해할 수 있게 되고,
당신도 당신의 게임을 더 잘 이해할 수 있게 된다.

게임 설명이 세 문단 정도 되면 개발 중에 마음 속에 새기고 있기가 어렵다.
피드백을 마구 받고 있는데 세 문단이나 되는 필터링 기준을 갖고 있으면 뭔가 빠뜨리기 쉽다.
단어를 추가한다고 해서 묘사가 정확해지는게 아니다.

두 문장으로 설명하기는 프로세스 초기에 해야 한다. 나중에 하면 너무 늦음.

그리고 사람들은 스팀 페이지를 몇 초밖에 안 봐주기 때문에 설명이 짧아야 유리함.

스팀 관련 이야기

대부분의 판매는 사람들이 스팀에서 알고리즘으로 유입돼서 발생한다.
그리고 스팀 알고리즘은 위시리스트 수, 스팀 페이지 보는 시간, 평균 플레이 시간 등 다양한 요소들로
자신의 게임을 정확하게 평가해준다.

그러니 마케팅 방식보다는 좋은 게임을 만드는 것에 우선순위를 둬야 한다.

훌륭한(great) 게임을 만드는 것과 적합한(right) 게임을 만드는 건 다르다. 플랫포머를 잘 만들어도 수가 너무 많아서 팔리기가 어렵다.