기존에는 그냥 자체 ui의 TMP의 텍스트나, so같은데 넣는 string들도 다 한글로 해놓고 작업했는데
이제 번역작업 하려니까 gpt한테 물어보니까 string 자리에 대신 key값 넣고 거기에 대응되게 한글, 영어.. 등등은 csv파일이나 json에 넣고 dictionary처럼 key value 대응되게 만들어서 하라고 하는데
보편적으로 다 이런 방식으로 하나요?? 게임이 카드 게임이라 카드 목록같은거 킬때 이 방식으로 하면 예전보다 살짝 프레임 드랍 생기는데 (기존에는 그냥 so에 있는 string을 가져와서 띄웠는데 이젠 dictionary에서 key값에 대응되는 value 가져오는 과정 포함되서)
아니면 so에서 번역이 필요한 string들만 따로 떼어서 또 다른 so로 만들어서 언어마다 갈아끼우는거도
매번 dictionary를 검색할 필요 없이 언어 바꿀때마다 so에 일괄적으로 다른 so를 끼워주는 방식이니까 dictionary 검색해야 해서 프레임 드랍같은게 생길것같진 않은데
so들에 string so들을 언어마다 갈아끼워주는 구조 만드는게 맞나 싶기도 하고, so는 인게임 도중 수정 없이 항상 똑같은 상태 유지해야 할거같은데,
보편적으로 어떤 방식으로 하나요??
공식 로컬리제이션 패키지라도 쓰시길
그런데 dictonary 키값에 맞는 value 가져오는 게 눈에 띌 정도로 성능저하 오기 힘든데 모르겠으면 윗댓 말 대로 있는 거 쓰자
유니티 로컬라이제이션쓰는게 나음. 어드레서블 연동까지 다 해줘서 편함
간단하게는 csv + 딕셔너리만으로도 되져 텍스트가 어지간히 많지 않는 이상.. so로 만들기에는 이점이 없는듯 스프레드시트로 관리하는 편이 나을 것 같은데
카드 목록 들고올때 프레임 드랍 생기는거면 필요할때마다 들고오는것 같은데 그냥 글로벌로 dictonary하나 만들고 언어 변경할때, 게임 시작할때 싹다 로딩하면 됨 dictionary에서 키 찾는 작업은 O(1)이니까 그리 무거운 거 아니라서 상관없고 내부 텍스트 다 들고있어도 메모리 많이 먹는것도 아니라서 아무 상관 없음
유니티 로컬라이제이션은 게임에 문자열에 파싱하거나 문자열 체크하고 동적 변환하는게 많아서 작업량 너무 많아질꺼같음.. 프레임 드랍은 게임 시작할때 미리 로딩해도 상관 없는 것들은 미리 로딩하는 식으로 해결해야겠어요.
음.. 언어 바꿀 때는 로딩이 걸려도 상관없을 것 같은데