rejin 아바타

서브컬처 게이머

세상의 모든 아름다운 것들을 위하여

image 177

[붕괴 3rd] 복귀 시스템 역기획서 작성 – Step 6

저번 글에서는 아래의 작업을 추가로 진행하였다.

  • 로컬라이즈 열 생성
  • 로컬라이즈 데이터 분리

오늘은 아이템 테이블에 로컬라이즈 열을 추가하고, 기존의 Data Table 내 아이템 이름을 아이템 Key로 변경하도록 하겠다.


지금까지의 데이터 최신화를 진행한 결과, 현재의 ‘보너스 상점’ 페이지의 표는 아래와 같다.

image 173

Item_Name, Currency_Type 열에 적혀있는 값이 현재 플레이어에게 노출되는 Text임을 확인할 수 있다.

앞서 이전 글에서 로컬라이즈 테이블을 분리하는 과정을 거쳤는데, 이 아이템 이름 또한 각 권역별로 서비스 된다면 로컬라이즈 적용이 필요할 것이다.

그렇다면 앞서 다른 글에서 진행했던 것처럼, 위 표에도 마찬가지로 아이템 이름의 로컬라이즈 열을 만들어서 관리하는 게 좋을까?

아이템 테이블 로컬라이즈 열 추가

image 174

위는 ‘복귀 출석 Table’을 가져온 것이다. 이때 Key 열의 값과 LocalizeKey의 값은 일정한 규칙에 따라 서로 대응하며 순차적으로 ID가 부여되고 있음을 알 수 있다.

여기서 잠깐 생각해보자.

지금까지 우리는 붕괴3rd의 ‘복귀 시스템’의 역기획서를 차례대로 작성해 오고 있었다. 복귀 시스템에 관해 Key를 부여하는 것이므로 ‘복귀 출석’, ‘복귀 상점’ 등의 용어가 등장한다. 따라서 복귀 시스템 전반에서 사용하는 Key값이 Return_으로 시작하는 것은 자연스럽다.

하지만 아이템은 ‘복귀 시스템’뿐만 아니라, 모든 붕괴3rd의 콘텐츠에서 전역적으로 사용된다. 복귀 시스템 내에서만 사용되는 아이템이 있을 수도 있겠지만, 그런 경우는 아주 한정적일 것이다. 일반적으로 시스템과 아이템은 서로 독립이다.

따라서 아이템의 로컬라이즈 키는 복귀 시스템 테이블이 아니라 다른 별도의 테이블에서 관리하는 게 자연스럽다.

아이템명의 로컬라이즈 열은 위의 Data Table이 아닌, 저번 시간에 별도로 빼놓은 Item 테이블에서 관리하도록 하자.

image 175

앞서 ‘Step 4’에서 우리는 명시적 데이터 부여를 진행하며 Item 테이블을 별도의 영역으로 분리한 바 있다. 로컬라이즈 열은 이곳에 추가하겠다.

image 176

위처럼 녹색 열을 새로 추가하고, LocalizeKey의 데이터는 좌측의 Key의 값에 ‘Localize_’의 접두사를 붙여 ID를 부여하였다.

그런데 이렇게 ID를 부여하고 나니 Key열, 그리고 LocalizeKey열 안에 있는 값이 지나치게 길고 서로 중복되는 텍스트가 많다는 점을 알 수 있다.

LocalizeKey는 Key열에서 ‘Localize_’ 접두어만 붙었을 뿐, 오름차순/내림차순 정렬마저 같다.

따라서, Key가 굳이 지금처럼 복잡한 이름 구조를 가질 필요가 없다.

ID는 길면 길수록 입력하거나 관리하기가 까다롭다. 아직 Item Table과 Data Table이 서로 참조 구조로 적용되기 전이니, Item의 Key 규칙을 지금 변경해보도록 하자.

아이템 Key의 대역폭 설정

아이템의 Key를 더 간단한 규칙으로 변경하려고 마음을 먹었지만, 실제로는 어떻게 구성하는 게 ‘간단’한 규칙이 될까?

image 177

인간의 뇌는 분류에 익숙하다. 모양이나 패턴이 같은 것끼리 나란히 있는 것에 ‘공통된 느낌’을 갖게 된다.

이를 ‘유사성의 법칙(Gestalt-Similarity)’이라고 한다.

Item Table에서 Item_Type이라고 하는 열에 주목하자. 이 열은 아이템의 사용 방식에 관해 분류하기 위해 추가한 열이다.

나는 이 열 안에 있는 공통된 항목끼리 같은 ID ‘대역폭’을 공유하도록 Key를 설정하도록 하겠다.

예를 들어, Consumption 유형의 ‘Ancient_Tradition’ 아이템은 Item_01로, Consumption 유형의 Ancient_Will’은 Item_02로 분류하는 식이다.

반면, Direct Use 유형의 ‘Portion_Hp’는 Item_100으로 분류한다면, 위처럼 두 자리수를 가진 아이템과 서로 구분될 것이다.

왜 여기서 갑자기 자리수를 바꾸었을까? 그것은 ‘자리수’를 기준으로 공통점을 분류하는 것이 우리의 직관이 이해하기 편리하기 때문이다.

위처럼 Key를 부여하기로 약속한다면, 우리는 자리수만 보고도 이 아이템의 유형을 바로 알 수 있다. (예: Item_399라면, 자리수가 3개니 Direct Use 타입이구나!)

Key는 서로 중복이 아닌 것도 중요하지만, 아이템명을 분류하는 기준으로써도 중요하다.

