'젤다: 왕국의 눈물', 오브젝트 조합 '스크래빌드'는 어떻게 탄생했나

지난 8월 22일, 파시피코 요코하마에서 게임 개발자를 위한 '컴퓨터 엔터테인먼트 개발자 컨퍼런스(이하 CEDEC) 2024'가 개최됐다. 주목할 세션으로 닌텐도 후지바야시 히데마로와 히로세 켄이치 게임 디자이너의 '젤다의 전설: 티어스 오브 더 킹덤의 스크래빌드가 만들어지기까지 - 준비를 위한 준비'가 진행됐다.

'젤다의 전설 티어스 오브 더 킹덤(이하 젤다의 전설 왕눈)'의 큰 특징인 '스크래빌드'는 무기를 비롯한 장비에 다른 소재를 붙여서 성능을 강화하는 것이다. 이를 실현하기 위해 후지바야시 히데마로(이하 후지바야시)와 히로세 켄이치(이하 히로세) 게임 디자이너가 진행한 세션을 전한다.

후지바야시 히데마로(왼쪽), 히로세 켄이치(오른쪽) 게임 디자이너.

게임보이 컬러 시절부터 '젤다의 전설' 개발에 관여한 후지바야시는 '젤다의 전설 왕눈'의 디렉터이자 스크래빌드의 창시자다. 히로세는 게임 개발 인프라팀의 리드 엔지니어로 개발에 참여했다. 개발에서 사용하는 서비스(주로 브라우저에서 사용하는 웹 앱)를 정비하여 개발을 보다 편리하고 효율적으로 하는 업무를 맡았다.

 

■ 스크래빌드의 재미와 문제점

먼저 후지바야시가 스크래빌드의 '붙이는 놀이'를 만들게 된 경위를 소개했다. 원래 아이디어는 전작 '젤다의 전설 브레스 오브 더 와일드(이하 젤다의 전설 야숨)를 개발할 때였다고 한다. 후지바야시가 '철창 너머에 있는 스위치를 창으로 찔러서 켜는' 장치를 만들었을 때, '더 멀리 스위치가 있고, 창을 두 개 연결해서 닿게 하는 놀이를 할 수 있다면 재미있을 것 같다'고 생각한 것이 계기다. 또한, '옥타 풍선'(오브젝트에 붙이면 공중에 띄울 수 있는)에도 '무언가를 붙이는 놀이'로서 가능성을 느꼈다고 한다.

그렇게 느낀 이유는 '젤다의 전설 야숨'부터 이어진 개발 테마에 '재미있는 일이 일어나는 구조를 만드는 것'이 있었기 때문이다. 후지바야시는 게임 내에 재미있는 일이 일어날 수 있는 구조를 만들어 두면, 그것들이 서로 결합하여 생각지도 못한 일이 일어나 새로운 경험을 만들어 낼 수 있다고 말했다.

'울퉁불퉁한 지형'과 '둥근 바위'만으로도 구멍에 넣거나 적에게 부딪혀 놀라게 하는 등 다양한 놀이가 가능하다.

이 테마를 '젤다의 전설 왕눈'에서 더욱 발전시키기 위해 생각한 것이 스크래빌드인 셈이다. 후지바야시는 아이디어를 어떻게 구체화했는지에 대한 소개로 넘어가면서 “젤다의 전설이란 어떤 게임인가?”라는 근본적인 질문을 던졌다. 자신은 '추리하고 실행하고 결과를 즐기는 게임'이라고 정의했다.

'젤다의 전설 야숨', '젤다의 전설 왕눈'에서는 '모닥불 너머에 있는 상자를 향해 화살을 쏘면 화살에 불이 붙어 상자가 타버린다', '나무를 자르면 통나무가 되어 강에 띄워 강물을 타고 내려갈 수 있다'는 것이 가능했다. 하지만, 후지바야시는 '이렇게 하면 되지 않을까라고 추리한 결과가 게임으로 이어졌다"고 표현했다. 그리고 이것이 바로 '젤다의 놀이'이며, 과정이 풍부할수록 재미있는 구조로 되어 있다고 한다.

이 설명은 '젤다의 전설 야숨' 개발 중 진행된 플레이 검증 영상을 바탕으로 작성됐다.

