[NDC 2021] 게임 처음 만드는데, 실수 좀 할 수 있죠

실수에서 배우는 게임 개발

김승주(4랑해요) 2021-06-10 18:44:42

많은 학생 게임 개발팀은 프로젝트 중간에 완성하지 못한 상태로 마무리가 된다. 이유는 팀이 와해되거나 이런저런 사정이 있기 때문이다. 그리고 대부분 이 사정은 '팀 내부 갈등'이 원인이다. 이전에는 "팀 운이 나빠서", "시기가 좋지 않아서"라고 생각했다.

하지만 한 발자국 떨어져 생각해보니, 우리가 경험이 적고 서툴러서임을 알 수 있었다. 박소현 개발자는 학생 시절 자신이 참여했던 프로젝트를 예시로 들었다. 이 강연을 통해 게임 개발을 시작하는 분에겐 덜 실수할 수 있는 팁을, 경험이 있는 분들에게는 공감을 드릴 수 있으면 좋겠다고 밝혔다. /디스이즈게임 김승주 기자

강연자: 박소현
소속 : 넥슨코리아 <프로젝트 HP> 게임 디자이너
이력:
▲ 3년차 게임 디자이너
▲ <0년차 게임개발> 공동 저자
▲ <야생의 땅 듀랑고> 라이브 서비스

# 구상 단계에서의 실수

첫 번째 이야기는 게임 구상 단계에서의 실수다.

학생 시절 처음 아이디어를 구상할 때, 간단한 아이디어와 레퍼런스만을 가지고 팀원을 구성했다. 이후 팀원이 모여 컨셉을 구체화하는 과정에서 갈등이 있었다. 결국 양보와 타협을 통해 개발을 시작했지만, 팀원 각자 만족스럽지 못한 컨셉을 가지고 개발을 하게 되었다.

이유가 무엇일까? 바로 아이디어를 구체화하지 않고 팀원을 모았기 때문이다.

박소현 개발자는 당시 "전략적 상황에 따라 파트너 캐릭터와 합체, 또는 협동하여 싸우는 액션 RPG"라고 간단히 게임 개요를 작성했다. 그리고 게임을 구체화하는 과정에서 콘셉이 세 번이나 바뀌게 됐다. 아이디어를 보고 팀원들은 각자 '다른 기대'를 하고 모였다.

레퍼런스도 명확하게 잡지 않았다. 가령 <라스트 오브 어스> 같은 게임을 만들자고 하면 어떤 팀원은 '실사 그래픽'을 생각한다. 또 다른 팀원은 '멋진 내러티브'를 생각한다. '무기를 여러 가지 사용하는 전투 시스템'을 상상하는 팀원도 있다. 각자 생각이 다르기 때문에, 기대도 다를 수밖에 없다.

이를 해결하기 위해선 아이디어 구체화를 마치고 팀원을 구하는 것이 좋다. 게임 규모, 목표, 플로우, 시스템, 맵 단위 등 이를 문서로 정리해야 한다. 그리고 팀원을 모집할 때 구체적인 자료를 제시할 수 있다면 생각이 비슷한 팀원을 구할 확률이 높아진다.

하지만 이미 팀이 꾸려진 상황이라면 어떻게 해야 할까?

이 경우에는 팀원 모두가 공감대를 형성해야 한다. 박소현 개발자는 무작위로 팀을 배정받았던 사례를 소개했다. 당시 팀원 모두가 해 봤던 게임을 레퍼런스로 삼고, 주인공이 달걀인 만큼 "계란으로 바위 치기" 속담에서 컨셉을 가져온 공격 스킬을 만들자고 제시했다. 팀원 모두가 해당 속담을 알고 있어 모두가 쉽게 동의했다.

즉, 팀 빌딩 전이라면 아이디어를 최대한 구체화해 기대가 비슷한 팀원을 구하고, 팀 빌딩 후라면 서로 알고 있는 공감대를 형성하며 의논하는 것이 좋다.

# 프로토타입 단계에서의 실수

당시 박소현 개발자는 게임 프로토타입을 "최소한의 기능만으로 재미를 검증하는 것"으로 생각했다.

하지만 재미를 검증 포인트로 삼으면 쉽게 결론을 낼 수 없다. 재미는 주관적인 개념이기 때문. 예시로 밝힌 사례에서는 팀원마다 반응이 달라, 계속 기능을 추가하다 보니 1주일이었던 프로토타입 일정이 1달까지 밀렸다. 결국 프로토타입 단계부터 오랜 기간을 소모하게 됐다.

시행착오를 거친 후, 박소현 개발자는 판단의 기준을 '재미'가 아닌 '의도'로 삼았다.

