오늘자 신문에

넥슨모바일, 모바일게임 퍼블리싱사업 전면화

란 기사가 떴다.(저번 포스트에서 씹었던 기자가 또 쓴글이다. 또 한번 씹어주고 싶지만 이번 포스트의 주제와는 동떨어지므로 통과~)
국내, 빅3라고 불리우는 이들이 퍼블리싱이 전면적으로 한다는건 사실 새로운 이야기도 아니다.

퍼블리싱에 대해 참 할말이 많지만 이번 포스트에서는 몇가지 오해만을 한번 정리해보고자 한다.

1. 퍼블리싱을 하면 개발자는 필요없다.
애초에 이러한 오해는 퍼블리싱에 대한 Role Define에 명확하지가 않고, 모바일 산업에 대한 이해가 부족할 때 생기는 말이다.(참고로 여기서 개발자라는것은 기획자, 디자이너, 엔지니어를 통칭하는 것으로 하겠다.)
모바일 산업의 특성상 다양한 폰이 나오고 새로운 LCD Size 등이 많이 나오게 된다. 또한 그 높으신 통신사 양반들의 자잘한 요구가 좀 많은가? 그 많은 응대와 품검 오류등을 그때그때마다 개발사에게 연락을 해서 수정 요청을 하고, 또 테스트 하고, 그것을 다시 통신사에게 보내는 것은 사실 Communication Cost가 너무 높게든다.

"내가 알고 있는 몇 업체는 개발자 없이 잘 하고 있는데" 라고 하겠지만 아마도 그 업체는 작은 규모의 스튜디오 퍼블리싱이 아니라 어느 정도 시스템이 잘 갖추어진 업체와 일을 하고, 저러한 일이 발생 될 때마다 개발업체의 현재 일정 싸그리 무시하고, 이쪽 업무를 최우선으로 해달라고 할 것이다. 그것은 퍼블리셔가 아니라 또하나의 "갑"이다.

게임 자체를 개발을 하지는 않겠지만 최소한의 가벼운 응대는 그때그때 해결을 할 수 있어야 하며, 이벤트 마케팅이 있을 때 그 부분 수정을 하거나(물론 업무가 크면 개발사에서 해야겠지만 대부분 모바일 마케팅이 그 정도 이슈가 있지는 않다.) 각종 이벤트에 따르는 포스터 작업 등등을 할 수 있는 인력은 있어야 한다.


2. 퍼블리싱은 리스크가 없다.
대부분 말로는 "퍼블리싱이 리스크가 없는게 아니라 자체 개발보다 작다" 라고 이야기 하지만 정말 그렇게 생각하는 사람이 그닥 많지가 않다.
퍼블리싱은 다 만들어 놓은 게임을 보고 성공 여부를 판단한 후에 계약하는 것이 다는 아니다. 퍼블리싱의 한 부분은 되겠지만 그게 전부는 아니란 소리다.
기획서나 프로토타입 등을 보고 가능성을 판단하여서 선투자(개발비) 해서 좋은 게임의 라인업을 갖추고 이들을 위한 효율적인 마케팅을 먼저 제안 할 수 있는 것도 퍼블리셔의 중요한 모델이다.
국내 모바일 퍼블리셔의 개발비 지원은 아직까지는 선투자 보다는 원가 수준의 개발비 지원, 타플랫폼으로 컨버팅하는 비용을 지원하는게 대부분인 듯 하다.
현재의 퍼블리셔 입장에서야 당연한거라고 반문하겠지만 역시나 또하나의 "갑"의 행태로 보인다.


3. 퍼블리싱은 Q.C, 운영만 하면 된다.
물론 온라인 게임의 퍼블리싱 모델이 모바일 산업에 그대로 적용되는 것은 아닐 것이다만 런칭업무에 너무 치중하는 것은 좋지 못하다.
기획서를 보면서 좀더 좋은 개발 방향에 대한 가이드 라인을 제공하거나 향후 관리를 위해서 공통 개발 라이브러리 플랫폼 등을 제공하는 것도 중요한 퍼블리셔의 역할이다.
또한, 다른 통신사의 런칭, 컨버팅 뿐만아니라 해외시장이나 시리즈물 기획과 같이 하나의 Produect을 다양한 채널화 시키는 것도 중요한 역할이다.


모바일 퍼블리싱에 대한 Role Define이 아직은 일반화 되지가 않았고, 시작하는 단계이기때문에 모든 업체가 이에 대한 연구가 필요할 것이라 본다.

위의 빅3 업체를 포함한 자신들을 퍼블리셔라고 외치는 여러 모바일 회사들...
퍼블리싱에 대한 준비가 되어있습니까?
아니면, 회사가 어려우니 다른 시도라도 해보는겁니까?
배고프고 힘드나 게임에 대한 열정으로 버티는 소규모 스튜디오에 대한 퍼블리싱은 왜 안하십니까?
기존 이름있는 업체들을 중심으로 해서만 퍼블리싱을 하는 이유는 뭡니까?
게임이 재미 없다구요? 맞습니다. 스튜디오에서 만드는 게임.. 재미 없습니다.
그것은 그들이 시장에 대한 정보가 둔감해서이고, 감이 부족해서 입니다.
그들에 대해 조금만 투자해 보세요. 처음은 못하지만 몇가지만 고치면 다음부터 잘 할겁니다.
온라인 전문 개발사들이 처음부터 잘하는줄 아세요?
퍼블리셔들이 잘 리드해주기 때문입니다.
통신사 담당자들하고 술마시면서 본인 회사 말고 모바일 산업 전체를 이야기 좀 해보세요.
갑이 될려고 하지마세요.. "외주"하고 "퍼블리싱"이 계약서 단어만 다른게 아닙니다.
제발 부탁입니다.

