게임 역기획서 작성법 2: 포맷 연산자·Condition·명시적 ID

1편에서는 캡처 자료를 표로 옮기고 Primary Key와 로컬라이즈 Key를 붙였다. 이번 글에서는 데이터에 박혀 있는 상수를 변수로 바꾸고 조건(Condition) 열의 역할을 다시 정의한 뒤, 개발자 코멘트와 명시적 ID로 표를 정리한다.

이 글의 핵심 요약

텍스트 속 숫자는 포맷 연산자(%d)와 변수로 바꾸면 행과 번역 비용이 줄어든다.
Condition 열은 플레이어용 문장, 실제 값, 개발자용 코멘트로 역할을 나눈다.
전역에서 쓰는 중복 Key는 따로 모으고 넘버링 ID는 이름만 봐도 뜻을 알 수 있는 명시적 ID로 바꾼다.

상수를 변수로

데이터가 상수로 들어가 있으면 그 데이터의 아주 일부만 바뀌게 되더라도 그것을 다른 데이터로 인식한다. 즉, 추가된 데이터의 개수만큼 행이 필요하게 된다.

붕괴 3rd 복귀 시스템 역기획 2편 – 상수를 변수로

위에서 보다시피, 상수에서는 숫자 1부터 5가 모두 상수 데이터로 들어가 있어서 상수의 수 만큼 행이 늘어났다. 반면 변수는 ‘n’이라고 하는 변수를 설정하고, 그 자리에 1이 오든 5가 오든 행은 1개만 필요하다. 변수로 지정하는 쪽이 훨씬 효율적이다.

보통 로컬라이즈에서는 위와 같은 상수 데이터가 많이 발생하는데, 따라서 불필요한 중복 번역이 많이 발생하게 된다. 그리고 이는 비용으로 이어진다. 따라서 상수와 변수 계획을 잘 세워둔다면 중복 데이터를 조금이라도 더 줄일 수 있다.

위 표는 1편에서 KEY 열을 추가하고 열 머리글을 수정한 ‘복귀 임무’ 데이터의 표다.

그런데 지금 보니, Condition_1 열에 입력한 데이터는 사실 플레이어에게 노출되는 텍스트다. 즉, 이렇게 입력을 해도 조건 데이터로써 기능할 수 없다. 플레이어가 보는 텍스트이기 때문에 Condition이 아니라 Text로 분류하는 게 맞다. 이런 요인이 계속 쌓이다보면 나중에 예기치 못한 데이터 오류를 초래하거나 커뮤니케이션 미스를 일으킬 수 있으니 이 부분부터 먼저 수정하도록 하자.

먼저 플레이어가 직접 눈으로 볼 수 있는 텍스트이기 때문에 텍스트로 빼도록 하자.

위에 첨부한 실제 게임 인게임 이미지를 확인해보면,

하얀색 텍스트: 제목 부분
회색 텍스트: 본문 부분
노란색 텍스트 : 변수(Parameter) 부분

여기서 하얀색 텍스트외 회색 텍스트는 고정되어 있고, 노란색 텍스트는 수치가 1000, 2000, 3000, 4000 등으로 바뀌고 있다.

따라서 하얀색 텍스트와 회색 텍스트는 로컬라이즈로 따로 관리하도록 한다.

그렇다면 저 변수에 해당하는 노란색 텍스트는 엑셀에 어떻게 기입하면 될까?

변수값을 포맷연산자로 표기

변수는 값이 계속 변하기 때문에 숫자 1, 2 등을 입력해둘 수 없다. 이럴 땐 값을 입력하는 자리에 ‘변수가 들어간다’고 알리기 위한 포맷연산자를 입력하면 된다.

포맷연산자(format specifier)란, 원하는 위치에 출력할 데이터 유형(자료형)을 정의하는 연산자를 말한다.
예를 들어, ‘3등’, ‘4등’, ‘5등’처럼 숫자 3,4,5가 입력된 자리의 값만 바뀌는 데이터가 있다고 한다면, 이 숫자가 있는 자리에 포맷연산자 ‘%d’를 입력한다.(파이썬 기준) 그리고 %d에 들어가는 값을 따로 변수처럼 관리하면 된다.

그렇다면 위의 텍스트를 포맷연산자 표기를 반영하여 수정하면 아래처럼 변경될 것이다.

숫자가 있던 자리에 포맷연산자 ‘%d’가 들어가게 되었다. 그렇다면 이 %d에 숫자를 어떻게 넣을까? 이 값은 Condition 열에 입력한 값을 불러오는 구조로 만들어보도록 하자.

Condition 설정

Condition은 사용자의 눈에 보이지 않는다. 사용자가 볼 수 있는 건 조건이 쓰여진 ‘텍스트’일 뿐이다.

가위바위보를 생각해보자. 가위는 보를 이기고, 보는 바위를 이기고, 바위는 가위를 이긴다. 이게 바로 가위바위보 게임의 룰이다. 그런데 이 ‘룰’은 눈에 보이는 게 아니다. 우리 모두가 암묵적으로 알고 있는 규칙이다. 조건도 이러한 가위바위보 룰처럼 눈에 보이지 않는 규칙 같은 것이다.

‘기억 전장에서 누적 %d점 획득’이라는 조건을 보자.