그래서 후지바야시는 '젤다의 전설 왕눈'에서도 '추리와 실행'을 통해 할 수 있는 것들을 플레이어의 자유로운 발상으로 넓힐 수 있도록 주력했다. 그 결과 스크래빌드의 붙이기 놀이에 몰두했다.

우선 무기에 무언가를 붙이는 것부터 시작했다. 호박밭에서 창을 휘두르면 창끝에 호박이 붙어 파괴력이 올라가고, 창끝에 벌집을 붙이면 벌이 나와 적을 공격한다. 방패의 좌우에 검을 붙인 후 짊어지고 걸으면 주변의 풀을 깎을 수 있는 것이 가능함을 알게 됐다. 할 수 있다는 것을 알게 된 후지바야시는 추리의 폭이 상상한 대로 넓어질 것 같다는 확신을 가졌다. 스크래빌드의 본질이 보이기 시작했다.

'그림이 기능을 나타낸다'처럼, 외형이 기능을 설명할 필요가 있다는 것이다. 막대기에 바위가 붙어 있는 것만으로도 파괴력이 높아진 것 같은 느낌이다. 붙이면 원래의 모습과 전혀 다른 모습으로 변하는 선택지도 있었지만, 플레이어가 상상하고 추론할 수 있도록 하기 위해서는 A+B=C가 아닌 A+B=AB의 형태가 좋다고 판단했다.

반응을 본 후지바야시는 '3개에서 4개까지 붙이면 더 재미있지 않을까'라는 아이디어를 떠올렸다. 하지만, 당연히 조합의 수가 방대해지기 때문에 다른 스태프들의 문제 제기가 있었다.

엔지니어는 “붙이면 원래 무기의 효능이 한꺼번에 발동하는 건가?”, 아티스트는 “어떤 모양이 될까?”라는 질문을 던졌다. "버그 체크가 엄청나게 많은데 어떻게 할 것인가?”, 게임 디자이너는 “무기 이름이 엄청나게 많아지는데 어떻게 할 것인가?” 등 다양한 질문을 던졌다. 팀 내에서는 “불가능하지 않을까?”라는 분위기가 팽배해지기 시작했다.

후지바야시는 모인 청중을 향해 “이런 경우가 자주 일어나지 않겠느냐"며, “여기서부터 마음을 다잡아야 한다”고 말했다. 이 단계에서는 스크래빌드 사양이 검증 단계에 머물러 있기 때문에, 직원들이 방대한 수의 조합을 막연하게 문제시하는 것은 어쩔 수 없다.

그래서 진행된 것이 '문제 분해'다. 사양을 명확히 하기 위해 '이런 것이 있었으면 좋겠다'는 희망사항은 '위시리스트'로, 필수적인 사양은 '플랜 리스트'로 분류했다.

이 시점의 위시리스트에는 '보스 보코블린의 휘파람을 검에 달고 휘두르면, 그 소리로 보코블린을 조종할 수 있다', '방패에 날개 달린 조나우기어를 달면 하늘을 활공할 수 있다'와 같은 것들이 있었다. 반면 플랜 리스트에는 '그림이 기능을 나타낸다', '무엇이든 붙일 수 있다', '소재는 여러 개 붙일 수 있다', '소재는 자유자재로 붙일 수 있다' 등의 내용이었다.

위시리스트는 필수 조건이 아니기 때문에 일단 보류하고, 우선 플랜 리스트 항목에서 문제의 근원인 '방대한 수'에 대한 추가 분해에 착수하기로 했다.

후지바야시는 '소재는 여러 개 붙일 수 있다'에 창을 3~4개 연결하여 원거리에서 공격하는 것, '소재는 자유자재로 붙일 수 있다'에 소재를 붙이는 각도에 따라 차이를 내는 것을 목표로 하고 있었다. 하지만, 검증을 진행하면서 '창을 3~4개 연결하면 다루기 힘들다', '여러 종류의 소재를 붙이면 외형상 기능을 상상하기 어렵다', '외형이 기능을 나타낸다는 점에서 각도는 별 의미가 없다'는 것을 알게 됐고, 이에 대한 수정이 이루어졌다.

각도에 대해서는 오히려 고정하는 것이 기능을 더 잘 이해할 수 있는 경우도 있다는 것을 깨달았다.

