논문요약 - 컴퓨터 게임 로칼라이제이션 by Gustafsson

제목: 컴퓨터 게임 로칼라이제이션(Localization of Computer Games)

저자: Robert Gustafsson, 스웨덴

문서유형: 석사논문(총 43페이지), 2007년

 

 

DICE라 불리는 스톡홀름의 한 게임 개발 스튜디오의 로칼라이제이션(현지화)이 어떻게 수행되며 개선할 점은 무엇인지를 조사한 자료

 

---

 

로칼라이제이션(Localization)

• 특정 문화 또는 시장에 적합하도록 제품을 변경하는 프로세스
• 컴퓨터 게임의 로칼라이제이션은 게임 개발의 한 부분으로 적절한 계획과 사전 준비가 필요한 작업이다.
• 게임 개발 스튜디오는 게임 퍼블리셔(publisher)의 도움을 받아 SKU(stock keeping units)라 불리는 게임의 여러 다른 버전을 만들어 각기 다른 시장에 배포한다.
• 로칼라이제이션 프로세스에서 모든 자산(스트링, 텍스트와 비트맵, 음성 등)이 다른 언어로 번역되며, 때때로 게임 설계의 일부가 특정 국가의 문화 및 법규에 맞도록 변경되기도 한다.
• 게임은 텍스트 외에 애니메이션, 음성(voice over), 음향(sounds), 그래픽 등을 포함하므로 다른 소프트웨어 보다 로칼라이제이션이 더 복잡하며, 또한 다양한 플랫폼과 기술에 대한 로칼라이제이션도 종종 요구한다.
• 로칼라이제이션의 큰 부분인 번역과 테스팅은 대개의 경우 개발 스튜디오가 아닌 퍼블리셔의 주도하에 외부 전문가에 의해 이루어진다. 개발 스튜디오는 로칼라이제이션 된 자산을 통합하고 발견된 로칼라이제이션 관련 결함을 수정하는 역할을 한다.

 

로칼라이제이션의 필요성(문화적, 법적 측면)

• 컴퓨터 게임을 특정 시장에 맞게 바꾸는 작업이 게임의 성공 실패 여부를 결정할 수도 있는데, 특히 서양과 동양의 취향에 큰 갭이 존재하므로 서구 게임이 일본에서 성공하는 경우가 드물다. 따라서 일본 시장을 위한 서구 게임의 로칼라이젠이션 수행 시 언어 번역뿐만 아니라 게임의 다른 부분도 일본인의 취향에 맞게 변경하는 경우가 있다(캐릭터를 새롭게 디자인 하거나 마케팅 자료와 게임 박스 디자인 등을 수정). 예를 들어 “Ratchet & Clank 2”라는 게임은 주인공 캐릭터인 Ratchet의 눈썹을 일본 버전에서는 더 두껍게 하여 애니메이션 스타일로 바꾸었으며, 박스 디자인도 아래 그림처럼 변경되었다(일본 버전은 애니메이션 스타일로 손으로 직접 그렸고 미국 버전은 컴퓨터 그래픽 사용)
• 1994년부터 시행된 프랑스의 Toubon 법은 프랑스어로 번역되지 않고 영어가 그대로 들어간(오디오, 텍스트 포함) 게임의 프랑스 시장 출시를 금지하고, 위반 시 수천 유로의 벌금을 부과할 수 있다. 특이한 점은 영어의 경우에만 문제가 된다는 것. 예를 들어 2차 세계 대전을 다룬 게임에서 독일 병사가 독일어를 하는 것은 그대로 두어도 무방하지만 미국 병사의 말은 프랑스어로 바꾸어야 한다.

[왼쪽: 미국 버전 게임 박스, 오른쪽: 일본 버전 게임 박스]

 

국제화(Internalization)

• 로칼라이제이션을 위해서는 해당 제품이 먼저 국제화(internationalized)되어야 함
• 국제화의 목적은 제품을 지역에 상관없이 어디서든 사용할 수 있도록 설계 단계에서부터 염두에 두고 개발하는 것이다. 즉, 다양한 문자 세트(character sets), 키보드 자판 배치(keyboard layouts), 날짜와 시간 형식, 통화 단위 등을 지원하도록 설계하며, 콘텐츠도 특정 문화나 사례에 국한되지 않도록 만든다. 또한 스트링을 코드로부터 분리하고(스트링만 따로 텍스트 번역하기에 용이), 게임 엔진이 영어 버전에서 사용되는 것보다 더 많은 글자(letters)와 더 긴 텍스트를 지원하도록 한다.

 