여기서 중요한 건 이 조건이 행해지는 콘텐츠의 이름인 ‘기억 전장’, 그리고 이 콘텐츠에서 달성할 수 있는 지표에 해당하는 누적 ‘%d’점 획득이다. 간단하게 정리하자면, 어떤 ‘콘텐츠’에서 어떤 ‘조건’을 달성하라는 말이다. 이것을 Condition에 적어주도록 하자.

여기에서 생각해보자.

Condition_1에 입력한 값을 보면, ‘월정액 가입’, ‘BP 경험치 달성’, ‘초끈 공간 특정 스테이지 완료’ 등이 입력된 것을 확인할 수 있다.

그런데 이러한 값은 실제 게임 내부에 어떤 개발명 및 ID로 들어가 있는지 알 수 있는 방법이 없다.

또한, 저 조건식(Condition_1)을 게임 내에서 실제로 불러오지 않는다. 실제 조건은 콘텐츠 내부에 포함되어 구동될 것이다.

예를 들어 ‘초끈 공간’이라는 콘텐츠가 있다면, 그 콘텐츠 내부에 있는 함수 및 데이터를 위의 복귀 시스템에서 ‘참조’하는 구조는 가능할 것이다.

따라서 위 표에 구체적인 함수 및 데이터의 값 기입은 무의미하다.

하지만 우리가 위의 값을 적는 이유가 뭘까. 그건 바로 위 문서가 ‘기획서’이기 때문이다. 협업 부서 개발자에게 내가 원하는 ‘니즈’를 전달하는 것도 중요하다.

따라서 위의 Condition_1에 기입한 텍스트는, 프로그래머(개발자)에게 디자이너(기획자)가 원하는 조건을 기입한 협업용 텍스트 열이라고 정의하도록 하자. 나는 이러한 개발자용 열에는 _dev_라는 문자열을 붙이겠다.

정작 프로그래머에게 중요한 건, 해당 조건의 ‘수치(Value)’이다. 따라서 이 값은 콘텐츠 등에서 불러올 수 있도록 위 기획서에 적어주는 게 중요하다.

쉽게 말해, 여기서 적어주는 건 메이플스토리에서 “‘주황버섯’을 ‘999’마리 잡기”퀘스트의, ‘주황버섯’과 ‘999’에 해당하는 데이터다.

따라서 저 Condition_1은 개발자용 텍스트로 분류하고, 실제로 중요한 ‘수치’ 데이터를 기입하는 열을 우측에 빼두도록 하자.

그렇게 정리한 표는 아래와 같다.

다른 표의 값들도 이번 글에서 진행한 규칙에 따라 정리하도록 하자.

여기까지가 변수와 조건 정리다. 데이터가 꽤 정리됐으니 이제 참조 구조를 준비하면서 ID를 손볼 차례다.

개발자 코멘트 추가

이제 데이터의 정리가 많이 진행되었으니, 슬슬 데이터 구조를 참조 구조로 변경하려고 한다.

그런데 참조 구조로 변경하게 되면, 현재 표 안에 입력된 데이터가 정확히 어떤 데이터였는지 알기가 어려워진다.

따라서 개발자 코멘트를 추가하여 추후 이 데이터가 어떤 데이터였는지 더 알기 쉽도록 표기를 추가해보았다.

그러면 현재까지 진행된 테이블 업데이트 내역은 아래와 같다.

중복 Key 제거

정리된 내용을 쭉 훑어보니, 일부 중복된 값이 보인다.

예를 들어, ‘복귀 출석’ 페이지에서 사용하는 ‘남은 기간: %d일 %d시’는, 복귀 임무, 보너스 상점 등에서도 똑같이 사용하고 있다. 즉, 이 키는 복귀 페이지 전역에서 사용하고 있으니 특정 세부 항목 페이지로 키를 두는 건 비효율적이다. (중복값이 발생하므로)

데이터를 관리하다보면 중복값은 계속 발생한다. 이는 어쩔 수 없다. 하지만 중복값을 계속 방치하게 된다면 예상치 못한 여러 가지 문제가 발생한다.

엑셀, 스프레드 시트를 불러오는 데 걸리는 시간이 늘어나는 문제
키가 서로 충돌하거나 호환되지 않는 문제
프로그램에서 버그를 일으키는 문제
중복값을 모두 번역 또는 확인해야 하므로 비용(시간, 금전)이 증가하는 문제
그 외 예기치못한 문제

나는 중복값을 통해 위의 문제를 경험한 바 있다. 따라서 중복값이 있을 수밖에 없다는 사실은 인정하되, 최대한 구조적으로 중복값을 예방하는 것이 중요하다고 생각한다.

따라서 전역적으로 사용하는 키는 별도로 표를 만들어서 관리하도록 하고, 기존에 각 세부 항목에 들어간 키는 삭제하도록 하자.

기존의 LocalizeKey_Return_Attendance_01에 해당하던 ‘복귀 출석 남은 기간’을 복귀 시스템 전역 테이블로 옮기고, 기존 키를 삭제했다.

그리고 나머지 키의 값이 02, 03, 04이므로, 01부터 다시 부여하였다.

원래 Key값은 한 번 부여하면 웬만해서는 수정이 어렵다. 참조 구조가 깨지기 때문이다. 하지만 지금은 아직 참조 구조로 연결하기 전이라서 ID도 바꿀 수 있는 상황이다. 따라서 참조 구조가 되기 전에서나 이런 변경이 수월하다는 점에 유의하도록 하자. (이미 참조식이 짜인 경우 수정하는 건 불가능한 건 아니나 복잡하고 버그가 일어나기 매우 쉽다.)