따라서 ID 대역폭을 이렇게 구성한다면 추후 ID만 보고도 그 아이템의 대략적인 쓰임새를 유추할 수도 있다.

하지만 나는 ID의 자릿수를 가지고 대역폭을 설정하지 않겠다.

나는 실무에서 ID의 자릿수를 가지고 대역폭을 구성한 테이블을 경험해보았고, 그 데이터가 완전히 꼬여 버린 것도 보았다.

그때 겪었던 그 어처구니없는 데이터 구조를 보고 나서, 다시는 자릿수를 기반으로 대역폭을 설정하지 않기로 다짐했다.

그런 참사가 벌어진 이유는 어처구니없게도, 엑셀의 ‘정렬’에 있었다.

ID를 정렬할 때, 우리의 직관은 ‘1, 2, 3, …, 10, … 201, …, 10100’ 순으로 숫자가 오름차순으로 커지는 것에 익숙하다.

하지만 엑셀에서는 접두사가 붙은 데이터 등을 정렬할 때 (예를 들어 접두사 a), 이러한 직관과 거스르는 방식으로 정렬한다.

가령, ‘a1, a10, a10100, a2, a202, a3, …’ 순으로 정렬되는 식이다.

그 이유는 엑셀에서 숫자와 텍스트 데이터가 혼용되는 순간, 그 데이터 내의 숫자마저 ‘텍스트 데이터’로 분류되기 때문이다.

그 결과 숫자의 정렬 기준은 숫자의 크기순(1 다음에 2, 2 다음에 3)이 아니라 숫자의 앞자리(1 다음에 10, 10 다음에 2)가 된다.

따라서 ID의 자릿수를 가지고 대역폭을 설정하게 되면, 나중에 데이터를 정렬할 때 저런 ID 꼬임 문제를 반드시 겪게 된다.

스스로가 저런 일을 벌이지 않을 것이라고 과신하면 안 된다. 테이블을 같이 쓰는 협업 파트너가 정렬 기능을 사용할 수도 있는 거고, 결국 테이블은 망가지게 되어 있다.

저런 사태가 이미 벌어진 뒤엔 정렬 기능을 아예 포기하거나 수동으로 정리해주는 수밖에 없다.

어쨌든, 나는 대역폭이 아니라 데이터 유형이라고 하는 ‘카테고리’ 별 간단한 접두사를 활용해 ID를 부여하고자 한다. 그 규칙은 아래와 같다.

아이템 Key 대역폭 정의

  • AutoGet: Item_0_01~
  • Choice: Item_1_01~
  • Consumption: Item_2_01~
  • Direct Use: Item_3_01~
  • Piece: Item_p_00(캐릭터 코드;캐릭터 개발명 순서 오름차순)

보다시피, Item 뒤에 _숫자_를 넣음으로써, 위의 정렬 문제를 해결하였다.

또한 별도의 자릿수 대역폭을 설정하지 않음으로써, 특정 아이템 개수의 오버플로우를 고려하지 않아도 되게 되었다.

오직 유의해야하는 것은 아이템 타입 개수가 오버플로우 되는가의 여부이다.

아이템 타입은 쉽게 늘어나지 않기 때문에 오버플로우를 걱정할 필요 없다. (만약 늘어난다고 해도 아주 가끔일 것이며, 그때 가서 문제를 해결해도 늦지 않다.)

이러한 기준으로 아이템 Key를 재부여하면 아래와 같다.

image 178

이렇게 해서 아이템 테이블의 Key값을 간소화하는 데까지 진행하였다.

image 180

한편, Item 테이블과 친척 관계쯤에 해당하는 Currency도 로컬라이즈를 진행해야 한다.

그런데 Currency 타입은 별도의 타입이 없다. (이것은 관점에 따라 다른데, 유료 재화/무료 재화 등으로 분리할 수도 있다. 하지만 나는 그런 분류는 하지 않겠다.)

따라서 이 경우는 Key의 길이가 길지도 않고 타입도 없으므로 이대로 Key값을 유지하겠다.

무슨 소리냐고? Currency 테이블에 한해서는, 이 Key값을 로컬라이즈 Key로도 사용하겠다는 의미이다. 왜냐하면 로컬라이즈 테이블 내에 Currency 값과 오인하거나 중복값이 없을 것이기 때문이다.

이런 식으로 그 테이블의 성격에 따라서 Key값이 로컬라이즈 Key값이 될 수도 있음을 유념하도록 하자.

단, 이런 경우를 남용하면 나중에 데이터 충돌이 일어날 가능성이 커지며, 협업 파트너 입장에서도 예외 규칙이 헷갈릴 수 있으므로 이러한 결정은 신중하게 내려야 한다.

image 181

겸사겸사 Category 테이블의 값도 예외적으로 로컬라이즈 열 추가 없이, 곧바로 로컬라이즈 테이블에 등록하겠다.

image 182

대신 아래와 같이 비고 란에 Key = LocalizeKey라는 점을 기록해두도록 하자.

image 183

아이템 이름 -> ID로 변경

데이터 관리를 위해서는 유저에게 노출되는 텍스트보다는 ID로 관리하는 편이 수월하다.

따라서 지금까지 Data Table에 남아 있는 아이템명도 모두 ID로 변경하도록 하자.

Xlookup함수를 사용하면 비교적 간단하게 일괄 수정할 수 있다. (단, 현재 엑셀 버전이 office365가 지원되어야 한다.)

이렇게 아이템 이름까지 ID로 변경을 마치면, 비로소 테이블 내에 개발자 코멘트를 제외한 유저 노출 텍스트가 사라지게 되는 것이다.

image 184