게임 개발 프로세스(Game development process)

 

게임 개발 스튜디오 마다 각기 다른 개발 모델을 가지고 있지만 DICE는 아래 그림과 같은 4개의 주요 단계(개념설계, 생산전, 생산, 테스팅)를 일반적으로 적용한다. 각 단계는 약 한 달 정도의 단기적인 반복(iterations) 주기로 나누어지며, 각 반복 주기의 완료 시 생성해야 할 산출물들이 있다. 새로운 단계(phase)에 들어가기 위해서는 프로젝트가 의도한 목표를 충족했는지 확인하는 톨게이트(a toll gate)를 반드시 통과해야 한다.

[게임 소프트웨어 개발 모델]

 

• 개념설계(Concept): 설계자, 프로그래머, 미술 담당 등으로 구성된 소규모 팀이 모여 게임의 상위 레벨 계획을 기술한 게임 설계 문서를 작성한다. 게임 스토리, 게임 동작 원리, 게임을 독특하고 흥미롭게 만들어주는 주요 기능 들을 식별하고, 다음 단계를 위한 현실적인 계획(일정, 인원, 산출물 등)을 세운다.
• 생산전(Pre-production): 개념 설계에 따른 프로토타입을 개발하는 단계로서 프로토타이핑 단계라고도 불린다. 프로토타입을 통해 최종 게임이 어떤 모습으로 어떻게 동작할 것인지 더 상세하게 파악하고 필요한 자원도 식별한다.
• 생산(Production): 가장 긴 시간과 가장 많은 인원이 투입되는 단계로 설계 대로 게임을 구축하고 테스트 한다. 이 단계의 완료 시점에 전면 테스팅(full-scale testing), 로칼라이제이션, 제품 인도(delivery)에 대한 계획이 생성되며, 개발의 중점이 기능 구축에서 테스팅 및 완성도 향상으로 옮겨가는 알파(Alpha)라는 주요 마일스톤이 있다.
• 테스팅(Testing): 생산후(post-production) 단계라고도 불리는 테스팅 단계에서 대부분의 로칼라이제이션이 수행된다. 이 단계의 테스팅은 크게 품질 보증(Quality Assurance: QA) 테스팅과 로칼라이제이션 테스팅(Localization Testing: LT)의 두 가지 유형으로 나뉜다. QA 테스팅에서 게임의 품질과 기능 검증이 이루어지며, LT는 각 언어 버전 고유의 항목(즉, 게임의 현지화된 텍스트와 음성)에 대해서만 테스트를 수행한다. 콘솔 게임 테스팅의 경우 테스터는 특정 업체(소니, 마이크로소프트, 닌텐도 등)의 스트링과 그래픽 가이드라인에 부합하는지 여부를 체크한다. LT는 종종 개발 스튜디오가 아닌 퍼블리셔에 의해 수행되지만, 정식 LT가 수행되기 전에 스튜디오의 QA 테스터가 일차적인 LT를 수행하기도 한다(모든 폰트가 제대로 디스플레이 되는지, 텍스트가 잘리는 경우는 없는지 같은 외국어의 이해와 관련 없는 사항들을 확인). 테스팅 마지막에는 베타(Beta)라 불리는 마일스톤이 있는데 이때부터 모든 자산(메뉴, 텍스트, 오디오 등)이 동결되어 수정이 금지된다.

 

로칼라이제이션 버그 유형

아래와 같은 9개 카테고리로 구분된다.

• 오디오(Audio): 음성(the voice over) 에러. 예, 잘못된 사운드가 플레이되거나 음성이 잘 들리지 않음
• 프로그래밍(Programming): 예, 자막이 충분한 시간 동안 보여지지 않는다거나 잘못된 텍스트가 잘못된 곳에서 보여짐
• 가이드라인(Guideline): 콘솔과 관련된 버그 카테고리. 컨트롤러의 명명 규칙(naming conventions of controllers) 같은 특정 플랫폼에 국한된 자산이나 기능과 관련된 버그. 가이드라인 버그는 높은 심각도를 가지므로 반드시 수정되어야 한다(그렇지 않은 경우 콘솔 제조업자의 검사를 통과하지 못하게 됨)
• 잘못된 언어(Wrong Language): 틀린 언어로 디스플레이 되는 경우, 텍스트가 들어갈 자리에 스트링 ID가 보이는 경우(이 문제는 프로그래밍 버그 카테고리로 분류 되기도 함)
• 길이 문제(Length Problem): 원본 영어 단어/텍스트 보다 번역이 더 길어지는 경우가 많아 종종 발생하는 문제
• 철자/문법(Spelling/Grammar): 프로젝트 말기에 테스터가 텍스트 데이터베이스의 수정 권한이 더 이상 없을 때 발생. 또는 비트맵 상의 텍스트 같은 텍스트 데이터베이스에서 직접 수정이 불가능한 경우에 발생
• 문맥/일관성(Context/Consistency): 대개 텍스트 데이터베이스를 수정하여 쉽게 해결되지만 코드 상의 날짜 또는 통화 형식을 변경할 필요가 있을 때는 문제가 됨
• 법규(Legal): 법률 문서 또는 지적 자산 관련 문제, 제 3자와의 합의 관련 문제
• 폰트(Font): 폰트 상의 에러. 예, 글자가 정확하게 디스플레이 되지 않거나 폰트 때문에 사용자가 텍스트를 읽기가 어려움

 

