모바일 게임 언어팩
다양한 국가에서 필요할 때만 언어팩을 다운로드 받고 유연하게 수정 반영할 수 있어야 함
언어팩이 필요한 부분
실제로 작업을 해보니 언어팩이 필요한 부분은 프로젝트와 관련된 모든 산출물이라고 보는 것이 좋다. 클라이언트, 서버 어플리케이션에 있는 스트링들은 당연한 이야기이고, 각종 가이드 특히 운영툴 까지 프로젝트를 진행하며 생기는 모든 부산물은 언어팩 적용 대상이다.
언어팩을 사용할 수 있는 구조
- 처음 기획부터 문장이 아닌 단어 형식으로…..
- 어쩔 수 없는 문장이라면 문장 사이에 하이라이트는 제외.
- 번역도 번역이지만 프로그래밍 할때 굉장히 피곤해짐. 해당 하이라이트 된 단어는 어순이 다른 언어일 경우 어디를 하이라이트를 해야 할 지 언어를 모른다면 알수가 없기 때문
- 단어 보다는 그 액션을 떠올릴 수 있는 그림으로…
- 그림이 안된다면 행동으로 보여준다.(ex. 튜토리얼 같은 경우도)
- 언어를 출력하는 부분에서 처음부터 스케일을 조정할 수 있도록 구성하든가 좌우로 흐르는 슬라이드 형식의 스트링으로 작성.
이미지폰트
- TTF의 각 알파벳을 아래와 같은 이미지 폰트로 대체
- 최대한 많은 언어를 커버할 수 있는 True type font(TTF)를 선정해 이미지 폰트로 바꾸면 추후에는 텍스트만 업데이트 해도 됨.
- 이미지 폰트를 안 쓰고 순수한 TTF로만 사용하면 편하긴 하지만 클라이언트 빌드의 용량이 커지고 어플리케이션의 퍼포먼스에도 안 좋은 영향을 미침.
Text in image
- 이미지 내부에 이미지로 존재하는 문구는 이미지폰트로 대체해야 유연한 대처가 가능
특수 이펙트 문구
- Perfect, Clear, Miss 등과 같은 게임 플레이 중 특수 이펙트를 나타내는 문구
- 텍스트가 아닌 이미지로 봐야함
- 언어 별로 분리가 필요하다면 각 언어별로 별도의 이미지 작업이 필요
국가 별 언어 소스는 통합 관리
언어팩 파일이 여기저기 돌아다니면 관리가 힘들기 때문에 통합하여 관리할 수 있는 똑똑한 툴(이를테면, Google Spreadsheet)을 사용하길 권장한다. 당연히 수정할 수 있는 권한은 관리가 필요하고 나 같은 경우는 구글 스프레드시트를 통해 각 국가별 번역 담당자들이 알아서 문구를 수정할 동안 개발작업에 매진할 수 있어서 좋았던 경험이 있다. 한 단계 더 나아가서 구글 스프레드시트를 읽어서 한 번에 언어팩 파일들이 올라가있는 서버로 배포할 수 있는 툴까지 작성한다면 더욱 더 큰 효과를 누릴 수 있다. (아래는 윈폼으로 만든 간단한 툴인데 소스가 필요하신 분이 있다면 github에 올려보는 것도 고민을...)
포맷 스트링
포맷팅 된 문구를 사용해야 할 이슈도 분명히 있다. 예를 들어
"린츠님은 30일 동안 8번 플레이 하셨습니다." 와 같은 문구는
"%s님은 %d일 동안 %d번 플레이 하셨습니다" 정도로 간단히 포매팅을 할 수 있다.
근데 사실 문제는 언어별로 어순이 다르기 때문에 %s와 %d의 자리가 바뀌어 버리게 되면 type에 민감한 언어들은 곧장 어플리케이션의 크래시로 이어진다. 그렇기 때문에 아예 스트링만 쓰던지 아니면 포맷 해주는 역할을 하는 함수를 따로 만들어 쓰는 것이 좋다.
언어팩 문구 매핑 전략
- Line number
- 새로운 문구가 추가될 때 마다 생기는 행 번호로 매핑
- 장점
- 일반적인 의미의 Key에 대한 고민이 필요 없음
- 단점
- 중간에 누군가 행을 삭제하면 그 다음부터의 모든 문구가 바르지 않게 노출 됨.
- 소스 상에서 행 번호만 보고 문구가 무엇인지 알기가 어려움
- Key/Value
- 해당 문구를 가장 일반적으로 표현할 수 있는 Key 값을 정하고 각 국가 별로 값을 매핑한다.
- 장점
- Key가 사람이 인식할 수 있는 값이므로, 여러 사람이 편집해도 실수를 줄일 수 있음
- 단점
- 일반적으로 표현할 수 있는 Key 값을 정하는 것이 힘들고 문구가 늘어날 수록 겹치치 않는 Key를 따는 것이 녹록치 않음