박소현 개발자는 당시에 개발했던 '슬로우 스킬' 프로토타입을 소개했다. 이전에는 프로토타입을 해 본 사람에게 "슬로우 스킬이 재미있나요?"라고 물었다면, 판단 기준 수정 후에는 "슬로우 스킬을 이용해 적의 공격을 막을 수 있나요?"라고 묻게 됐다.

무엇을 검증할지 정하니 이전보다 결과를 뚜렷하게 판단할 수 있게 되었다. 결과를 판단할 수 있게 되니, 개발에도 확신이 생겼고 개발 속도를 이전보다 올릴 수 있었다.

그리고 두 번째 사례를 소개했다. 위 사례처럼 프로토타입 개발이 장기화하는 일이 발생하자 새로운 문제가 생겼다. 프로토타입 개발이 끝나지 않아 아트 팀원의 일이 없어진 것이다. 아트 팀의 공백이 길어지자 해당 팀원 사기가 떨어졌다.

해답은 간단했다. 다른 프로토타입을 동시에 병렬 작업한 것이다. 프로그래머가 무료 에셋을 통해 프로토타입을 개발하는 동안, 아트 팀은 플레이 프로토타입과 별개로 컨셉에 맞는 씬을 제작했다.

# 열정 유지하기

개발 기간이 길어질수록, 프로젝트를 시작하며 생긴 열정은 자연스레 줄어들 수밖에 없다. 열정 감소를 구조적으로 완화할 방법은 없을까? 박소현 개발자는 크고 작은 결과물이 나왔을 때 팀의 의욕이 상승한다고 설명했다. 유저 반응까지 볼 수 있다면 더 효과적이다. 즉, 열정 감소를 늦추려면 개발 과정에서 성취감을 얻어야 한다.

이를 위해서 두 가지 방법을 제시했다. 첫째로 작은 목표를 가지는 것이다. 욕심을 줄인 작은 목표는 비교적 달성하기 쉽고, 이를 달성해 작게나마 성취감을 느낄 수 있다. 성취감은 새로운 목표를 향한 동기가 된다.

두 번째는 진행 상황을 시각적으로 공유하는 것이다. 시각 정보는 보기 쉽고 더욱더 많은 정보를 담을 수 있으며, 영상을 주고받을 때 협업에 대한 성취감을 얻기도 한다. 다만 시각적인 자료는 준비가 어렵고, 시간도 오래 걸릴 수 있어 상황에 따른 적절한 수단을 선택하는 것이 좋다.

세 번째는 정기 빌드로 다 함께 플레이해 보는 것이다. 게임 회사라면 PM이 빌드와 플레이 일정을 관리하지만, 그런 부분을 잘 모르는 아마추어팀에서는 놓칠 수 있다.

개발 중인 게임을 플레이한다는 것은 큰 동기 부여가 된다. 진행에 대한 믿음이 생기며, 개인 작업이 새로운 환경에 적용된 것을 보았을 때 새로운 수정 사항을 알 수도 있다. 또한 빌드에서만 확인되는 개선점이나 버그를 확인할 수도 있다.

네 번째로 분업 구조 설정이다. 작업물이 빠르게 적용되면, 성취감과 함께 업무 효율도 상승한다. 박소현 개발자는 대학 시절 프로젝트를 예시로 들었다. 당시 분업 구조를 위해 레벨디자인 맵툴을 따로 제작했다. 맵툴로 레벨 디자인을 작업하면 프로그래머 손을 거치지 않고, 새로운 맵을 곧바로 적용해 플레이할 수 있었다.

다만, 기간이 짧은 프로젝트일 경우 분업 구조를 만드는 비용이 더 클 수 있다고 당부했다.

# 실수도 해 봐야 안다

강연 마지막에서, 박소현 개발자는 실패 사례도 포스트모템해야 한다고 강조했다.

당연한 말일 수도 있지만, 개발 공부를 할 때는 잘 된 사례 위주로 찾다 보니, 잘 안 된 사례를 포스트모템하는 것을 소홀히 하는 경우가 있다. 박소현 개발자는 잘 안 된 사례를 포스트모템 하는 것이 게임을 출시할 때 만큼의 큰 성장 계기가 됐다고 밝혔다.

또한 숲을 볼 수 있도록 강조했다. 누구나 실수는 할 수 있다. 그렇기 때문에 개선책을 개인에서 찾는 것이 아닌, 큰 그림에서 파악하려는 노력이 필요하다. 박소현 개발자는 이런 과정을 통해 "운이 없었다"고 생각한 일이 "사실은 실수였고, 개선할 수 있는 일"이었음을 알 수 있었다고 밝혔다.