로칼라이제이션 관련 이슈

DICE 스튜디오의 기존 로칼라이제이션 작업을 검토한 결과 아래와 같은 문제점들이 식별됨

• 개발자들의 로칼라이제션에 대한 인식 부족. 개발 중 사전 준비에 따라 로칼라이제이션이 간편하기도 하고 그 반대의 경우가 되기도 하므로 작업자의 로칼라이제이션에 대한 지식이 중요
• 로칼라이제이션을 전담하는 담당자가 없이 다른 역할의 작업자가 부수적으로 커버. 주업무가 아니다 보니 우선순위가 밀리고 계획도 부족하여 프로젝트 후반 알파 단계에 가서 여러 로칼라이제이션 문제가 발생
• 로칼라이제이션을 용이하게 해 주는 도구가 일부 존재. 예, 텍스트 데이터베이스(게임의 원본 및 번역본 텍스트와 스트링 ID를 나열한 Excel 파일)는 어느 부분이 변경되었는지 쉽게 파악할 수 있게 해 줌. 콘솔 게임의 경우 실제 스트링 대신 스트링 ID를 보여주는 a cheat code가 있어서 테스터가 게임의 어느 부분에 어떤 스트링 ID가 쓰이는지 알 수 있게 해 줌. 문제는 테스터들이 이런 도구가 존재하는지 몰라 제대로 활용하지 못함.
• 게임 엔진(Game engine)이 어떻게 작동하는지가 로칼라이제이션에 미치는 영향이 큼. 한 예로 PC 게임 엔진이 유니코드(Unicode)를 지원하지 않아서 아시아 문자를 디스플레이 하지 못하는 문제가 생겼고 개발팀이 서둘러 이를 보완해야 했음(이런 요구사항은 개발 초부터 사전 계획이 중요).
• 라틴 언어권 개발자들이 아시아 언어를 모르다 보니 아시아 언어 폰트가 회전되어 디스플레이 되거나 읽기에 지나치게 작게 디스플레이 되거나 하는 문제가 있었음
• 게임 폰트 지원에 많은 어려움을 겪음. 아시아 문자는 어려움이 있을 것으로 예상이 되어 추가적인 시간 투자를 미리 계획했지만, 폴란드 특수 문자 같은 일부 유럽 언어도 예상치 않게 개발 팀에 여러 문제를 가져다 줌.

 

 

개발 단계별 로칼라이제이션 체크리스트

1) 개념설계(Concept)

• 문화적 측면에서 게임의 개념(the game concept) 검토
  - 일부 지역에서 문제가 될 수 있는 내용을 게임이 포함하고 있는가?

 

2) 생산전(Pre-Production)

• 로칼라이제이션 관련 작업을 식별하고 계획
  - 텍스트 관리는 어떻게 해야 하는가, 어떤 언어/문자가 지원되어야 하는가, 적절한 도구가 준비되어 있는가?
  - 오디오 로칼라이제이션을 위해 어떤 언어가 필요한가?
• 자산의 오너(owners)와 처리 절차(workflows)를 결정
  - 특정 시점 이후 변경을 못하도록 동결되는 오디오 스크립트, 음성(voice overs), 게임 텍스트의 오너가 필요. 오너는 해당 자산의 로칼라이제이션이 용이하도록 구축되게 할 책임을 진다(예, 스트링 명명 규칙을 준수하여 일관성 있고 알기 쉬운 이름을 붙인다)
