Rythmnamu(리듬나무) 제작과정, 그리고 파탄까지의 앱 제작기.

결론을 줄여서 말하자면 -

나에게 OutOfMemoryException으로 뙇!을 주다니!

입니다 (....) 그 넘쳐나는 갨S2의 800MB 가용램은 왜 다 쓰질 못하니!

서론은 이러하고, 만들었던 프로그램의 정리 겸사겸사, 쭉 정리해 보겠습니다.

---

1. 무슨 프로그램인가

이런 느낌의

리듬꼐임 앱입니다 (....)
이클립스 기반의 자바 언어로 제작했었습니다.
게임 형식은 유비트랑 비슷똑같습니다. 하지만 파일 기반은 BMS라죠.
미리 만들어진 곡도 많고, 제일 중요한 핵심은 바로 8키 매칭!
그리고 마커를 "벌목"식으로 바꾸어서 .... 돈나미의 저작권을 피하면 만사 ㅇㅋ! (?!?)
패널 수도 4x4가 아니라 2x4로 했습니다. 안드로이드로 보니까 딱 맞더군요.

요런 느낌!

덤으로 설렉 상태도 (?)

EUC-JP는 깨져 나와야 제 맛...

2. 프로그램의 구조는 어떠한가

나름대로 정식(?) 프로그램이기 때문에... 게다가 모든 UI가 드로잉과 터치 이벤트만으로 처리 되어야 하기 때문에... 클래스별로 나누어서 이번에는 프로그램을 계획해 보았습니다.

조금 형편없게 나누긴 했지만.. 요렇게 나눠봤습니다.

class RythmNamuActivity
 - 핵심요소죠. 프로그램을 구동하는 뼈대.

class RythmView
 - 드로잉이 이루어지는 뷰입니다. 하지만 실질적인 드로잉은 타 클래스에서 이루어집니다.
 - 프로그램이 메뉴상태인가, 플레이상태인가, 스코어상태인가, 옵션상태인가 에 따라서 크게 4가지로 뷰를 처리할 클래스를 선정하도록 했습니다. (하지만 정작 클래스는 아직 2개밖에 못 만들었군요)

class Menu
 - 메뉴 부분을 담당하지만, 정작 상표(?)로고, 메인메뉴, 그리고 Select UI 까지 담당한다는 것이 에러. 조금 규모가 큰데.. 나누기도 애매한 것 같기도 하고, 일단 그런 일들을 합니다.
 - 설렉부분에서는, 키가 8개인 SP(싱글플레이어)모드인 곡들만 읽어야 합니다. 그래서 설렉부분에서는 BMS를 미리 읽게 됩니다 (로딩에 표시되지요...). 그런데 맛폰의 한계 답게 느리다!라는게 느껴집니다.

class Play
 - 게임 플레이 부분을 담당합니다. 역시 하는 일이 많습니다. 일단 다중터치를 담당하여, 누르는 이벤트를 감지/발생시키도록 하고, BMS 로드뿐만 아니라 판정담당도 하고 있습니다.
 - 비트맵/음악을 로드하는데.. 짱 느립니다 으어어! 키음도 제한적으로 지원하고 ... 안드로이드 OS 자체의 한계지요.
 - 판정은, 현재 시간에서 이전 노트와 이후 노트 각각 한 개씩의 시간을 구하고, 그 중에서 시간차가 적은 녀석과의 차이에 따라서 판정을 짜도록 했습니다. 물론, 이미 판정 처리된 노트가 아닌 선에서 말이지요.
 - 음악재생과 비트맵은... 현재 시간이 비트맵/음악의 인덱스 시간을 넘어가면 그때 하나씩 재생하면서 인덱스를 넘겨준다, 이런식으로 메인 타이머에 처리 루틴을 넣어서 확인하고 있습니다. (메인 타이머 함수에 판정,터치,드로잉,음악재생 부분 다 들어가네요...)

