반응형
몇달후 다행이 한국의 Gamebase라는 곳에서 인수를 했고, 미국 법인을 유지하면서 2011년 1월에 신규 버전을 런칭한다는 소식을 접해고, 해당 Gamebase 를 통해 관련 정보를 입수 했다.
기존 3.x대 버전 사용 개발자들에게는 패치형식의 업데이트 방법 같고, 신규 구매자나 겜브리오 엔진에 대해 새로 염두를 하는 개발자에게는 3.2 버전에 대해 궁금해 할 것이다. 본인이 알기로는 겜브리오를 사용하는 대부분 한국 개발 업체들이 2.x 버전을 사용하고 있을 것으로 알고 있다.
그동안 겜브리오 엔진의 2.x 버전을 사용하다가 이번에 처음 3.x 버전을 처음 접하면서 이슈가 될 수 있는 요소에 대해서 정리하고자 한다. 이 부분은 현재 개발중인 게임을 고려해서 바라본 항목이라 다른 스타일의 게임을 개발하고 겜브리오를 바라보는 개발자와의 의견차가 존재할 수 있다.
새로운 엔진을 반듯이 구매해야 하는가?
기존의 구버전을 통해 노하우가 어느정도 축적이 되어 있고, 겜브리오 엔진에 장단점을 명확히 알고 있는 상황이다.
어느정도를 지원하며, 지원이 안되기 때문에 직접 엔진을 수정하거나 개발을 해야 하는 요소에 대해서 명확히 알고 있는 단계다. 만약 현재 개발이 어느정도 진행이 되어 있고, 마무리 단계라면 굳이 신규 버전에 대해서 염두할 필요는 없다고 판단이 된다. 이미 개발하려는 게임에 맞게 겜브리오 엔진에 맞게 프래임웍이 구성이 되어 있을 것이기 때문이다.
만약에 개발을 새로 시작하거나 기존 엔진 버전의 문제점을 개선하기 위해 시간을 많이 투자를 못하는 경우에 대해서는 신규 버전을 염두하는 것도 방법이 아닐까 생각한다. 본인이 보는 또다른 한가지는 엔진을 판매하는 Gamebase의 정책을 눈여겨 보았다. 바로 기존의 2.6 판매 정책과 3.2 판매 정책이 다르다는 것이다. 기존의 2.6은 현재 개발을 어느정도 완성단계에 있고, 출시를 앞둔 개발사를 배려한 정책이라 그런지 향후 기술 지원이라는 부분이 빠져 있다.
반면 이제 막 나온 버전인 3.2 버전에 대해서는 기존의 겜브리오 엔진과 동일한 기술지원 정책이 적용이 된다.
겜브리오 엔진의 특징
가장 처음 겜브리오 엔진을 접할때 많이들 입에 오르내리는 말이 Scene 기반의 획기적인 엔진이라는 말과 함께 툴도 제공되고 익스포트도 잘되고... 결정적인 이슈는 WOW도 겜브리오로 만들었데...
그 이후 어느정도 사용해본 개발자들의 입에서는 Scene 기반의 한계로 가장 떨어지는 엔진중에 하나가 겜브리오인것 같다라는 말이 나오기 시작했다.
하지만 중요한 것은 겜브리오만의 특징이 있고 장점이 존재한다. 대부분의 겜브리오 엔진을 바라보며 또는 사용하며 언리얼이나 크라이 엔진급의 게임이 나오길 기대하고 수정보완을 하기 때문에 발생되는 문제들이 아닌가 싶다.
분명 장점은 있다. 예를 든다면, 디자이너들이 복잡한 과정없이 3D MAX에서 Export해서 뷰어툴이나 Scene Designer라는 툴을 통해 보고, 배치를 해볼수 있다는 장점이 있다. 한자리에서 게임이서 쓰일 데이터가 나오고 그것을 직접 엔진에 올려놓고 확인해본다는 것은 과거 일일이 프로그래머 손을 거쳐 검수후 보여지기 까지 번잡한 과정 없이 그래픽 자리에서 한큐에 해결한다는 건 정말 획기적이라 할수 있는 엔진이였다. (어디까지나 초창기 이야기다)
그런데, 대부분의 개발자나 개발사에서는 이건만을 원하는건 아니다. 바로 우리나라 대한민국은 온라인 게임을 개발하고 드넓은 필드와 MMO RPG라는 개념이 겜브리오 엔진을 통해 나오길 기대하고 그렇게 지시를 하고 개발을 한다.
하지만 겜브리오라는 엔진은 한마디로 팩키지용 엔진이다. 단순히 MAX에서 나온 데이터를 그대로 올려서 그대로 게임에 나오고 다시 화면 전환될시 다른 데이터가 읽어와 다시 찍어주고 하는 식의 간단한 게임용이라는 것이다.
그렇다면 나름 각자가 머리에 그려지는 게임들이 있을 텐데, 보편적으로 말하는 캐쥬얼 게임이라는 분야에서 많이들 사용되어지고 있다. 단순히 방만들고 들어가 한판 게임 신나게 즐기고 방을 나오면 끝나는 그런류의 게임을 말하는데 혹 다른 게임을 생각했다면 패스~
반면, 겜브리오 엔진을 가지고 엔진의 기대를 넘어서서 게임이 나오기도 한다. 과거 그런 게임이 있었지만 망했다.
나름 겜브리오의 한계를 넘어서기 위해 얼마나 많은 공을 들였을까 하는 생각을 하면 한편으로 그 엔진은 더이상은 겜브리오 엔진이 아닐 것이다라는 생각이 들기까지 한다. (대표적인것이 WOW 초창기에 썼던 넷이머스라는 엔진)
다시 간단히 겜브리오 엔진의 특징을 정리하면
1. 3D MAX에서 나온 결과물을 빠르게 확인 가능하다.
2. 인터페이스가 복잡하지 않아 쉽게 디자이너들이 접근 가능하다.
3. 간단한 룸개념의 게임을 개발하기에 좋다 . (Scene 단위 데이터 생성 방식?)
4. 팩키지 게임을 개발하기에 훌륭하다.
5. 기타 찾아 보면 더 있을듯...
엔진 2.6 의 기술적 한계
겜브리오 엔진은 DirectX 9.0 버전에 맞추어 개발이 되어 있다. 9.0 버전이 나쁘다는 것은 절대 아니다. 현재도 많은 게임들이 9.x버전으로 개발을 하고 있고 출시되어 있기 때문이다. 하지만 "겜브리오가 9.x를 제대로 지원하는가" 라는 질문을 던져보는데... 대부분의 겜브리오를 접하는 렌더링쪽 개발자들의 대답은 불만이 많은 편이다.
DirectX 9.0 SDK를 랩핑해 놓은 수준이라고 봐도 과언이 아니다라는 말이 나올 정도다. 겜브리오 초창기 버전은 특정 기능을 구현할때 DirectX SDK 로 개발하는 것 보다 한참 돌아가게 해서 코딩의 복잡도나 한계가 많아 문제점이 많았었다.
1. 렌더링 포퍼먼스가 아주 좋지는 못하다. (버텍스나 기타 3D 데이터의 효율성이 무척 떨어진다.)
2. 엔진 전체적으로 지원을 명확하게 지원하기보다는 시도 수준의 기능만을 제공하는 듯하다. ex) "이런것도 된다"
3. 제한된 파티클 지원
4. 쉐이더 적용이 단순함?
5. 멀티 스레드 지원이 불안정(거의 미흡함)
6. 맵툴이 별도로 없다. (일반적인 MMO RPG용 Terrain Tool)
7. 캐릭터의 IK 지원 없다.
8. 서드 파티가 부족해서 지원안하는 미들웨어 사용시 직접 연동 작업을 해야 한다.
추가 제작을 위해 투자해야 하는 요소들
게임 개발에 있어 엔진을 도입하는 이유의 큰 목적중의 하나가 컨텐츠 중심의 게임 개발을 진행하고자 엔진 도입후 컨텐츠에 제작을 집중 제작, 테스트를 하여 퀄러티 높은 게임을 개발하고자 하는데 주 목적이 있다하겠다.
반면 겜브리오 엔진(버전 2.x)의 경우는 달랑 렌더링 코어만이 존재하고 다른 게임 프래임웍을 구성하는 요소들이 어설프게 존재하다보니 오히려 개발자들이 겜브리오에서 제공된 것을 수정 보완하면서 개발하거나 아예 새롭게 개발하면서 개발을 하고 있다. 지금까지 개발을 해오면서 컨텐츠 개발을 위해 들어가는 시간보다 엔진을 해당 게임에 맞게 수정 보완 개선하는 시간의 투자가 많아 리스크가 크다 하겠다.
겜브리오 엔진 버전 3.2의 기술적 특징들
다음은 Gamebase 업체에서 강조하는 몇몇 이슈들에 대해서 먼저 정리 해보도록 하겠다.
1. 멀티 플랫폼 지원
2. 멀티 코어 지원
3. 포괄적인 개발 시스템
4. 빠른 프로토 타이핑과 제작 (KickStart를 이야기 하는 듯 싶다.)
5. 유연함과 확장성
6. 빠른 반복 작업
3.x 버전에서 LightSpeed라는 명칭으로 새로운 아키텍처를 제공하는 것으로 제공된 정보로 나와 있다.
이번 엔진 2.6 버전과 비교해서 3.2 버전에서 새로운 것들은 무엇인가를 먼저 살펴보자.
1. EMT(Entity Modeling Tool)
2. WorldBuilder
3. LuaDebugger
4. DirectX3D 10.x, 11 지원
5. Parallel-Split Shadow Maps(PSSM) : 참고 페이지
6. Entity and Behavior System
7. 기타 등등(나머지는 크게 이슈거리는 아닌듯하여 제외)
실제로 게임마다 다르기 때문에 이슈가 될만한 요소는 5번 기능(PSSM)의 지원인데, 그래픽적인 개선이 될만한 요소라 2.x의 경우 직접 관련해서 구현해야 했던 부분이 들어가 있는 요소라 하겠다.
또한 기획쪽이나 게임을 디자인하는 파트에서 Lua라는 스크립트를 기본적으로 제공되어 디버깅도 된다고 하는데, 구체적으로 살펴보진 않아 어느정도의 수준인지는 파악을 못했다. 만약 자체적으로 개발해놨고 어느정도 익숙하다면 기존에 개발된 Lua 나 기타 다른 스크립트 연동된 것을 사용해도 무방할듯 싶다.
3.2 버전에서 가장 크게 부각이 되는 요소중에 하나가 WorldBuilder라고 하는데, 이부분은 툴로 제공이 되고 기존 2.x 버전에서 제공이 되지 않았던 부분이고, 각자 업체 개발자마다 알아서 만들어 제작을 하던 불편함이 겜브리오에서 엔진에 맞게 만들어 놓았다고 한다. 하지만 예상컨데 게임의 특징에 따라 수정을 해야 하는 것은 분명 발생할거라 본다.
개인적으로 눈여겨 보는 요소중에 하나는 멀티코어 처리 부분인데, 겜브리오 엔진에서 NiFloodgate라는 라이브러리가 2.x 버전부터 들어가 있지만 버전 2.x에서는 그닥 빛을 보지 못한 부분이라 생각을 하는데, 이것으로 인해서 Lock과 Unlock이 뒤엉켜서 소스가 지저분해져 있는 듯하고 가끔 관련해서 오류도 나오는 부분이 있었다.
버전 3.2 에서 멀티 코어를 지원하고 기존의 불필요한 코드를 삭제했다고 한다. 아마도 최적화를 조금 한듯해 보인다.
파티클 시스템의 성능 향상
1. 파티클 갯수 제약이 더많은 갯수를 지원한다.
2. 기존 2.x 버전에 있던 몇몇 버그등이 수정이 되었다. (예) Clone시 멈추는 현상이 간혹 발생
쉐이더 시스템의 변화
2.x 버전에 비해서 3.x 버전에서 변화가 보이는데, 기존 3.1 사용자에게는 3.2 에서는 큰 차이가 없어 보인다.
1. 쉐이더 갯수 제약이 없다.
2. FX, FXL, FX10등의 쉐이더를 지원한다. 이로써 PSSM이 지원되는 듯하다.
물리 처리 강화
PhysX 를 기존 2.x 버전에 비해 강화된 연동을 지원한다.
특히 지형툴에서는 지형과의 충돌 처리부분까지 PhysX를 이용하고 있다.
PhysX를 이용한 Cloth 지원
3.x(3.2 기준) 구분명(namespace)이 추가
기술적 특징이라기 보단 2.6 버전과는 다른 구분이라 정리해 본다.
1. ecr : Emergent core
2. efd : Emergent Foundation
3. egf : Emergent Game Framework
4. egm : Emergent Gamebryo Message
5. eon : Emergent Online
6. etk : Emergent Network
각각의 크게 구성된 요소에 따라 구분명을 붙여서 기존의 2.x 버전대의 단순한 Core만 존재하는 것이 아닌 부가적인 요소의 기능들이 들어 가 있다.
부가적인 기능들 중에 눈여겨 볼 요소들
1. svn을 이용한 패치 시스템을 위한 기능이 들어가 있다.
2. 간단한 Network 게임을 개발할수 있는 P2P 기반의 네트웍이 연동되어 있다. (Replication 지원)
3. Lua외에 Python 스크립트 제공 (서버쪽에서 파이썬 선호시 괜찮을 듯하다.)
4. Log 서비스 기능
2.6과 3.2의 버전에서 위의 열거한 내용들외에도 다른 차이점들이 존재한다.
보통 개발후 1~2년후 출시를 염두하고 어느정도의 퀄러티를 지원해야 하는가 라는 고민을 대부분의 개발자라면 하게 될 것이고, 나름 시대 흐름에 부흥하는 수준의 그래픽 퀄러티를 제작하려 한다면, 엔진이 어느정도는 좋아야 한다고 판단된다. 요즘 개발자 뽑는 것이 어려운 상황에 엔진쪽 작업만 줄여도 컨텐츠 개발에 많은 향상을 가져올 거라 예상해본다. 게임을 개발하는 과정과 서비스되는 시점 그리고 유지보수 단계에서 엔진쪽의 기술 지원이 나름 이슈가 될수 있는데, 컨텐츠야 계속 제작하고 만들다 보면 어느순간에는 렌더링쪽의 부가적인 연출이나 이팩트 효과를 넣어야 하는 단계가 존재하는데 이때 엔진의 한계로 인해서 개발진행의 어려움을 겪어서는 안된다고 본다.
(개인 견해로는 Gamebase 의 기술 지원에 대해서는 과거 사례로 크게 기대하진 않는다.)
다시 정리하면 겜브리오 엔진 버전 2.6을 사용해서 여러가지 기술적인 기능들을 개발하고 어느정도 개발이 완성단계라고 한다면 굳이 엔진을 버전업 할 필요는 없다고 생각한다. 하지만 시작단계나 프로타입단계에서 겜브리오 엔진을 고려한다면 3.2 버전으로 시작해보는 것이 어떨까 싶다. 향후 개선이 더 된다면 앞으로 3.4, 3.6 .... 버전이 더 나올 것이고 그런 개선된 기능들이 앞으로 개발후 서비스되는 요소에 부흥 할수 있다면 좋은 것이 아닌가 싶다.
개인적인 여담으로 기술은 더 낳은 기술을 만들고 시대 흐름을 유지하거나 앞서가야 한다고 본다. 컨텐츠만을 볼때는 기술이 꼭 돈을 벌어주는 요소는 아니라고 본다. 다만 컨텐츠를 원활히 소화해낼 수 있는 도구가 기술이 아닌가 싶은데 적어도 개발자들이 많은 욕심을 내는 것이 아닌 최소한의 시대 흐름에 맞추어 나가면 개발하는 환경은 갖추어져서 개발해야 한다고 본다.
반응형