한편, '무엇이든 붙일 수 있는 것'에 대해서는 추리와 실행을 땅에 붙이는 구조라고 다시 한번 확신했다. 또한, 무기 이름에 대해서는 '이름도 기능을 나타내는 것'이 알기 쉽다는 것을 깨닫고, 원래 무기 단계부터 기능을 나타내는 이름으로 하는 것을 계획 리스트에 추가했다.

이런 결과를 바탕으로 후지바야시는 '하지 말아야 할 것'을 결정했다. 구체적으로는 “2개 이상 붙이는 것”은 하지 않는다. “붙이는 위치가 자유자재”는 하지 않는다. “하나하나 고유한 이름"을 짓지 않는다. 물론 이것만이 전부는 아니지만, 크게는 이 세 가지를 기준으로 삼았다.

계획 목록이 좁혀진 단계에서 위시리스트도 재검토, 날개+방패는 당초와 다른 효과로 구현

플랜 리스트가 업데이트되면서 엔지니어는 '2개 이상 붙이지 않으면 괜찮다', 게임 디자이너는 '일정한 규칙에 따라 이름을 붙이면 되지 않겠느냐'는 등 스태프들의 생각도 바뀌었다.

하지만 새로운 조건에서도 조합이 12만 가지나 되기 때문에, 특히 아티스트가 외형과 이름을 체크하는 작업의 부담이 커질 것으로 예상됐다.

 

■ '12만 가지' 문제 해결

이어 히로세가 연단에 올라 '12만 가지' 문제를 해결하기 위해 게임 개발 인프라팀이 진행한 작업을 소개했다.

스크래빌드를 통해 생성되는 무기의 체크 항목으로는 주로 외형과 이름이 있다. 아래 이미지와 같이 검과 바위를 붙였을 때, 검 위에 바위가 얹혀있는 것이 아니라 검이 바위에 꽂혀있는 모양으로 만들어야 한다.

또한, 이름에 대해서는 앞서 언급했듯이 일정한 규칙을 정하고 있지만, 이것이 부족하면 외형과 이름이 맞지 않는 문제가 발생한다.

이런 부분은 아티스트나 테스터를 비롯한 담당자가 눈으로 확인할 수밖에 없다. 또한, 한 번 확인하면 끝나는 것이 아니라 프로젝트의 중요한 시기에는 전체적인 점검이 이루어지고, 원래의 무기나 소재에 변경이 있으면 스크래빌드 후에도 다시 한번 확인해야 한다. 즉, 점검 횟수는 12만 번으로 끝나지 않는다.

이렇게 되면 조합의 수를 줄이고 싶지만, 히로세는 “타협해서 줄이면 재미가 없어진다”고 단언했다. 또한, 체크 비용이 커지면, 브러시 업을 주저하게 되는 경우도 생긴다고 지적하며, 체크의 부담을 줄이는 것이 매우 중요하다고 말했다.

이러한 체크를 할 경우 보통은 개발기에서 게임을 실행해 스크래치 빌드를 한다. 이어 카메라를 돌려서 외형을 확인하고, 마지막으로 포치 화면에서 이름을 확인한다. 하지만 이렇게 12만 가지를 확인하면 시간과 노력이 너무 많이 소요된다는 것은 누구나 알 수 있을 것이다.

그래서 히로세는 스크래치 빌드 후의 모습을 촬영한 이미지를 웹 브라우저에서 확인할 수 있는 구조를 생각했다. 게임을 실행하지 않고도 확인할 수 있는 것이다.

다면 전개도나 포치 화면 등 아이템별로 정리된 여러 이미지를 확인할 수 있다.

물론, 이미지만 나열된 것만으로는 확인하기 어렵기 때문에 '이미지 게시판'을 통해 정리했다. 다양한 조건으로 검색이 가능하며, 목록에서 이미지를 클릭하면 상세 화면으로 이동한다. 마음에 드는 부분을 발견하면 거기서 수정 작업을 발행할 수 있다. 또한, 게임 내에서 확인하고 싶을 때를 위해 이미지 게시판에서 클릭 한 번으로 게임 내에 직접 생성할 수 있는 기능도 마련했다.

촬영 날짜를 기록으로 남기도록 한 덕분에 문제가 발견되었을 때 '언제부터 문제가 발생했는지'도 바로 알 수 있다. '언제 문제가 발생했는지'에 대한 조사는 개발에 있어 큰 부담으로 작용하기 때문에 이를 해소할 수 있었던 것이 매우 컸다고 한다.

