[📜일지] <콩쥐스 크런치 타임> 기획 회고록 #01

[익명(125.129)]

이전 글 #00

안녕하세요, 프로그래밍 퍼즐 게임 <콩쥐스 크런치 타임>을 만드는 ㈜조이풀조에서 레벨 디자인을 맡은 김기획(가명)입니다.

버닝 비버에서의 재미있는 시간이 지나가고, 다시 ‘크런치 타임’이 다가옵니다.

지난 BIC와 BIGS에서는 동일한 버전을 제출했었는데, 이번에는 챕터 사이사이에 스테이지가 추가되고 레벨 난이도 곡선이 조정된 버전을 전시하기 때문에… 두 버전을 모두 플레이해주신 분들은 양쪽의 레벨 디자인의 차이가 있다는 사실을 깨달으실 수 있을 것 같습니다.

하여튼, 이번 글은 레벨의 난이도 조정과 관련된 이야기입니다.

퍼즐 기획을 하며 가장 크게 생각하는 것은 플레이테스트의 양과 질이다.

내부적으로 진행하는 테스트는 아무래도 한계가 있고, 특히나 매 레벨에서 플레이어가 도전하는 것처럼 느끼는 우리 <콩쥐스 크런치 타임>같은 경우는 더욱 그랬다.

그래, 분명 잘 알고 있었는데...

한 가지 간과한 점이 있었다면, 나는 내 지인들에게 이 게임의 플레이테스트를 부탁했었고 그 지인들이란 곧 프로그래밍 경험이 있거나, 적어도 논리 알고리즘이 어떻게 돌아가는지에 대한 지식이 있는 사람들이었다는 것이다.

초기 버전은 튜토리얼도 부족했고, 시각적으로 친절하지도 않았으며, 하나하나 질문과 답을 주고받으면 퍼즐에 대한 힌트를 줄까봐 일반 유저들에게 테스트를 맡기는 건 조금 불안했어서.

테스트 대상 타겟을 잘못 고른 대가는 이후 BIC에서 우리 게임이 첫 공개 전시를 가질 때에 가서야 치르게 된다.

<한 플레이테스터의 회고록...talk>

온오프라인 전시를 거치며 가장 많이 들었던 이야기는 "레벨 설명이 잘 이해가 안 돼요!" 였다. 가끔씩은 "내용이 잘 안 들어와요" "의미를 모르겠어요" 등등의 배리에이션 형태를 가졌지만, 결국 기획자에게 다가오는 피드백은 하나의 형태였다. (아무 말 없이 고민하지만 이해를 못했음이 확실한 상황도 포함된다.)

"과제 설명이 잘못되었어요."

음, 그 말에 대해서는 나도 할 말이 있다.

<Human Resource Machine의 한 레벨 설명>

우리는 내심 저것보다 낫다고 생각하고 있었거든!!! (물론 Human Resource Machine이 매 번 저러는 건 아니다. 우리가 더 잘난 것도 아니다. 악의적인 편집이다.)

변명거리도 못되겠지만, 라이트 유저가 메인 타겟이니 글은 압축해야 하는데, 정보의 정확함을 살린다는 허들까지 넘으려 하다가 되려 정보는 부족하고 글은 어줍잖아지는 이도저도 못되는 현상이 있었다.

글이 어줍잖게 길고, 정보도 부족해서 명료함이 부족한 글이 있는 것은 곧, 게임의 불편함과 난이도의 상승으로 직결됐다.

플레이어들이 느끼는 체감 난이도가 최초의 기획 의도보다 훨씬 높았다.

왜 이런 현상이 발생했을까? 정말 다른 게임들처럼, 그토록 의식하고 배제하려고 노력했는데도 개발자가 고인물이 되어서 난이도에 무덤덤해졌던 것일까?

한 줄로 요약하자면, 일지 #00에서 얘기했던 '플레이어는 가장 먼저 떠오르는 아이디어를 시도한다'를 얼마나 쉽게 유도할 것인지의 문제였다. (유튜브, Game Maker's Toolkit의 'What Makes a Good Puzzle?')

시도를 해야 오류를 찾고, 오류를 고쳐야 퍼즐도 풀 수 있다.

따라서 문제의 난이도를 낮추려면, 실제 해법의 난이도 말고도 플레이어가 거치는 시행착오의 과정을 잘 유도해야 했다.

<콩쥐스 크런치 타임>은, 퍼즐이 비주얼라이즈 되어있는 기타 퍼즐 게임들과 다르게 문장형으로 퍼즐의 풀이를 요구하다보니, 과제 칸 안의 모든 글자를 읽지 않는 이상 플레이어는 무엇을 해야할 지 그 첫그림조차 그리지 못하는 경우가 발생하기 쉬웠다.

아니, 그러면 이 문제는 프로그래밍 퍼즐이라는 장르 자체의 문제 아닌가요?

어떻게 해결해야 하죠?

그야 당연히, 비주얼라이즈 해야지!

프로그래밍 퍼즐도 비주얼라이즈를 통해 문제를 전달할 수 있다는 사실을 깨달은 건 플레이테스트를 제법 돌리고 난 이후의 일이었다.

이번 회고록의 주인공, 1-5 레벨을 만나보자.

