[펌] 「만만치 않지만」즐거운 모바일 네트워크 게임 개발

「만만치 않지만」즐거운 모바일 네트워크 게임 개발

‘나는 이동중에도 게임한다’ 이제는 게임도 모바일 시대다. 핸드폰이 점점 고급화되어 가면서, 모바일 게임도 변화하고 있다. 단순한 텍스트 기반의 게임에서 이제는 웬만한 휴대용 게임기 수준의 퀄리티를 보여주고 있다. 이에 따라 PC방이나 집에서만 즐기던 게임이 어느새 핸드폰 안에서 게이머들을 유혹하고 있다. 이 글에서는 최근 몇 년간 급격히 높아진 모바일 게임의 위상과 실제 모바일용 게임을 제작 할 때의 여러 고려사항에 대해 필자들의 경험을 바탕으로 소개하고자 한다. 김세익, 정진수, 이창욱, 김남이 (이쓰리넷, 마이크로소프트웨어) 2003/07/25

이제 핸드폰에서 할 수 없는 것보다 할 수 있는 것이 더 많아졌다. 핸드폰에서 TV를 본다거나 영화를 예매하고 음악도 들으며 결제 기능까지 갖춘 폰도 나왔다. 이러한 모바일 멀티미디어 시대에 게임은 중요한 하나의 축을 이루고 있다. 실제로 모바일/무선인터넷 관련 컨텐트 중 가장 많은 수익을 내는 상위 3개 애플리케이션 카테고리는 벨소리/통화연결음 관련 컨텐트와, 그림나라류의 폰 데코레이션 컨텐트, 게임 관련 컨텐트 카테고리이다. 벨소리/통화연결음 서비스와 폰 데코레이션 컨텐트류에 비해 게임 관련 컨텐트들의 발전 가능성은 무궁무진하다. 이제 모바일에서 게임을 빼고 멀티미디어 컨텐트를 이야기한다는 것은 있을 수 없는 일이 되어버린 것이다. 모바일 게임의 어제와 오늘 과거 게임들은 SMS를 이용한 텍스트 기반의 게임에서 발전해 WAP(Wireless Application Protocol)을 이용한 무선인터넷 게임이 주류를 이루고 있었다. 그러다가 LG텔레콤에서 KVM이라는 자바기반 VM 플랫폼을 발표하면서 SK텔레콤, KTF 등 타사들도 경쟁적으로 VM 플랫폼을 폰에 탑재하기 시작하였고 VM을 기반으로 한 다운로드형 게임이 출현하게 되었다. 이와 같은 다운로드형 게임은 초기에는 흑백 LCD, 느린속도, BGM의 결여(비프 사운드의 한계), 작은 용량의 한계로 인기를 끌지 못하다가 폰 스펙의 향상과 더불어 급속도로 성장하기 시작하였다. WAP 게임의 단점이었던 네트워크 접속에 따른 지나친 통신 요금의 부담과 텍스트 기반 게임의 한계를 무너뜨린 VM 게임은 초기에는 미미했으나 갈수록 창대해지고 있다. VM 게임으로 모바일 게임의 큰 축이 이동하면서 마치 휴대용 게임기의 화면을 조금 축소해 놓은 듯한 퀄리티를 보이는 게임들이 속속 등장하기 시작했다. 이제는 모바일 게임을 쉽게 보고 함부로 제작할 수 있는 단계는 아니라는 것이다. 현재 서비스되는 게임은 RPG를 비롯하여 슈팅/아케이드, 보드 게임(고스톱/포커 등) 등 종류도 다양하며 유명 PC 게임이나 업소용 게임의 라이선스 버전도 상당한 인기를 끌고 있다. 그만큼 유저층도 다양해졌으며 특정 타겟을 상대로 한 게임도 수익성이 보장되고 있다는 반증이 된다. 새로운 트렌드 ‘네트워크 게임’ 단독 실행형 게임은 현재는 좋은 수익을 내고 있다. 그러나 신규 유입되는 VM 이용 가능 사용자는 점점 증가세가 둔화되고, 한번 다운받으면 해당 사용자에게서는 더 이상의 수요를 바랄 수 없다는 점에서 한계를 보인다. 또한 단독 실행형 게임은 게임 자체의 수명이 3～4개월로 짧은 편에 속한다. 반면 지속적인 수익창출이 가능하며 같이 하는 즐거움 또한 누릴 수 있는 네트워크 게임은 향후의 킬러 컨텐트로 부상할 가능성이 높다. 실제로 네트워크 게임은 최근 이동통신사의 부양 정책에 힘입어 점점 그 영역을 넓혀가고 있으며, 매출 비중도 점점 늘어가고 있는 추세이다.    모바일 네트워크 게임의 맹점 이렇듯 고 성장세가 예상되는 모바일 네트워크 게임에도 문제가 있다. 바로 ‘가격’. 이 한계는 유선 온라인과는 본질적으로 다른 모바일 무선 인터넷의 과금 특성에 기인한다. 즉 현재의 온라인 과금체계는 대다수가 정액제로서 한달을 기준으로 정해진 이용요금을 납부하면 해당 대역폭만큼의 속도로 용량에 상관없이 무한정 이용이 가능한 서비스를 제공하지만, 모바일은 접속 시간 혹은 사용 용량만큼의 종량제 서비스를 제공한다. 이 때문에 사용자들에게 자칫 과중한 부담을 지울 수 있다는 것이 서비스 제공자의 고민이다. 이는 망을 제공하는 이동통신사가 막강한 권력을 쥐고 있는 현 국내 사정과, 사용주파수 대역에 한계가 있는 무선 인터넷의 특성으로 인하여 해결하기 어려운 가장 심각한 문제이며 과제이다. 이 문제를 최대한 비껴나갈 수 있는 개발시 기술적 노하우는 후반부에서 간단히 다루도록 하겠다. 폰 특성과 하드웨어 사양 알아보기 모든 게임이 다 그렇겠지만, 모바일은 특히나 심한 개발 제약사항 때문에 플랫폼 및 하드웨어의 사양을 비교적 상세히 알고 또 그에 맞는 대비를 철저히 해야 한다. 지피지기면 백전백승! 개발을 하거나 기획을 할 때에도 폰의 특성을 알고 진행한다면 시행착오를 훨씬 많이 줄일 수 있다. 일단 핸드폰에서 지원되지 않는 기본 사항들에 대해서 알아보자. ◆ 동시 키 입력 불가 : 동시 키 입력은 일부 플랫폼(Brew)에서는 지원을 한다. 그러나 기본적으로 통신을 목적으로 만들어진 핸드폰이기에 기계적으로 동시 버튼 입력을 지원하지 않는다. 따라서 격투 게임 등을 기획/개발할 때에는 이점에 충분히 유의하여야 한다. ◆ 동시 사운드 출력 불가 : 동시에 두 가지 사운드는 출력이 불가능하다. 예를 들어 BGM을 출력하면서 효과음은 출력이 되지 않는다(잘못하면 폰이 뻗어(?)버리니 주의하자). 음악이 들어가는 모든 게임에서 유의해야 할 사항이다 ◆ 작은 메모리 : 핸드폰에 따라서 조금씩 다르지만, 폰에 할당된 힙(heap) 메모리나 기타 작업 공간은 대단히 제한적이다. 특히 폰별로 용량이 제각각이기 때문에 주의해야 한다. 기획을 하거나 개발할 때에 과도하게 그래픽을 사용하거나 애니메이션이 많이 필요한 게임이라면 미리 유의하여 가능성을 검토해 보자. ◆ 제한된 화면 크기 : 가장 기본적으로 고려해야 할 사항이다. PC나 여타 업소용 게임기에 비하여 현저하게 작은 화면을 가지고 있기 때문에(실 화면 크기는 120×106～172×178 정도까지 다양하다), 한 화면에 많은 오브젝트가 보여야 하는 게임이나 매우 작은 오브젝트를 가지고 플레이하는 게임은 적합하지 않다. 그 외에도 작은 화면 때문에 UI 및 화면 구성에 어려움이 있다. 이 제한된 화면 크기야 말로 가장 크게 유의해야 할 점이다. 모바일 게임 개발시 고려 사항 모바일 게임은 앞에서 말한 것처럼 PC 게임이나 업소용 콘솔 게임과는 대단히 다른 특성을 가지고 있다. 작은 화면으로 인한 표현의 난점과 입력기기의 조작성이 떨어짐에 따라 기인하는 조작의 불편함으로 인해 모바일 게임을 기획할 때에는 여러 가지 주의해야 할 사항들이 많다. 또 디자인할 때에도 화면 크기가 매우 작고 사용할 수 있는 컬러 수가 256 컬러로 제한되어 있다. PC 게임에서 사용하는 작은 아이콘 크기만한 오브젝트가 날아다니고 뛰어다니고 마법도 쓰고 칼질도 하는 모든 동작을 소화해야 한다는 점을 잊지 말아야 한다. 제한된 리소스에 따라 주의할 점 앞에서 기술했듯이 기본적으로 모바일 핸드셋에서 지원하지 않기 때문에 주의해야 할 것들 외에도 여러 가지 주의사항들이 많다. 예를 들어 모바일 게임에서 삼국지를 모토로 두 가지 유형(장르)의 게임을 만든다고 가정하고 예제를 들어 간단히 설명을 하도록 하겠다. 대전 게임을 만들 때 고전 게임중에 삼국지 무장쟁패라는 게임이 있었다. 알다시피 삼국지에 나오는 무장들을 선택하여 CPU 혹은 2P와 일대일 대결을 펼치는 게임이다. 이러한 대전 게임은 사실 조이스틱 혹은 그에 준하는 아날로그 입력기기를 이용해야 즐기기가 용이하다. 커맨드를 입력하면서 특정 버튼을 눌러 기술을 구사하게 되는데, 사실 키보드와 같은 디지털 입력기기로도 부드러운 입력이 어려운 것이 사실이다. 이와 같은 커맨드를 중시하는 대전 게임을 기획할 때에는 동시 키 입력이 불가능한 모바일 핸드셋의 특성을 이해하고, 최대한 키 입력을 간편화하여 게이머의 조작 편의성을 도모하여야 한다. 물론 PC나 업소용 게임의 복잡한 커맨드를 그대로 수용한다는 것은 무리이기 때문에 이동 컨트롤러의 한바퀴 회전과 같은 난해한 커맨드는 지양하고 좌우 반복과 같은 단순한 커맨드로 생략하여 처리하는 것이 좋다. RPG를 만들 때 필자가 실제로 삼국지를 컨셉으로 한 턴 베이스 SRPG(Strategic Role Playing Game) ‘삼국지 촉한전(최근 서비스 개시)’을 기획할 때 가장 고심했던 것은 게임의 용량이었다. 사실 모바일에서도 마음만 먹는다면, PC 게임에 필적할만한 RPG나 어드벤처 게임을 만들 수도 있다. 다만 이렇게 된다면 게임의 용량이 수백 KB를 초과하게 되어 게이머의 폰 안에 담겨질 확률이 낮아지게 된다(물론 그 전에 이동통신사에서 태클을 걸어온다). 스토리 전개를 위한 많은 대사량과 스테이지/캐릭터별로 달라지는 전투 목표를 구현하기 위해서는 상당히 많은 용량이 필요하다. 결국 용량 문제는 맵 리소스를 별도로 관리하여 에피소드별로 FTP 연결을 통해 따로 다운받을 수 있도록 구현해 해결하였다. 용량 뿐 아니라 화면 크기도 큰 고민이었다. 전체 화면 크기가 작기 때문에 전략성을 늘리고자 가시 영역을 넓히면 그만큼 캐릭터가 작아지고, 또 캐릭터를 키우면 가시 영역이 좁아져 전략성이 떨어진다. 이 두 마리 토끼를 동시에 잡기 위해서 필자는 미니 맵(전체 맵을 한 화면으로 압축해 보여준다) 기법과 유저가 직접 조종할 수 있는 캐릭터의 숫자를 대폭 줄여버림으로서 해결하였다(한 화면에 캐릭터가 적게 보이도록 유도한 것이다). 마지막 방법은 용량 문제를 해결하는 데에도 약간의 도움을 주었다. 필자가 근무하고 있는 이쓰리넷에서 개발한 삼국지 촉한전의 스크린샷을 약간 첨부해 보겠다(<화면 1, 2, 3>). 스크린샷을 참조하여 적당한 캐릭터/가시 영역 비율과 더 좋은 화면 구성을 찾아보기 바란다.     <화면 1> 한 화면은 5칸으로 구성된다.   <화면 2> 이것이 미니 맵이다.   <화면 3> 이것은 스테이지를 클리어하기 위한 승리 조건이다. 디스플레이와 속도 감안하기 모바일 게임을 구현함에 있어서 가장 걸리는 문제는 아마도 속도일 것이다. 다이렉트X 기반으로 개발한 상용 게임의 경우 온갖 화려한 오브젝트들이 난무하면서도 화면에 갱신되는 속도는 60～100프레임의 대단히 뛰어난 성능을 자랑한다. 오브젝트가 별로 없는 상황에서는 거의 몇백, 몇천 프레임까지 나온다. 그럼 핸드폰의 경우 속도가 얼마나 나오는지 따져보자. 그야말로 절망적인 수준이다. 잘 나와야 8프레임 정도이고, 평균 4～5프레임 사이다. 좀더 멋지게 보이고 싶어서 예쁜 오브젝트를 뿌려대고, 잔 기술을 부리다가는 속도는 2프레임 이하로 곤두박질치기 일쑤다. 보통 모바일 게임에서 게임을 즐기기 위해선 최소 4～5프레임 이상은 나와줘야 한다. 하지만 각 특성을 타는 폰들에서 이런 속도가 일정하게 나올 리 만무하다. 삼성 계열의 폰을 보면 평균 2～6프레임의 속도가 나오며 LG 계통 폰은 8～14프레임이 나온다. 느린 속도를 어떻게 극복할 것인가 이런 상황을 타개하기 위한 노력으로 여러 다양한 방법들이 여기저기서 나오고 있는 상황인데, 그 방법들은 거의 대부분 다이렉트X 기반으로 게임을 개발하기 이전 도스, 윈도우 3.1 시절에 사용하던 기법들이다. 그중 하나의 방법으로 부분 리페인팅 방법이 있다. 한번 보여지는 배경 이미지를 더 이상 갱신시키지 않고 이동하는 오브젝트, 변경이 있는 부분만 배경이미지의 최소만 잘라서 갱신시킨다. 필자가 처음 개발할 때 속도의 중요성을 전혀 깨닫지 못한 채 주인공을 기점으로 맵 스크롤되는 방법을 쓰다가 새삼 ‘세상은 내 맘대로 되지 않는구나’라고 깨달았다. 만약 타일을 이용해 RPG를 만든다면 맵 스크롤이 속도에 전혀 도움을 주지 못한다는 사실을 명심해야 한다. 필연적으로 전체 화면을 갱신시켜 주어야하는 맵 스크롤 기법으로 전체 화면과 오브젝트까지 모두 출력시켜 주면서 빠른 속도를 기대했다면, 폰에서 테스트할 때 필자가 경험했던 쓴맛을 보게 될 것이다. 이런 문제점의 해결책 중 하나는 화면에서 맵 스크롤을 시키지 않고 부분 리페인팅을 쓴 후에 화면 외곽으로 오브젝트가 벗어났을 때 화면 전환이 이뤄지는 방식을 쓰는 것이다(<화면 4>). 이렇게 하면 화면 가득히 꾸물거리는 오브젝트가 없는 한 속도가 느려지는 것을 최대한 막을 수 있을 것이다. 만약 출력되는 오브젝트가 많은 가운데 부분 리페인트 기법을 쓴다면 어마어마한 계산량과 API 호출이 빗발칠 것이다. 그렇게 되면 오히려 전체를 리페인팅한 것보다 속도가 안나오는 황당한 일이 벌어질 수도 있다. 또한 에뮬레이터에서 체크한 속도와 막상 폰 테스트에서 나오는 속도는 거의 완벽하게 틀리다. 나중에 절망에 빠지기 싫다면 번거로워도 폰 테스트를 자주 하여 속도와 색상 체크를 해봐야 한다.   <화면 4> 최소한의 애니메이션처리되는 부분의 배경 오브젝트만 갱신시킨다.             리페인트만 잘 쓰면 이 정도 오브젝트와 애니메이션에도 속도가 많이             줄어들지 않는다. 컴팩트한 코딩 지향하는 이미지 컨트롤 필자는 간혹 모바일 게임을 개발하면서 착각에 빠질 때가 있다. 개발하고 있는 게임이 윈도우 기반에서 돌리는 게임인냥 맘껏 메모리를 확보하고 이미지 로딩시키며 해제 또한 대충대충 해버릴 때가 있다. 하지만 테스트를 하게 될 때면 돌아오는 것은 수많은 알 수 없는 에러와 대답없는 핸드폰 액정 화면 뿐이다. 경험삼아 ‘맨땅에 헤딩’을 해보고 싶으면 이런 과정을 겪어보는 것도 괜찮겠다. GVM은 전역으로 한번에 로드되고 해제되는 경우라서 상관없지만 Brew는 각 이미지 메모리나 각 인터페이스 인스턴스 생성해제를 폰 특성에 따라서 개발자가 알아서 생성/해제해 주어야 한다. 어떤 폰에서는 멀쩡히 잘 돌아감에도 불구하고 어떤 폰에서는 메모리오버, 스택 오버플로우 에러와 종료시 각종 이미지, 인스턴스 해제를 해 주지 않았다는 이유로 폰이 다운되는 경우가 많다. 단 하나의 인스턴스라도 해제해 주지 않으면 문제가 될 소지가 크다. 더욱이 골치아픈 것은 변수를 메모리로 얼로케이션 시켜줄 때 스택 오버플로우되는 기준이 각 폰마다 틀리다는 사실이다. 기본적으로 ‘넉넉하게 메모리를 생성시켜야지’라는 생각은 좋지 않은 버릇이다. 언제나 대범하게 변수 등 각종 메모리를 확보 선언했던 개발자들이 모바일 게임 개발을 한다면, 그 대범한 성격을 다소 소심한 성격으로 변신시킬 수 있을 것이다. 모바일은 언제나 컴팩트한 코딩을 지향한다. 이미지 로딩/해제의 기본 필자가 이미지 메모리를 로딩하고 해제시킬 때는 언제나 각 게임 State별로 free, loading을 시켜준다. 특히 이미지메모리를 free시켜줄 때는 하나의 함수에 게임 내 사용되는 모든 이미지를 free시켜주는 루틴을(이를테면 AllFreeImage()) 만들어 주는 게 좋다. 따로따로 해제시키는 것보다 눈의 이해력이 빨라지며 소스 코드 인테리어도 괜찮아진다. 물론 어이없는 에러와 폰이 다운되는 현상이 벌어지기 전에, 해제시키기 전에는 널값 체크를 일단 하고 해제시키는 것을 잊어서는 안 되겠다. 이렇게 해제하고 난 후에 각 State별로 호출되는 최소의 이미지만을 로딩시키면 된다. 이 모든 것을 함수로 묶어 주면 역시 또 눈의 이해력이 빨라지고 인테리어도 괜찮아지는 것은 당연하다. 퀄리티와 메모리, 중도의 미를 지키자 앞의 경험에 비추어 볼 때 한 번에 너무 많은 이미지 로딩을 하는 것은 특정 폰에서 혹은 전체 폰에서 에러를 토해낸다는 사실을 알 수 있었다. 그렇다고 해서 너무 빈번하게 메모리를 사용하고 해제하는 것은 오히려 속도 저하라는 문제를 안겨준다. 실제 필자가 개발했던 ‘스토커(KTF 서비스)’라는 게임에서 잡다한 이미지가 많이 출력되는 도중 팝업 메뉴를 띄우는 부분이 있었다. 메모리 최적화를 위해 온갖 메모리 로드 해제를 반복하다 특정 폰에서 갑자기 속도가 느려지는 현상이 발생하기도 했다. 이런 핑계(?)로 모바일 게임에서의 UI 혹은 게임 화면은 다소 공허하며 쓸쓸하고 외롭게 표현되는 경우가 많다. 게임 퀄리티와 메모리 안정, 이 두 가지의 적당한 타협점은 개발자 스스로 찾아야 할 것이다.    전시회 속 모바일 게임 ◆ E3에서의 모바일 게임 지난 5월 중순 전세계 최고의 게임쇼인 E3에서도 모바일 게임의 열기는 계속되었다(물론 아시아 경제 침체로 작년보다는 덜한 모습이었기는 하다). 노키아에서는 N-Gage라는 ‘게임기+통신모듈’ 인듯한 모습을 한 게임용 핸드셋을 발표하였으며, 국내의 여러 업체도 공동관을 통하여 홍보에 열심이었다. 그러나 네트워크 게임은 거의 찾아볼 수 없어 아쉬웠다. 아마도 지역별로 네트워크 특성이 다른 것이 원인중 하나가 아닐까 싶었다. 물론 아직까지는 온라인 접속형 네트워크 게임보다는 다운로드형 게임이 대세라는 반증이 될 수도 있다. 그러나 가까운 미래에는 대형 멀티비전으로 수십명의 게이머가 동시에 핸드셋을 들고 게임을 하는 진풍경이 연출될 것이라 감히 예언해 본다. ◆ Expocomm에서의 모바일 게임 5월말에는 국내의 각 이통사 주도로 와이어리스 인터넷 전시회인 Expocomm이 개최되었다. 이 전시회에서의 화두는 단연 네트워크 게임으로, 고스톱/맞고, 4인용 네트워크 대전 게임(포트리스 온라인) 등이 전시되었으나 아쉽게도 보드 게임(고스톱)을 제외한 다른 게임의 전시 비중은 대단히 낮았다. 뒤에서 다루겠지만 모바일 게임의 편중현상(특히 네트워크 게임의)이 아직도 극심하다는 것을 새삼 느낄 수 있는 전시회였다. SKT와 KTF의 고스톱 맞불작전이 눈에 띄었으나 씁쓸한 느낌을 감출 수 없었다. 이러한 편중 현상이야말로 현재 업계에 종사하고 있는, 혹은 앞으로 업계에 발을 내딛을 참신한 개발자들이 헤쳐나가야 할 숙제가 아닐까? 플랫폼별 차이점과 고려 사항 모바일 플랫폼은 크게 GVM/SKVM(이상 SKT), Brew(KTF), JavaStation(LGT)으로 나누어진다. 이 4가지의 플랫폼을 개발 언어에 따라 나누면 자바가 2종, C 계열이 2종이다. GVM은 신지소프트, SKVM은 XCE, Brew는 퀄컴, Javastation은 벨록스 소프트가 썬마이크로시스템즈의 J2ME를 기반으로 개발하였으며 자세한 사항은 개발사 홈페이지를 참조하도록 하자. 여기서는 각 플랫폼별로 주의해야 할 사항이나 특징적인 사항들을 다루어 보겠다. 네트워크에 강한 Brew 플랫폼 각 플랫폼마다 각기 다른 특성과 장점들을 가지고 있는데, 필자의 경험으로는 Brew가 전반적으로 우수한 편이다. 장 최근에 상용화된 플랫폼이며 강력한 성능을 가지고 급속도로 보급되고 있다. 넌블럭킹 방식의 빠르고 강력한 네트워크 기능과 자바에 비해 월등한 처리속도 등을 무기로 플랫폼의 성능만으로는 가장 뛰어나다고 할 수 있겠다. 그러나 폰의 OEM에 따라서 특성을 많이 타고, 프로그래머의 잔손이 많이 가는 특성이 있어 개발의 난이도는 비교적 높다. 개발 환경은 비주얼 C이며, 네트워크 게임, 스탠드 얼론 게임 등 다양한 방식의 게임 개발이 가능하다. 가장 널리 보급된 GVM GVM은 신지소프트에서 C를 간략화시켜(Mobile C) 제작, 배포한 플랫폼이다. 플랫폼의 안정성과 개발 용이성은 뛰어나지만 용량의 제한이 있고(128KB), 사용할 수 있는 컬러 뎁스가 7bit에 불과하며(Brew는 8bit이다) 네트워크에 취약한 모습을 보인다. 그러나 가장 널리 보급된 플랫폼으로서 빠른 처리속도와 안정적인 개발환경으로 오래도록 왕좌를 놓치지 않고 있다. 조만간 강력한 기능이 추가된 GVM 3.0(Gnex)이 발표될 예정으로, 앞으로의 판도 변화가 기대된다. 안정적인 자바 기반의 SKVM과 JavaStation SKVM은 XCE에서 썬마이크로시스템즈의 기술을 사용하지 않은 상태로 개발해낸 자바 플랫폼이다. 다른 자바 플랫폼(LGT의 JavaStation)에 비해서는 빠른 처리속도를 가지고 있지만 C 계열 플랫폼에 비하면 속도는 많이 떨어지는 편이다. 또한 안정적인 네트워크 기능을 가지고 있으나, 느린 응답속도로 인하여 게임에 적용하기는 어려운 점이 많다. 속도를 제외한 안정성에서는 자바 플랫폼답게 거의 폰 에러를 발견하기는 어려울 정도로 뛰어나다. JavaStation은 썬마이크로시스템즈의 J2ME 그대로 채용했기 때문에 별다른 설명이 필요없어 보인다. LGT에서 추가적으로 사용하는 API에 관해서는 LGT JavaStation 페이지(http://java.ez-i.co.kr)나 플랫폼 개발사인 벨록스 소프트웨어(http://www.veloxsoft.com) 를 참조하기 바란다. 각기 다른 플랫폼에 대응하려면 앞에서 기술한 대로 여러 플랫폼마다 특성이 모두 다르고, 개발 환경도 많이 다르다. 따라서 각 플랫폼별로 주의해야 할 사항이 많은데, 기본적인 몇 가지만 짚고 넘어가도록 하겠다. 먼저 각 플랫폼은 용량 제한폭이 많이 다르다. Brew의 경우 플랫폼 자체의 용량제한은 없으나 KTF 정책적으로 200～250KB로 용량 제한을 하고 있는 상태이며, GVM은 플랫폼의 기술적 한계로 인하여 128KB를 넘을 수가 없다. 다른 플랫폼들도 각기 용량 제한이 다르기 때문에 게임을 기획할 때, 이같은 사항을 충분히 숙지하여야 다양한 플랫폼에 대응할 때 고생을 덜 하게 된다. 그래픽적인 측면을 살펴 보았을 때에는 플랫폼에 따라 사용할 수 있는 컬러 뎁스가 다르기 때문에 전체적인 그래픽을 재처리해야 하며, 이에 따라 변경되는 용량문제도 신경을 써야 하는 등 여러 가지로 머리아픈 일들이 많다. 개발자들은 WIPI(Wireless Internet Platform for Interoperability) 가 성공적으로 정착하기를 바라는 수 밖에는 별 다른 해결책이 없어 보인다. 불안정한 모바일 네트워크 해결책 휴대폰이 대중화되던 초기에 모든 이동통신사들은 자사 광고에 어디서든 통화가 잘 된다는 점을 제일 강조했다. 그 당시만 하더라도 지하에만 내려가면 안테나가 모두 사라지는 시절이었으니. 모든 통신사들이 경쟁적으로 기지국 확장에 총력을 기울였고 그 덕분에 지금은 달리는 지하철에서도 깨끗한 통화가 가능하게 되었다. 유비무환의 정신으로! 그럼에도 유선에 비해 무선 인터넷은 아직 불안정한 것이 사실이다. 휴대폰으로 네트워크 연결을 할 때 안테나가 3칸 미만일 경우 잘 연결되지 않는다. 즉 휴대폰으로 네트워크 게임을 한참 잘 즐기고 있다가 갑자기 통화 연결 상태가 좋지 않다면 게임은 그 자리에서 멈출 수밖에 없다. 그래서 모바일 네트워크 게임을 제작할 때에는 패킷 수신이 다 되지 못했을 때의 처리를 반드시 해 주어야 한다. 그렇지 않을 경우 게임이 비정상적으로 작동할 수 있다. 실제로 필자는 4인용 네트워크 퀴즈 게임을 만들때 미처 이러한 처리를 하지 못해 황당한 경우를 목격한 적이 있다.   <화면 5> 비 정상적인 작동. 게이머 한 명이 사라졌다. <화면 5>와 같이 한 방에 4명이 동시에 조인을 시도했는데 어떤 폰에서는 3명만 들어와 있고 또 다른 폰에서는 정상적으로 4명 모두 들어와 있는 걸 볼 수 있다. 물론 이런 경우는 흔하게 일어나지는 않지만 언제 어디서 통화 수신률이 떨어질지 모르기 때문에 꼭 처리를 해두는 게 좋다. 대답없는 폰에 대한 처리 또한 통신 연결상태가 좋지 않을 경우 게임이 정지 상태가 될 수 있는데 일정시간 패킷 수신이 되지 않을 경우 그에 따른 적절한 처리를 해 주어야 한다. 그렇지 않으면 다른 게이머들도 게임이 계속 멈추어 있어 마치 핸드폰이 다운된 것처럼 보이기 때문이다.   <화면 6> 통신 연결이 끊어졌을 때 처리 <화면 6>과 같이 통신 상태가 좋지 않을 경우 통신 연결을 끊고 사용자에게 메시지를 띄워 이를 알린 다음 초기메뉴로 돌아가거나 그 게임에 알맞게 적절한 처리를 해주도록 하자. 놀 사람이 없을 때 ‘인공지능아, 놀아줘’ 요즘 컴퓨터를 사용하는 사람들중에 메신저를 쓰지 않는 사람은 거의 없을 거라 생각된다. 그중에 MSN 메신저를 사용하는 사람들의 대부분은 사람이 아닌 인공지능 ‘심심이’란 친구를 등록해놓은 걸 흔히 볼 수 있다. 대화 할 사람이 없을 때나 그냥 심심할 때 한마디 건네면 가끔 엉뚱한 말을 하긴 하지만 대부분 대답을 잘 해주는 게 참 기특하다. 모바일 네트워크 게임을 만들 때에도 심심이 같은 인공지능을 만들어 주는 게 좋다. 네트워크 게임은 실제 사람과 사람이 대결을 하거나 같이 게임을 하는 게 특징이다. 하지만 같이 게임을 할 사람이 없다면 게임을 할 수가 없다. 모바일 네트워크 게임은 유선보다는 아직 사용자 수가 현저히 적기 때문에 게임을 하기 위해 접속해도 같이 게임할 사람이 없는 경우가 많다. 그래서 <화면 7>과 같이, 게임에 접속해 사용자를 기다리다가 일정시간 게이머가 들어오지 않을 경우 인공지능 플레이어를 출동시켜 심심한 사용자와 즐겁게 놀아주도록 처리를 해주어야 한다(이는 모 이동통신사의 강제 적용 사항이기도 하다). 이 때 중요한 건 사용자가 최대한 사람과 같이 게임을 하는 것처럼 느끼도록 인공지능을 만들어 주는 것이다. 특히 게이머의 레벨에 따라서 인공지능 플레이어를 다르게 설정하는 것도 좋은 방법이다. 인공지능 플레이를 해 주어야 할 경우가 한 가지 더 있다. 게임 도중에 같이 게임을 하던 사용자가 나가 버리게 될 경우 남아 있는 사용자는 게임을 계속 즐길 수 없게 된다. 이 상황을 방지하기 위해 게임을 하던 사용자가 갑자기 나가더라도 그 사용자가 마치 계속 게임을 하고 있는 것처럼 인공지능 플레이로 대체를 하는 것이다. 이때 주의해야 할 점은 어쩌다 한번씩 게임 서버에서 클라이언트와의 연결이 끊어진 것을 인식하지 못할 때가 있다. 중간에 과금 서버를 거치기 때문에 그런 경우가 가끔 생기는데 그런 상황을 처리하지 않으면 상당히 오랫동안 게임이 정지 상태가 된다. 따라서 이러한 경우 일정 시간 클라이언트로부터 패킷이 오지 않을 경우 서버에서 강제로 연결을 끊어버리는 처리를 해주어야 한다. 유선에 비해서 네트워크가 불안하고 사용자 수도 현저히 적은 모바일 네트워크의 특수성을 이러한 인공지능 플레이로 조금은 극복할 수 있다.   <화면 7> 인공지능 플레이를 하고 있는 화면.   녹색 머리가 인공지능 캐릭터 ‘노라줘’이다. 모바일 네트워크 서버 구축하기 아직까지는 모바일 네트워크 게임 서버를 구축하기 위해 고사양의 서버가 필요하지 않다. 유선 네트워크 게임에 비해 동시 접속자 수나 패킷의 양이 많지 않기 때문이다. 중저가의 서버만으로도 충분히 상용화 서버를 구축할 수 있다. 서버 프로그램의 경우에도 모바일에서 가능한 서비스가 작기 때문에 유선 네트워크 게임 서버만큼 크지 않다. 많은 부분에서 일반 온라인 게임 서버와 비슷하지만 몇가지 다른 점은 미리 감안해야 한다. 통신사별로 다른 규격 먼저 모바일의 경우에는 여러 통신사를 통해서 데이터를 전송하기 때문에 각 통신사에서 규정한 방식에 따라서 패킷의 헤더에 과금 헤더를 추가해야만 한다.이 부분에 대해서는 뒷 부분(과금 체계)에서 자세하게 다룬다. 이 과금 헤더는 서버에서 각 서비스 별로 분리하여 처리할 때 아주 유용하게 쓰인다. 보통 모바일 네트워크 게임의 경우에는 하나의 서버 프로그램에서 여러 상용 게임을 돌리는 다중 서비스 시스템을 사용한다. 이때 서버에 접속하는 사용자의 패킷에서 과금 헤더 부분의 서비스 코드를 분리하여 어느 게임에서 접속했는지를 분석해 각 게임에 맞는 서비스로 나눠서 처리한다. 현재 이쓰리넷에서 상용 서비스중인 ‘재미니의 육아일기’, ‘동전쌓기’를 포함해 여러 종류의 게임들이 하나의 랭킹 서버를 사용한다. 또한 모바일 네트워크 게임은 수익 계산을 바로 할 수 있다. 서버에 접속하는 로그를 분석해 애플리케이션의 다운 건수, 주 사용시간, 일별 및 월별 다운 건수 변화율 등의 정보를 분석할 수 있다. 이러한 정보는 간단한 로그 분석 프로그램으로 손쉽게 정보를 얻을 수 있다. 중복 로그인 처리를 할 때 주의점 또 다른 특이한 점은 <그림 1>에서 보는 것과 같이 모바일 네트워크에 접속하는 사용자는 아주 많지만 결국에는 각 이동통신사의 네트워크 서버를 통해서 일반 CP 업체의 게임 서버로 접속하기 때문에 게임 서버에 접속하는 IP는 1～3개의 이동통신사 서버 IP로 고정된다. 따라서 IP를 중복 체크할 필요가 없다. 해킹이나 중복 로그인을 막기 위해서 중복 IP를 막을 경우에는 서비스를 못하게 되는 상황을 초래한다. <그림 1> 모바일 네트워크의 구조 모바일 네트워크 게임의 경우 간혹 중복 로그인이 되는 경우가 있다. 동일한 ID를 가진 사용자가 동시에 2개가 접속해 있는 경우다. KTF-X2000 폰의 경우 네트워크 게임 도중 종료키를 누르면 실제 핸드폰은 종료된 상태이면서 서버에는 연결이 끊어지지 않고 접속이 계속 유지되는 경우가 발생한다. 이것은 폰 특성으로 특정 단말기에서만 종종 발생하는 현상이다. 따라서 중복 로그인이 되었을 때에 대한 처리가 따로 필요하다. 그렇지 않을 경우 아이디를 검색하여 패킷을 보내는 서비스의 경우 실제로 접속한 사용자가 아닌 이전의 ID로 패킷을 보내서 오류를 발생시킨다. 현재 상용화되어 있는 게임에서 이를 막기 위해서 서버 접속시 랜덤하게 아이디를 생성하여 막거나 이전에 접속한 ID의 연결이 끊어질 때까지 동일한 ID의 사용자가 로그인 못하게 하는 방법을 쓴다. 하지만 가장 좋은 해결책은 접속하는 ID와 동일한 ID로 이전에 접속한 사용자가 있는지를 비교해 이전에 로그인한 ID는 접속을 끊어 주는 방법이다. 랭킹 서버의 경우, KTF의 경우 마이랭킹팩(MyRankingPack)이 강제 사항이기 때문에 자체 랭킹뿐만 아니라 KTF의 랭킹 서버에 랭킹을 업데이트시켜야 한다. 사용자가 저장한 랭킹 정보를 게임 서버의 DB에 저장한 다음에 동일한 정보를 마이랭킹 서버로 보내야 한다. SKT의 경우는 자체 서버만으로 구성이 가능하기 때문에 별 다른 처리를 해 줄 필요는 없다. 상용 서버를 테스트하자 이렇게 여러 주의점을 고려해 완성된 서버를 구축했다면 이제 상용 게임 서버를 구축하기 위해 테스트해야 하는데, 이 부분에서 또한 많은 어려움이 발생한다. 단말기 제조 업체가 아닌 이상 일반 CP 업체에서 다수의 단말기를 소유하고 있지 않은 상황이라면 많은 수의 사용자가 서버에 접속하여 게임을 진행할 때 발생하는 문제를 체크하기란 어려운 일이기 때문이다. 이동통신사의 지원을 바랄 수 밖에 없지만 완벽한 지원은 기대하기 힘들다. 실제로 모바일 네트워크 게임을 상용화시키고 나서 웃지 못할 에피소드가 하나 있었다. 네트워크 게임을 상용화하고 여유있게 서버를 모니터링하는데 언제부터인가 알 수 없는 패킷이 일정한 간격으로 서버에 날아오는 것이었다. 당황한 필자는 ‘서버에 오류가 있는가’, ‘해킹을 당하는 것은 아닌가’라는 생각이 스치고 지나갔다. 하지만 유심히 살펴본 결과, 패킷이 들어오는 시간이 30초로 일정한 간격을 유지하고 있었다. 그 알 수 없는 패킷의 정체는 이동통신사에서 네트워크 게임의 서버를 관리하기 위해 서버의 이상 유무를 진단하기 위한 패킷이었다. 상용화된 서버가 다운되는 경우에 사람이 서버를 계속 모니터링하지 않고 있는 상황이라면 서버의 이상 유무를 알 방법이 없다. 이를 막기 위해 상용화된 서버에 일정한 시간 간격으로 패킷을 서버로 날려줌으로써 서버가 정상적으로 운전 중인지를 관리하는 것이다. 이 글을 읽는 독자 여러분은 이러한 일이 발생하더라도 당황하지 않기를 바라는 마음이다. 모바일 게임에서 빠뜨릴 수 없는 ‘과금 체계’ 모바일에서 과금 체계는 이동 통신사의 정해진 과금 정책에 맞추어져 있다. 각각의 서비스에 따라 정해진 코드를 패킷에 첨가해야만 한다. 그렇지 못할 경우 개발한 애플리케이션이나 게임을 서비스할 수 없다. 그렇다보니 이동통신사와의 원활한 협조가 이루어지지 않을 경우 많은 어려움을 겪게 된다. 이쓰리넷에서 개발한 ‘스토커K’(KTF 서비스중)‘와 같은 성인 게임 같은 경우 2003년 1월에 최종 버그 테스트를 통과해 런칭시켰지만 현재까지 서비스를 못하고 있다. KTF 성인 컨텐트의 경우 KTF에서 하이텔로 넘어가는 바람에 상용화가 현재까지 연기된 것이다. 과금 정책이 자주 바뀌어서 낭패를 본 일도 있다. 앞에서 말한 성인 컨텐트의 경우에 성인 인증 서비스가 2002년 9월에 기존에 비해서 더욱 강화됐다. 기존 규칙에 맞춰 성인 인증 서버를 구성해 두었는데 정책이 바뀌면서 새로 서버를 구성해야만 했다. 또 모바일의 패킷에 붙는 과금 헤더의 경우에도 패킷의 종류에 따라서 과금의 형태를 구분짓는 코드(BCSP, BCNB)가 있는데 이 코드가 자주 바뀌어서 여러번 고쳐줘야 했다. 이동통신사와의 협조가 중요 이동통신사와의 호환이 이뤄지지 않아 어려움을 겪은 경우도 있다. 앞의 <그림 1>에서와 같이 CP 업체의 게임 서버에서 오고 가는 패킷은 전적으로 이동통신사의 서버와 통신을 한다. KTF의 빌컴 서버의 경우에 볼랜드 제품으로 서버를 구성했는데 변수를 인식할 때 거꾸로 인식하여 실제로 게임 서버에서 과금을 적용한 패킷을 전송할 경우에 빌컴 서버에서 변수를 잘못 인식하는 문제가 발생한다. 자체 게임 서버에서 패킷을 보낼 때에 MACS 헤더 부분의 값들을 바이너리 방식으로 거꾸로 뒤집어서 보내주어야만 한다. 당연히 전송받는 단말기에서도 받은 부분의 변수들을 뒤집어 줘야지만 정확한 값을 얻을 수 있다. 단순히 한 패킷만 전송하는 서비스의 경우에는 커다란 문제가 발생하지 않지만 파일 다운로드 서비스의 경우 연결된 패킷이 연속으로 전송될 때에는 패킷 크기를 제대로 읽어오지 못해 연속해서 들어오는 패킷을 읽는 데 문제를 일으키게 된다(필자도 이러한 사실을 모른 채 코딩하다가 엄청 고생한 적이 있다). 과금을 적용한 서버를 테스트하는 데에도 많은 어려움이 있다. 이것은 이동통신사와의 원활한 협조가 있어야 하기 때문에 더욱 어렵다. 이동통신사 측의 과금 정책에 맞춰 서버를 구성했다하더라도 제대로 기능을 하는지를 테스트하려면 이동통신사에서 확인해 주어야 한다. 하지만 많은 CP 업체들을 이동통신사에서 모두 확인해 주는 것은 사실상 불가능한 일이다. 최근에는 CP가 직접 과금 테스트를 할 수 있도록 과금 테스트 페이지를 만들었는데, 아직 완벽하게 과금 검증이 이루어지는 것은 아니다. 과거에는(비교적 최근까지) 보통 자체적으로 테스트를 하는데, 이때 에뮬레이터상에서 테스트를 해 보거나 클라이언트 프로그램을 제작해 테스트했다. 그러나 이것은 실제로 과금 서버에서 과금이 적용이 되는지 100% 체크할 수 없다. SKT의 경우 과금 검증이라는 절차를 밟아야만 정상적인 서비스 런칭을 할 수 있어 과금 테스트는 정확하지만 검증 기간만큼의 런칭일자가 늦어진다는 단점이 있다. 이제는 모바일 게임도 3D로 즐기자 얼마전 SKT에서는 ‘GIGA 기술 설명회’를 개최하여 GVM 3.0(Gnex) 및 SKVM의 새 버전에 대한 공개를 실시하였다. GIGA 기술 탑재 폰의 주요 특징은 폰 내부에 그래픽 가속과 3D 가속이 가능한 하드웨어 가속 칩을 내장하고 출시된다는 사실이다. 또한 폰에서 구현 가능한 프레임수가 기존 4～8프레임 수준에서 평균 15프레임 이상으로 비약적인 향상을 이뤘다. 또한 WIPI를 지원하며, 최대 개발 가능 용량도 128KB의 네 배에 달하는 500KB 전후로 모바일 게임의 블록버스터화(?)를 이끌 첨병으로 주목받고 있다. 3D 성능 또한 최대 700～1000폴리곤까지 처리가 가능하다 하여 참가자들의 탄성을 자아냈다. 이와 같이 플랫폼에 3D 엔진을 탑재하는 것은 여러 가지 복합적인 이유가 있겠지만, 점점 폰의 성능이 향상되면서 더이상은 2D 화면으로 게이머들의 눈높이를 맞추기 어렵다는 사실을 인지했기 때문이 아닐까 한다. 이유야 어떻든, 3D 엔진이 탑재된 플랫폼에 발을 맞추기 위해서는 개발자들도 3D에 적응해야만 하는 것이 현실이다(진정한 3D 업종으로의 전환인지도 모르겠다). 새로운 핸드셋과 이에 따른 이슈들 얼마전 모토롤라에서는 타 폰보다 좌우로 넓은 LCD를 가진 와이드 폰을 국내에 출시했다. 물론 LCD 자체의 크기가 큰 것은 아니지만 새로운 액정 타입과 깔끔한 디자인으로 시장에서 선풍적인 관심을 끌고 있다. 또 삼성에서는 TV 튜너를 내장해 네트워크 접속없이 공중파 TV를 시청할 수 있는 폰을 출시함으로써, 동영상 VOD에 사업추진력의 대부분을 쏟고 있는 각 이동통신사들을 긴장하게 만들고 있다. 국제적으로는 삼성의 매트릭스 폰(영화 매스릭스 2에서 네오가 사용한 폰) 등 디자인으로서 차별화된 제품들이 많이 등장하고 있으며, 노키아의 N-Gage의 경우는 디자인 뿐 아니라, 게임기+통신모듈 인 듯한 제품 기능으로 휴대용 게임기 시장을 노리는 케이스다. 이렇듯 최근의 핸드폰은 디자인 및 다양한 기능의 특화로 사용자들의 구매욕을 자극하고 있으며 개발자에게도 특화된 기능을 활용하고 싶은 욕구를 불러일으키고 있다. 앞으로도 핸드셋 시장은 점차 다양성과 특화된 강력한 성능을 바탕으로 시장쟁탈을 벌일 것으로 예상되며, 이와 같은 특화된 폰의 특성과 기본적인 보편성의 가운데서 많은 고민을 하게 될 것 같다. @

 

ZDNET 펌~~