rejin 아바타

서브컬처 게이머

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

image 159

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

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

  • 개발자 코멘트 추가
  • 중복 Key 제거
  • 명시적 ID 부여

오늘은 각 키에 필요한 로컬라이즈 키를 정리하고, 로컬라이즈 데이터는 별도의 테이블로 옮기도록 하자.


지금까지의 로컬라이즈 데이터는 하나의 시트, 각각의 표 안에서 관리하고 있었다.

이런 관리 방법이 틀린 것은 아니다. 이렇게 관리함으로써 얻는 장점도 있다. 일단 데이터 테이블의 구조가 간단해지고 굳이 다른 테이블 데이터를 참조할 필요가 없으니 표 내용이 직관적이다. 만약 하나의 권역(예: KR)에만 서비스할 계획이라면 로컬라이즈 테이블을 따로 관리하지 않는 것도 크게 문제되지 않을 것이다.

하지만 우리 게임이 글로벌 권역을 서비스하게 된다면 로컬라이즈 테이블을 별도로 관리해야 한다. 서비스 대상 국가(또는 언어)의 수 만큼 열이 늘어나야 하기 때문이다.

로컬라이즈 데이터는 보통 아주 긴 문장이 포함된다. 따라서 이러한 열이 하나라도 존재한다면 그 테이블을 관리하는 입장에서는 관리가 다소 까다로울 수 있다.

예를 들어, 로컬라이즈 열 1개 때문에 아주 작은 열(예 : amount) 5개가 가려지게 된다면 이는 로컬라이즈 열 하나 때문에 개발자의 문서 가독성이 저하되게 된다. 실무에서는 이처럼 하나의 표 안에 굉장히 많은 열 또는 데이터가 들어감으로써 문서의 활용도가 떨어지는 일이 비일비재하게 발생한다. 따라서 이런 일이 사전에 일어나지 않도록 미리미리 데이터 구조를 잘 짜두는 것이 좋다. 그래서 로컬라이즈 데이터도 별도로 분리하는 것을 권하는 것이다.

또한, 이렇게 먼저 테이블을 짜 두는면 나중에 서비스 권역이 늘어나도 대처가 편하다.

image 159

Data Table(기존까지 우리가 수정하던 테이블)과 Localize Table을 서로 분리하여 참조하는 구조를 도식화한 것이다.

DataTable의 Primary Key는 Key01, Key02, Key03, Key04이다. 이 값은 DataTable의 기본키로 동작한다.

그런데 DataTable의 값을 로컬라이즈 테이블에서 ‘참조’하려면, 로컬라이즈 키를 불러올 열이 필요하다. 따라서 DataTable에 LocalizeKey 열을 추가한다. (녹색)

마지막으로, 로컬라이즈 테이블에 잘 모아둔 데이터의 Primary Key(LocalizeKey_01, LocalizeKey_02, LocalizeKey_03, LocalizeKey_04)를, DataTable에 새로 생성한 녹색 열 값에 붙여넣는다.

이때 로컬라이즈 키는 DataTable입장에서는 Foreign Key가 된다. 다른 테이블에서 불러온 키라는 의미이다.

이렇게 작업을 진행하기 위해, 먼저 DataTable(기존에 작업하던 테이블)에 로컬라이즈 열을 생성해보도록 하자.

로컬라이즈 열 생성

image 160

앞서 위 표처럼, 복귀 시스템 LocalizeKey를 녹색 열머리글로 따로 정리한 바 있다.

여기서 회색 열 머리글에 해당하는 데이터에 LocalizeKey를 넣어보도록 하자.

image 161

그러자, 위의 표처럼 정리가 된다. 여기서 ‘복귀 출석 1일’에 해당하는 Text 1일에 대응하는 LocalizeKey부터, ‘복귀 출석 7일’헤 해당하는 Text 7일에 대응하는 LocalizeKey까지, 총 7개의 로컬라이즈 키를 추가한 것을 알 수 있다.

그런데 여기서 아차, 위에서 보는 것처럼 위에 별도로 빼둔 해당 세부 목록 페이지의 다른 로컬라이즈 키와 중복이 발생하고 말았다.

이는 세부 목록 페이지의 로컬라이즈 키 부여 정책과, 데이터의 로컬라이즈 키 부여 정책이 별도로 정해지지 않은 채 그저 ID를 입력했기 때문이다.

자, 그렇다면 어느 쪽을 고치는 게 나을까? 이는 사람마다 그 판단의 근거가 다르겠지만…

image 162

회색 열 머리글의 테이블에 입력한 값을 보라색으로 칠해보았다. 이 테이블만 본다면, Return_Attendance_01은 Localize_Return_Attendance_01 키와 1:1 대응한다.

