태그 보관물: 밸런스

클라우드 게이밍 – 그리고 게임 디자인

개인적으로 올해 2014년 지스타에서 게임 이외의 관심을 끌었던 이슈는 클라우드 게이밍(또는 스트리밍 게이밍)으로 대표되는 이른바 N-스크린 게이밍에 대한 이야기였다. NC 소프트는 ‘리니지 이터널’로 클라우드 게이밍 기술을 전면에 내세우며 이슈를 만드는 분위기였고, 지스타가 끝나기 무섭게 엔비디아에서는 스트리밍 게이밍 주변기기인 쉴드 태블릿을 국내에 발표하면서 시장의 주목을 받고 있는 중인 듯 하다.

이것으로 자기 전에 침대에서 게임을! - 그 전에 아내에게 욕 안들으면 다행이겠지만. ;
이것으로 자기 전에 침대에서 게임을! – 그 전에 아내에게 욕 안들으면 다행이겠지만. ;

기술적인 부분에 대한 장 단점은 이미 소니 / 엔비디아 / 밸브(스팀) 등이 해당 기술을 적용 한 제품들(리모트 플레이 / 쉴드 / 스팀 홈 스트리밍) 을 발표하면서 매 번 이야기가 되었기 때문에 그 주제를 다시 한 번 꺼낼 필요는 없을 듯 하다. 다만 이번 리니지 이터널에서 보여졌던 ‘특징이 서로 다른 하드웨어(PC – 모바일 디바이스)’에서 적용 되는 클라우드 게이밍 환경에서의 게임 디자인 측면의 고민에 대해 몇 가지 매모를 남겨보고자 한다.

서로 다른 환경이 가져오는 게임 디자인 부분의 문제

PC와 모바일 디바이스의 사용자 환경은 입력기기와 디스플레이 측면에서 커다란 차이점을 보인다. 키보드와 마우스로 대표 되는 PC의 입력 기기는 모바일 디바이스의 터치 입력 체계에 비해서 훨씬 많은 종류의 입력을 세분화 할 수 있고, 정확도 역시 우월한 반면, 터치 입력 체계에 비해 조작이 대단히 복잡하고 잡아 끄는(드래그) 조작이 상대적으로 불편한 단점이 존재한다.

더불어서 모바일에서의 터치 입력 체계는 디스플레이 장치 위에서 입력이 직접 일어나기 때문에 사용자에 의해 스크린을 가리는 현상이 일어나기 때문에 디스플레이의 UI 구성에도 영향을 받기 마련이다.

이렇게 서로 다른 환경에서 ‘동일한’ 게임을 플레이 한다는 것은 1차적으로 게임의 ‘사용 경험’이 갈리게 만들 수 밖에 없게 된다. 그리고 여기에 대한 게임 디자인적으로 가장 큰 부작용은 바로 ‘멀티플레이 게임에서 게임 장치에 따라서 밸런스가 무너진다’ 라는 점이다.

서로 다른 개성을 가진 다양한 기기에서 동일한 게임을 즐기겠다는 클라우드 게이밍의 기본 전제는 여기서 문제가 발생한다. 동일한 게임을 즐기지만 게임 경험은 천차만별로 갈리는데다, 공정성을 추구해야 하는 게임이 공정해지지 못하는 현상이 발생한다. 기존의 스트리밍 게이밍은 이 문제를 아에 하드웨어적인 방식으로 해결했는데, 소니의 리모트 플레이는 PS4 와 Vita를 이용하여 게임 경험을 통일시키려 하였고, 엔비디아의 쉴드 역시 초기 버전에서는 별도의 게임 패드를 기기에 강제로 통합시켜버리는 식으로 문제를 해결했다(하지만 쉴드 태블릿에 와서는 게임 패드를 별도 분리 시켰는데 개인적으로 이건 엔비디아의 실책이라 생각한다). 스팀의 홈 스트리밍 역시 사용 환경은 방 안의 PC 와 거실의 PC를 연동 하는 쪽으로 가닥이 잡혀있는 상태이다.

까짓거 동일한 환경 만들면 되지 - 단 비타는 네가 사야 함
까짓거 동일한 환경 만들면 되지 – 단 비타는 네가 사야 함

환상속의 그대… 는 아니지만