• 사용자 인터페이스(UI)와 코드의 로칼라이제이션 요구사항 결정
  - 사용자 인터페이스가 로칼라이제이션이 용이하도록 되어 있는가? UI가 모든 문자를 지원하고, 강제 줄 바꾸기(forced linebreaks)를 지원하며, 영어 보다 더 긴(30% 또는 그 이상) 스트링을 허용하는가?
  - 게임이 자막을 필요로 하는가? 필요로 한다면 개발 조직이 이를 위한 기술을 가지고 있는가?
• 로칼라이제이션 일정 수립
  - 로칼라이제이션 담당자는 로칼라이제이션 요구사항, 자산 오너, 작업 절차를 고려하여 일정을 수립한다. 수립된 일정은 프로젝트 전반에 거쳐 상황에 맞게 업데이트 된다.

 

3) 생산(Production)

• 자산 동결 일자(lock dates for assets) 수립
  - 오디오 스크립트와 게임 스크립트의 동결 날짜를 오너와 합의하여 결정
• 로칼라이제이션이 된 자산의 통합 프로세스 수립
  - 오디오 레코딩 시 스튜디오의 오디오 디렉터가 필요한가?
  - 파일 형식 관련 요구사항은 무엇인가?
  - 로칼라이제이션 된 자산을 받는 시점과 이를 빌드로 통합하는 시점은 언제인가?
• 사용자 인터페이스(UI)와 코드의 로칼라이제이션 요구사항이 충족되었는지 확인
  - 모든 요구되는 특수 문자를 포함하여 폰트가 선정되고 테스트 되었는가?
  - 아시아 언어 전문가(원어민)가 폰트 및 폰트 사이즈가 읽기에 적절한지 확인하였는가?
  - UI가 사이즈 조절이 가능한 박스(resizable boxes)로 되어 있어서 높이 및 길이가 더 큰 텍스트를 허용하는가?
  - 자막이 완전하고 로칼라이제이션이 용이하도록 만들어 졌는가?
  - 코드가 글자 간격(hard spaces)과 강제 줄 바꾸기(forced line breaks)를 지원하는가?
  - 백도어(cheats) 명령어와 디버그용 명령어로 지원되는 것이 어떤 것들이 있는가?
  - 모든 법적 문서가 결정되고 준비되어 있는가?
• 새로운 이정표(milestones)에 따라 로칼라이제이션 일정 업데이트
  - 번역과 레코딩을 위해 자산을 보내고, 통합을 위해 로칼라이제이션이 된 자산을 돌려 받는 일자
  - 일차 로칼라이제이션(현지화)된 빌드의 인도 일자
  - 로칼라이제이션 테스팅 시작 일자
  - 신규 빌드의 인도 일자
  - 로칼라이제이션 테스팅 완료 일자
• 아래를 포함하는 로칼라이제이션 테스팅 세트(a localization testing kit)를 준비
  - 테스팅을 돕는 백도어와 기타 명령어 목록
  - 프론트엔드 플레이와 게임 플레이에 대한 설계 문서와 플로우차트
  - 테스트 반복 주기에 대해 명세한 테스트 계획서

 

4) 테스팅(Testing)

• 로칼라이제이션이 된 빌드 생성
  - 품질 보증 담당자가 제품을 테스트 하였고 로칼라이제이션 테스팅(LT)을 시작하기에 충분한 품질(완성도)에 도달했는지가 검증되었는가?
  - LT 시작에 앞서 보고된 모든 주요 결함들이 수정되었는가?
  - LT 수행 동안 언제 테스트가 완료되고 언제 새로운 버전의 로칼라이제이션이 된 빌드를 전달할 필요가 있는지를 커뮤니케이션 한다. 통합을 위해 수정이 완료된 로칼라이제이션 자산을 반환하는 시점도 명시
• 버그 추적 및 담당자 할당
  - 보고된 로칼라이제이션 버그들은 일차적으로 로칼라이제이션 책임자에게 할당되며, 로칼라이제이션 책임자가 버그를 검토하여 적절한 사람에게 할당한다.
  - 로칼라이제이션 책임자에게 할당된 버그뿐만 아니라 모든 로칼라이제이션 관련 버그를 추적하여 주요 버그가 잘못된 사람에게 할당되는 일이 없도록 한다.
• 로칼라이제이션 진행 상황 업데이트
  - 프로젝트 주요 책임자들에게 로칼라이제이션 진행 상황을 업데이트 해 준다. 로칼라이제이션 지연으로 전체 프로젝트가 지연 될 수 있으므로 프로젝트 말이 될수록 현황 업데이트가 특히 중요
• 프로젝트 종료 후 사후보고서 작성
  - 프로젝트 수행 동안 무엇이 잘 되었고 개선이 필요한 것은 무엇이었는지를 기술