1챕터의 마지막을 장식하는 1-5 레벨은 '루프 안의 루프'라는 게임 내 핵심 응용 메커니즘을 소개하는 동시에, 유저 스스로 이 메커니즘을 발견해야 하는 첫 '숨이 턱' 레벨로 난이도가 급상승한 느낌을 받는 레벨로 기획되었다.

이전 일지에서 언급했듯 이 '숨이 턱' 레벨들은 실제로 어려워선 안 됐는데, 문제는 이 레벨은 실제로 어려웠다는 사실이다.

시간을 조금 거슬러 올라가 2023년 8월 초, 그 이전까지의 1-5 레벨의 레이아웃은 다음과 같았다.

<출처: BIC 유튜브 채널 '내는 존 인디 JON-N-INDIE'>

해당 레벨이 요구하는 정답 코드는 초기 구상안부터 한 번도 바뀐 적이 없지만, 당시의 레벨은 플레이어가 무슨 일을 해야하는 지 알아차리기조차 어려웠다.

중앙의 [4] 크기의 저장공간을 이용해서, 앞 4개의 큐브를 5번째의 큐브 뒤로 밀어내는 순서 조작 형태의 퍼즐이었는데... 플레이어가 글을 읽고 '아하 그러면 내가 뭘 해야겠다.' 라는 생각이 전혀 들지 않았다.

우리가 발견한 문제는 두 종류였다. 아니, 한 종류의 문제가 두 개 있다고 볼 수도 있겠다.

첫 번째는 커다란 루프 안에서 처리되는 그룹이 추상적이었다는 것.

들어오는 큐브를 다섯 개씩 묶으라는 것부터 플레이어에게 추상적인 사고를 요하고 있었고, 대부분 일반 플레이어들은 이런 형태의 사고방식에 익숙해 있지 않았다. 후반 스테이지라면 몰라도, 1챕터인데 벌써부터 이러면 안 된다는 신호는 명확했다.

두 번째는 큐브의 특정이 추상적이었다는 것.

5개씩 묶은 추상적인 그룹 안에서도 '가장 뒤'라는 한 차례 더 추상적인 특정까지 더해지면서 플레이어에게 현재의 레벨 레이아웃이 다소 무가치하게 느껴지게 만드는 현상까지 있었다.

이렇게 만들었던 이유는, 무작위로 구성된 입력에 로직으로 대응하라고 준 것이었는데...

지나치게 추상적인 문제 구성은 플레이어에게서 직관을 앗아갔고, 여느 퍼즐 게임에서나 작동하는 '플레이어는 가장 먼저 떠오르는 아이디어를 시도한다'는 행동의 시점을 늦추거나 문제 해결 실패까지 이어져 레벨의 난이도를 상승시켰다.

그래서 우리가 찾은 답은, 추상적인 게 문제라면 되려 피상적으로 만들면 해결되지 않겠냐는 것이었다. (정확히는 이건 우리 팀장님 아이디어였다. 모든 게 잘 작동하니까 이제와서 마치 내가 잘한 것처럼 적고 있지만.)

'5개짜리 큐브의 그룹'은 이후 레벨에서 등장하는 그룹들과 똑같은 방식으로 연속되는 같은 색 큐브들을 하나의 그룹으로 취급했다.

그리고, '그룹 내의 위치'는 큐브의 숫자를 사용해서 표시해주었다.

큐브의 색깔도, 숫자도 이후 챕터에서 활용하는 개념으로 1챕터에선 전혀 사용하지 않았고, 그저 큐브의 순서가 섞였는지 체크하는 용도로만 무작위로 부여해주던 값이었는데, 오히려 적절하게 사용하자 초반의 레벨 커브 구성에 커다란 이점을 가져갈 수 있었다.

결국 프로그래밍이라는 컨셉트와 별개로, 이 게임의 정체성이 퍼즐 게임인 이상 퍼즐 게임의 문법에 따르는 것이 최선이라고 느끼는 가장 큰 계기가 된 일이었다.

어쨌거나 <콩쥐스 크런치 타임>은 기존 프로그래밍 언어에 기반을 하지 않고있고, 코드 라이브러리를 통상적인 프로그래밍 교육 순서에 맞춰 제공하는 게임도 아니니까.

다만 오직, 재미있는 퍼즐을 만들기 위해 레벨 디자인을 한 땀 한 땀 깎을 뿐이다.

<우리들 선정 훈수하기 최적화된 게임 '콩쥐스 크런치 타임'>

버닝 비버 오프라인 일정이 끝나자마자 몸살이 닥쳤습니다.

책상 앞에서 코딩하는 대신 누워서 회고록을 적으니 몸도 따뜻하고 편안해진 것 같습니다.

전시자분들도, 관람객 분들도, 현장에 못 오신 분들도 모두 건강 조심하세요.

<콩쥐스 크런치 타임>은 버닝 비버 온라인 전시관에서 12월 10일까지 만나보실 수 있습니다. 많은 관심 부탁드려요!

온라인 전시관 바로가기

텀블벅 페이지 바로가기

[team_candle(teamcandle)]

콩쥐야 크런치... 해야겠지?

[카퍠인(happys96)]

[익명(4o6dlasyxrkx)]

진짜 고생 많으셨어요