반면, 위의 녹색 열 머리글 테이블의 데이터는 하나의 테이블에 다른 대응하는 Key가 없다. 그러니 위의 녹색 열 머리글 데이터의 로컬라이즈 키 부여 규칙을 변경하도록 하자.

image 163

이쯤에서 ‘복귀 출석’ 세부 페이지를 다시 보자. 위에 주황색 글씨로 정리한 데이터는 이 세부 페이지의 UI 영역에 들어가 있으며, 전역적으로도 쓰일 수 있게 생긴 것을 알 수 있다. 그래서 나는 여기서 ID 부여 규칙을 ‘Localize_Return_Attendence_UI‘로 수정하겠다.

image 164
image 165

그런데 지금 보니, 위에 ‘복귀 출석’부터 ‘복귀 설문’ 까지의 텍스트도 전역적으로 쓰이는데다 로컬라이즈 키로 별도로 정리해야할 것 같다. 이 데이터들도 전역 키로 관리하도록 하자.

지금까지의 수정사항을 반영하면 아래와 같다.

image 166

이제 위 적용한 규칙을 바탕으로, 아래의 다른 세부 페이지(예: 복귀 미션)까지 수정을 적용해주도록 하자.

image 167

위는 복귀 미션의 로컬라이즈 적용 과정인데, 우측의 Text_2열에 해당하는 데이터는 중복값이 발생한 것을 알 수 있다. 그래서 위 색깔 영역처럼 ID를 부여하였는데, 오히려 지금의 데이터 구조로 보아하니 이렇게 관리하면 오히려 복잡해보일 듯하다.

따라서 지금 정책을 마련하겠다.

‘시스템 테이블에서 하나의 테이블 내에 두 개의 로컬라이즈 키 열 머리글이 존재한다면, 두 로컬라이즈 키의 숫자값은 서로 대응하도록 한다.’

이에 맞춰서 수정을 하게 되면,

image 168

이렇게 대응하는 구조로 만들 수 있다.

로컬라이즈 키 부여 규칙은 다시 한번 강조하지만 스튜디오마다 조직마다 다를 수 있으니 어떤 것이 정답이라고는 말할 수 없다. 다만 나는 내가 생각하는 중복값 이슈보다는 이러한 직관적인 ID 대응이 더 중요하다고 생각하여 이렇게 새로 정책을 마련한 것 뿐이다.

로컬라이즈 데이터 분리

이제 위에 녹색으로 된 영역을 별도의 로컬라이즈 테이블로 분리하도록 하자.

로컬라이즈 테이블로 분리할 때, 대상이 되는 테이블의 규칙이 뒤죽박죽이 되어서는 안 되니 아래와 같은 포맷 안에 넣을 수 있도록 하자.

image 170

지금 작업하고 있는 언어는 한국어(KR)이니, 기존의 Text 열에 들어가 있던 데이터는 모두 KR에 넣도록 하겠다.

그런데 위 표를 보면 알 수 있지만, ‘로컬라이즈’ 테이블 내에 이렇게 Condition_value가 관리되는 것은 일반적이지 않다.

각 세부 페이지(복귀 출석 등) 내부의 데이터는 각 Key에서 이러한 값을 통제하지만, 위처럼 전역 Key(_UI_)는 별도로 관리해주는 테이블이 없다.

일단 지금은 임시로 Condition_value를 적어두고, 나중에 별도의 Condition Value를 관리하는 전역 변수 테이블을 만들어주도록 하자.

이제 기존의 Data 표에 각각 분산되어 있던 LocalizeKey와 그 데이터(녹색 행)을 하나로 합치도록 하자.

image 171

이렇게, 하나의 표 안에 Global, Attendance, Mission 등이 합쳐졌다.

기왕이면 A-Z 순(오름차순)으로 정렬하는 게 보기 좋을테니, LocalizeKey열에 오름차순 정렬을 적용해주자.

그리고 LocalizeKey열에는 중복값이 생기면 안 되므로 중복값이 나타나면 알려줄 수 있도록 조건부 서식 – 중복값 표시를 적용해주도록 하자.

중복값이 따로 나타나지 않았다면, 붉은 색 셀 없이, 아래와 같이 오름차순으로 정리되어 있는 표를 볼 수 있다.

image 172

이제 기존의 데이터 테이블에 있던 로컬라이즈 데이터 중, 텍스트(기존의 Text 열)는 날려버리도록 하자.

또한 해당 테이블 중에서 전역(_UI_) 키값도 날려도 좋다.(이미 로컬라이즈로 그 모든 데이터가 이사왔기 때문에)