그렇다면 이기종간의 진정한 클라우드 게이밍(과 스트리밍 게이밍)은 환상향이나 기술 실증에 불과한 일인가? 하드웨어적으로 게임 디자인 문제를 해결하지 않는다고 하더라도 방법이 없는 것은 아니다. 몇 가지 방법을 떠올려 본다면 다음과 같은 방법론이 있을 것이다.

방법 1. 각 기종 특성에 따른 밸런스를 따로 맞춘다.

특성이 서로 다른 게임 기기에 대해서 서로 다른 밸런스를 맞추는 방법이 있을 수 있다. 터치 디바이스에서의 끌어 당김 조작은 패널티를 주고, 핀 포인트 터치 조작은 보너스를 준다거나, 반대로 PC 환경에서는 서로 반대의 보너스와 패널티를 주는 방식이다.

문제는 이러한 밸런싱을 잡는데 있어서 게임 디자이너의 감에 의존하게 되고 이를 정량화 할 모델을 만들기가 쉽지 않다는 점에 있을 것이다(아마도 그 모델 만드는 시간에 게임 하나 더 만들 수준의 것이라 생각한다).

방법 2. 그냥 지원 기종 모두에 적당히 잘 어울리는 게임을 만든다.

리니지 이터널 같은 식의 핵 앤 슬래쉬 게임은 다행이도 PC와 모바일의 조작 방식에 있어서 커다란 차이점을 보이진 않는다. 다만 게임 디자인에 있어서 게임 플레이의 정밀도는 적당히 뭉개는 수준으로 게임 시스템을 제작 할 수 밖에 없다는 점은 존재한다 – 모든 판정의 타이밍을 상당히 여유있게 잡아버린다던가, 모든 기기에서의 조작을 감안해서 조작 자체를 최대한 단순하고 심플하게 죽여버리는 방법이 있을 것이다.

당연히 이런 고려 하에서는 대전 액션, 리듬 액션, 슈팅 게임 등의 제작은 제약을 받을 수 밖에 없다 – 아마도 제약이 더 많은 모바일 환경에 어울리는 게임과 장르만이 그 대상에 포함되지 않을까.

N 스크린 – 게임 디자이너가 고려해야 할 것이 N배 씩 쌓여가는 함정

클라우드 게이밍 자체야 기술적으로는 어느정도 확립이 된 이야기이지만, 전혀 다른 기종 간의 게임 플레이 밸런스에 대한 문제는 이 기술이 점차 발전한다는 가정하에서는 게임 디자이너에게 골치 아픈 이야기 일 수 밖에 없을 듯 하다 – 사실 개인적으로야 클라우드 게이밍 시장은 요즘 휴대기기에서의 스마트 워치와 비슷한 성격의 시장 아닌가 싶다(흥미를 끌 만 하지만 정작 사용자가 얼마나 될까 싶은 수준의).

사실 이러한 작업을 할 만한 위치에 있는 게임 디자이너는 아마도 전 세계에서도 극소수에 불과 할 문제라 보기 때문에 나 자신도 흥미 위주의 생각 이외에는 더 깊게 생각해보고 싶진 않다 – 개인적으로는 평생가도 그런 게임은 못 만들지 않을까. (아, 잠깐. … 눙물이 ; ) 그렇기 때문에 메모는 여기까지만. (도망)

수치 기반 밸런싱 – R 프로젝트의 병과 상성 밸런스 잡기

R 프로젝트에 삽입되어 있는 전투 시스템은 기본적으로 자동으로 이루어진다. 플레이어가 전투에 직접적으로 개입 할 수 있는 여지는 존재하지 않는다-어째서?! 라고 반문하고 싶겠지만 미안하다 전투를 따로 구성할 여력이 없다(어흑). 다만 플레이어는 전투 경험이 쌓인 휘하 장군들이 레벨 업을 함에 따라서 개별 장군들의 병사 구성을 편집 할 수 있다.

각 장군들은 자신의 고유 병과(예를 들어 육군/공군/해군)를 가지고 있으며, 이 고유 병과는 서로 물리고 물리는 관계로 상성이 구성되어 있다.

  • 육군은 해군에 강하다.
  • 해군은 공군에 강하다.
  • 공군은 육군에 강하다.