이미지 게시판을 통한 점검 작업은 현실적인 부담으로 안정화됐다. 그러자 프로젝트 내에서 입소문이 퍼져 방어구나 바람에 의한 흔들림의 거동 확인 등에도 활용하게 됐다.

 

■ 준비를 위한 준비는 팀 문화의 형성

다시 후지바야시가 단상에 올랐다. 앞서 말한 스크래빌드 사양 작성에 필요한 준비 작업에는 '팀 문화 형성'이라는 또 다른 준비, 즉 '준비를 위한 준비'가 필요했다. 게임 개발 인프라팀이 만든 게시판의 구조가 도움이 되었다고 밝혔다.

후지바야시는 스크래빌드를 구현하기 위해서는 팀원들이 지향하는 바를 공통으로 인식하고, 무엇이 옳은지 그른지에 대한 규칙과 인식의 일치, 공통의 사전 같은 것이 필요하다고 말했다. 그것이 팀 문화다.

그 형성에 게시판이 도움이 되었는데, 설명에 앞서 후지바야시는 '젤다의 전설 왕눈'의 제작 플로우를 보여줬다. 그것이 아래 이미지다.

새로운 사양이나 시스템 내용 설명이 이루어지고, 멤버들이 이를 이해하여, 실제로 만들어서 구현한다. 마일스톤마다 멤버들이 모두 플레이하고, 거기서 나온 정보를 취합하여 주요 멤버들이 면밀히 검토한다. 이후 개선책이 멤버들에게 배포되는 흐름을 반복한다.

'팀 문화 형성'은 개발 사이클을 잘 돌리기 위해 필요한데, 특히 '마일 플레이', '정보 취합', '정밀 조사'에서는 방대한 정보를 수집하고 정리해야 하므로 효율화가 필요했다.

그래서 사용된 것이 게시판 시스템이다. 마일플레이를 하면서 회원들이 느낀 점을 실시간으로 작성할 수 있는 공간으로 원래 있던 게시판에 자체적인 커스터마이징을 가미해 만들었다.

게시글에는 일련번호와 게시자 이름 외에 '좋았다/궁금하다'라는 감상란, 구체적인 내용을 작성하는 댓글란, 게시자 외의 멤버가 해당 내용에 동의할 때 누르는 '그래!' 버튼, 리더들이 게시물의 내용을 검토한 결과를 작성하는 방침란 등이 마련됐다. '그래!'의 숫자가 '젤다의 전설'에서 사용되는 화폐 '루피'로 표시되어 '루피 게시판'이라고 불리게 됐다.

이를 통해 비슷한 정보가 여러 구성원으로부터 중복되는 일이 줄고, 팀원 모두가 어떤 과정을 거쳐 결론이 나왔는지 직접 파악할 수 있게 됐다. 또한, 투명성과 이해도가 높아져 개발 주기가 더 원활하게 돌아갈 수 있게 됐다.

다만, 댓글을 달 수 있는 게시판인 만큼 잘못 사용하면 문제가 발생해 개발 진행에 지장을 초래할 위험도 있다. 그래서 게시판 이용에는 다음과 같은 규칙을 정했다.

-의견이 아닌 정보를 쓴다.

후지바야시에 따르면, 이것이 가장 중요한 규칙이라고 한다. '가시를 먹고 게임오버가 되었습니다. 불합리합니다'는 의견이지만, '가시를 먹고 게임오버가 되는 것은 불합리하다고 느꼈다. 오른쪽에서 봤을 때는 가시가 보였는데, 왼쪽에서 봤을 때는 가시가 보이지 않아 기습을 당했기 때문이다'라고 쓰면 정보가 된다. 즉, 개선의 실마리가 있느냐 없느냐 하는 것이다.

-인식이 바뀌면 추가 기입.

'처음에는 어렵다고 생각했는데, 플레이를 진행하다 보니 재미있어졌다'는 경험은 게이머라면 누구나 한 번쯤 겪어봤을 것이다. 플레이하면서 인상이 바뀌는 경우가 많은데, 처음 쓴 정보를 그대로 두면 정확도가 떨어지기 때문에 업데이트가 필요하다. 또한, 추가 기입을 통해 투고자 생각의 변화도 알 수 있어 게임 디자이너가 난이도를 조정하는 데 매우 효과적이었다.

-토론은 하지 않는다.

