Sunrider Academy는 스팀에서 팔고 있는 야겜*-_-*입니다.

스팀에디션과 Denpa에디션이 있는데 스팀에디션은 검열삭제를 했고 Denpa에디션은 그냥 풀버전입니다..그래서 Steam to Denpa로 만들어주는 모드도 돌아댕기고 있습니다. 뭐..이건 저한테 묻지마세요.

일단 이놈도 렌파이 기반입니다. 따라서 안드로이드 포팅이 됩니다.

Ubuntu 14.04

OpenJDK7

Python 2.7

Ren'Py 6.99.10

rpatoolhttps://github.com/Shizmob/rpatool

Android 4.0 IcecreamSandwich이상

고맙게도 Long Live The Queen때와는 다르게 rpy파일이 같이 있습니다. unrpyc같은 고생은 안 해도 됩니다.

그냥 Renpy폴더에 /.steam/steamapps/common에 있는 Sunrider Academy 폴더를 복사해서 가져옵니다.

그리고 rpatool을 Sunrider Academy/game폴더에 넣고 다음과 같이 명령을 내립시다.

python rpatool -x archive.rpa

그러고 나면 rpa아카이브가 풀리면서 CG등을 볼 수 있게 됩니다. 이 부분은 안드로이드가 rpa지원이 아직이라 rpa를 풀어주는 작업을 하는 겁니다.

그리고 렌파이를 실행하고 안드로이드 포팅을 시도하면....'

에러납니다.

렌파이 엔진은 무한루프를 막기위해 일부 기능이 작동하는데 무한루프가 아님에도 성능 문제로 이 기능이 작동해 버린겁니다. 따라서 위험하기는 하지만 일단 안드로이드 APK을 만들기 위해 해당 기능을 정지하도록 합시다.

본래 renpy.exe renpy.sh가 있는 폴더(즉 SDK)에서 renpy으로 들어가시면 execution.py가 있습니다. 여기서 한줄을 삭제합니다.

54번째 줄 raise Exceptoion~~앞에 #을 넣으시면 됩니다.

요렇게 말이지요.

이제 안드로이드 빌드를 하면 무사히 되기는 하는데 오프닝 영상에서 에러납니다. 제일 무식한 방법은 오프닝을 스킵하는 겁니다.

game/script.rpy열고 308, 310줄 앞에 #을 붙여서 오프닝 자체를 재생못하게 하면 무사히 넘어갑니다. 아니면 안드로이드에서 그냥 재생 가능한 형식으로 인코딩 하면 되는데 game/CG/opening.avi 파일을

https://www.renpy.org/doc/html/android.html

http://developer.android.com/intl/ko/guide/appendix/media-formats.html

여기를 참고하셔서 해당 형식에 맞게 인코딩 하면 되는데 귀찮으니...그냥 오프닝을 스킵하는 것으로 결정했습니다.... webm정도가 가장 적당할 것으로 보이는데....인코딩은 너무 귀찮습니다. 어차피 오프닝 잘 보지도 않으니 넘어가는 것으로...(성능문제도 있고...)