워낙에 많고 다양한 모바일 플랫폼을 개발을 하고(한 툴에 겨우 익숙해지면 다른 플랫폼 개발 프로젝트가 떨어지게 된다.) 그 다양한 이기종간에 네트워크를 개발하다보니...
바이트 오더링이 여간 신경써지는게 아니었다.
서로 네트워크 패킷이 오갈 때 사용하는 바이트 배열값이 동일한 플랫폼에서는 신경 안 써도 되는 것이지만, 이기종이다 보니 종종 원치 않는 값을 얻어오기도 한다.
게다가 모바일에서 주로 사용하는 Arm 프로세서라는 넘은 스위치 조작에 따라 빅엔디안과 리틀 엔디안을 설정할 수 있다.(둘다 지원한다는 소리다.)

그래서 값을 바이트 배열에 넣을 때는 무조건 아래 함수를 사용하는 버릇이 생겼다.

int getUint32(unsigned char * data, int index)
{
return ((data[index] & 0xff) << 24) | ((data[index + 1] & 0xff) << 16) | ((data[index + 2] & 0xff) << 8) | (data[index + 3] & 0xff);
}

void setUint32(unsigned char * data, int index, int i)
{
data[index] = (byte)(0xff & (i >> 24));
data[index + 1] = (byte)(0xff & (i >> 16));
data[index + 2] = (byte)(0xff & (i >> 8));
data[index + 3] = (byte)(0xff & i);
}

int getUint16(unsigned char * data, int index)
{
return (int)(((data[index] & 0xff) << 8) | (data[index + 1] & 0xff));
}

void setUint16(unsigned char * data, int index, int i)
{
data[index] = (byte)(i >> 8);
data[index + 1] = (byte)i;
}

64비트도 뭐... 이런식으로 하나 만들어서 사용해 왔다.
워낙 오래된 버릇이라 불편한 것도 몰랐고, 이젠 당연히 쓰게 되었다.

어느날 팀원에게 소스 주면서 아무 생각없이 이걸로 쓰라고 하자..
"왜요? 귀찮자나요.."
라고 한다..

달리 반박할 말이 생각나질 않는다..
동일한 플랫폼 안에서는 별 필요 없지 않은가????
쓸데 없는 버릇인가?
아닌 것 같은데......

컴투스의 '천주'가 드디어 오늘 KTF에서 오픈을 하였다.
마케팅 잘하는 우리의 컴투스 나리께서 올 1월달부터 '천주'를 SKT로 서비스한다고 광고를 내더니..
결국 SKT는 런칭을 아직 못하고 KTF에 먼저 오픈을 한다.

올해 2월, 위 동영상을 보고 엄청난 충격을 받았다.
모바일폰에서 이 폴리건과 프레임이 도대체 나온단 말인가? 궁금도 하고 의심도 많이 갔었다.
설마, 실제 플레이 동영상이 아니라 따로 제작한 거겠지.. 라고 밖에 생각이 안드는...
(정확하진 않으나 내가 알기론 위의 동영상은 컴투스게 아니라 일본에서 만든걸로 알고 있다.)

역시나 개발이 무진장 삐그덕 거린 듯 하다. 애초에 폰 스펙이 무리였겠지.
handygame의 신규 게임란에 스샷이 없는 것만 봐도 런칭이 얼마만큼 힘들었는지를 짐작할 수가 있다. 개발자 고생 많이 했겠네...

개발자분.. 너무 힘들어할필요 없을 것 같소.. 당신 잘못이 아니잖소.
애초에 무리라고 이야기 했을 것 아니오? 컴투스에서 이정도 프로젝트 맡길 정도면 바보는 아닐테니깐 분명히 단순 컨버팅으론 힘들고, Customizing 들어가면 게임맛이 달라져서 안된다고 이야기 했을 것 아니오?
개발자말 안 듣고 무조건 시키는 윗대가리들이 멍청한거지.. 당신 능력이 부족해서 그런게 절대 아니오. 힘내길 바라오..

혹시............. 윗선에서 물어보니깐 할 수 있다고 한 바보개발자는 아니겠지??

KTF 지팡만 아니고 WIPI 까지 지원하는게 의아하긴 하지만...
사람들을 무진장 설레게했던 이 동영상 만큼의 프레임은 내 장담하건데 절대 나올 수가 없다.
Arm9이고, 가속칩이고, 삼육이건간에 절대로 안나온다!!
절대로!!!!!
나온다면?? YOU WIN!!!

해보고 싶네.....
예전 같으면 바로 받아봤을텐데 이젠 그런 환경이 안되니............... 궁금해라.........

경험에 의하면 IM6400 에서 SKVM으로 개발을 할 때에 LCD의 너비를 얻어오는 쪽에 버그가 있다.

LCD.getWidth()는 물론이고, HCENTER 등도 작동하지 않는다.
그래서, IM6400 에서는 하드 코딩을 해주어야 한다.

그런데, 이 문제는 나만 알고 있는 것인가, 아니면 나만 잘못 알고 있는 것인가?
분명히 이 문제로 품검에러가 걸렸고, 디버깅 결과 문제가 있는 것을 확인을 했었는데, 아무도 이러한 글을 올리는 것을 보지 못했다.

심지어 SKVM의 단말별 이슈 문서에서도 언급이 되질 않는다.

신기하네.....