rejin 아바타

서브컬처 게이머

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

image 158

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

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

  • 상수를 변수로
  • 변수값을 포맷연산자로 표기
  • Condition 설정

오늘은 데이터에 개발자 코멘트를 추가하고, 앞서 부여한 ID를 최신화하는 공정을 추가로 진행해보도록 하자.


개발자 코멘트 추가

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

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

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

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


image 146

image 147
image 148
image 149
image 150
image 153
image 154

중복 Key 제거

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

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

image 158

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

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

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

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

image 155

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

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

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

명시적 ID 부여

지금까지는 ID의 이름 규칙을 계속 넘버링을 하는 식으로 쌓아왔다.

하지만 이런 ID로 데이터를 계속 관리하게 되면, 추후 어떤 ID가 어떤 항목을 가지고 있는지 확인하기가 어렵다. 이는 협업하는 환경에서 유지보수를 정말 어렵게 만든다.

따라서 지금까지 임시 ID로 부여한 넘버링 ID를 이제 명시적 ID로 변경할 것이다.

아래는 Reference 테이블에 이전에 별도로 정리한 아이템 및 카테고리의 ID를 최신화한 것이다.

image 156

실제 그 아이템의 개발명은 알 수 없기에, 플레이어에게 노출되는 ‘아이템명’ 기준으로 영어로 Key를 부여해보았다.

이렇게 이름을 바꾸면 01, 02일 때보다 Key만 보더라도 그 아이템이 무엇인지 알 수 있다.

하지만 이렇게 하면 입력하기 더 어려워지기 때문에 아이템명을 이렇게 길게 하기보다는 스튜디오 내부의 규칙을 마련하여 더 협업에 용이한 아이템명을 정하는 것이 좋다.