들어가며
23년 4월 초에 페이퍼 프로토타입, 2차 테스트를 진행했다. 이번 테스트는 <RIP> 팀에 신규 아트 분이 합류하면서, 비전 공유를 할 겸, 1차 테스트 때 확인하지 못한 덱 빌딩의 재미를 검증하고자 진행했다.
2차 테스트는 지난 번, 1차 테스트에서 사용한 카드들을 변경하고 몇 가지 룰을 추가하여 진행했는데, 본 글에서는 이런 준비 과정과, 진행하며 느낀 것들을 위주로 정리하려고 한다.
목차는 아래와 같다.
- 2차 테스트의 목적
- 덱 컨셉의 설계 과정
- 물리적 한계 극복을 위한 시도
- 결과물
- 테스트 후기
2차 테스트의 목적
23년 2월, <RIP> 팀에 신규 아트 분이 합류하게 됐다. 새로운 팀원이 들어오면서 다시 한번 비전 공유를 할 필요가 있어 보였는데, 이에 이전에 진행했던 페이퍼 프로토타입을 진행하기로 했다.
나는 모두가 모여 페이퍼 프로토타입 테스트를 진행하는 기회가 자주 있지 않는만큼, 이전 테스트를 그대로 진행하기보다 한층 더 업그레이드해서 1차 테스트 때 아쉬웠던 부분을 보완하기 위해 디자인한 새로운 시스템을 추가해 재미를 검증하고자 했다.
그리고, 이에 더해 이전에 <Slay the Spire>를 분석하며 정리한 덱 빌딩의 재미 요소를 녹여내어, 덱 컨셉을 정의하고자 했다. 이에 따라 새로운 카드들을 디자인한 뒤, 테스트를 진행해 덱 빌딩의 재미를 검증하기로 했다.
이렇게 '새로운 시스템과 덱 빌딩의 재미를 검증하자.'라는 목적 아래, 2차 테스트를 준비하고 진행하게 됐다.
덱 컨셉의 설계 과정
카드 디자인을 위한 정의와 조합
2차 테스트를 준비하면서 가장 어려웠던 부분은 덱 컨셉을 설계하고, 카드를 디자인하는 부분이었다. 새로운 시스템이야 기획한 시스템을 물리적으로 테스트 가능하도록 변형하기만 하면 된다.
하지만, 덱 컨셉 같은 경우는 기존에 추상적으로 생각하던 것들을 정리하고, 이것들에 기준을 세워 정의한 뒤, 최종적으로는 유저가 경험해야 하는 감정을 창발할 수 있도록 조합하는 과정을 거쳐야 했기에 카드 디자인 경험이 부족한 나로서는 막막하게만 느껴졌다.
하지만 막막하다고 안 할 건 아니지 않은가? 어떻게든 시작은 해야 한다. 처음 시작은 자료 수집이었다. <The art of Game Design>을 참고하며 유기적인 관계를 통해 복잡성을 숨기고, 깊이를 더하는 lenticular design을 알게 됐는데, 'Easy to learn, Hard to master'를 추구하는 나에게 적합한 디자인 방식이라는 생각이 들었다.
Lenticular design 방식을 참고 했다지만 특별한 건 없다. 우선 덱 컨셉을 정의하기 전에 카드 기능의 주체, 동작, 객체가 될 수 있는 것들을 정의했고, 이것들과 수치를 조합하여 카드를 디자인할 수 있는 틀을 마련했다. 그리고, 이 틀을 기반으로 컨셉을 구상하고 카드를 디자인했다.
정의하고, 조합하는 것. 이게 끝이다. 그렇다면, 이 방식이 왜 매력적인 것일까? 예를 통해 살펴보자.
우선 정의하지 않고, 되는대로 카드를 디자인하는 경우이다. 처음에는 아이디어가 폭발적으로 나온다. 내가 떠올린 창의적이고 놀라운 아이디어에 기반한 카드들을 보면 괜스레 뿌듯하고 자랑스럽다. 다만, 그 아이디어 사이에는 공통점이 없다. 만일 있더라도 부분적으로만 존재한다. 그렇기에 새로운 카드를 디자인하고 구현할 때마다 하나씩 설계하고 구현하며 검토해야 한다. 이는 겉으로 보기에는 완벽해 보여도 규격 없는 부품들로 조립했기에 결코 양산할 수 없는 고철 덩어리와 같다.
다음은 정의하고, 조합하여 카드를 디자인하는 경우이다. 이 방법은 처음에는 어렵기 마련이다. 게임 시스템을 전체적으로 살펴보고, 카드 기능의 주체와 객체가 될 수 있는 요소들을 명시한 뒤에 이를 어떻게 다룰지에 대한 동작 또한 정의해야 한다. 머리가 아프고, 복잡한 과정이다. 그러나 이러한 밑 작업이 철저하게 진행되어, 규격이라는 틀이 만들어지면, 그 이후부터는 손 쉬워진다. 프로그래머들은 주체와 객체를 다루는 동작을 한 번 구현해 놓은 뒤 재사용하면 되고, 기획자들은 본인들의 의도대로 이를 조합하면 된다. 그렇기에 이는 곧 카드를 양산할 수 있는 기초가 된다.
요약하자면 어설프지만 빠르게 나아갈 것이냐, 느리지만 탄탄하게 나아갈 것이냐의 차이다.
그런데 이쯤되면 한 가지 의문이 든다.
빠르게 만들고 검증하는 페이퍼 프로토타입인데 이렇게까지 해야 되나?
정답은 '이렇게까지 할 필요 없다.'이다. 오히려 하면 안 된다. 페이퍼 프로토타입의 의의는 '빠르게 검증하는 것'에 있다. 나는 이를 신경 쓰지 않고, 규격에만 집착하며 과한 시간과 노력을 투입했다. 그리고 뒤에서 말하겠지만 이것 또한 페이퍼 프로토타입이 실패한 이유 중에 하나가 된다.
다만, 그럼에도 이렇게 예를 들어 설명하는 이유는 이때 설계해놓은 규격 자체가 실제 개발을 위한 데이터 테이블을 구성에 큰 도움이 됐기 때문이다.
장기적으로 봤을 때는 정답이지만, 단기적으로는 실패인 시도였다.
이야기가 샜는데, 정리하자면 '카드 디자인을 위해 카드 기능을 주체, 동작, 객체로 정의한 뒤 조합했다.'로 이해하면 좋을 것 같다.
간단하게만 예를 들어보자면, 주체와 객체가 될 수 있는 것은 체력, 칩, 행동력 등의 게임 내 인지 요소, 동작이 될 수 있는 것은 '피해를 준다.', '방어한다' 등의 인지 요소를 다루는 방식이다.
그리고 이렇게 구분한 것을 바탕으로 아래와 같이 조합한다고 해보자.
'주체 : 체력, 동작 : 받은 피해를 모아둔다, 객체 : 효과'
그럼 플레이어는 '받은 피해를 모아둔다.'는 동작을 통해 '인내'를 경험하고, '복수'라는 생각을 하게 된다. 이를 통해 '인내하고 복수한다.'는 컨셉이 만들어지는 것이다. 그리고 이에 적절한 이름을 붙여 '축적'이라는 효과를 만들 수도 있다.
이해를 위해 하나만 더 예를 들어보자. 아래와 같은 조합이 있다.
'주체 : 효과, 동작 : 소멸되지 않는다, 객체 : 카드'
위와 같은 효과가 있는 상태에서 노코스트, 고성능의 소멸 카드를 사용한다고 하면, 플레이어는 카드를 한 턴에 폭발적으로 사용할 수 있게 된다. 그럼 유저는 카드를 연속적으로 사용하는 동작에서 '호쾌함' 또는 '강함'이라는 인상을 받게 되고, 이렇게 게임에서 재미를 느끼게 된다. ('소멸되지 않는다.'는 동작이 아니라 특성 같지만.. 적당히 넘어가자 ㅋㅋ)
이런 식으로 유저가 카드를 통해 어떤 인상을 받을지 예측하고, 설계하기 위해 위와 같은 방식으로 디자인했다.
글은 이렇게 적어놨지만, 아직까지는 익숙하지 않아 어렵기에, 더 연구가 필요하다. 언젠가 머리 속에 잘 정리되면, 이 디자인 방식에 대한 글을 작성해 보겠다.
시너지의 구성
위에서처럼 카드를 디자인하는 과정에서 키워드도 함께 디자인했다. 키워드를 만든 데에는 여러 이유가 있지만, 가장 큰 이유는 덱 컨셉 사이의 연결 고리로써 기능하게 하기 위함이다. 나는 플레이어가 특정한 하나의 덱에 고정되어 그저 카드 모으기만을 반복하는 게임이 되는 걸 방지하고자 했다.
이런 부분의 긍정적인 예로 <Magic the Gathering>과 <Slay the Spire>등의 덱 빌딩 게임이 있다. 해당 게임의 카드 속에는 키워드가 존재한다. 이런 키워드들은 기능을 갖는데, 키워드 자체로 어떠한 컨셉을 갖고, 그 키워드들의 조합을 통해 원하는 컨셉을 빌드하는 형식으로 덱 빌딩 과정을 구성했다. 따라서, 특정 키워드의 카드가 하나의 덱에서만 쓰이지 않고, 응용하기에 따라 무궁무진한 덱 조합에 활용될 수 있게 만든다.
예를 들어 보자. <Slay the Spire>에는 '소멸'이라는 키워드가 있다. 해당 키워드의 카드는 같은 코스트의 카드에 비해 성능이 좋지만 사용 시 이번 턴동안 그 카드가 덱에서 소멸된다. 유저는 '소멸'이라는 키워드를 통해 '강하지만 미래가 없음.'이라는 인상을 받는다.
다음으로, '방어도'라는 키워드(효과)가 있다. 방어도는 해당 수치만큼 적의 피해를 막는다. 유저는 '방어도'라는 키워드를 통해 '안정적임.'이라는 인상을 받는다.
여기에 카드가 소멸될 때마다 방어도를 얻을 수 있는 카드가 있다면, 이 두 가지 키워드를 엮은 카드를 핵심으로 강하면서도 안정적인 덱 컨셉을 구성할 수 있는 것이다.
나는 이렇게 유저의 실력에 따라 게임 내 요소의 유기적인 연결을 통해 게임의 복잡성을 더할 수 있는 방식이 lenticular design의 핵심이라고 이해했고, 키워드를 통해 조합을 구성하며 카드의 가치를 높이는 방식으로 카드를 디자인했다.
테스트 용 덱 컨셉
이런 방식으로 아래와 같은 5가지의 컨셉 덱을 디자인할 수 있었다.
- 카드를 내는 행위의 재미를 강화한 콤보 덱
- 칩을 독점하고 생산력으로 밀어붙이는 자본 덱
- 상대의 덱에 상태 이상 카드를 넣어 방해하는 훼방 덱
- 초반에는 약하지만 점점 방어력이 올라가는 방어 덱
- 입은 피해를 상대에게 돌려주는 복수 덱
물리적 한계 극복을 위한 시도
이전 테스트에서는 물리적인 한계 극복을 위해 많은 시스템을 제외하고 일부만 테스트를 진행했으며, 그마저도 카톡을 통해 진행했다. 하지만 여전히 물리적인 한계를 극복하고, 가능한 모든 부분을 게임 내에서 처리하고 싶었기에, 몇 가지 아이디어를 추가했다.
첫 번째는 역할 능력 사용을 위해 카드 삭제 단계를 추가했다는 것이다.
2차 테스트에는 밤 턴 종료 이후에 카드 삭제 단계를 추가했는데, 이때 역할 카드를 삭제하면 해당 능력이 발동되는 형식으로 디자인했다. 카드 삭제 단계에서는 모두가 필수적으로 한 장의 카드를 버리게 설정했는데, 이는 2가지 상황에서 기인된 아이디어다.
먼저 카드 삭제에 대한 기획이 나와 있지 않아 덱 최적화를 할 수 없는 상황이었고, 다음으로는 역할 능력을 누가 언제 사용했는지 알 수 없게 설정해야 하는 상황이었다. 이런 상황에 카드 삭제 기능을 추가하면서 익명으로 역할 능력을 사용하게 만들기 위해 이와 같이 한데 엮어 처리하도록 디자인했다.
두 번째는 주사위를 적극적으로 사용했다는 것이다.
물리적인 공간에서는 익명이 요구되는 상황에 무언가를 지목하기가 힘들다. 예를 들어, 사보타지 같은 경우에 사보타지 할 지역을 선택해야 하는데, 이를 선택하는 건 '내가 곧 스캐빈저다.'라고 말하는 것이나 다름 없기에 익명을 필요로 한다. 하지만, 익명의 플레이어가 수 많은 지역 타일 중에 하나를 몰래 지목해 전달 한다는 건 불가능에 가깝다.
따라서, 이 부분은 전부 주사위를 통해 랜덤으로 처리했는데, 이 과정에서 5인 기준 플레이였기에 1의 가중치를 다른 대상에게 부여하는 방식으로 처리하여 밸런스를 잡았다. 예를 들어, 낮 턴이 끝날 때마다 사회자만 볼 수 있게 사보타지 주사위를 굴리고, 1에서 5가 나오면 해당 번호의 플레이어가 위치한 타일이, 6이 나오면 스캐빈저 플레이어가 위치한 타일이 사보타지 되도록 처리하여, 플레이어들이 스캐빈저의 정체에 대한 단서를 유추할 수 있게 설계했다.
이를 통해 게임이 진행될수록, 주사위의 시행 횟수가 많아지니 추리망은 점점 좁혀지게 된다. 여기에 역할 능력을 통한 추리까지 더해지니 스캐빈저 입장에서는 사보타지가 마냥 좋지만은 않게, 생존자 입장에서는 무조건 나쁘지만은 않게 설계하여 아슬아슬할 때 게임이 끝나도록 설계하고자 했다.
이런 주사위 활용을 사보타지 뿐 아니라 대상 지정이 필요한 역할 능력에도 사용함으로써 추리의 단서로 활용되도록 설계했다.
결과물
이렇게 디자인 한 프로토타입은 이전과 같이 그림을 그려주는 인공 지능 'Midjourney'를 활용하여 제작했다. 결과물은 아래와 같다. 위에 올린 것처럼 페이퍼 프로토타입 규칙 설명서 PPT도 만들고 나름대로 열심히 준비해서 아래처럼 잘 플레이했다.
테스트 후기
결론부터 말하자면 실패했다. 그것도 대차게 실패했다. 이유는 아래와 같다.
- 한꺼번에 너무 많은 것을 테스트하려고 했다.
욕심이 너무 과했다. 1차 테스트 때는 '낮 턴 탐색, 밤 턴 전투'라는 컨셉이 재미있는지 여부만 테스트하려 했다면, 이번에는 메인이 '덱 컨셉' 테스트였다지만 '캐릭터 능력 조합', '공격권', '역할 능력', '방랑 상인', '레서 스캐빈저' 등과 같은 부분을 포기하지 못해 조금씩 넣다 보니 게임 규칙 자체가 너무 복잡해지고, 어려워졌다.
무언가를 확실하게 하고 싶다면, 포기할 건 과감히 포기하는 법을 배워야 할 것 같다. - 직관적이지 않았다.
개인적으로 <Lost In Hope>의 타겟 유저층을 <Slay the Spire>와 같은 덱 빌딩 게임 경험 유저로 생각하고 있었다. 그래서 '소멸', '삭제'와 같은 용어를 사용했고, 이와 비슷한 분위기의 '무방비'와 같은 용어로 카드와 효과, 키워드를 정의했는데 이 용어 자체가 직관적이지 않다는 평을 많이 받았다.
사실 유저에게 유사 게임 플레이 경험이 있다는 걸 전제하고 디자인하면 안 됐는데 이 부분은 명백한 내 패인이다. 그리고 이 테스트를 통해 느낀 거지만 나는 말이나 글을 참 어렵게 적는 재주가 있는 것 같다. 결국 말과 글은 전달을 위한 것이니 수사적인 표현은 자제하고 최대한 직관적으로 작성할 필요가 있어 보인다.
위의 2가지 이유가 실패의 가장 큰 원인으로 짐작된다. 물론, 플레이 제한 시간이 1시간 30분에 불과했고, 인원도 갑작스레 4인으로 플레이하게 돼서 어느 정도 어긋난 것도 있지만, 이를 감안해도 위의 2가지 이유는 달라지지 않는다.
이 외에 아쉬운 점은 내가 사회자 역할이 미숙해서, 생각보다 복잡한 규칙에 지레 걱정했다는 것이다. 규칙 일부를 날림으로 처리하거나 생략했고, 이에 따라 게임 흐름 자체가 어딘가 어설퍼보이게 진행됐다.
이번 테스트를 돌이켜보면 재미를 검증하기 위해 프로토타입을 만들기보다는, 프로토타입을 만들기 위해서 재미를 검증한 느낌이 없지 않아 있어서 여러모로 반성하게 된다. 퀄리티를 높이는 건 좋지만, 이는 어디까지나 재미 검증을 위한 것이지 어떤 작품을 만들기 위함이 아니다.
그리고, 마지막으로 이번 글을 적으면서 느낀 점인데, 이번 글은 특히나 작성하기가 힘들었다. 글도 잘 안 써지고, 중간중간 말이 안 되는 것 같은 느낌을 계속 받았으며, 어딘가 꽉 막힌 느낌이 들었다. 아마도 2차 테스트 준비에 대한 내 생각 자체가 글로 표현할 만큼 정교하고 명확하지 않았기 때문이라고 생각되는데, 이런 상태에서 테스트를 준비했으니 이런 결과가 나온 것 같기도 하다.
이 부분은 <Lost In Hope>를 개발하는 동안 꾸준히 고민하고 정의해야 하는 부분이니만큼 어느 정도 정리되면 다시 다른 글로 작성해보려고 한다.
뼈 아프지만 내 어긋난 부분을 확인할 수 있는 경험이었다. 부족한 게임임에도 끝까지 플레이해 주고, 디지털로 구현하면 괜찮을 거라는 위로를 남겨준 팀원들에게 감사를 전하며 글을 마친다.
'프로젝트 > Lost in Hope' 카테고리의 다른 글
Lost In Hope - 05월 개발 일지 (2) | 2023.07.02 |
---|---|
Lost In Hope - 04월 개발 일지 (0) | 2023.05.18 |
Lost In Hope - 03월 개발 일지 (0) | 2023.05.11 |
Lost In Hope - 02월 개발 일지 (0) | 2023.03.13 |
Lost In Hope - 01월 개발 일지 (0) | 2023.02.12 |