RenPy게임은 사실 허점이 많습니다. 이런 저런 잠금장치를 해봐도 결국 Python이라는 특성상 Py파일을 열 수 있고 엔진의 Py파일을 손대면 이러니저러니 해도 데이터 마이닝을 쉽게 할 수 있습니다.
사실 대다수 게임엔진은 개발자모드 혹은 콘솔진입을 허용합니다. 대표적인 게임이 퀘이크 엔진과 그의 영향을 받은 소스엔진 같은 게임 엔진입니다.
멀리 갈 것도 없이 소스엔진 게임인 half-life를 실행한 상태에서 `키(혹은~키)를 누르면 갑자기 게임 내에서 명령어 창이 뜹니다. 이게 바로 게임 엔진의 콘솔인 것이지요. 일반인들은 이 콘솔을 치트키를 치는 창 정도로 생각하지만 (sv_cheats 1 이런 것)사실은 이 명령창은 개발자의 개발 편의성을 위해 만들어진 것 입니다.
RenPy도 게임엔진이기에 개발자의 편의를 위한 기능을 내장하고 있습니다. 보통 options.rpy파일로 이를 제어하고 있습니다.
바로 개발자모드를 활성화 하는 코드입니다. 물론 실제 상용 게임에는 True를 False로 바꿔서 개발자모드 진입을 막습니다. 그리고 파일을 쉽게 읽기 어렵게 하기 위해 rpyc형태로 배포합니다. 한번 컴파일한 형태이지요. 물론 rpyc는 쉽게 디컴파일이 되지만 Python 직접 접근 구문에서 간혹 파일이 깨지기도 합니다. 그러므로 rpyc파일을 디컴파일해서 rpy로 만든 다음 수정해도 되지만 이는 별로 추천하지 않습니다.
무엇보다 Renpy는 Python이기에 위험한 작업 없이도 쉽게 됩니다.
Python은 인터프리터 언어이고 이미 있는 객체의 이름을 다른 객체로 선언하면 이전의 객체는 무시됩니다. 그리고 Renpy는 스크립트를 읽어들일때 이름 순으로 읽습니다. 즉, A로 시작되는 파일을 읽기 시작해서 z로 시작하는 파일로 끝내는 것입니다.
그렇다는 것은 Options.rpy를 읽어들여서 개발자모드가 비활성화 되었다고 한들 z로 시작되는 파일을 읽어서 활성화 되면 개발자모드가 다시 활성화 되는 것입니다.
두근두근 문예부의 경우 이를 비활성화 해 놓았습니다. 막말로 이런 플레이어를 가지고 노는 게임이 개발자모드로 진입하면 이게 게임의 일부분인지 아니면 실수인지 알 길이 없지요.(오류메시지나 블루스크린마저 게임의 일부분으로 써먹는 게임이니까요. 진짜 오류메시지와 구분이 안 갑니다.)
RenPy로 만들어진 게임은 기본 언어가 Python이라서 성능이 생각보다 많이 좋지 못합니다.
심지어 아직도 Python2.7을 사용하기 때문에 3.x에서 해결된 GIL이슈가 아직도 현재 진행형입니다. 고작 2D게임 주제에 무슨 성능 이슈냐! 라고 하시는 분도 있을 것입니다. 그런데 나름 2D게임에서도 3D 효과를 쓰거나 투명도를 잔뜩 쓰는 경우 성능 이슈를 겪을 수 있습니다. 그리고 빠른 프레임을 원한다면 더 하지요.
이러한 RenPy로 만들어진 게임은 대략 다음과 같습니다.
Long Live The Queen
두근두근 문예부
아날로그
등등
일단 RenPy게임에서 성능 이슈라긴 뭐하지만 묘한 성능 이슈를 여기서 겪었습니다.
..JUST MONICA
뒷 배경을 보면 알파값을 심하게 써서 살짝 버벅거림이 눈에 띄더군요. 이유를 잘 몰랐는데 아래의 페이지에서 원인을 알 수 있었습니다.
아마도 OpenGL설정이 제대로 되지 않아서 성능 이슈가 생긴 듯 합니다. 그럴 때는 여기에 나온 대로 Shift+G를 누른 다음
여기서 Force OpenGL Renderer를 선택하시면 됩니다. 강제로 OpenGL로 돌아가면서 성능 이슈가 조금이나마 나을 겁니다. 전 어찌된 영문인지 Software로 잠시 들어갔었던 듯 합니다.
만약 LLVM Pipe 등의 Software OpenGL 렌더러를 쓰신다면 반대로 Force Software Renderer를 쓰시면 조금이나마 나아집니다. 그런데 이런 경우는 요즘 많이 없을 듯 하네요.
참고로 Windows에서는 DirectX 렌더링이 뜨기도 하는데 이걸 쓰면 성능이 더 나아지기도 합니다. 그런데 Windows에서는 어눌한 해킹드라이버를 쓴다거나 하지 않는다면 OpenGL 2.0로 굴러가지 못하는 경우가 없습니다. 그냥 일반적으로 기본 설정으로 하다가 이상하다 싶으면 강제 설정을 하시면 됩니다.
여깁니다. 어차피 무료이니 여기서 다운로드 버튼을 눌러보면 리눅스, 맥, 윈도버전을 다운로드 받을 수 있게 해놓았겠지요.
하하... 게임이 마음에 들면 기부해 달라고 하네요. 네 마음에 드신다면 여기서 필요한 만큼 금액을 적어서 Paypal이나 기타 방법으로 기부를 하시면 됩니다. 일단 저는... 무료로 해보기 위해서 "No, Thanks. Just take me Download." 를 위치고 다운로드를 하기로 했습니다. 그런데 10달러정도는 기부할 만한 게임입니다. 여러가지 의미로 말이지요...
펭귄그림이 윈도용과 함께 있군요. 그러니까 윈도용과 리눅스용은 공용판이었나 봅니다. Windows용을 다운로드 받으면 되겠군요.
사실 그동안 무슨짓을 했냐고 하신다면 먹고살려고 발버둥 쳤다고 밖에는 말 못하겠습니다. 하지만 먹고 살려고 하는 짓이라고 해도 그게 결국 먹고 살게 되면 문제가 되지 않지만 결국 발버둥에 그친다면...?
아무튼 그렇고 그런 발버둥이 있었습니다. 아직은 먹고 살만은한데 이러면 언젠가는 굶어 죽을지도 몰라요. 그래도 아직까진 희망은 있으니 그렇다고 해둡시다.
최근 Python가지고 이런저런 장난을 또 치고 있었습니다. 이 장난의 결과에 대해서는 나중에 제대로 올릴 예정인데 Python이란 언어가 재미있으면서도 선택의 기로에 섰다는 기분이 다분히 들고 있습니다.
사실 Python 홈페이지(https://www.python.org)홈페이지에 들어가면 두 가지 버전을 구할 수 있지요. Python 2.7과 Python3.x입니다. 그냥 쉽게 말해서 Python2와 Python3로 나뉘어진 셈인데 Python2는 2.7버전을 끝으로 더이상의 업데이트는 없다고 밝혔습니다. 그것도 2010년이었네요. 하지만 그 이후로도 2.7은 계속 쓰였고 아직까지도 2.7을 사용하는 프로그램들이 꽤나 있습니다. 사실 이해가 안 되는 것도 아닌게 Python3는 초기에 엄청 느렸습니다. 벤치마킹을 하면 Python2가 20%~50%정도 더 빨랐거든요. Python2와 Python3는 사실 겉으로보면 거기서 거기지만(80%정도 코드 재활용이 가능했습니다.)내부는 완전히 달라져서 Python3는 현대의 패러다임에 맞춰서 설계를 다시한 물건입니다.
이후 Python3는 2017년 지금 현재 상당한 성능개선이 이루어졌고 현대 하드웨어에 맞추어서 만들어졌으므로 Python2.7에 비해 효율도 상당히 개선되었습니다. 하지만 Python3초창기에 질렸던 사람들이 2.7을 고수하는 경우가 많은 것이 현실입니다. Python3의 개선점이 알려지며 많이 3.x로 교체가 이루어졌고 유명라이브러리는 3.x가 당연히 지원이 되고 있지만 문제는 개인 혹은 사내에서 사용하는 라이브러리가 아직까지도 2.7로 만들어져있는 경우가 많아서 2.7을 보안업데이트를 제외한 기능업데이트는 없다고 밝힌 지금까지도 이용되고 있습니다.
우리나라에서 Python이 제일 많이 쓰이는 곳은 어딜까요?
당연하게도 각종 서비스용 서버프로그램입니다. DB를 sqlite를 쓰고 Python으로 DB관리를 하면 굉장히 쉽게 사용이 가능합니다. 이외에도 모든 웹과 온라인 서비스를 Python으로 처리하는 경우도 많지요. 그런데 문제는 이런 서비스들이 2.x로 작성된 경우가 많아서 python3로 못 넘어간 경우가 많다는 점입니다. 이에 대한 원인으로 여러가지를 들 수 있지만 제일 큰 문제는 비용문제입니다.
사실 python2에서 python3로 넘어가는 것은 그렇게 큰 문제는 아닙니다. 코드의 80%가 재활용이 가능하고 대다수 라이브러리가 3.x호환이 되게끔 업그레이드가 이루어져서 약간의 노력만 하면 Python3로의 전환도 그렇게 어렵지는 않다고 합니다. 하지만 기존의 Python2기반의 서비스를 Python3로 전환하면서 몰랐던 버그가 발생할 수도 있고 (python2와 달리 python3는 무조건 유니코드기반이라 cp949를 기반으로 짰으면 고생길이 열리게 됩니다.) 충분한 테스트가 이루어지지 않으면 서비스가 중단되는 초유의 사태가 벌어질지도 모르기 때문에 이에 고민을 하는 것입니다. 그럴거면 일단 2020년까진 버티기로 버티고 그 다음 Python3로 넘어가도 늦지 않다는 생각을 가진것으로도 보입니다.
사실 테스트? 조금 시간들이고 비용을 조금만 들이면 얼마든지 할 수 있습니다. 디버깅제대로 안 하고 서비스하다가 망한 것이 어디 한 두가지입니까? 원래 디버깅은 모든 개발에 필수코스입니다. 그건 서비스를 하는 중에도 이루어져야합니다. 그럼 지원기간까지 버티다가 전환하는 것은요? 우리는 WindowsXP를 떠올려야합니다. WindowsXP는 연장지원 2년을 통해 일종의 유예기간을 가졌지만 전환을 늦게하는 바보짓을 하는 바람에 한동안 혼란을 겪고 말았습니다. 그리고 NPAPI지원도 크롬에서 지원을 끊겠다고 발표를 했음에도 이를 미루고 미루다가 결국 크롬의 NPAPI지원코드가 완전히 삭제되고 나서야 부랴부랴 PPAPI로 전환을 시작했습니다. (그런데 그것마저도 엉망이라는 느낌입니다.)
Python2.7의 지원기간은 3년정도 남았습니다. 생각보다 길다고 느끼실지도 모르지만 시간은 생각보다 빨리 지나갑니다. 그리고 Python3의 성능이 Python2보다 더 좋아졌음이 밝혀진 지금 이젠 성능핑계도 댈 수가 없게되었습니다. 그런데 아직도 2.7을 고수하시겠다면...?
당신은 그저 과거의 향수에 젖어 현재를 보지 못하는 늙다리일 뿐입니다. 개발자가 늙다리같은 생각에 빠져있다면 그 프로젝트는 이미 망한 프로젝트인 것이지요.
아직 늦지 않았습니다. 당신의 프로젝트 이제는 Python3로 시작해주세요.
P.S 우분투도 그동안 라이브러리 문제와 일부 프로그램 때문에 Python2.7을 기본탑재하고 있었습니다. 하지만 16.04이후로는 기본 탑재프로그램들이 Python3.5를 지원하고 있어서 Python2대신 Python3.5를 기본 탑재했습니다. 물론 Python2.7을 설치하지 못하는 것은 아니지만 저장소에서 python2.7이 사라질 준비를 하는 것으로 보입니다. 그때가 되면 python명령은 python2.7이 아닌 python3를 실행하는 명령이 되겠지요.
P.S2 업데이트가 굉장히 빠르기로 유명한 Arch는 python명령을 쓰면 Python3가 실행된다고 합니다. 버전업도 빠르기 때문에 무조건 최신버전이 뜨는 것이지요.
만약 아치를 쓰시는 분이 계신다면 터미널에서 python --version 명령을 쳐보세요.
P.S3 사실 이 글은 제 자신한테 하는 말입니다. Python으로 장난을 치는데 저도모르게 Python2스타일로 코딩을 하고 있더군요. 무의식적으로 Python2가 손에 너무 많이 익어버린 것 같습니다. 나름 의식하고 코딩을 하고 있지만 익숙함에서 나오는 그것은 정말 무서운 것이었습니다.
실시간 게임번역기란 물건이 있습니다. Monkey head's OCR Realtime Translator - 이하 Mort (http://www.steambb.com/bbs/board.php?bo_table=gamebb&wr_id=479632) 라는 물건입니다. 기존의 텍스트 후커는 API후킹방식을 주로 이용하여 이루어졌는데요. 이 방법은 그냥 화면에 나오는 문장을 OCR로 읽어서 텍스트를 읽어들입니다. 사실 이는 이전에 VNR(Visual Novel Reader)란 프로그램에서도 지원되는 기능이었지만 이 물건은 워낙 묵직했던데다가 API후킹도 지원되던 탓에 OCR방식은 잘 쓰이지 않았습니다. (모르는 사람도 있습니다.) 그에 비해 Mort는 성능도 괜찮고 그럭저럭 쓸만합니다. 단점이라면 Tesseract의 학습 기능을 어느 정도 쓰지 않았다면 인식률이 개판입니다. Mort는 학습 기능과 함께 이미지 전처리 기능을 넣어서 어느정도 인식률을 올린 듯 합니다. 그럼에도 여전히 엉망이라 Spell Checker 기능까지 우겨넣어서 인식률을 끌어 올려야 하더군요.
그래도 상당히 좋은 물건인 듯 해서 리눅스에서 돌릴 수 있는지 봤는데...
닷넷 프레임워크를 필요로 합니다. mono로는 실행이 안 됩니다. 그래서 약간의 폭발 이후 비슷한 클론을 하나 만들어 냈습니다.
...물론 대충 만들어서 모양은 별로이며 동일한 Tesseract 엔진이라 인식률은 꽝입니다. 심지어 이미지 전 처리 기능도 없습니다.....(PIL이나 OpenCV를 써서 넣으면 되기는 합니다만...)
적당히 만들어서 Gitjub 정도에 올리면 되지 않을까 생각하고 있습니다. 자신 있게 올리기엔 코드가 더러운게 흠이지만요.(저는 프로그래밍 전공이 아닙니다. 그래서 알고리즘이 최적화 되어있지 않습니다.)
제작 언어는 제작 속도가 더럽게 빠르기로 유명한 Python 2.7입니다.(3.x는 일부 라이브러리 때문에 사용 불가) 그리고 Tkinter와 기타 플랫폼 독립적 라이브러리를 이용했기 때문에 (OSX, Windows, Linux만 되기는 하지만)크로스 플랫폼(!) 입니다. Tesseeract-OCR를 라이브러리 형태가 아니기에 따로 추가 설치 해주셔야 합니다. (하지만 Tesseract-OCR도 각 플랫폼 별 바이너리를 제공하기에 큰 문제는 없습니다.)
Mort에 비하면 UI가 공대 감성입니다. 미리 말씀드리자면 완성된 프로그램도 아니고 그냥 비슷한 기능을 구현한 것입니다. 작동 되면 좋고 아님 마는 겁니다.
구성은 창 2개입니다. 왼쪽 터미널 위에 있는 컨트롤 창과 오른쪽 Scan Area 창 두 개입니다.
우선 캡쳐 하고자 하는 부분을 Scan Area 창으로 가려 버립니다(!) 저 Scan Area 창은 X버튼의 기능을 삭제 했습니다. 때문에 그냥 구역 설정 기능만 갖춘다고 생각하시면 됩니다.
...그리고 Start를 누르면...Scan Area창이 최소화되면서 해당 Area 부분을 캡쳐한 뒤 신나게 OCR로 읽어들입니다. 인식률은????.........아직은 포기하면 편해요. 이미지 전처리 기능을 만들지 않는 이상 인식률을 효과적으로 끌어올리기는 힘들 듯 합니다.
그리고 한국어 번역을 쓰는데 구글 웹 번역기(?)를 씁니다. goslate란 모듈이 이를 지원합니다. (영어 → 한국어) 보다는 (영어 → 일어 →한국어)가 더 번역율이 높다고 들어서 한번 해봤는데 구어체는 별 차이가 없습니다. 그래서 그냥 (영어 → 한국어) 로 처리 중입니다.
그냥 한번 어떻게 되는지 구경이나 해봅시다.
번역을 하고 싶은 부분을 찾아서 Scan Area 창을 신나게 가지고 놀자
일단 게임을 실행하고 작성한 파이썬 스크립트를 실행합니다. 항상 위 옵션으로 걸려있으므로 Scan Area 창은 절대로 게임 창 뒤로 가지 않습니다.
번역을 하고자 하는 구역을 Scan Area 창으로 가려버리자! 추후 여기에 번역문을 띄울까 하는 생각도 해봤지만...그건 별로
번역을 하고자 하는 부분 위에 창을 올려놓고 조절합니다. 그냥 가리면 됩니다. 참 쉽죠?
그리고 Start를 하면??? Scan Area 창이 자동으로 최소화 됩니다. 그리고 터미널에 보면!!!
왼쪽에 터미널을 주목하자 아직 출력 창을 안 만들었기에 터미널에 번역문을 대신 띄우고 있다. 참으로 공대감성이 아닐 수 없다.
....번역기의 성능은 기대 안 하는 것이 좋습니다. 어차피 구글 번역기이니까요. 심지어 잘 못 인식된 글자도 있네요. 저것은 이미지 전 처리 기능과 Spell Checker를 추가로 붙여서 보완해야 합니다. 하지만 이를 리눅스로 구현했다는 데에 의의가 있습니다. (그런데 테스트에 쓴 게임은 Windows용 Wine 구동 게임...)
이걸 조금만 더 다듬으면 훌륭한 크로스 플랫폼 실시간 번역기가 될 수 있을 듯한데 모양도 별로고 조금 공대 감성을 탈피해야 합니다. (범인은 Tkinter) 하지만 3일만에 만든 것 치고는 그럭저럭 괜찮네요. 이제 OCR된 문자열 및 번역문 츨력창을 따로 만들고 이미지 전 처리 기능을 넣고 Hunspell- Spell Checker (http://hunspell.sourceforge.net/)을 적용하면 인식률을 엄청 끌어 올릴 수 있을 것 같은데 뭐....언젠가는 하겠지요 뭐...
Long Live The Queen 프린세스메이커의 패러디 게임이라고 하는데 죽을일이 없는(가끔 가출은
하더만...) 프린세스 메이커와는 다르게 잘못된 선택은 곧 죽음인 살얼음판의 프린세스메이커라고 한다고해서 가격도 싸길래 냉큼
질러보았다.(사실 리눅스 지원인것도 한 몫했다. 리눅스 지원 게임이 그리 많지는 않으니..최근 개인프로젝트로 돌릴까 하는
클라우드게이밍도 스팀이 리눅스를 지원하면 그냥 클라우드 데스크탑에 스팀만 띄워주면 되니까 쉬워진다.)
일단 냉큼 지르고 영어의 압박을 간단히 떨친후(사실 영어로 되어있어서 반대로 게임하기 수월했다.) 뭐가뭔지 몰라(...) 공략을 찾던 중 이 게임이 Ren'Py라는 엔진으로 만들어졌다는 것을 알았다.
Ren'Py...
이름에 왠지 Py가 들어가는데다가 MacOSX, Linux, Windows를 전부 지원한다? 혹시 이거 Python?하고
스팀설치 폴더에 들어가서 뜯어본결과 Python맞더만...그것도 PyGame이라는 엔진을 비주얼노벨용으로 만든게 Ren'Py고
PyGame이 안드로이드도 지원하기 때문에 Ren'Py도 안드로이드 지원이 가능하다고 되어있었다.
그러나. 이 게임은 스팀에서 판매하기에 안드로이드 지원이 될 턱이 없었고 스크립트 언어인 Python이라면 별 저항없이 안드로이드에 이식이 되지 않을까 하던중 RenPy SDK에서 안드로이드 지원이 가능하다는 것을 찾아내었다.
흐음...이걸 일단 안드로이드에 이식해 보기로 하고 결국 휴일에 삽을 들고 말았다...에라이.
자 안드로이드 포팅(?)을 위한 준비물을 우선 말해보도록 하겠다. 여기서는 우분투같은 리눅스 환경에서 작업하는 것으로 되어있습니다. Mac이나 Windows는 스팀게임의 경로나 안드로이드폰 연결방법등이 다릅니다.
5. 손을 댈 Ren'Py로 만들어진 게임(여기선 Long Live The Queen 되시겠다. 이건 Steam관련 스크립트가 있긴 하지만...스팀없이도 실행되는 것을 확인)
6. rpatool https://github.com/Shizmob/rpatool rpa나 rpi등으로 이미지나 음악들이 압축 되어있는 경우 어쩔 수 없이 이 파일들을 풀어 해쳐놓아야 안드로이드에서 실행이 된다. 아니면 다른 방법이 있을 수도 있는데 방법을 잘 모르겠다.(...)
7. 삽질을 위한 안드로이드 기반 기기(에뮬레이터는 비추)
8. adb 안드로이드개발 홈페이지에서 다운로드 받던지 아니면 sudo apt-get install android-tools-adb
*. 당신의 삽질력
일단 되었으면 JDK와 Python을 설치하자.
그리고 Ren'Py SDK를 적당한곳에 압축을 풀고 RAPT를 Ren'Py SDK의 압축 푼곳에다가 같이 압축을 풀어넣자.
압축 풀기가 완료되었다면 renpy.sh를 실행해서 Ren'Py런처가 실행이 잘 되는지 우선 보도록 하자. 되었다면 예시로 같이 들어있는 것도 실행해 보고 이것저것 하다가 일단 종료.
이
제 스팀에서 Ren'Py게임을 구입하자. 아니면 조금 뒤적거리면 무료로 좋은 게임을 배포하기도 하니 잘 찾아보자. 걔중엔
지하철에서 하기에는 조금 엄한물건도 있기는 하지만....여기서는 아까 말했던 Long Live The Queen(이하 LLQ)을
이용하도록 하자. 그리고 꼭 한번 실행시켜주자. 가끔 스팀이 제대로 다운로드 안 하고 다 됐다고 사기치는 경우가 있어서
그런것이니 한번은 꼭 실행시켜보도록 하자.
실행이 확인 되었으면
~/.local/share/Steam/SteamApps/common 로가면 당신이 그동안 스팀에다가 쏟아부은 결과물들이 들어가
앉아 있다. 여기서 Long Live The Queen이란 이름의 폴더째로 일단 복사하자.
복사한
폴더는 위의 Ren'Py SDK와 RAPT의 압축을 풀어넣은 곳에다가 붙여넣기 하면 된다. 다시 한번 renpy.sh를
실행해보자. LongLifeTheQueen이 보이는가? 오른쪽에 Android라고 보이는가? 여기에 보면 Emulation으로
실행을 해볼 수 있다!!!! 그.러.나. 여기서 실행하면 당연하다는 듯이 에러난다. 이 에러를 잡는 것이 바로 이 삽질의
핵심이다.
삽질의 처음은 로그를 뜯어보는 것이다. 로그를 한번보자. glpatch.rpy가 에러가
났다고 나온다. 하지만 게임폴더를 아무리 뒤져도 rpy파일은 보이지 않는다. 사실 파이썬을 써보면 알겠지만 속도를 위해 한번
바이트코드로 컴파일하게 되는데 렌파이도 비슷한 원리로 스크립트를 컴파일 해 놓은 것이다. 즉 로그에서 rpy라고 나오는 파일이
사실 rpyc를 말하는 것으로 생각해도 좋다.
암튼 glpatch라는 놈이 문제라고 되어있는데 이미
컴파일되어있는 스크립트를 어떻게 해볼 수는 없고 한번 제거해보도록 하자.즉 삭제! 그리고 빈파일을 하나 만들어서
glpatch.rpy라고 하나 만들어 놓자. 빈 파일이기 때문에 아무런 내용은 없지만 그렇다고 파일이 없으면 그건 그것대로 또
에러가 난다. 말그대로 patch라고 되어있는 걸로 봐서 OpenGL관련 문제를 해결한 패치로 보인다. 그러나 안드로이드에서는
저게 도리어 문제를 일으키니 패치를 없애도록 하자. 그리고 한번 게임을 실행해보면 glpatch.rpyc가 생성되어있는 것을 알 수
있다. rpy가 빈파일이므로 rpyc도 빈내용으로 만들어진 바이트코드가 된다. 이걸로 한 가지 알 수 있는 것은 저 패치는
PC에서만 통하는 것으로 보인다는 것. 아마 Nvidia나 ATI드라이버 호환내용이 아니었을까?
왠 아이콘 이미지를 못 찾는다고 뜬다.(icon-big.png)ignore 버튼을 누르니 이번엔 배경이미지를 못찾는다고 하고 배경음악도 못찾는다고 하고..
이 파일들 아까 Game폴더에 없었는데?
사실 이것의 경우는 안드로이드용 렌파이의 문제일것으로 보인다. 게임 개발자나 회사에서 감추고픈(?) 이미지나 음악들이 떠돌아다니는 것을
싫어하기에 Ren'Py에서는 rpa라는 파일로 압축+암호화를 하는데 이게 안드로이드 내에서 정상적으로 복호화가 진행이 되지 않은
것이다. 잘 뒤져보면 llq.rpa란 파일이 보인다. 아마 못찾는다고 뜬 파일들은 이 안에 다 있을 것이다. 그럼 이걸 풀어서
game폴더에 흩뜨려 놓으면 정상적으로 실행이 될 것이다.
그럼 무엇으로 복호화를 할까? 아주 간단하게도 rpatool을 이용하면 된다. 이 것도 하나의 파이썬 스크립트로 되어있는데 그냥 game폴더에 넣어주자. 그리고 cd명령으로 game폴더까지 들어간다음
./rpatool.py -x llq.rpa
이러면 암호화되었던 것들이 압축이 싹풀리면서 보이게 된다. 그럼 이제 rpatool하고 llq.rpa파일은 필요없어졌으니 삭제하자. 겸사겸사 bytecode.rpyb파일도 삭제해주고.
이제 다시 빌드하고 폰에 넣으면?
타이틀화면 입성! 게임까지 입성이다!!!
오오..
힘든 사투였다.오오..근데 이 게임을 지하철에서 하는 건 좀 무리 아니려나...
2014. 7 .26 우선 안드로이드 포팅을 하는 방법을 올린 유튜브 영상이다. 본인이 찍었으며 이 방법을 통해서 만들어진 결과물을 마음대로 배포하지를 않기를 바란다. 만들어진 결과물은 개인적으로만 사용하고 꼭 스팀에서 구입한 것을 이용하자. 공식홈페이지에서 구입한 것은...잘 모르겠다.