각 고유 병과 별로 레벨 업 때 마다 추가 유닛이 해제 되는데, 이 유닛들은 기존의 상성을 강화(육군은 해군에 더욱 강해진다)시켜주거나 혹은 기존 상성을 무시(육군이 공군에 강해진다)하고 역의 유닛을 잡는 역할을 하는 것을 디자인 목표로 삼았다. 때문에 유닛 설정에 있어서, 각 유닛 간 교차 상성 밸런스를 잡아야 되는것이 게임 디자이너의 최우선 과제가 되었다.

기본 상성도: 물론 각 추가 유닛 간 상성도 존재하지만 이 도표에서는 제외

밸런싱을 잡기 위한 방법은 여러가지가 있다. 일일이 설정 스크립트의 수치를 하나 하나 바꿔가면서 게임을 플레이 하면서 모든 것을 직접 확인해보는 방법은 가장 단순 무식하고 시간을 많이 잡아먹는다. 견고한 수식 체계를 만들고 머릿속에서 연산을 하는 방법은 필자와 같이 뇌의 노화가 진행되고 있는 평범한 인간에게는 불가능한 일. 때문에 R 프로젝트의 병과 상성 밸런스를 잡기 위해서 다음의 방법을 사용하였다.

1. 프로그래머에게 전투 테스터와 로그 작성기를 요청한다

프로그래머에게 전투 테스터(Battle Tester) 기능을 요청하였다. 스크립트화 된 테스트 셋(Test set)을 읽어와 자동으로 전투 진행 중 발생하는 이벤트들에 대한 로그(Log)를 CVS 형태의 파일로 저장해주는 것. 데이터는 프로그램 내에서 가공하지 않고 날 것 상태(Raw Data)로 저장하도록 하였다-자잘한 통계 분석 사항 때문에 프로그래머를 귀찮게 하느니 게임 디자이너가 바로 데이터를 가공하여 확인하는 것이 훨씬 빠르다. 유능한 프로그래머 덕분에 기능은 반나절 정도 뒤에 완성. 자잘한 버그 테스트를 거친 후 바로 실전에 투입하였다.

날 데이터는 좋은 단백질 공급원이죠

2. 데이터 가공을 준비한다

전투 테스터에서 별도의 데이터 가공을 하지 않은 대신 기획자가 직접 데이터 가공을 준비하였다. 대량의 데이터 처리를 위한 통계 패키지(SAS, SPSS, R 같은)의 이용을 검토하였지만, 배가 산으로 갈 공산이 크다고 판단하여 스프레드시트(마이크로소프트 사의 엑셀)를 이용하기로 결정했다. ‘전투 보고서’라 이름 붙인 문서에는 총 3개의 시트를 만들었는데, 각각의 역할은 다음과 같다.

  • 보고서: 가공한 데이터의 처리를 보여주는 시트, 개별 테스트의 테스트 통과 여부와 밸런싱에 필요한 통계 데이터를 보여주는 역할을 한다.
  • 데이터: 전투 테스터에서 생성된 로그 데이터를 입력하는 시트. 자동으로 엑셀 문서에 데이터를 밀어넣어주면 좋겠지만 어른들의 사정에 의하여, 일단 복사&붙여넣기로 해결했다.
  • 쿼리: 보고서 작성을 위해 필요한 스프레드시트 용 쿼리 테이블을 입력한 시트. 엑셀의 DB 관련 처리 함수의 구조 상 필요했다.

전투 보고서를 만들면서 가장 미묘했던 부분이 엑셀의 DB 관련 함수들. 사실 원하는 기능은 장대한(?) 로그 데이터들 중에서 검색 조건에 맞는 애들을 추출해서 통계 처리를 하기를 원했던 것이었지만, 엑셀로 게임을 만드는 수준의 능수능란한 사용자는 아니었기 때문에 적절한 함수를 찾는데 시간이 소모되었다. 어찌어찌 DB 관련 함수들로 원하는 기능을 작성하기 시작했지만 개인적으로 테이블을 기반으로 데이터 검색 조건을 작성하는 방식은 그리 직관적으로 와닿지 않았던데다, 요령도 없어서 일일이 검색 조건과 보고서의 셀을 일일이 수작업으로 맞춰야 했다-때문에 개발 서버에 자동으로 올려서 php로 파싱, DB에 저장 한 후 SQL로 데이터를 추출-가공-결과를 HTML로 출력… 같은 것을 잠시 생각했다가 프로젝트가 또 다시 히말리아 등반을 하고 있는 것 같아서 포기.

