태그 보관물: 전투

아미 앤 스트레테지 전투 시스템 디자인 – 끝나지 않은 이야기

2012년 6월 경. 프로젝트가 거의 막바지에 이르고 있다고 자체적으로 판단을 했을 무렵. 게임 디자인에 대한 설명을 하는 글을 쓰기 시작했다. 당시의 글 들은 ‘아미 앤 스트레테지 시스템 디자인 기록’이라는 동일한 제목을 가지고 있었고, 총 두 편(전투 시스템, 외교 시스템)의 글을 작성하였었다. 외교 시스템의 경우에는 그때도 그랬지만, 지금에와서도 AI 개선 정도의 수정 사항 이외에 커다란 변경점은 없다.

게임의 전투 시스템은 2013년 2월, 리뉴얼을 선포 한 이후 대대적으로 개편되었다. 기존의 퍼즐 조합 형태의 자동 전투는 IGF China 2012 출품 및 행사 시연 당시 몇 가지 중대한 문제점을 노출하였었고, 크라우드 펀딩 캠페인이 진행 되는 도중에 시스템을 전체적으로 갈아엎는 무모한 결정을 하게 만들었다.

이번 글에서는 예전 글에 이어서 전투 시스템 리뉴얼의 결정과 지금의 전투 시스템에 이르기까지의 의사 결정 과정에 대해서 정리를 해 보고자 한다 – 이전의 전투 시스템 디자인과 관련한 기록은 ‘아미 앤 스트레테지 전투 시스템 디자인 기록’ 글 참조.

문제점 – IGF China 의 교훈

IGF China 이후에 전투 시스템 디자인에 대한 문제는 계속적으로 불거져 나왔다. 당시 상하이에서의 시연에서 드러난 문제점들 중 하나는 진입 장벽이 꽤 높다라는 것이었는데, 이것은 튜토리얼 부재 뿐만 아니라, 복잡한 형태의 전투 규칙에도 문제가 있다는 강한 심증이 있었다.

기존의 전투 시스템은 퍼즐에 가까웠다
기존의 전투 시스템은 퍼즐에 가까웠다

무엇보다 전투에서의 규칙을 ‘직관적으로 이해’하기 힘든 것은, 기존 전투 시스템의 가장 큰 약점이었다. 전투는 자동, 턴 방식으로 진행이 되었는데, 이 턴에서 ‘순서’를 결정하는 규칙이 매번 문제를 일으켰다.

  • 행동 우선권은 행동력이 높은 유닛 → 공격자 순으로 부여
  • 최전방에 있는 부대의 행동 우선권이 동일 할 경우 공 → 방 순이 아닌 동시 행동
    • 최전방에서 벗어나 있는 유닛은 이 규칙을 적용 받지 않는다
  • 유닛이 사망하면 자동으로 빈 자리를 체운다

큰 규칙은 단순한 편이었지만, 이 룰을 강제하기 위한 세부 예외 처리는 상당히 복잡했고, 무엇보다 직접 눈으로 봤을 때 몇 수 이상의 예측을 하기가 어렵다는 커다란 단점이 있었다(이를 개선하기 위해서 유닛 수를 줄여 경우의 수를 작게 만드는 등의 일을 하였었다).  특히, ‘유닛이 사망하면 자동으로 빈 자리를 채운다’는 룰은 플레이어의 예측을 빈번하게 벗어나게 만들고 말았다. 분명히 이번 행동에서 상대 유닛을 죽일것으로 예상을 했었는데, 자리가 변경 되면서 예상과 다른 유닛이 먼저 죽는 것 같은 사소한 예측 오류에서 부터, 어떤 경우에는 자리 변경에 대한 복잡한 예측을 하지 않으면 해법을 찾기 힘든 상황도 발생하였다-그것도 게임 시작 초반부에서.


궁병 vs. 궁병 – 어느쪽이 이길 것인가? 그리고 당신의 예상은 맞았는가?

이는 전투 진행에 대한 플레이어의 예측을 무너트리기에 충분한 요소였다. 예측이 되지 않는 플레이는 곧 규칙이 없는 것으로 받아들이기 좋았고, 게임에 대한 흥미 감소로 이어지기 좋은 문제다. 이는 별도의 세부적인 전투 튜토리얼을 거치지 않는 이상, 한계를 돌파하기는 힘들었다(실제로 ‘전투 전용 튜토리얼’인 ‘저니’ 모드를 만들어 테스트 했을 때에 전투 시스템에 대한 이해도가 대폭 올라가는 것을 확인 할 수 있었지만, 문제는 대부분의 플레이어는 튜토리얼이나 부가 게임 모드를 의무적으로 즐기진 않는다는 점에 있었다).

리-빌드

전투 시스템을 원점에서 다시 제작하기로 결정하였지만, 어떻게 제작 할 것인지에 대한 고민은 쉬운 것이 아니었다. 우선적으로 고려되어야 하는 ‘새 전투 시스템’은 아래와 같은 최소 충족 조건을 만족해야 했다.

  • 플레이어에게 직관적으로 전장 정보를 전달해야 함.
  • 전투 진행에 대한 규칙 파악이 쉽고, 결과에 대한 예측이 쉬워야 함.

기존 전투 시스템의 가장 큰 특징은 퍼즐과 같은 전투 진행(상대의 진형을 먼저 파악하고, 규칙에 따라서 수를 읽은 후, 자신의 진형을 결정하는 형태)이었다면, 새로운 전투 시스템은 좀 더 역동적이고, 능동적일 필요가 있었다. 실제 전장을 3D 환경에 담기는 게임 제작 여건 상 불가능한 일이었기 때문에, 독특한 개성을 가진 전장을 만들 필요가 있었다. 이러한 이유로 자연스럽게 기존에 폐기되었던 ‘실시간 전투’ 형태의 프로토타입들을 재검토하게 되었다.

