180bpm

scaleform 3.3과 4.0에서 로컬라이징 테스트(2) 본문

Flash/Scaleform

scaleform 3.3과 4.0에서 로컬라이징 테스트(2)

powdersnow 2012. 1. 27. 18:39
FontConfig를 사용한 GFxTranslataor를 사용하는 방법은 Scaleform에서 기본적으로 제공해주는 기능입니다.
다만, 이미 언리얼에는 로컬라이징을 위한 폴더링이 되어 있고 번역테이블까지 있기 때문에 스케일폼만을 위해 2개를 만들어서 두는건 비효율적인 방법이고, 또 에픽게임즈에서 이런 방식을 내버려두진 않았을꺼라 생각해서 언리얼의 로컬라이징 파일을 사용하는 방법을 테스트 해봤습니다.

언리얼에 통합된 Scaleform의 로컬 테이블은 Localization/국가코드/GFxUI.int (디폴트)에서 가져 올 수 있습니다.
번역을 처리할때의 내부구조도 똑같은 방식으로 돌아가는것으로 알고 있습니다.

사용법은 다음과 같습니다.
1. GFxUI.int를 연다

2. [Global] 다음째 줄에 키 값=매핑 값을 쓴다.
FontConfig.txt에서는 tr   "키 값" = "매핑값" 입니다.
그래서 언리얼에서 로컬라이징이 될 때 키 값 구분을 위해 임시로 붙여둔 인자인 $가 들어가니 해당 키 값을 찾지 못했습니다. 문자열로 하는것이 좋을듯 싶습니다.
3. 인게임에 들어가면 바로 확인이 가능합니다.

다만 문제점이 있습니다. FontConfig는 개발시 Scaleform Launcher에서 테스트가 가능하지만 언리얼 로컬라이징 테이블은 가져와서 테스트 할 방법이 없습니다.
(UDN 메일 답변에서 확인. Unprog3에서도 불가능이라고 함)

정리

FontConfig의 장점
 Scaleform Launcher로 테스트 가능.
단일 파일 안에 모든 각국의 로컬 테이블을 넣을 수 있다.
FontConfig의 단점
default folder가 현재 테스트중인 파일의 root이기 때문에 인게임에서는 쿸킹이 되서 txt를 넣을 수 없다.
그래서 엔진으로 경로를 수정해줘야 한다.

컨테이너던, 개별 UI건 어쨌든 지역명을 던져줘야한다. 하지만 이 불편을 꼼수로 사용 할 방법도 있다. korean1, korean2 이런식으로 구분해서 같은 UI에도 필요할 때 마다 로컬만 던져주면 바로 변한다.
다만 4.0에서는 지역명을 받는 변수가 사라져서 대처법을 찾는 중. 다만 FontConfig 파일이 있다면 첫번째 로컬 테이블로 매칭이 됨 


언리얼 로컬 테이블의 장점
새로 만들지 않아도 된다. 엔진의 로컬을 따라가서 별도로 날려 줄 필요가 없다.
언리얼 로컬 테이블의  단점
개발중 테스트가 불가능하다.
HTML 태그가 안된다. 
https://udn.epicgames.com/lists/showpost.php?list=undev-kor&id=46944&lessthan=46995&show=200 
이건 큰 문제라고 생각한다.

그래서 로컬라이징 테스트를 하려면 테스트땐 FontConfig를 사용하고 인게임에서는 언리얼 로컬 테이블을 사용하면 된다고 생각합니다.
Comments