모든 테스트가 파란불이면 '기본'이 끝난겁니다.

보고서 항목은 눈에 잘 들어도록 중요한 부분에 알록달록 색을 추가해 준다. 엑셀에서 지원하는 ‘조건부 서식’ 기능을 이용해서 통과 된 테스트는 ‘초록색’, 통과하지 못한 테스트는 ‘빨간색’으로 불이 들어오도록 세팅해 문제가 된 테스트가 한 눈에 들어올 수 있도록 하였다.

3. 자, 이제 테스트에요

준비가 되었으면 전투 테스터와 전투 보고서를 가지고 테스트에 들어간다. 자! 드디어 밸런스 완성! (짝짝짝) …… 이면 좋겠지만, 좋은 도구들을 만들어둔다고 하더라도 밸런스 조정은  막장일이다.

이 사이클을 수백번 쯤 하면 운 좋게 밸런스가 맞을지도?

특히, R 프로젝트와 같은 교차 상성 밸런스는 하나의 유닛의 수치가 변경 되면 다른 테스트에 바로바로 영향을 미치기 때문에, 도구들이 있더라도 반복 테스트는 결국 피할 수 없게 된다. 테스트 결과가 서로 독립이 아니란 점은 밸런스 테스트 후반부에 사람을 더욱 괴롭히는 요소가 되어버렸다. 하나의 테스트를 통과하면 기존에 통과한 테스트가 다시 실패로 돌아가는 악순환에 빠지는 것. 이 부분을 해결하기 위해서는 근성과 데이터를 보는 눈을 필요로 한다. 밸런스 판정에 필요한 수치들을 찾아내서 이를 기반으로 수정해야 할 유닛 설정 값을 유추해 내는 것은 전적으로 게임 디자이너의 논리와 감각에 달린 일이다.

빨XX를 잡아야 합니다!

그나마 다행인 것은 미리 준비한 위의 도구들이 있었기 때문에 이 정도 수작업이라도 감내할 수준이었다는 것. 테스트에 사용된 기본 테스트 셋은 총 27개였는데, 이를 유닛의 수치 하나 바꿀 때 마다 일일이 27회씩 테스트 하여 결과를 보는건 상식적인 인간이 할 짓은 아니다-최소한 툴이 있어서 업무량이 1/27로 줄어든 것이다.

모든 테스트에 통과되었다고 해서 일이 모두 끝난 것은 아니다. 기본 수치상으로는 유닛의 상성이 맞다고 해도, 플레이어가 플레이하면서 느끼는 감정은 또 다른 이야기가 된다. 해당 유닛 특성에 맞는 설정을 입혀주고, 비주얼 디테일을 잡아주고, 기타 여러가지 작업들을 해야 최종적인 유닛 설정 작업이 최종적으로 완료가 된다.

정리

유닛 등의 수치 밸런스를 잡기 위해서는 일단 그 수치가 정확하게 파악이 되어야 한다. 게임 상에서 직접 플레이를 해 보며 밸런스를 잡아나가는 것은 게임 내 ‘플레이 감각’을 파악하는 데 도움을 주긴 하겠지만, 결정적으로 그것이 원하는 결과인지를 확신할 수 없게 만들어버린다. 물론 당신이 촉이 좋은 사람이라면야 이야기가 다를 수도 있지만.

수치 밸런싱을 위한 작업 순서를 다시 한번 정리하고 긴 글을 마무리 하도록 하겠다.

  • 밸런싱 목표를 수립한다. 목표는 구체적이고 명확해야 한다.
  • 해당 목표를 확인 할 수 있는 도구를 제작한다-별도의 테스트 툴, 스프레드시트, 통계 패키지등 여러가지 옵션 중에서 규모와 형태에 맞게 적당히 선택한다.
  • 목표를 검증 할 수 있는 테스트를 설계한다.
  • 테스트를 검증 할 수 있는 데이터를 선정하고 이것을 추출-가공한다.
  • 테스트 결과에 맞춰 밸런스를 수정한다.
  • 모든 테스트가 통과 할 때 까지 무한 반복.