기존 실시간 전투 형태에서 가장 문제가 되었던 부분을 꼽아본다면 다음과 같은 것들이 있었다.

  • 연출 상의 문제: 부대가 겹침으로써 발생하는 전장 정보 표기 혼란 문제.
  • 게임 조작 부재: 전투 진행 중 플레이어가 개입 할 여지가 없기 때문에 자칫 전투 자체를 보는 것이 지루해 질 우려가 있었다.
  • 2차원 전투의 한계: 신선한 형태의 전투이긴 하지만, 전투의 양상이 다양해지긴 힘들다.

한 번 버렸던 실시간 전투 시스템을 다시 들고 나온다는 것은 팀 내부에서도 모험과 같은 일임에는 분명했다. ‘기존 프로토타입의 단점을 개선 할 수 있을 것인가?’ 그리고 ‘개선을 했을 때 어떠한 결과물을 얻을 수 있는가?’ 에 대한 예측을 하는데 많은 시간을 할애 했다. 그 고민의 결과 새로 제작하기로 한 전투 시스템은 아래와 같은 특징을 가지게 될 것이었다.

  • 전투는 다시 예전과 같은 실시간 – 2차원 전투.
  • 부대의 위치 정리: 각 부대는 자신의 위치를 일정 이상 확보하며, 타 부대와 서로 겹치지 않는다.
  • 플레이어는 전투 상황에 좀 더 적극적인 개입이 가능하다: 전체 군단의 이동(전진, 후진, 후퇴) 결정, 구성 부대의 위치 결정.
  • 이전보다 더 확실한 공성전의 묘사: 일반 부대 + 공성 부대 형태의 2 라인(Line) 전투 묘사.

아트 디자인

신규 시스템을 제작하면서 시각적으로 크게 달라지는 부분은 ‘전장을 묘사’ 해야 하는 부분이었다. 때문에 전장에 배경이 들어가고, 부대들은 1기가 아닌 병력의 현재 수에 따라서 그 표기 기수가 가변적으로 변해야 했기 때문에, 유닛은 기존보다 한참 작게 표기 될 수 밖에 없었다.

때문에, 기존의 ‘체스 말 형태’의 부대 디자인은 신규 전투 시스템에 그대로 쓰기에 문제가 발생 할 수 밖에 없었다. 다수의 병력과 전장을 표현하기 위해 사이즈를 줄일 경우 발생하는 디자인 관련 문제, 전장 표현을 위해 부대 애니메이션을 새로 추가해야 하는 상황 등이 가장 대표적이었다.

기존 디자인을 버리기까지 많은 고민이 필요했다
기존 디자인을 버리기까지 많은 고민이 필요했다

거기에 더하여 팀원들의 작업 부하와 관련한 상황도 문제였다. 기존에 부대 디자인을 담당해주셨던 아트 디렉터에 대한 작업 부하가 우리가 좀 더 부탁드리기 어려운 수준으로까지 치솟는 중 이었다(무엇보다 우리의 결정으로 프로젝트 기간이 슬금 슬금 늘어나고 있는 탓이 컸다). 때문에, 부대 디자인에 대한 담당을 교체하고 유닛 디자인 역시 원점에서 다시 검토하는 결정을 내릴 수 밖에 없었다(아트 디렉터 분께서 정말 열의를 다하셔서 기존 유닛 디자인을 해 주셨다는 것을 알고 있었기 때문에, 담당자 교체 및 신규 작업 결정은 정말 어려운 결정이었다).

신규 유닛 디자인을 하면서 디자인 가이드 라인으로 삼는 부분은 다음과 같은 것들이 있었다.

  • 게임 내 그래픽 디자인 컨셉의 통일: 기존에는 장군 캐릭터들의 경우 카드 형태의 귀엽고 독특한 디자인에 진중한 형태의 유닛 디자인이었다면, 신규 유닛 디자인에서는 힘을 좀 빼고, 디자인 컨셉을 통일시키는 것에 중점을 둔다.
  • 캐릭터 구조는 단순하게: 동작 애니메이션 등의 기존에 없는 작업이 추가되므로, 최대한 단순한 구조로 디자인
  • 무장 및 장구의 디자인으로 유닛 다양화: 기존보다 훨씬 다양한 수의 유닛들이 등장하게 되므로, 무장 및 장구를 특징으로 각 유닛의 시각적 구분을 두고, 이들의 색상으로 등급을 표현.

마무리

새 전투 시스템을 만들기로 결정하기 위해, 그리고 결정을 한 이후 많은 시간이 소요 되었다. 그 오랜 시간 동안 많은 고민과 생각들이 겹쳐 일단은 결과물을 낼 수 있는 현재에 까지 도달을 하였지만, 몇가지 의문은 머릿속에서 가시질 않는다. 이전의 전투 시스템은 어째서 채택이 되었던 것이었을까? 프로토타입 단계에서 현재의 실시간 전투 시스템으로 선택 할 여지는 정녕 없었던 것일까? 같은-덕분에 개인적으로는 자괴감 같은 감정에 휩싸였던 것도 한 두번이 아니었었다.

게임 개발이 원래 그래요. 라고 읊조린다면야, 할 말은 없지만.

아미 앤 스트레테지 게임 디자인 연작 글 보기

수치 기반 밸런싱 – 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로 줄어든 것이다.

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

정리

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

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

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