Zournal - zuke가 바라보는 세상.
모바일 게임 만들면서 어려웠던 점... 본문
모바일 게임 기획자가 되면서 선임 기획자에게 배운 것은 단 하나...
화면사이즈였다.
각 폰마다 규격화된 몇 종류의 화면 사이즈들...
우선 화면 사이즈 때문에 엄청나게 고생했다.
PC겜이나 콘솔게임은 통일된 규격화가 있었지만, 헨드폰은 워낙 발전속도도 빠르고, 각 헨드폰마다의 화면사이즈가 다르니..
처음 시작할때는... 120 * 106, 120 * 114, 128 * 146, 176 * 183 의 사이즈에 동일한 게임이 돌아가게 만들어야 했다.
이게 무슨 소리인지....
도대체 이해가 되지 않았다.
간혹, 각 화면 사이즈 별로 따로 게임을 제작하는 회사도 있었지만, 단 하나의 게임으로 모든 화면 사이즈에서 이상하지 않게 돌아가게 만들어야 했다.
120 * 106과 176 * 183의 차이는 정말 하늘과 땅 차이였다.가로 56, 세로, 77 픽셀의 차이...
좌절이였다.
화면 사이즈라는걸 전혀 생각해본적없는 나로서는 정말 힘들었다.
그리고 중간 중간 출시되는 이상한 화면사이즈의 폰들, 지금이야 가로본능이라는 폰이 있었지만, 작년 초만해도 가장 난수는 모토로라에서 나온 정사각형... 이건 가로가 넓고 세로가 좁아서 다른 폰과는 완전 반대였다.
두번째는 각 폰마다 다른 힙 사이즈 (PC로 말하면 메모리를 말한다.)
출시되는 폰마다 다르고, 같은 시기에 출시된 것도, 다르니..
현재 카샨과 같은 게임은 힙사이즈 500K 에서도 돌아가지만, SPH-S1000과 같이 힙사이즈가 10MB인 폰에서도 돌아간다.
힙사이즈 500KB와 10MB가 같은 게임을 돌려야 한다니....
당연히 힘든 것이다.
세번째는 해당 플랫폼의 차이...
PC게임이야 대부분 C++ 로 구현한다고 하지만, 모바일 게임은 각 통신사 별, 해당 플렛폼으로만 제작해야 한다.
SKT는 GVM, GNEX, SKVM, WIPI,
KTF는 BREW (이전에는 MAP이라는걸 썼다.), WIPI
LGT는 MIDP와 WIPI
WIPI는 최근에 정통부에서 통일한 것이지라 제외해도 각 통신사 별로 이런 플렛폼이 있으니.. 하나의 플렛폼에 맞춰서 재작하기가 힘들다.
특히 C기반인 플렛폼과 JAVA기반인 프렛폼이 있으니 이 둘사이의 컨버팅도 쉬운일이 아니였다.
네번째는 게임의 용량이였다.
GVM 게임은 최대 128KB 안에 게임을 만들어야 했다. 하지만, 유저의 눈은 높아가고..
요즘은 GVM을 거의 사용하지 않고, JAVA기반의 SKVM을 사용하는 경향이 많이 늘었지만, 역시 JAVA기반이라
속도가 느리다는 단점이 있다.
하지만, 무한정 게임의 용량을 늘여나갈 수는 없는 법.
앞에서 말한대로 GVM은 플렛폼자체가 128KB 이상은 게임이 실행이 되지 않고, KTF BREW는 내부적으로 250KB라는 규정을 만들었다. 게임의 퀄리티는 높여야 하고, 용량은 줄여야 하고 ... 어려운일이였다. ㅠㅜ
규제가 없다고 해도 무한정 용량을 늘일 수가 없는 것이.. 바로 다운로드를 할 때 드는 통신비..
용량이 큰 게임은 유저가 기피하는 현상이 있다. 그만큼 무선인터넷 비용이 많이 나오니까.
2000원짜리 게임 다운받는데 무선 인터넷 비용이 3000원 이상 나오게 되면 배보다 배꼽이 더 큰 격이 아닐까?
다섯번째는 두번째랑 비슷한데, 구형 헨드폰과 신형 헨드폰의 조화.
구현 헨드폰에서도 돌아가야 하고, 신형 헨드폰에서도 돌아가야 한다는 것...
구형 헨드폰에서도 돌아가야 하니.. 게임의 퀄리티는 크게 향상되기는 어려운 것이다.
여섯번째는 각 통신사 마다 다른 U/I
게임을 제작할 때 게임에 어울리고 가장 편한 인터페이스를 구상하게 된다. 하지만, 규격화된 U/I로 인해 오히려 유저에게 불편함을 주게 되고, 컨버팅시 다른 U/I 때문에 여러가지를 다시 구상해야 하는 점이였다.
간단하게 여섯가지를 나열했지만...
모바일 게임을 만드는 어려운점은 한두가지가 아니다.
물론 온라인, 콘솔 게임을 만드는 쪽이 몇 백배는 어려운 점이 많겠지만..
모바일 게임도, 후딱 대충 만들어지는 게임이 아니라는 것이다. ㅠㅠ
그냥 개발자 입장에서 유저들도 이러한 고충을 좀 알아줬으면 하는 바람이다.
zuke