묻고 답하기

쉬운일이 아니실텐데 도전하시려는 모습이 아름답습니다.

먼저 1번 항목의 경우 후커와 다르게 대사를 가로 챌수 있는 포인트를 찾는게 중요시가 됩니다.

이점에 있어서 후커의 경우 글자를 출력하는 곳이나 글자를 이미지로 변경하는 윈도우 함수를 가로채서 원문을 복구 하는 형식이 주류를 이루는데요. 출력을 어떻게 하냐는 엔진마다 개별이지만 그 형태를 바꾸는 일이 거의 없고 출력방식구조가 많이 달라봐야 한정된 내에서밖에 바뀌지 않기 때문에 후커에 있어서 이곳을 공략하는 방식은 매우 강하다고 할 수 있습니다.

반면, 전문이 필요한 아랄의 경우 게임엔진의 텍스트를 압축된 상태에서 어떻게 복호화하고 스크립트 형태나 개행문, 이름과 같은 별도 출력, 특수문자를 이용한 명령어의 운용 등 을 해석하는 알고리즘과 이것을 출력하기전에 백로그, 세이브 데이터, 출력속도 등 내부에서 필요한 연산이 가해지기 때문에 각엔진마다 이런 루틴이 공통적인 부분은 없다고 보셔야 합니다. 그 결과 후커처럼 편하게 찾을수 없다는 단점이 생기기 마련이죠.

간단히 요약하면 후커는 출력시 뿌리는 값을 역으로 예상하여 원문을 예측 추출하는것이고

아랄은 대사를 운용하는 도중을 찾아 바꿔 써넣는 구조입니다.

2번 항목의 답변입니다.

사실상 코드 전체가 퍼가기 금지라고 해도 가로챌 주소가 코드에 고스란히 보이기 때문에 원천적으로 코드자체의 보안성은 없습니다. 따라서 추후 누군가가 이와 비슷한기능을 만들어 주소포인트만 가져다가 ATCode와는 다른 형태로 운영한다면 막을 권리가 없겠죠. 무엇보다 이곳의 자료를 다른형태로 운영가능한 방식으로 마이그레이션 하는것도 상당한 일이 될것이고, 나서서 하시는 분은 별로 없으리라 생각됩니다.

3번 항목입니다.

VNR로 기능을 옮긴다고 하여도 여러가지 문제점이 많습니다. 먼져 아랄은 후커와 다르게 전문을 가지고 처리하는데 이점의 큰 난관은 가로 채고 나서 게임의 오류를 내지 않는게 중요시가 됩니다. 무조건 있어야할 문자라든지 텍스트 길이가 줄거나 늘어나도 되는지 다른 여타 검증을 이행하는지 등 엔진에서 사용될 에러 체크용 부분 전부를 무사히 진행해야 한다는 점입니다. 이런점을 보완하기 위해 필터라는 존재가 생기게 됩니다. 여기서의 필터란 번역률을 올리는 후커의 필터와는 다른 개념으로 대사를 원문에 유사한 형태나 무리없는 방향으로 번역된 데이터를 다시 가공하거나 번역이 쉬운 형태로 원문을 추출하는 기초단계의 것을 말합니다. 물론 지금 있는 기능을 구현하는것은 관계가 없으나 지금까지 아랄이 가지고 있는 필터는 어디까지나 한글을 기준으로 제작되었습니다. 중국어나 다른 여타언어 사용시 적용되지 않아 그런 부분들이 전부 제작되어야 할 요지가 있습니다. 이런 단계까지 되면 한글화패치를 하시는 분의 지식도 필요하게 되는데 VNR 제작자 분께서 모든 언어의 패치 지식을 가지고 있는지는 모르겠군요. 물론 '한국어에 한해서 이 기능을 도입해달라' 는 부분을 제작자분이 수용할지도 미지수 같습니다. 그 VNR프로그램 제작의 전제는 글로벌 번역기라는 컨셉이 중요하니까요.