스턴락 스튜디오에서 개발한 ‘배틀라이트’는 기존의 MOBA(Multiplayer Online Battle Arena) 게임과는 다른 노선으로 주목받은 게임이다. 일반적으로 MOBA 장르는 파밍을 통한 성장과정을 거치고, 공성과 한 타 싸움을 통해서 승부를 가리는 방식이다. 그렇지만 배틀라이트는 이와 같은 요소를 배제하고 지속적인 싸움을 통해서 승패를 가리는, 말 그대로 '배틀'에 치중한 게임이다.
배틀라이트는 그 특유의 스타일리시한 아트풍과, 심플한 룰, 쉽고 빠른 전투 방식으로 호응을 얻어 2016년 얼리액세스 출시 후에 70만 장 이상 판매됐으며, 2017년 11월 8일 스팀에 정식으로 출시됐다. 국내에서는 넥슨이 퍼블리싱을 맡아 연내 출시 예정이다. 국내 출시 전 스턴락 스튜디오의 토비아스 요한슨 프로그래머는 플레이엑스포 컨퍼런스에서 유저들에게 배틀라이트가 어떻게 만들어졌는지에 대해서 설명하고자 한다.
배틀라이트는 13명의 학생이 시작했던 프로젝트 '블러드라인 챔피언'에서부터 시작했다. 이때 멤버를 중심으로 해서 스턴락 스튜디오가 만들어졌고, 현재는 스웨덴의 스코브드라는 소도시에서 약 50명 정도가 배틀라이트를 제작하고 있다.
요한슨 프로그래머는 일반적으로 말하는 MOBA 게임과 배틀라이트는 지향점이 다르다는 것을 강조했다. 도타, 리그 오브 레전드 등은 플레이하면서 레벨이 오르고, 벌어 들인 돈으로 아이템을 사들이는 성장 요소가 들어있다. 그렇지만 배틀라이트는 그 부분을 배제하면서 오직 전투라는 요소에만 집중했다. 이를 두고서 요한슨 프로그래머는 팀 아레나 브롤러라고 정의했다. 순수하게 팀 단위로 싸움을 계속한다는 의미에서 그렇게 이름붙인 것이다.
전투라는 요소에 집중한 만큼, 배틀라이트는 유저에게 빠르고 다양한 전투의 느낌을 제공해야 했다. 그래서 각 캐릭터마다 다른 특수 능력을 부여하고, 스테이터스를 다양하게 적용해서 캐릭터의 개성을 살렸다. 또한 컨트롤과 무빙의 묘미를 살리기 위해서 모든 스킬을 논타겟 방식으로 구성했다.
기획 단계에서 이런 차이점을 언급하는 것은 크게 문제가 되지 않았다. 다만 이를 실제로 구현하기 위해서는 여러 문제가 있었다. 우선 캐릭터가 30명 이상인데, 각 캐릭터마다 9가지의 스킬이 있으며 능력치나 스테이터스도 다 달랐다. 스킬 메카니즘도 다양했기 때문에 이를 빠른 시간 내에 다 구현하는 데에 어려움이 봉착했다.
앞서 말한 것처럼 배틀라이트는 국면 전환이 빠른 전투 위주의 온라인 게임이다. 아울러 전투의 안정적인 재미를 위해서는 움직이거나 스킬 사용 간에 렉이 없이 매끄럽게 움직여야만 했다. 즉 네트워크 반응이나 로딩 문제도 중요했다.
또한 배틀라이트는 다수의 대전 게임처럼 처음부터 e스포츠를 염두에 두었다. 즉 e스포츠화를 위해서 공정성과 캐릭터 밸런스, 지속성을 확보해야만 했다. 이를 확보하기 위해서는 캐릭터 밸런스를 지속적으로 테스트하고 적용하는 과정이 필요했다. 이를 어떻게 매끄럽게, 시간을 효율적으로 활용해서 진행할 수 있느냐가 관건이었다.
처음 배틀라이트를 개발할 당시에는 24명의 작은 팀이었고, 1년 반 이상 개발을 지속해왔다. 지금에 와서는 인력도 늘었고, 기술도 늘었지만 지금까지 다다랐지만 요한슨 프로그래머는 저 문제에 대한 해답은 아직 완벽히 나오지 않았다고 고백했다. 다만 그는 자신과 스튜디오 멤버들이 이를 해결하기 위해서 고민한 것들에 대해서 풀어놓았다.
배틀라이트를 개발할 때 그는 유니티를 활용하긴 했지만, 유니티를 메인 엔진으로 사용하지 않았다. 네트워크 관리와 게임플레이에 관련된 엔진은 독자적으로 만들면서, 유니티는 비주얼적인 부분을 보조하는 이중적인 방식으로 설계를 한 것이다. 예를 들어 유니티는 게임플레이 구동 간에 크게 변화가 없는 UI 같은 부분에 사용했으며, 일부 애니메이션 구현은 유니티를 활용해서 만들어냈다.
개발 간 가장 신경을 쓴 부분은 로딩과 이터레이션 타임을 최소한으로 줄이는 것이었다. 개발을 하면서 특정 부분이 문제가 생길 때 수정하고, 컴파일하는 작업을 반복하면서 문제를 해결해나가게 된다. 이 과정에서 로딩이 길어지면 그만큼 개발 시간이 낭비가 되는 만큼, 모든 개발자들이 이를 줄이는 것을 최우선 과제로 삼는다.
또한 디자이너와 아티스트들은 자체 코드를 활용하거나 하는 부분에서 제한이 있기 때문에, 그들도 쉽게 활용할 수 있는 툴이 필요했다. 이때 유니티는 매우 유용하게 쓸 수 있는 툴이었다. 스튜디오의 멤버 대부분이 유니티에 익숙했기 때문이다.
배틀라이트의 아키텍처는 앞서 말했듯 이중적으로 구성되어있다. 자체 엔진으로 게임플레이와 네트워크, 피직스 부분을 구축하고 자체 툴로 데이터와 스텟, 에셋 등을 관리한다. 여기에 유니티는 그래픽과 사운드, UI, 에셋, 인풋을 구현해두고, 자체 엔진과의 연계를 통해서 모니터에 실제 게임플레이 화면을 출력하는 방식을 취한 것이다.
연계 방식은 우선 유니티가 그래픽과 사운드, UI, 에셋, 인풋 등을 게임엔진에 넘긴다. 그러면 게임 엔진 번들이 캐릭터 좌표나 스킬 효과 등 시각화된 데이터 일체를 유니티로 넘기고, 유니티는 이 데이터들을 언팩해서 스크린에 출력하는 방식이다. 개발 과정에서 이 과정은 로컬 네트워크를 통해서 진행되며, 둘은 다른 exe 파일을 갖고 있다. 즉 둘이 연계는 되어있지만 독립적으로 움직인다는 것이다.
이 말을 다르게 이야기하자면 게임플레이 화면과 엔진이 분리가 되어있다는 의미이기도 하다. 이 방식의 장점은 데이터를 수정했을 때, 바로 게임플레이에서 어떻게 영향을 미치는지 확인할 수 있다는 것이다. 기존의 원 엔진 방식에서는 엔진에서 수정하고, 컴파일하고 빌드를 만드는 과정을 거친다. 이 과정에서 많은 시간이 소요되고, 빌드가 되는 동안에 다른 작업을 할 수 없다는 단점이 있다. 하지만 배틀라이트는 자체 엔진과 툴을 따로 구축하고 유니티와 연계했다. 유니티에서 빌드를 만드는 동안에도 자체 엔진은 별도로 움직이기 때문에 게임플레이 상황을 내버려두고 코드를 바꾸는 것도 가능하다. 배틀라이트에서 유니티는 게임 엔진 자체를 건드리지 않고, 게임 로직과 별도로 움직이기 때문에 유니티를 끄고, 코드를 바꾼 다음에 컴파일하고 유니티를 실행하면 되기 때문이다.
요한슨 프로그래머는 애쉬카의 스킬을 일부 조정하는 과정을 직접 시연하면서 이 부분에 대해서 설명했다. 애쉬카의 화염구 스킬의 데미지를 높이기 위해서는 자체 엔진 내의 화염구 스킬의 코드 수치를 일부 변경하고 바로 컴파일하면 된다. 몰튼 피스트 스킬에 붙은 넉백을 화염구에도 구현하고자 하면 게임 툴에 들어가서, 몰튼 피스트 스크립트에 있는 넉백 스크립트 코드를 복사해서 화염구 스크립트에다가 붙여넣기하고, 변수 이름을 바꾼 다음에 세부 수치를 조정하고 저장하면 된다. 원상복귀하고 싶은 경우에는 코드를 지워서 해결할 수 있다.
이렇게 즉각적으로 게임플레이 화면에서 캐릭터의 스킬 효과와 데미지가 적용되는 걸 확인하고, 바로 컴파일해서 수정하는 과정을 구축하면 시간을 획기적으로 절약할 수 있다고 요한슨 프로그래머는 강조했다. 한두 캐릭터라면 모르지만, 30명 이상의 많은 캐릭터가 구현이 된다면 컴파일하는 시간이 그만큼 길어지게 되기 때문이다.
시간을 줄일 수 있는 아키텍처를 구현하기 위해서 그는 무엇보다도 데이터에서 변수 형태를 최소화했다고 언급했다. 스턴락 스튜디오에서는 float 등 일반적으로 사용되는 변수를 거의 사용하지 않았다. 대신 스테이트와 상수 데이터를 활용했다. 이 둘을 별도로 리스트화한 상태에서 비주얼 스튜디오로 코드를 만들고, 컴파일하고, 런하는 과정에서 이 데이터가 서로 교류하고 스왑하면서 적용되는 방식을 취한 것이다.
코드를 구성할 때는 레퍼런스를 통해 모든 요소에 접근할 수 있도록 했다. 즉 큰 스테이트 리스트에서 어떤 한 데이터를 찾을 수 있도록 한 것이다. 셀프 스테이트를 통해서 인스턴스와 관련된 모든 변수를 볼 수 있도록 설정하고, 다이렉션 등 변수를 설정하거나 또 다른 변수를 설정하는 방식으로도 게임 속에 적용되는 스킬의 효과 등이 변경되도록 했다.
이런 아키텍처들을 처음 구현할 때는 꽤나 복잡한 과정을 거쳐야 하고, 고려할 부분이 많았다고 요한슨 프로그래머는 회고했다. 하지만 이 과정을 구축해야 하는 이유가 더 컸다고 강조했다. 구현해야 할 캐릭터가 많아지면 많아질수록 반복작업으로 인해서 소요되는 시간은 기하급수적으로 늘어난다. 이를 역으로 말하자면, 이터레이션 타임을 처음부터 줄이는 방법을 찾고 적용함으로써 그만큼의 시간을 줄일 수 있다는 의미이기 때문이다.
■ Q&A
Q. 배틀라이트의 아키텍처는 처음부터 그렇게 이중적인 구성으로 만들고 적용했는지 궁금하다.
요한슨: 그렇다. 우리의 첫 프로젝트인 블러드라인 챔피언스를 만들었을 때 밸런스 문제가 있었고, 이를 수정하는 과정에서 앞서 말한 이터레이션 타임 이슈가 발발했다. 이런 것을 다시 겪지 않기 위해서 빨리빨리 중간에 체크하고, 이터레이션 타임을 줄이는 방식을 처음부터 고려해서 설계했다.
Q. 자체 엔진과 또 다른 엔진으로 렌더링과 게임플레이를 분리한 구성인데, 여기서 유니티를 선택한 특별한 이유가 있나 묻고 싶다.
요한슨: 스튜디오의 인력들 대부분이 유니티를 활용해서 게임을 만든 적이 있어서 편했기 때문이다. 또한 유니티의 렌더링은 괜찮은 수준이고, 또 이미 시중에 나온 툴이고 일반적으로 많이 사용하는 툴이기 때문에 새로 인력이 추가됐을 때 적응하기도 쉬운 것도 이유 중 하나다.
Q. 다른 엔진을 활용했을 때 이터레이션 타임을 줄이는 방안에 대해서 조언을 해주었으면 한다.
요한슨: 사실 다른 엔진을 활용한 경험이 많지 않아서 만족스러운 답을 주기는 어렵다. 다만 엔진마다 스크립트 언어나 데이터를 실시간으로 변환하는 방법들을 지원하는 경우도 있는 만큼, 이 부분을 확인해보는 게 좋을 것 같다. 물론 처음부터 구축해야 하는 경우도 있다. 실제로 우리도 우리가 필요한 부분을 처음부터 구축하기도 했고.
디자이너는 우리와는 다른 시스템을 활용하기도 했다. 예를 들면 워크래프트 3 엔진 같은 거라던가, 그런 걸로 자신이 원하는 것을 일단 구현해둔다. 그리고 나서 그 자료를 우리에게 보여주는 방식이다. 그걸 엔지니어가 보고서 우리 툴에 적용하고는 했다.
Q. 유니티로 어떤 것들을 만들어서 적용했는지 더 구체적으로 듣고 싶다.
요한슨: 레이아웃 등 게임플레이 화면에서 들어오는 부분은 유니티로 구현했다. 윈도우 매니지먼트를 위한 부분이라던가, 그 외 다른 시스템도 유니티로 어느 정도 만들었다. 일단 최대한 활용할 수 있는 부분은 최대한 활용했다고 볼 수 있다.
Q. 디자이너가 작업을 하면서 때로는 리로딩이나, 재시작을 해야 하는 경우도 있을 것 같다. 이때 이 방식이 문제가 되지 않는지 궁금하다.
요한슨: 이 질문에 답하려면 시스템에 대해서 더 자세히 설명해야 할 것 같은데, 그러기엔 시간이 상당히 부족하다. 일단 간단하게 말하자면, 우리 방식에서는 게임 내에서 변경 사항이 있으면 로컬 게임 에셋 서버에 호스팅하고, 개발 모드에 있는 게임이 실시간으로 업데이트가 된다. 이걸 바로 받아와서 리로딩하는 방식이다.
이 과정에서 애초에 리로딩을 하지 않고는 변동사항이 적용이 안 되는 경우도 존재한다. 이 경우에는 엔진을 재시작하거나, 혹은 코딩으로 해결할 수 있다. 다만 이 부분을 최소화하려고 하고 있고, 이 분야는 아직도 우리가 계속 고민 중에 있는 영역이다.
Ruudi@inven.co.kr