게시판에는 다른 사람의 글에 댓글을 달 수 있는 기능이 있었지만, 토론은 하지 않고 같은 사건에 대해 느낀 다른 정보는 별도로 게시했다. 후지바야시는 토론이 안 되는 것이 아니라, 새로운 정보를 게시하는 형태가 팀 문화 형성을 촉진하는 데 도움이 된다고 생각했다.

루피 게시판을 3가지 규칙으로 운영하면서 구성원들 간의 의식이 통일되고 팀 문화가 형성되어 개발 사이클이 잘 돌아갈 수 있게 됐다.

루피 게시판에 '스크래빌드에 필요한 절차가 너무 많아 사용하기 어렵다'는 글이 올라와 담당자가 자극을 받아 절차를 압축했다고 한다.

 

■ 개발 인프라팀에도 준비를 위한 준비가 있었다

히로세의 게임 개발 인프라팀에서도 준비를 위한 준비가 있었다. 구체적으로는 이미지 게시판을 비롯한 서비스를 지원하는 것이다.

게임 개발에서는 고민거리나 새롭게 하고 싶은 일이 많이 발생한다. 때문에, 게임 개발 인프라팀에서는 그러한 요구에 부응하여 보다 편리하고 효율적으로 만들고 싶지만, 직접 해결하는 데는 한계가 있다고 한다. 그래서 '젤다의 전설 왕눈'처럼 개발자가 자유롭게 발명할 수 있는 구조를 만들기로 했다.

그중 하나가 '데이터 수집 분석' 시스템이다. 원래 엔지니어로부터 '버그의 내용을 분석하고 싶다'는 상담을 받아 준비한 것이다. 개발기에서 출력되는 오류 정보를 올리면 자주 발생하는 버그를 나열하는 등 오류 상황을 시각화할 수 있다.

메커니즘 자체는 오류 정보에만 국한된 것이 아니기 때문에 다양한 곳에 활용됐다. 일정 관리 담당자는 작업 진행 정보를 넣어 프로젝트 진행 상황 분석과 작업 완료 시점을 예측하고, 최적화 담당자는 무대가 되는 하이랄 각지의 부하 데이터를 넣어 히트맵을 만드는 식이다. 이처럼 담당자마다 새로운 사용법이 생겨나면서 활용의 폭이 넓어졌다.

이러한 서비스는 안정적인 운영이 중요하기 때문에 서버가 몇 대 정지해도 문제없이 운영됐다. 회원 수가 증가하여 부하가 커지면 자동으로 서버 대수가 늘어나는 구조다.

히로세는 프로젝트에 도움이 되는 것을 만드는 것은 매우 어려운 일이라고 말했다. 자칫하면 독선적인 방향이 될 수 있기 때문에 가능한 한 빨리 현장에 투입하여 피드백을 받으면서 만들어 가는 것이 효과적이라고 한다.

그런 가운데 성장한 서비스로 '개발기 클라우드'가 있다. 이는 미리 준비된 개발기 중에서 필요한 부분을 바로 이용할 수 있는 구조로, 개발기를 제어할 수 있는 환경도 동시에 제공된다.

이전에는 '개발기가 필요하다'는 요청이 들어오면 개발기뿐만 아니라 제어용 PC를 준비하고 배선하여 초기 설정하는 등의 번거로움이 있었다. 하지만, '개발기 클라우드'를 통해 웹브라우저에서 바로 이용 절차가 가능해졌다.

앞서 언급했듯이, 이미지 게시판은 스크래빌드뿐만 아니라 다양한 용도로 사용됐다. 대응에는 개발기 클라우드가 큰 도움이 됐다. 이 시스템은 '젤다의 전설 왕눈' 이외의 프로젝트 팀에서도 이용했는데, 개발기의 '전달' 버튼 하나로 원활하게 진행할 수 있다. 물리적으로 준비할 때는 반납도 힘든 작업이었지만, 그마저도 불필요해져 사용하지 않고 방치되는 개발기기도 줄어들었다.

세션의 마지막에 후지바야시는 다시 무대에 올라 스크래빌드 팀과 게임 개발 인프라팀 모두 '준비를 위한 준비'가 있었음을 다시 한번 언급했다. “오늘 말씀드린 내용이 스크래빌드의 모든 것은 아니지만, 효과를 발휘한 방법이나 인프라의 개념 및 운영 방법론 등은 응용할 수 있을 것"이라고 정리했다.