class BMS
 - BMS 파일을 읽어들이는 부분입니다
 - 자료구조는 "MAIN DATA FIELD" 이전의 자료들은 ArrayList로 "#속성", "값"과 같은 식으로 저장하도록 했습니다.
 - "MAIN DATA FIELD" 이후의 자료는 각 줄의 자료를 읽고, 2 글자씩 읽어서 "00"이 아닌 부분의 노트의 시간을 직접 계산하여 각 노트별 시간 순서대로 스택에 차곡차곡 쌓듯이 저장했습니다. (타 리듬게임에서도 이런 식으로 처리하는지는 모르겠네요... 스텝매니아에서는 이렇게 처리하는 것 같기도 하고.)

BMS 형식 부분은 ruv-it! 공식 사이트와 메아리 풉 사이트를 참조해서 만들었습니다. 물론 절대 완벽한 상태는 아닙니다. 확장 명령어 하나도 인식 못해요.. 초 간단한 기본 형식만 지원합니다 ;; ... 추후 보강이 절대적으로 필요하지만 일단 이 정도 상태에서도 어지간한 BMS는 읽어들이므로 스킵.


다중해상도는 canvas.scale로 처리하려고 했는데.. 마우스 밉맵은 어떻게 해야 하나 싶더라고요. 그건 나중에 해결해도 늦지 않은 문제니, 일단 스킵.

3. 무엇이 문제인가!

그리고 프로그램을 가동하면!!!!! 오오!!! 노래가 나온다 나와!!

그리고...

A. SoundPool의 재생 최대 갯수는 무궁무진하지만 아무리 많이 걸어봐야 소용 없단다!

음악 파일도 180개밖에(?) 안되는 A c i - L 에서... 재생 20~30초정도 하면..

"AudioFlinger could not create track, status: -12 / Error creating AudioTrack"

이것이 의미하는 바는 바로 메모리의 한계라 하니... 아니 다중 키음이 있는 BMS형식에서 저더러 뭘 어쩌란 말입니까?!
패.배.


B. 파일이 50MB 가까이 되면!!!

전기 튜브로 유명한(신발폭타도 있지만, 애써 무시합시다 ^*^) Dengeki Tube.
용량은 50MB입니다.
제가 직접 한번 로드해 보았습니다.

뙇!!!! 읽다가 나 견딜수가 엄어.. 하면서 에러가 납니다.
메모리 초과 오류입니다.
비트맵을 더 줄여도 어지간히 에러가 뜹니다. (빨간 표시 한 부분). 17메가도 할당 못 하다니... 포기.

다른 소소(?)한 에러들도 많지만 뭣보다...
리듬게임에서 소리가 안 나다니! 이게 무슨 소리요!!
.. 으앙 하면서, 3~4일간의 삽질은 물거품이 됩니다.
안드로이드 안정화되기 전까지 할 수 있는 게 없네요. 늅늅....

4. 프로젝트 파일

Rythmnamu.zip

이 파일이 이클립스용 파일이고 (...)

RythmNamu_Apk.zip

요건 Apk와 이런 저런 파일들 ...

뭐, 해 보시면 알 겁니다. 몸소 실천하면 좌절이 보이리!

5. 후기

 - new 객체 생성 하기 전의 obj를 줘 놓고 이후에 다른곳에서 obj = new Menu(); 처리해서.. 널 포인트 에러 발 생해서 ... 아리송했던 기억이 나네요 (....)

 - Non-Debugging 모드에서는 BMS 로드 속도가 Debugging 모드보다 5배는 빠른것 같습니다. 진심 (...) 이러지 마라!

 - 리겜 이야기 하다가 생각난건데, 어뮤즈카드는 Felica 형식의 단거리통신을 하는데, 폰에서는 NFC로 어뮤즈처럼 쓸 수 있다고 하더라고요! 찾아보니까 일회용인 문제가 있긴 하지만 일련넘버를 폰에 저장시키는 것만 구현한다면 되는데.. 마침 진행중인 Felica 프로젝트가 있더라고요! 문제는 ... 아 내폰에 NFC 기능이 없다! 헬지라 그렇다! .... 망.

 - [추후 재개발 될지도 모름] SoundPool 객체에서 Play가 Return하는 Integer을 이용해서 다시 재생시키거나 해야 메모리 오버플로가 발생하지 않는대요 ... 으아 이게 무슨 소리야! 그리고 비트맵은 libGDX와 같은 안드로이드 게임 라이브러리를 쓰면 다시 개발할 수 있을것 같은데.. 으으.. 일단 시간도 없고 해서 보류.