한글패치는 안드로이드 빌드 전에 ghap님 블로그(http://ghap.tistory.com/category/SUNRIDER%20ACADEMY)가서 미리 적용해주시면 끝입니다. LLTQ와 달리 그냥 덮는 방식이라 따로 사후 작업은 없습니다.

...근데 이거는.LLTQ보다 더 하기 힘들겠는데..??

2016. 5.6

하다보니 안드로이드 버전만의 버그가 있습니다. 점심시간, 방과후에 맵 선택 부분에서 버그가 있습니다.

자세히 보니 focus_mask 옵션 관련 버그입니다. 현재로써는 방법이 없는듯 해서 그냥 maps.rpy파일을 그냥 뜯어 고쳤습니다. 기존에는 마우스 선택을 기준으로 잡혀 있었는데 버튼을 클릭해야 넘어가게 했습니다. 지금 보니 코드가 원래 더러웠네요. 작은 기업이라 어쩔 수 없었겠지만 솔직히 코드가 통일성이 없습니다... 뭐 이따위로 만들었냐...

일단 maps.rpy만 왕창 수정해서 올립니다. (결국 수정해야 했잖아..)game 폴더에 덮어주세요.

maps.rpy

이번에은 간단하고 짧고 그러나 의외로 많이 쓰일 만한 내용을 알려드리려 합니다.

사실 별로 중요한 내용은 아닙니다. 어쩌면 평생 쓸 일이 없을 지도 모릅니다. 하지만 *nix계열을 사용한다면 이 명령 하나만큼은 정말 강력하게 쓰게 될 겁니다.

dd

네 dd 입니다. 리눅스, 유닉스, OSX, 심지어 Win32, Win64용으로도 포팅해서 쓰는 dd입니다.

dd는 정말 강력한 프로그램입니다. 그리고 SSD시대에 도래하면서 그 효용성은 더욱 좋아졌습니다. 그런데 어떤분은 이러실 겁니다. 그래서 dd가 뭔데?

Windows용으로 제일 유명한 dd계열은 Win32 Disk Imager가 있습니다. IMG파일을 USB에 입힐 때 쓰는 바로 그 프로그램입니다. 사실 이 놈은 dd가 쓰는 구동을 Windows용으로 컨버팅한 것입니다. dd 그 자체를 포팅한 것도 있지만 Windows는 cmd가 편하지가 않아서 (사실 터미널이 편하다는 것도 무리이기는 합니다...) GUI로 만들어 낸 것이지요.

Windows에서 IMG나 ISO입히는 것으로 제일 유명한 Win32 Disk Imager. 대다수 책들이 이놈을 설명한다.

dd는 본래 명령줄 프로그램입니다. 하지만 명령체계는 단순합니다.

dd if=~~ of=~~ bs=~~

이겁니다. if는 입력 of는 출력 bs는 한번에 얼마나 이미지를 입힐지.

이렇게 생각하시는 분들이 있을 겁니다. 장치에서 파일이나 파일에서 장치로 입히는 것은 어떻게 하는 거지? 뭐 이런식으로요. 그런데 *nix들은 장치조차 파일로 취급합니다. 무슨이야기냐면 /dev/안에 폴더를 보면 수많은 0바이트 파일들이 있는데 이 파일들이 실은 그 장치와의 인터페이스 입니다. 

요것들이 사실은 전부 시스템에 연결된 장치 그 자체다. 이는 Linux인 안드로이드와 BSD인 iOS도 동일

이 파일에 내용을 써넣는 것으로 장치에 신호를 보내는 것이고 이 파일의 내용을 읽는 것으로 장치에서 신호를 읽어오는 겁니다.

예를 들어 /dev/video0는 사실 컴퓨터에 연결된 웹캠인데요. 여기서 /dev/video0의 파일내용을 읽어들이면 Linux4video2 형태로 만들어진 이미지 하나가 튀어나옵니다. 또 /dev/ttyS0는 장치에 연결된 시리얼 포트입니다. (Windows 기준으로 COM1)여기서 파일 내용을 쭉 읽어들이면 시리얼통신으로 들어오는 모든 신호를 읽어들이는 겁니다. 반대로 파일에 내용을 써넣으면 시리얼통신으로 내보내는 것이고요. 비슷한 것으로 /dev/ram 이라던가 여러가지가 있습니다.

참고로 내부 HDD는 /dev/sdXY(X는 순서대로 a, b,c 순서로 되어있습니다.Y는 파티션 번호입니다. 즉 숫자입니다. )이고 CD같은 광드라이브는 /dev/srY(마찬가지로 숫자입니다.)입니다.

그냥 위의 장치를 그대로 dd로 파일로 떠버리면 이미지가 되는 겁니다.

즉, CD드라이브가 /dev/sr0이고 ~/CD.iso파일로 읽어내고 싶다면

dd if=/dev/sr0 of=~/CD.iso

이거면 홈폴더에 CD.iso파일이 생기면서 이미지가 떠지는 겁니다. 그냥은 속도가 굉장히 느리고 답답하므로

dd if=/dev/sr0 of=~/CD.iso bs=4M

이렇게 해주시면 한번에 4Mb씩 쓰므로 속도가 꽤 빨라집니다. 이미지를 떴으니 이걸 다시 CD-R이나 CD-RW 혹은 DVD-R등으로 구우려면 그냥 iso파일을 브라세로 같은 프로그램으로 구워버리면 됩니다. 그냥 인터넷등지에서 흔히 보시는 iso파일이 이렇게 뜨는 겁니다. (물론 Windows에서 Nero나 Easy CD Creator같은 것으로 뜰 수도 있기는 합니다.)

USB메모리나 HDD등도 마찬가지입니다. 물론 이미지 파일은 읽고 있는 디스크에 만들면 안되겠지요.

dd if=/dev/sdb of=~/HDD.img bs=4M

이렇게 하면 홈폴더에 HDD.img라는 디스크를 통짜로 복제한 이미지가 떠집니다.

디스크가 아닌 파티션을 복제하려면 /dev/sdb대신 /dev/sdb1 처럼 뒤에 숫자를 붙이시면 됩니다.

dd if=/dev/sdb1 of=/dev/sdc2 bs=4M

이렇게 하시면 /dev/sdb의 1번 파티션의 내용을 그대로 /dev/sdc 디스크의 2번 파티션에 덮어버립니다. 다만 이 경우 /dev/sdc의 2번 파티션이 충분히 크지 않으면 3번 파티션까지 밀어버립니다. 강력한 만큼 따로 안전장치가 없기 때문에 주의하셔야 합니다.

반대로

dd if=~/USB.img of=/dev/sdb bs=4M

이렇게 해주시면 /dev/sdb에 그대로 디스크 이미지를 덮습니다. Win32 disk Imager가 하는 것과 동일하지요. 하는 짓이 예전에 많이 봤던 Norton Ghost를 닮았네요.

사실 *nix에서 Ghost가 따로 없는 대신 이 dd를 참 많이 이용합니다. 온라인게임에서 악명높은 백섭할 때 보통 이용한다고 합니다. 명령 한줄이면 쭉 되니까요. 해킹피해나 서버가 맛이 갔을 경우 dd로 처리하는 경우가 많습니다. 요즘은 btrfs나 BSD의 JFS의 스냅샷 기능을 쓰는 경우도 많지만 예전에는 dd를 써서 처리했다고 합니다. 사실 그 만큼 강력합니다.

어떠신가요? 명령어 한 줄의 위력이 대단하지 않나요? 이런 강력한 명령어 덕에 가상화같은 최신 기술도 사용하고 지금의 클라우드 컴퓨팅도 가능해진 것이랍니다. ISO를 뜨는 법을 물어보시는 분들이 가끔 있는데 dd가 바로 그 답입니다.

P.S

이런 강력한 명령어를 GUI로 구현하는 프로젝트도 당연히 있습니다. 

https://sourceforge.net/projects/ddgui/

여기인데요. Windows도 지원하고 꽤 지원범위가 넓습니다. 그런데....저는 이제 명령어가 익숙해서 안 건드리게 되네요. CMD나 터미널과 아직 어색하신 분들이라면 참고하세요.

TextHooker란 프로그램들을 아시나요? 사실 대부분의 일본산 비주얼노벨 게임을 하신 분들이라면 비슷한 프로그램들을 상당히 많이 알고 계실겁니다.

제일 유명한 것이라면 TextHooker중에서 제일 대중에게(?) 퍼진 Oh! TextHooker가 있습니다. 이외에도 4chan에서 만든것으로 추정?되는 AGTH(Anime Game Text Hooker)와 중국에서 만든것으로 보이는 VNR(Visual Novel Reader) 등이 있습니다. 상당히 많은 프로그램들이 있는데 이들의 공통점은 공통적으로 쓰이는 API(대표적인 것이 TextOut())를 후킹해서 문자열을 끌어낸다음 번역기나 사용자사전을 써서 번역된 문장을 출력하는 것이 목적입니다.

각종 TextHooker의 할아버지뻘인 Oh! TextHooker 지금도 돌아가는 게임이 있다! (출처:http://ohhara.sarang.net/ohthk/scrshots.html)

가장 최신의 기술로 무장했고 편의성도 훌륭한 VNR의 모습. 출처 : https://namu.wiki/w/VNR

API후킹 기술은 사실 어둠의 영역에서도 자주 사용되었고 빛의 영역에서도 상당수 이용됩니다. 대표적인 어둠의 영역은 키보드의 이벤트를 후킹해서 키입력 로그를 만들어 해킹하는 곳에 사용되는 것을 말 할 수 있습니다. 하지만 대개 이런 부류는 백신에서 쉽게 잡아냅니다. 빛의 영역은 시각장애인용 TTS프로그램을 들 수 있습니다. 마우스를 움직이면 마우스 아래에 있는 문장을 읽어들여서 TTS로 읽는 것이지요. 이런 프로그램은 상당히 종류가 많습니다. 그런데 리눅스에서는 이런류의 프로그램이 사실상 없습니다. Firefox나 Chrome의 확장에서는 있는 것 같지만 인터넷 웹환경에 한해서만 작동하기 때문에 한계가 있습니다.

애초에 이런 게임들이 당연히 (일본어판) Windows전용이다보니 참 문제가 많습니다. 리눅스에서 굴린다는 것 부터가 이미 글러먹은 것이지요. 그것도 번역기를 통하려고보니 더 엉망진창이고요. Wine은 DLL injection이나 API Table같은 기술이 잘 먹히지 않습니다. 본래의 API와 외부 구조는 비슷하지만 내부 구성이 다르기 때문입니다. (내부 구성까지 같으면 Wine은 Windows의 저작권에 위배되는 프로그램이 됩니다.) 즉 VNR이나 Oh! Text Hooker는 정상적인 동작이 보증되지 않습니다.

애매한 것으로 Mort란 것이 있기는한데 이건 OCR을 쓴 것이니 넘어가도록 합시다.(이전에 제가 Mort의 기술을 써서 리눅스에서 비슷하게 굴린적이 있습니다.)

그런데 API 후킹의 원리는 API의 외부 구성을 그대로 만들고 본래의 API대신 자신이 끼어들어 이리저리 조작한 후 본래의 API를 호출하는 원리입니다. (본래의 API를 호출하지 않으면 프로그램이 정상적으로 돌지는 않을 겁니다. 문자열이 나와야 하는데 안 나온다거나...)그런데 이거 Wine이 하는 짓하고 비슷합니다. http://moordev.tistory.com/83 그래서 저는 여기서 이런 방법은 어떤지 제안을 한 적이 있습니다. 해 본 결과 폭망이었지만 (애초에 구조가 달라서 먹히지 않습니다.) 역으로 리눅스에서 Wine으로 게임을 굴리면서 후킹하는 것은 어렵지 않게 구현할 수 있었습니다. gdi.so소스를 뜯어고치면 TextOut()함수를 내 마음대로 돌아가게 하는 것은 어렵지도 않고 CreateFont()함수도 고쳐버리면 폰트도 내 마음대로 바꿀 수 있게 되는 겁니다.(이건 AppLocale의 원리와 같습니다.)

그래서 sprintf함수로 문장을 처리하는 게임을 타겟으로 삼아 Wine에서 구현한 sprintf함수 조작한 다음 sprintf 출력 문장을 디버그창에 띄우게 했더니...의외로 잘 나오네요.

......이거 잘하면 리눅스용 후커도 만들 수 있을 것 같습니다. 번역 엔진이 문제이기는 한데 그건 그냥 구글번역을 통하면 될 듯하고 Chrome하고 연동하는 방법을 쓰면 구글번역기능도 쉽게 쓸 수 있을 듯 합니다. 하지만 이건 윈도용 게임이야기이고 리눅스용 게임은.....나중에 생각하도록 합시다. 아직 리눅스용 게임은 이러한 물건은 적으니까요.