3편에서는 로컬라이즈 열을 만들고 로컬라이즈 데이터를 별도의 테이블로 분리했다. 이번 글에서는 아이템 테이블에 로컬라이즈 열을 더하고 아이템 Key 규칙을 정한 뒤, 엑셀의 표·관계·데이터 모델 기능으로 테이블을 실제 참조 구조로 연결한다. 시리즈에서 데이터 작업을 마무리하는 편이다.
이 글의 핵심 요약
- 아이템은 특정 시스템이 아니라 게임 전체에서 쓰이므로 로컬라이즈 열도 Item 테이블에서 관리한다.
- 자릿수로 ID 대역폭을 나누면 엑셀 정렬에서 ID가 꼬인다. 카테고리 접두사(Item_0_01 등)로 나누는 편이 안전하다.
- 엑셀의 표 만들기, 관계, 데이터 모델 다이어그램만으로도 참조 구조를 만들고 협업 상대에게 보여 줄 수 있다.
아이템 이름도 로컬라이즈가 필요할까
지금까지의 데이터 최신화를 진행한 결과, 현재의 ‘보너스 상점’ 페이지의 표는 아래와 같다.
Item_Name, Currency_Type 열에 적혀있는 값이 현재 플레이어에게 노출되는 Text임을 확인할 수 있다.
3편에서 로컬라이즈 테이블을 분리했는데, 아이템 이름도 여러 권역에 서비스한다면 로컬라이즈가 필요하다.
그렇다면 3편에서 한 것처럼 위 표에도 마찬가지로 아이템 이름의 로컬라이즈 열을 만들어서 관리하는 게 좋을까?
아이템 테이블 로컬라이즈 열 추가
위는 ‘복귀 출석 Table’을 가져온 것이다. 이때 Key 열의 값과 LocalizeKey의 값은 일정한 규칙에 따라 서로 대응하며 순차적으로 ID가 부여되고 있음을 알 수 있다.
여기서 잠깐 생각해보자.
지금까지 우리는 붕괴3rd의 ‘복귀 시스템’의 역기획서를 차례대로 작성해 오고 있었다. 복귀 시스템에 관해 Key를 부여하는 것이므로 ‘복귀 출석’, ‘복귀 상점’ 등의 용어가 등장한다. 따라서 복귀 시스템 전반에서 사용하는 Key값이 Return_으로 시작하는 것은 자연스럽다.
하지만 아이템은 ‘복귀 시스템’뿐만 아니라, 모든 붕괴3rd의 콘텐츠에서 전역적으로 사용된다. 복귀 시스템 내에서만 사용되는 아이템이 있을 수도 있겠지만, 그런 경우는 아주 한정적일 것이다. 일반적으로 시스템과 아이템은 서로 독립이다.
따라서 아이템의 로컬라이즈 키는 복귀 시스템 테이블이 아니라 다른 별도의 테이블에서 관리하는 게 자연스럽다.
아이템명의 로컬라이즈 열은 위의 Data Table이 아닌, 2편에서 별도로 빼놓은 Item 테이블에서 관리하도록 하자.
앞서 2편에서 우리는 명시적 데이터 부여를 진행하며 Item 테이블을 별도의 영역으로 분리한 바 있다. 로컬라이즈 열은 이곳에 추가하겠다.
위처럼 녹색 열을 새로 추가하고, LocalizeKey의 데이터는 좌측의 Key의 값에 ‘Localize_’의 접두사를 붙여 ID를 부여하였다.
그런데 이렇게 ID를 부여하고 나니 Key열, 그리고 LocalizeKey열 안에 있는 값이 지나치게 길고 서로 중복되는 텍스트가 많다는 점을 알 수 있다.
LocalizeKey는 Key열에서 ‘Localize_’ 접두어만 붙었을 뿐, 오름차순/내림차순 정렬마저 같다.
따라서, Key가 굳이 지금처럼 복잡한 이름 구조를 가질 필요가 없다.
ID는 길면 길수록 입력하거나 관리하기가 까다롭다. 아직 Item Table과 Data Table이 서로 참조 구조로 적용되기 전이니, Item의 Key 규칙을 지금 변경해보도록 하자.
아이템 Key의 대역폭 설정
아이템의 Key를 더 간단한 규칙으로 변경하려고 마음을 먹었지만, 실제로는 어떻게 구성하는 게 ‘간단’한 규칙이 될까?
인간의 뇌는 분류에 익숙하다. 모양이나 패턴이 같은 것끼리 나란히 있는 것에 ‘공통된 느낌’을 갖게 된다.
이를 ‘유사성의 법칙(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를 재부여하면 아래와 같다.
이렇게 해서 아이템 테이블의 Key값을 간소화하는 데까지 진행하였다.
한편, Item 테이블과 친척 관계쯤에 해당하는 Currency도 로컬라이즈를 진행해야 한다.
그런데 Currency 타입은 별도의 타입이 없다. (이것은 관점에 따라 다른데, 유료 재화/무료 재화 등으로 분리할 수도 있다. 하지만 나는 그런 분류는 하지 않겠다.)
따라서 이 경우는 Key의 길이가 길지도 않고 타입도 없으므로 이대로 Key값을 유지하겠다.
무슨 소리냐고? Currency 테이블에 한해서는, 이 Key값을 로컬라이즈 Key로도 사용하겠다는 의미이다. 왜냐하면 로컬라이즈 테이블 내에 Currency 값과 오인하거나 중복값이 없을 것이기 때문이다.
이런 식으로 그 테이블의 성격에 따라서 Key값이 로컬라이즈 Key값이 될 수도 있음을 유념하도록 하자.
단, 이런 경우를 남용하면 나중에 데이터 충돌이 일어날 가능성이 커지며, 협업 파트너 입장에서도 예외 규칙이 헷갈릴 수 있으므로 이러한 결정은 신중하게 내려야 한다.
겸사겸사 Category 테이블의 값도 예외적으로 로컬라이즈 열 추가 없이, 곧바로 로컬라이즈 테이블에 등록하겠다.
대신 아래와 같이 비고 란에 Key = LocalizeKey라는 점을 기록해두도록 하자.
아이템 이름 -> ID로 변경
데이터 관리를 위해서는 유저에게 노출되는 텍스트보다는 ID로 관리하는 편이 수월하다.
따라서 지금까지 Data Table에 남아 있는 아이템명도 모두 ID로 변경하도록 하자.
XLOOKUP 함수를 쓰면 비교적 간단하게 일괄 수정할 수 있다. (XLOOKUP은 Microsoft 365와 Excel 2021 이상에서 쓸 수 있다. 그보다 낮은 버전이라면 VLOOKUP이나 INDEX/MATCH를 쓰면 된다.)
이렇게 아이템 이름까지 ID로 변경을 마치면, 비로소 테이블 내에 개발자 코멘트를 제외한 유저 노출 텍스트가 사라지게 되는 것이다.
이제 Data Table 안에는 개발자 코멘트를 빼면 플레이어에게 보이는 텍스트가 남아 있지 않다. 마지막으로 이 테이블들을 실제 참조 구조로 연결해 보자.
참조 구조 적용 가능 여부 판단
‘참조(參照)’란, 사전적 의미로 “참고로 비교하고 대조하여 봄.”이라는 뜻을 갖고 있다.
그런데 이런 사전적 의미만 두고 본다면, 이 ‘참조’라는 말이 ‘참고’와 어떻게 다르다는 것인지 헷갈린다.
일상 생활에서도 ‘~~한 점을 참고 부탁드립니다.’ 와, ‘~~한 점을 참조 부탁드립니다.’라는 표현이 혼용되어 쓰이는 것을 쉽게 볼 수 있다.
데이터베이스 상에서 ‘참조’의 뜻은 한 마디로 ‘조회’한다는 뜻이다.
A테이블에서 a, b, c라는 열이 있다고 가정하자. 이것을 B테이블에 있는 a1, b1, c1이라는 데이터를 조회해서 불러오겠다고 할 때 ‘참조’한다고 한다.
그렇다면 지금까지 한 작업에서 ‘참조’ 구조로 연결될 수 있는 곳이 있을까?
위 그림을 보자.
‘복귀 출석’ 테이블(위)에 있는 연두색, 그리고 파란색 데이터는 다른 테이블(Localize, Item)과 화살표로 연결 되어 있다. 여기서 화살표로 연결된 곳이 바로 참조 구조로 되어 있는 곳이다.
참조 구조로 되어있는 데이터는 엑셀/스프레드시트에서 ‘참조 함수’를 활용할 수 있다.
VLOOKUP, INDEX/MATCH, XLOOKUP 같은 조회 함수는 이렇게 Key로 이어진 참조 구조가 있어야 제 역할을 한다.
지금까지 위의 테이블을 만들고 수정하는 과정도 실은 데이터가 위처럼 서로 연결되기 용이하게 하기 위해 진행한 것이다.
그렇다면 위의 데이터를 두고, 참조 구조로 연결시키도록 하자.
테이블 데이터 연결
표 만들기
앞서, 지금까지 작업한 모든 데이터 테이블을 모두 ‘표’로 변경하도록 하자.
위처럼 복귀 출석 테이블 데이터를 모두 선택(Ctrl+A)한 뒤, 표 만들기(Ctrl + T) 단축키를 눌러 표를 생성한다.
위 데이터는 머리글이 있는 데이터이므로 머리글 포함에 체크한다.
앞서 나는 이 역기획서를 쓰면서 ‘범위’, ‘테이블’, ‘표’ 등의 용어를 혼합해서 사용했는데,
실제로 엑셀이 이 데이터를 표(테이블)로 인식하는 건 우리가 이 영역(범위)을 표 만들기 기능으로 표로 만든 이후부터다.
위의 복귀 출석 외에도, 복귀 미션부터 로컬라이즈 테이블까지 모두 표로 만들도록 하자.
표로 만들게 되면 위 이미지처럼 사각형 모양의 버튼이 열머리글마다 생기고 줄무늬 행 서식도 자동으로 적용된다.
서식은 건드리지 말고 그대로 두자.
표 이름 부여하기
엑셀 상단에 기능 버튼이 가로로 모여 있는 곳을 ‘리본 메뉴’라고 한다.
여기서 ‘수식 – 정의된 이름 – 이름 관리자’를 클릭한다.
나는 이미 다른 테이블은 모두 이름을 이렇게 미리 변경해두었다. (Table_테이블 이름 규칙)
표 이름을 건드린 적이 없다면 위에 보이는 것처럼 ‘표10’ 같은 규칙의 이름으로 되어 있을 텐데, 이것을 Table_테이블 이름 규칙으로 수정하도록 하자.
위의 ‘표10’은 ‘Table_Return_Attendance’로 변경하였다.
관계 설정하기
다시 리본 메뉴로 돌아와, ‘데이터 – 데이터 도구 – 관계’를 클릭한다.
이러한 ‘관계 관리’ 창이 팝업되면, ‘새로 만들기’ 버튼을 클릭한다.
‘관계 만들기’ 팝업을 보면 낯선 용어들이 보인다. ‘열(외래)라든지, 관련 열(기본)’이라든지… 차근차근 해보자.
앞서 3편에서 위의 표를 첨부한 적이 있었다.
여기서 좌측의 DataTable이 바로 위의 ‘관계 만들기’ 팝업에서 테이블에 넣어야 할 테이블에 해당하는 지점이다.
여기서는 ‘복귀 출석’ 테이블을 위 이름에 넣어두도록 하자.
앞서 표 이름을 모두 수정했다면, 위처럼 표 이름이 나타나게 될 것이다.
만약 표 이름을 수정하지 않았다면 위의 이름이 모두 ‘표1’, ‘표2’ 등으로 되어 있어서, 각 표가 어떤 내용을 담고 있는지 알 수 없다.
복귀 출석 표의 이름은 ‘Table_Return_Attendance’이니 이것을 선택하자.
열(외래)을 선택하면, ‘복귀 출석’ 테이블 내에 있는 열 머리글이 쭉 나타난다. 이 열 머리글은 각 열의 데이터를 대표하는 이름이다.
지금은 DataTable과 LocalizeTable을 연결해 보자. 따라서 위에서 LocalizeKey를 선택한다.
이 열 머리글은 DataTable과 LocalizeTable이 공유하는 Key에 해당한다. LocalizeKey는 복귀 출석 Table 입장에서는 외래키(FK)이고, LocalizeTable 입장에서는 기본키(PK)이다.
(위 데이터 연결에 대한 자세한 내용은 데이터베이스에 대해 공부하면 알 수 있으니 여기서는 생략한다.)
결과적으로 위의 그림처럼 되면 완성이다.
한편, Category 테이블과 Currency 테이블처럼 Key=LocalizeKey 규칙을 지키는 곳도, 아래와 같이 관계 만들기를 진행해주자.
별다른 오류 없이 Key가 연결되는 것을 볼 수 있다. 이렇게 5개의 관계를 만들어주도록 하자.
데이터 모델에서 관계 확인하기
엑셀은 데이터베이스 프로그램이 아니지만 MS Access의 데이터베이스 기능을 상당수 지원한다.
그래서 데이터를 만들고 관리하고 분석하는 데 강점이 있다.
액세스에서나 하던 일을 점점 엑셀로 옮겨 오는 추세이기도 하다.
엑셀의 ‘데이터 모델’도 원래는 액세스에서나 볼 법한 데이터베이스 도구다. 여기로 들어가 보자.
엑셀 리본 메뉴에서 ‘데이터 – 데이터 도구 – 데이터 모델 관리’를 선택한다. 만약 특정 기능 활성화가 필요하다고 하면 승인한다.
그러고 나면 우리가 지금까지 보고 있던 엑셀 데이터와 거의 같은, 또 다른 엑셀 영역같은 창이 활성화된다.
이 데이터 모델의 리본 메뉴를 보면 ‘홈 – 보기 – 다이어그램 보기’가 있다. 이것을 선택한다.
그러면 위와 같은 도식화된 데이터 연결 구조를 확인할 수 있다.
데이터 모델 화면은 엑셀 2010부터 들어온 ‘파워 피벗’ 분석 기능의 바탕이기도 하지만, 각 테이블마다 참조하는 것을 자동으로 도식화해주는 면에서도 의미가 있다. (사실 후자를 위해 진행하게 되었다.)
처음에는 위처럼 깔끔하게 나오지 않을 텐데, 위치를 조금 조정해주면 위처럼 정리된 모양으로 볼 수 있다.
이로써 현재 데이터 구조가 서로 어떻게 참조되고 있는지 확인할 수 있다.
위의 데이터 구조 다이어그램은 만들기 쉬운 반면에, 협업 상대에게 시각적으로 데이터 구조를 바로 보여줄 수 있다는 점에서 만드는 것을 권하고 싶다.
이로써 역기획서의 데이터 입력, 수정, 참조 구조 설정을 마친다.
여기까지 작업한 결과물은 엑셀 파일로 받을 수 있다. 테이블 관계까지 설정해 둔 상태라 파워 피벗의 다이어그램 보기에서 위와 같은 연결을 직접 확인할 수 있다. 2023년 4월(6.5 버전) 기준으로 추정해 만든 학습용 예제라는 점은 감안해 주길 바란다.
데이터 작업은 여기까지다. 다음 글에서는 이렇게 정리한 데이터를 바탕으로 복귀 플레이어의 여정을 따라가며 복귀 시스템의 기획 의도와 개선점을 분석한다. → 다음 글: 분석: 게임디자인 관점에서 본 복귀 설계
붕괴 3rd 복귀 시스템 역기획 시리즈
- 시리즈 소개: 게임 역기획서 작성 실전 가이드
- 붕괴 3rd 복귀 시스템 역기획 1: 자료 확보와 Key 설계
- 붕괴 3rd 복귀 시스템 역기획 2: 변수화와 Condition, ID 정리
- 붕괴 3rd 복귀 시스템 역기획 3: 로컬라이즈 테이블 분리
- 붕괴 3rd 복귀 시스템 역기획 4: 아이템 Key 규칙과 엑셀 참조 구조 (현재 글)
- 붕괴 3rd 복귀 시스템 분석: 게임디자인 관점에서 본 복귀 설계
답글 남기기