[아카이브] 게임 디자인의 결정 모델과 최적화 Part 1: 소개

[Zerasion 4]

Voosco 님이 작성하셨던 포스팅의 아카이빙입니다.

---

 

게임 디자인의 결정 모델과 최적화 Part 1: 소개

여러 복잡한 개념들을 원문에도 충실하고 뜻풀이도 이해가 용이하게 해석하기가 어려워서 이번에는 의역이 상당히 많이 들어갔습니다. 원문에 충실 vs 이해 용이 중에서 후자쪽을 택했다고 보시면 됩니다. 한편 저로서는 이해를 돕는걸 우선하기 위해서였으나 오히려 이로 인해 혼선이 빚어질 수도 있겠죠. 이런 점이 신경쓰이는 분들은 원문주소를 참조해주세요.

원문 주소 : http://intelligenceengine.blogspot.kr/2013/07/decision-modeling-and-optimization-in.html

------------------------------------------------------------------------------------------------------------

우리는 반복검증이 아니라 탐색을 한다.

게임 디자인의 대부분은 탐색의 과정이다. 디자인을 할 때면 우리는 주어진 게임 디자인의 문제를 해결하기 위해 취할 수 있는 여러 디자인 측면에서의 초기값을 놓고 평가한다. 여기에는 던전의 각 방을 어떻게 연결할 것인가, 서로 다른 캐릭터들이 갖게 될 능력과 특징들, 전투 시스템에서 유닛의 효율과 직결되는 특정한 ‘마법의 숫자’를 결정하는 일, 그리고 심지어는 게임을 출시할 때 어떤 컨텐츠들의 조합을 갖게 될 것인가하는 문제에 이르기까지가 포함된다. 

AI 캐릭터가 게임 월드에서 어딘가를 찾아기가 위해 길찾기 (pathfinding) 시스템을 사용하듯, 게임 디자인은 아주 높은 수준의 가능성 공간에서 다양한 초기값들을 취해보고 이를 반복검증하는 과정을 통해 길을 찾아나선다. 우리는 게임 디자인의 – 그게 전투 시스템이든, 게임 월드의 일부분이든, 전략 게임의 테크트리이든, 또는 당신이 가진 어떤 문제이든 – 몇몇 측면들이 어떤 상태인지를 주의깊게 살피면서, 초기값을 바꾸어가며 더 나아진 길이 어디인지를 찾는다. 

디자이너들은 보통 이 과정을 일컬어 ‘반복검증’(*1)  이라는 단어를 즐겨 사용한다. 그러나 ‘탐색’ 이 보다 적당한 묘사이다. 우리가 게임 디자인을 ‘반복검증’을 할 때, 이는 사실상 개발 과정에서 게임을 실험하고 있는 것이다. 추론을 통해 도출한 작은 초기값들을 바꿔보면서, 현재 게임 디자인의 초기값을 좀더 우리의 기준에 부합하는 방향으로 조금씩 고쳐나가려 노력한다. 

이런 ‘반복검증’은 흔히 컴퓨터 코드를 작성하는 과정에서 볼 수 있는 선형적인 반복검증과는 유사한 점이 없다; 이는 날카로운 모서리들과 막다른 길을 만나 뒤로 돌아가는 것이 일상인, 미로를 탐색하는 작업과 훨씬 유사하다. 이런 작업은 종종 우리를 목표에 좀더 가까운 곳으로 데려가주지만, 많은 경우 이 변화가 게임을 더 나아지게 했는지 아닌지는 명확하지 않으며, 때로 게임을 개선하려 시도했던 디자인 상의 변경점이 오히려 게임에 예측하지 못했던 결점이 있음을 드러내어 이를 취소하거나 다시 시도해야하기도 한다. 

게임 디자인은 믿을 수 없을만큼 어려운 과목이다. 게임 디자인은 날카로운 물체들로 가득한 어두운 방과 같아서, 낯익은 길에서 일단 벗어나면 안전하게 빠져나가기가 엄청나게 어렵다. 가는 도중 거의 언제나 고통스러운 상처들을 만나게 되며, 빨리 움직이려 한다면 특히 더 그러하다. 그리고 우리는 이런 어두운 방에 비출 비교적 적은 조명만을 가지고 있다. 게임 디자인의 탐색 과정에서 우리에게 주어진 잘 정의되고 다듬어진 기법들은 얼마 되지 않는다. 

이 어두운 방이 바로 우리가 ‘반복검증’을 하는 이유이다. – 우리는 게임 디자인에서 내린 결정이 어떤 결과로 파생될지 이를 시도해보기 전에는 알지 못한다. 다른 말로, 우리는 탐색한다. (Will Wright 또한 2004년 GDC Talk에서 “해답 공간의 탐색” 이라는 말을 통해 직접적으로 언급한 바 있다.)

그 결과 게임 디자인은 꽤 자주 생산성의 병목이자, 단점의 주된 원인이고, 게임 개발의 가장 큰 리스크의 근원이 된다. 셀 수 없이 많은 팀들이 잘못된 계획에 의거한 디자인적 결정, 창조성의 참패, 컨텐츠에 대한 과도한 욕심, 목표 시장에 대한 오해, 그리고 제품의 퀄리티 문제를 초래한 여러 디자인 문제들에 의해 발목 잡혀왔다. 

이 모든 위험들이 게임 디자인을 시험하는 과정에서 수반된다. 따라서 많은 퍼블리셔들과 거대 개발사들이 왜 리스크를 싫어하는지, 왜 잘 알려지고 검증된 장르, 라이센스 그리고 장르 컨벤션을 선호하고 혁신적 게임 디자인과 그에 수반되는 예측하기 어려운 매출을 기피하는지는 자명하다. 어두운 방을 탐험하는 것은 그저 너무 위험한 것이다. 

우리는 이런 태도들을 바꿀 방법을 찾아보려한다. 단순히 혁신을 회피하려는게 아니라, 우리의 디자인 기술을 발전시키고 능력을 확장하며 디자인 혁신을 보다 안전하고 효율적으로 시도할 수 있는 강력한 도구를 구축하는 것이 우리가 지향하는 방향이다. 

본 시리즈는

이 글은 결정 모델을 소개하는 전체 시리즈의 첫 번째 글이다. 결정 모델이란 결정을 분석하여 정규적인 모델로 만들고, 이를 통해 가장 원하는 결과물을 얻기 위한 일련의 도구들의 모음이다. 

결정 모델과 최적화는 주로 매니지먼트, 금융, 프로젝트 기획 개선, 그리고 그 외의 다양한 분야에서 가능한 여러 선택들을 인간이 수작업을 통해 하는 것보다 훨씬 빠르게 탐색하여 결정 프로세스를 개선하고 어려운 결정 및 최적화 문제들을 해결하는 데 사용된다. 

여러 잠재적 이익들에도 불구하고 결정 모델과 최적화는 게임 산업의 디자인 분야에서는 비교적 덜 알려진 것으로 보인다. 인기있는 개발자 포럼에서 프로 게임 디자이너들을 대상으로 한 최근 조사에 의하면, 응답자의 25%만이 결정 모델을 들어본 적이 있으며, 8%만이 이를 실전에서 사용하고 있다. 페이스북을 통해 조사한 유사한 서베이 또한 위와 거의 일치하는 결과를 보여주고 있다. 

적절히 사용된다면, 결정 모델은 게임 디자인 과정의 여러 측면들을 크게 향상시킬 수 있다: 게임 디자인 시스템의 특정한 초기값을 최적화하거나, 게임 패러미터의 최적값을 찾는데 도움을 줄 수 있다. 게임이 어떤 요소들을 포함하는게 좋을까를 결정하는데 대해 한줄기 빛을 비춰줄 수 있다. 당신의 게임에서 플레이어들이 취할 법한 전략, 특히 지배전략(*2) 을 찾아내거나 플레이어들이 시스템을 가지고 노는 경우를 발견하는데 결정 모델이 도움이 될 수 있다. 이 시리즈에서, 우리는 각각의 카테고리에 속한 세 가지의 사용례를 모두 다루어 볼 것이다. 

정의

그럼 결정 모델이란 무엇인가? 

간단하게 아래와 같다. 

결정 모델은 결정을 시뮬레이션하고 그 해를 찾는 과정을 자동화한 것이다.

결정 모델에서 우리는 어떤 종류의 결정을 정의할 때 그 결정에 영향을 미칠 수 있는 모든 연관된 요소들을 골라내면서 시작한다. 이를 그 결정을 정확하게 표현하기 위한 모델로 만들고, 일련의 입력변수와 하나의 결과변수를 특정한다. 그리고 가능한 최고의 결과값에 최적화된 결정 변수 (또는 입력변수) 의 조합을 찾아나간다. 

모든 과정들이 잘 진행된다면, 우리의 상상으로 또는 손으로 하는 것보다 훨씬 더 큰 숫자의 해결책들을 검토할 수 있게 될 것이다. 모든 분야에 결정모델을 적용할 수는 없겠지만, 적절한 문제가 주어질 경우에는 더 나은 결과, 더 빠른 결과, 그리고 어떤 경우에는 결정모델을 통해서가 아니라면 답을 구할 수 없는 경우에도 결과를 얻을 수 있을 것이다. 

그 과정에서 우리에게는 결정모델의 정합성을 지키기 위해 벗어나서는 안 될 몇 가지 제약이 주어질 것이다. 이 제약들은 우리 모델의 어떤 측면 또는 입력변수의 종류와 범위를 제한할 수도 있다. 

왜 모델을 구축하는가?

시드 마이어의 문명을 플레이하면서 ‘으어 ... 잠깐만. 도시를 지으려면 뭐부터 짓는게 맞는 방법이지? 기념물부터 짓고 곡물 저장고를 지어야하나? 곡물 저장고를 먼저 지어야 하나? 아니면 사원 먼저인가? 그 다음에 곡물 저장고? 뭐가 최고의 결정이지? 답을 알아낼 방법이 있기는 한건가?” 라고 궁금해 했던 적이 있는가? 

RTS게임의 전투 시스템을 살펴보자. RTS게임에 등장하는 다수의 유닛들을 밸런싱하는 것은 악명높은 어려운 문제이다. 만약 패러미터를 고칠 때마다 반복해서 플레이테스트를 하지 않고도 게임의 전투 밸런스에 대한 적절한 해답을 빠르게 찾아주는 시스템이 있다면 어떨까? 만약 “두 명의 창병과 세 명의 궁수를 물리치기 위해 몇 명의 검병이 필요한가?”와 같은 질문에 대답을 해주는 시스템이 있다면? 또는 “적의 감시탑을 무너뜨리기 위해서 투석기와 궁수를 쓸 수 있다면 각기 몇 마리씩으로 조합하는게 가장 비용이 낮은 방법인가?” 라는 질문은 어떨까? 

실제로, 우리는 이런걸 만들 수 있다!

만약 우리가 이런 게임 디자인의 문제를 적절히 모델링 할 수 있다면, 가능한 여러 조합들 중 무엇이 최적화된 조합인지를 자동으로 탐색해주는 도구를 얻게 될 것이다. 게임을 수천 번씩 플레이테스트 하지 않고도 우리가 원하는 기준에 부합하는 답을 얻을 수 있는 것이다. 

여기 비슷한 유형의 문제가 있다 – 이 시리즈에서 이후에 다루게 될 문제의 예시이다. 

여기 ‘수퍼탱크’라는 게임이 있다고 해보자. 수퍼탱크에서 우리는 거대한 SF탱크를 몰고 다른 수퍼탱크들에 맞서 싸운다. 전투에 들어가기 전에, 탱크에 어떤 무장조합을 탑재할 지 고를 수 있다. 

당신에게는 무기조합에 사용할 수 있는 100크레딧이 있다. 당신의 수퍼탱크는 50톤의 무기를 실을 수 있고, 3개의 슬롯에 특별 초강력 무기를 장착할 수 있다. 

아래와 같은 5가지 종류의 무기들 중에서 고를 수 있으며, 당신이 원하는 무기를 원하는만큼, 또는 아예 싣지 않을 수도 있다. 

당신은 자신의 수퍼탱크가 최고의 데미지를 갖기를 원한다고 가정해보자. (여기서 데미지란 초당 피해량을 의미하며, 이 예에서의 데미지는 각 무기의 발사속도를 이미 고려한 양이라고 해보자) 또한 모든 무기들이 같은 사거리, 정확도, 그리고 발사속도를 가졌고, 위의 표에 나타난 것 이외의 모든 다른 부분들은 모두 동일한 것이라고 가정해보자. 

자, 빠르게 !! 수퍼탱크에 얼마나 많은 기관총, 로켓, 레이저 등등을 장착해야할까? 무기들을 어떻게 조합해야 비용, 무게, 슬롯수를 초과하지 않고 최대한의 화력을 가지도록 구성할 수 있을까? 

계산기 또는 수작업으로 이 문제를 해결할 수 있는지 보라. 

할 수 있는가? 

만약 이를 실제로 시도해봤다면, 이 문제가 놀랍도록 까다롭다는 점을 빠르게 눈치챘을 것이다. 

아마도 이 문제를 풀 수 있는 복잡한 방정식이 있을 것이다. 그러나 우리는 게임 디자이너들이고, 전문적인 수학을 다루는 사람들이 아니다. 

아울러 만약 위의 패러미터가 달랐더라면 어땠을지 생각해보라. 수퍼탱크가 50톤이 아닌 60톤을 탑재할 수 있다면? 비용이 100 크레딧이 아닌 90 크레딧 또는 110 크레딧이었다면? – 최적 무기 탑재는 어떻게 변화할까? 슬롯이 4개가 아닌 2개라면 어떨까? 

그리고 이제 어떤 요구조건 (무게, 비용, 슬롯 수) 패러미터가 대입되더라도 그 즉시 최대 데미지의 무기조합을 계산해주는 시스템이 있다고 상상해보라. 위의 테이블에서 무기 패러미터와 수퍼탱크의 패러미터 (50톤, 100 크레딧, 3슬롯) 를 적어넣으면, 짜잔! 최적 무기탑재의 답을 구해준다. 

멋지지 않겠는가? 

이 시스템을 통해 아래와 같은 모든 유용한 질문들에 대한 답을 즉시 내놓을 수 있다. 

• -    수퍼탱크의 패러미터를 바꾸면 최적 무기조합은? 
  - 어떤 무기의 패러미터를 바꾸면 최적 무기 조합은?
  - 특정한 조건 (무게, 비용, 슬롯수) 하에서 수퍼 탱크가 뽑을 수 있는 최대 데미지는? 
  - 각각의 무기들에 주어진 4개의 패러미터 (데미지, 무게, 비용, 슬롯 수) 는 적절하게 밸런싱되어 있는가? 
  - 지나치게 강력하고 너무 자주 사용되는 무기가 있는가? 만약 어떤 무기가 ‘언제나 사용’될 정도로 유용하다면 이 무기를 사용하는건 언제나 최적 결정이 되고, 여기에는 어떤 의미있는 선택도 없다는 뜻이다. 이럴 경우 우리는 이 무기를 게임에서 빼거나 이 무기가 의미 없어지는 어떤 환경을 만들어 넣어야 한다. 
  - 어떤 무기가 활용성이 떨어져서 드물게 사용되거나 전혀 사용되지 않는가? 위의 경우와 유사하게, 만약 어떤 무기가 전혀 사용되지 않을 정도로 쓸모가 없다면 마찬가지로 여기에는 어떤 의미있는 선택도 없다는 뜻이다. 이럴 경우 우리는 이 무기를 게임에서 빼거나, 이 무기가 유용하게 쓰일만한 어떤 환경을 만들어 넣어야 한다. [/list:u]
  이들은 모두 게임 디자인상으로 꽤 중요한 부분이며, 게임 디자이너들이 그 답을 알고 싶어할 질문들이다. 이 질문들에 대한 답을 아는 것은

수퍼탱크라는 게임을 밸런싱하는데 크게 도움이 될 것이다. 

지금까지 몇 문단에 걸쳐서 우리는 수작업으로 풀기엔 상당히 어려운, 그러나 마이크로소프트 엑셀에 이미 내장된 도구를 통해서라면 잡일정도로 처리할 수 있는 문제들에 대해 서술했다. 

이후의 에피소드에서 우리는 이 질문들에 대한 모든 해답을 알려줄 결정 모델을 실제로 구축할 것이다. 

당신은 이 모델이 아니었다면 다루기 까다로웠을 문제들을 수월하게 처리할 수 있는 결정 모델을 수분 내에 구축하게 될 것이다. 단지 약간의 작업만으로, 안전하고 빠르게 디자인의 가능성 공간을 탐색할 수 있는 강력한 도구를 만들어낼 수 있다. 

로드맵

이 시리즈를 통해서 우리는 좀더 복잡한 몇몇 예들을 살펴볼 것이다. 레퍼런스로 쓰기 위한 스프레드시트를 함께 제공하여 이 예제들을 여러분이 스스로, 다른 아무것도 없이 오로지 엑셀만으로 다루어 볼 수 있도록 하겠다. 우리의 예제는 아래 내용들을 포함할 것이다. 

• - 전략 게임을 위한 단순한 전투 예제
  - 다수의 인구 중심지가 존재하는 우주 배경의 mmo게임에서 서로 연결된 웜홀의 텔레포트 좌표를 최적화하는 모델
  - 시드 마이어의 문명과 같은 4X(*3) 전략 게임에서, 단순화된 도시 모델을 배경으로 세수와 시민의 행복도 사이를 균형잡기 위해 어느 정도의 세율을 사용할 지 결정하는 모델
  - mmo게임에서 어떤 캐릭터 클래스에 특성과 마법을 어떻게 설정할 지 선택하는 모델
  -

Master of Orion등의 고전 게임과 유사한 4X 전략 게임에서 행성 식민지 건설을 위한 최적의 빌드 오더를 결정하는 최적화 모델
- MechWarrior스타일의 게임에서 열관리 (Heat Management)(*4) 를 포함한 훨씬 더 복잡한 무기 탑재 예시 
- 어떤 게임 개발팀이 게임에 포함할 컨텐츠의 적절한 조합을 고르는 과정에서 결정 모델을 사용하여 적절한 균형점을 찾아가는 예시 [/list:u]
대체로 이 시리즈에서는 특정한 게임의 어떤 시스템에서 플레이어의 최적 전략을 찾아내는 단순한 예시를 구축한 후, 결정 모델을 통해서 게임 시스템의 패러미터 및 컨텐츠 조합을 최적화하는 방향으로 진행될 것이다. 

이런 일련의 케이스들에서 우리는 문제를 설명하고, 이를 엑셀에서 어떻게 모델링하며, 엑셀에 내장된 ‘해 찾기’ 도구를 이용하여 이 문제를 해결하는 과정을 보일 것이다. 각각의 경우에 당신이 직접 어떤 해 찾기나 그에 해당하는 다른 도구들이 없이 문제를 해결하는 것보다 우리가 이를 좀더 쉽고, 빠르고, 검증된 방식으로 해결하는 모습을 보게 될 것이다. 우리는 또한 각각의 예시에 대한 스프레드시트를 제공할 것이며, 당신은 이를 다운로드받아 직접 시도해보고, 결과를 재생산하며, 각 모델을 시험할 수 있을 것이다. 

아울러 좀더 기본적인 부분에서, 스프레드시트를 쓰던 고급언어를 이용한 프로그래밍을 하든 그 외의 무엇을 통하든 수단은 문제되지 않는다. 중요한 것은 우리가 엑셀과 해 찾기 기능을 이용하든 Java/C++/C#을 이용하든, 문제를 모델링하고 해결하려 노력한다는 점이다. 

왜 결정 모델을 사용할까?

몇몇 독자들은 믿기 어려울 것이다. 결정 모델을 만드는건 작업량이 꽤 많아보인다. FGT나 베타 테스트 같은 유저들의 실전 테스트를 활용할 수 있는데 왜 이런 노력을 해야하는걸까? 

공식적으로 솔직하게 말하자면, 결정 모델을 모든 문제에 적용할 수는 없다. 몇몇 문제들은 너무 복잡하거나 이런 테크닉으로 모델링을 하기에는 너무 어렵다. 아울러 게임에는 아주 다양한 측면들이 존재하며 (미적 고려, 오락 가치, 그리고 게임의 ‘느낌’ 적 부분) 이들은 숫자를 통해 모델링하기에는 불가능하거나 너무 어렵다. 아울러 결정 모델은 베타 테스트나, 자기가 만드는 게임을 매일매일 플레이하며 수행해야 하는 여러분의 역할을 대신할 수도 없다. 

그러나 이런 모든 요소들에도 불구하고 이 시리즈가 끝나갈 즈음에는 결정 모델과 최적화가 우리에게 독특하고 강력한 일련의 도구임이 명확해 질 것이다. 이 방법론은 다른 방법을 통해서는 합리적으로 풀기 어려운 여러 종류의 문제들을 부분적으로 또는 통째로 해결할 수 있으며, 결정 모델과 최적화가 아니었다면 답변하기 어려웠을 모든 종류의 문제들에 대해 직관과 답을 얻는데 도움을 준다. 여느 다른 도구들과 마찬가지로, 이 도구의 사용이 적절한가 여부는 실무자들의 결정에 달려있다. 

한편 결정 모델을 적용하기에는 부적합하거나 유용하게 쓰이기엔 너무 협소한 많은 문제들이 있다. 그러나 이 시리즈를 통해서 알게 되겠지만 이 도구는 놀랄만큼 유용하다. 개발의 이른 단계에서 우리가 더 괜찮은 게임 디자인을 뽑아낼 수 있다면, 그리고 유저 테스트 단계에 들어가기 전에 최대한 많은 디자인 상의 버그들을 잡아낼 수 있다면, 우리는 게임 시스템을 좀더 견고하고 흥미로우며 버그가 없이 만들 수 있을 것이다. 

평범한 프로그래머들에게 주어지는 여러 도구들에 대해 생각해보라. 프로그래머는 아주 어려운 직업이다. 그러나 그들은 테스트를 하기도 전에 버그를 잡아주는 다양한 도구들의 축복을 받았다.  컴파일러는 오타가 날 때마다 계속해서 비명을 질러댄다. 소프트웨어의 결함을 확인하기 위해 방어적 프로그래밍 기법을 사용한다; 다른 프로그래머의 결점을 확인하고 좋지 못한 스킬들을 지적하기 위해 서로 코드리뷰를 한다; 다양한 프로파일링 및 통계분석 도구들을 통해 모든 종류의 퍼포먼스 버그와 다른 결점들을 찾아낸다. 

그러나 게임 디자이너들에게는 이러한 도구가 없다. 우리의 직업은 분명히 무척 어려운데도 문법 실수를 지적해 줄 컴파일러가 없다. 프로파일러도, 디버깅 툴도 없다. 통계분석 도구도 없다. 우리는 ‘코드’를 만들지 않으므로 코드리뷰를 할 수도 없다. 우리는 그저 기획서를 쓰는게 전부다. 컨셉 기획서와 상세 문서 등을 만들어서 팀원들에게 공유하고 좋은 피드백을 주길 바라지만, 대부분의 경우에 우리의 디자인이 잘 동작하는지 보려면 게임을 직접 해봐야만 한다.  

이런 점들은 게임 디자인을 믿기 힘들 정도로 위험하고, 시간을 많이 잡아먹으며, 값비싼 것으로 만든다. 

만약 마치 프로그래밍처럼 인적 과오가 이 과정에서 피할 수 없는 자연적인 요소라면, 우리는 프로젝트와 우리 자신을 가능한 한 보호하기 위해서라도 좋은 도구들을 많이 필요로 한다. 

우리는 프로그래머들이 엔지니어링의 가능성 공간을 탐색할 때 사용하는 컴파일러, 디버거, 프로파일러, 그리고 통계분석 등의 도구에 비해 어느모로 보나 가깝다고 말하기 어려운 수준의 도구들만을 사용해서 게임 디자인의 가능성 공간을 탐색하고 있다. 그러나 최근에 Cut the Rope를 기반으로 만들어진 “Cut the Rope: Play Forever”와 같은 게임성(*5) 확인도구를 포함하여, 여러 커스텀 게임 문제 해결 도구와 디자인 도구들이 떠오르는걸 볼 수 있다. 보드 게임 Yavalath를 만들어 낸 추상 게임 디자인 시스템 Ludi나, 내가 모바일 게임 City Conquest를 만들면서 개발한 자동 게임 밸런스 도구 Evolver 등이 여기에 해당한다. 결정 모델은 우리를 몇 발자국 더 앞으로 나아가게 도와줄 수 있으며, 자동화된 도구들은  게임 디자이너들의 지적 능력을 좀더 증강하고 확장할 수 있다. 

스프레트시트 얘기가 아닌 모델링의 얘기

이 시리즈는 게임 디자이너들을 위해 쓰여졌다. – 이는 아티스트에서 전직했든 프로그래머에서 전직했든 스토리텔링을 하던 사람이든 또는 보드 게임계에서 왔든 관계없이 ‘모든 종류의’ 디자이너들을 말한다. 따라서 우리는 이 시리즈를 단순하게 유지함과 동시에 아래의 약속들을 지켜나가려 한다. 

• -

코드 없음 : 우리는 이 글을 통해 어떤 코드도 사용하지 않을 것이며, 모든 예제는 오로지 마이크로 소프트 엑셀에 내장된 ‘해 찾기’ 도구만을 사용할 것이다. 그러나 이 시리즈가 스프레트시트나 엑셀에 대한 얘기가 아니라는 점은 꼭 기억해야 한다. – 이 글들은 결정 모델과 최적화에 대한 것이다. 이 시리즈에서 우리가 하는 모든 일들은 고급 프로그래밍 언어를 통해 쉽게 (때로는 우리가 여기서 하는 것보다 더 쉽게) 구현이 가능하다. 
- 수학 없음 (아니면 최소한 복잡한 수학은 없음) : 우리는 이 시리즈를 거의 대부분 수학과 무관하게 이끌어 갈 것이다. 기초적인 산수 이외의 어떠한 것도 사용하지 않겠다: 덧셈, 뺄셈, 곱셈, 나눗셈과 가끔 제곱근정도. 이외의 수학기호는 엄격하게 금지된다. 
- 4차원 스프레드 시트 없음 : 우리는 2차원 스프레트 시트만 사용할 것이다. [/list:u]
당신이 게임 디자이너라면 이 시리즈를 통해 어떤 코드를 짜거나 프로그래머에게 코드를 짜달라고 부탁할 필요 없이 혼자서 결정 모델을 만들 수 있게 할 것이다. 프로그래머라면 이 시리즈는 어떤 고급언어를 사용하든 스스로 결정 모델을 만들거나, 별다른 사전지식 없이 엑셀과 해 찾기 도구를 이용하여 템플릿을 구축할 수 있는 비교적 쉬운 가이드가 될 것이다. 

이 글들은 모두 단순한 시작점이 되려는 의도로 쓰여졌다. 따라서 여기서 확인할 수 있는 개념들을 취하여 엑셀에 만들든, 다른 최적화 도구를 사용하든, 또는 고급 프로그래밍 언어를 사용해서 스스로의 해 찾기 도구를 만들든 할 수 있다. 스프레드시트는 시작점으로서는 좋지만 결정 모델의 개념은 각자의 게임 구조 자체를 통합하는 더 풍부하고 세련된 모델을 위한 발판에 가깝다. 

유의 사항

결정 모델에 지나치게 깊이 빠져들기 전에, 몇 가지 유의사항이 있다. 결정 모델과 최적화는 게임 디자인을 위한 어떤 종류의 완성된 시스템도 제공하지 않는다. 다시말해 이걸 사용했을 때 결과가 확정적으로 보장되는 것이 아니다. 결정 모델과 최적화를 게임 디자인 과정의 어떤 부분을 돕기 위한 도구로 본다면 도움이 될 것이다. 아울러 여느 도구들이 그러하듯, 이 도구 또한 다양한 한계들이 존재한다. 

아래의 몇 가지 한계들을 알아두어야 한다. 

• -

잘못 사용하기 쉽다. 다른 도구들과 마찬가지로 결정 모델 또한 잘못 사용되거나 부적절한 곳에 사용될 수 있다. 잘못 구축된 또는 버그가 있는 결정 모델은 당신을 잘못된 결론으로 이끌 수도 있다. 다른 소프트웨어들처럼, 당신의 결정 모델이 규모가 커질수록 거기에는 버그가 포함되기도 쉽다. 또한 이 모델의 결과를 잘못 해석하거나 당신이 내리려는 결정을 정확하게 반영하지 못하는 그릇된 모델을 만들 위험도 존재한다. 

- (때때로) 복잡하다. 게임 디자인의 몇몇 문제들은 이 접근법을 통해 모델링을 하기에는 지나치게 복잡하다. 많은 문제들이 유동적인 부분을 가지고 있거나 게임의 다른 부분들과 지나치게 유기적으로 밀착되어 있어서, 독립된 엑셀 스프레드시트로 다루기에는 적합하지 않을 수 있다. 이런 경우에 흔히들 시스템의 일부만을 모델링하기로 결심하거나 (잘못되거나 부정확한 모델로 연결될 수 있다) 게임 자체를 통째로 모델링하거나 (엄청난 일이 될 것이다) 아니면 그냥 결정 모델 자체를 포기하게 된다. 

- 모든 것을 모델링 할 수는 없다. 결정 모델은 어떤 부분이 재미있는지, 미학적으로 즐거움을 주는지, ‘옳게’ 느껴지는지, 플레이어에게 적절한 정보와 손쉽게 사용할 수 있는 인터페이스를 제공하는지 말해줄 수는 없다. 이런 종류의 주관과 미학적 요소들을 포함하는 모델링은 대부분의 경우에 불가능하다. 이는 즉 결정 모델이 어디에 쓰여야 하고 쓰일 수 있는지에 대한 한계가 명확하다는 의미이다. 시스템 디자인과 매커니즘 최적화, 그리고 미학보다는 역학에 관련된 부분이 그것이다. 

- 한계가 존재한다. 우리가 사용할 엑셀은 해 찾기를 비롯해 모든 최적화 도구들은 한계가 있다. 적합한 모델을 만들고 이에 따른 해답이 존재하긴 하지만, 어떤 최적화 도구도 그 답을 찾을 수 없을 정도로 복잡한 경우가 있을 수 있다. 불확정 입력의 가짓수가 충분히 많은 경우 엑셀의 해 찾기 기능이 모든 가능한 입력의 조합을 검토하여 해를 찾을 수 없는 영역에 도달할 수 있고, 이때는 다른 다양한 최적화 방법론에 기대야 한다. 이 시리즈를 통해 보게 되겠지만 우리는 모델의 표현을 가급적 단순화하여 해 찾기 기능이 다룰 수 있도록 만들 수 있으며, 해 찾기 기능의 개발자는 더 많은 문제들을 위한 보다 강력한 도구를 제공하고 있지만, 그럼에도 여전히 해 찾기가 해를 찾을 수 없는 모델을 만들 가능성은 존재한다. 

- 최적을 100% 보장하지 않는다. 따라서 우리가 복잡한 모델을 다룰 때는 우리가 발견한 최적 결정이 정말 최적값이라고 언제나 100% 확신할 수는 없다. 우리는 때로 차선을 택해야 한다: 최적화에 시간을 더 투자하고 검산하는 과정들을 거친다면, 우리가 발견한 값이 최적값이거나 최소한 신뢰할만한 수준에서 최적값에 극히 가깝다는 점은 말할 수 있다. [/list:u]
그리고, 마지막으로 가장 중요한 것은: 

• -

모델링의 대상이 확실해야 한다. 모든 문제들이 이런 종류의 노력을 필요로 할만큼 중요하지는 않다. 우선순위를 명확히 해야하며, 훨씬 더 중요할지도 모르는 더 큰 다른 문제들을 무시하면서 대단치 않은 부분들을 모델링하는데 과도한 노력을 기울이는 경우를 피해야 한다. [/list:u]
넓은 관점으로 말하자면 결정 모델이 유용하게 쓰이기 위해서 유효해야하는 몇 가지가 있다. 질문의 결정은 반드시 우리가 일종의 독립된 모델에 넣을 수 있도록 압축 가능해야하며, 결정의 결과가 단일한 값으로 산출될 수 있는 것이어야 한다. 다른 말로 하자면 유한한 가짓수의 입력을 결정 모델에 넣고 돌려서 단일한 결과값을 얻을 수 있으며, 그 결과값을 최소화하거나 최대화하는 것이 곧 우리의 결정을 더 나은 것으로 만들 수 있는 질문이어야 하는 것이다. 

주관적 요소들이 개입되어 모델로 축약될 수 없는 경우들 – 예를 들어 미학적 고려나 사용성, 게임성 등의 요소들 – 의 경우에는 이를 결정 모델로부터 깔끔하게 분리하거나, 초기 검증에만 사용하거나, 결정 모델을 완전히 포기해야 한다. 

한편 결정 모델을 스프레드시트에서 구동하기 위해서, 모델의 복잡성에도 한계가 존재한다. 어떤 게임이 아주 복잡한 작업을 수행한다면, 그 복잡함의 정도를 엑셀에서 재현할 수 없을 수도 있다. 한편 이는 우리가 엑셀을 이용해서 구현하려는 결정 모델의 한계일 뿐이며, 결정 모델 자체의 한계는 아니라는 점을 염두에 두어야 한다. 여러분은 독자적인 스프레트시트에서 할 수 있는 것보다 더 강력한 해 찾기 도구를 자기 자신의 게임 엔진 자체에 구축할 수 있으며, 이 시리즈가 정확히 그런 부분들을 자극할 수 있다면 좋겠다. 

한편 이런 동전의 이면에는 이 모든 한계에도 불구하고, 결정 모델이 쓸모없는 것이 되기는 어렵다. 어떤 문제가 결정 모델을 통해 구축하기엔 지나치게 복잡한 경우에도 결정 모델을 구축하려는 노력은 여전히 당신이 찾는 올바른 정답에 가까이 가는데 필요한 여러 요소들을 찾도록 도와줄 것이며, 개발의 초기 단계에서 많은 기초적인 문제들을 찾아내고 수정하는데 보탬이 될 것이다. 

문제가 지나치게 복잡해서, 또는 미적 요소나 그 외의 주관적 견해를 필요로 하기에 결정 모델이 주어진 문제에 대한 최적해를 찾아내지 못하는 경우에조차 결정 모델은 해결책의 범위를 좁히고, 막다른 길로 가지 않게 막아주어 문제의 복잡도를 줄이는데 도움을 줄 수 있다. 

마지막으로 당신이 결정 모델을 사용하지 않기로 하고 이후로도 스프레드시트나 그 외의 해 찾기 도구를 사용해서 최적화를 하지 않는다해도, 결정 모델에 대한 이해는 당신이 게임 디자인에 대한 결정을 생각하고 바라보는 방식을 바꾸는데 도움이 된다. 

이 시리즈는 탐험이다. 우리는 다양한 게임 디자인의 문제들을 살펴보고 강력한 게임 디자인 도구를 통해 모델을 만들어 최적화하는 방법을 탐험할 것이다. 이에 대해 회의적인 분들도 있고 이런걸 쓰지 않는 쪽을 더 편하게 느끼는 분들도 있을 것이다. 그러나 그런 분들도 나와 함께 시리즈의 끝까지 가서 거기에 무엇이 있는지를 확인해보면 좋겠다. 

결론

결국 우리는 맞는 게임 디자인을 원하는 것이다. 

게임 디자인의 많은 질문들이 주관적이다. ‘맞’거나 ‘틀린’ 대답이 존재하지 않는다. 그러나 어떤 경우에는 – 아마도 당신이 생각하는 것보다 많은 경우에 – 맞는 답이라는 것이 명백하게 존재한다. 그리고 그럴 때 우리는 어떻게 정답을 찾아야 하는지 알고싶어 하거나 최소한 어떻게 정답을 정의하고 만약 정답이 존재한다면 그걸 어떻게 찾아야 할지 이해하고 싶을 것이다. 

결정 모델과 최적화는 정확히 그런 경우에 우리에게 도움을 줄 수 있는 강력한 도구이다. 나는 이 도구가 모든 게임 디자이너들의 도구상자에 들어있어야 한다고 믿는다. 약간의 훈련만으로도 이 도구가 어둠에 잠긴 게임 디자인의 방을 좀더 안전하고 빠르게 탐험할 수 있는 아직 발견되지 않은 잠재적 힘을 가졌음을 분명히 느낄 수 있을 것이다. 우리는 이 시리즈의 다음 글들을 통해 다양한 응용예와 함께 어떻게 해야하는지를 보여주려 한다. 

: Paul Tozour

이 글은 게임 디자인에서 결정 모델과 최적화에 대한 시리즈의 첫 번째 글이며, 이 시리즈는 아마도 10 – 15 편의 글로 구성될 것이고, 2013년 7월부터 개괄적으로 1주에 한 편씩 공개할 예정이다. 우리는 어떤 질문, 코멘트, 피드백 및 결정 모델에 대한 이의 또한 환영한다. 

작가는 Robert Zubek과 Jurie Hornema의 이 글에 대한 피드백에 감사하는 바이다.

*1 반복검증 : 원문은 iterative, iteration 등 입니다만, 현업에서는 이 단어를 음차하여 그대로들 사용하는지라 한국말로 옮길만한 마땅한 단어를 몰라 일단 '반복검증' 이라고 옮깁니다. 괜찮은 단어를 추천해주셔도 됩니다. 
*2 지배전략 : 다른 전략들에 비해 확연히 우위에 있기 때문에 이 전략을 택하는게 당연한 전략
*3 4X : 탐험, 확장, 개발, 몰살을 게임 디자인의 핵심으로 삼는 일련의 전략 게임을 지칭하는 용어. 이들을 영어로 하면 explore, expand, exploit, exterminate 인데 모든 단어에 X가 포함된 것에 착안한 용어인 듯
*4 열 관리 (Heat management) : 무기 또는 에너지 등을 사용하면 열 게이지가 오르고, 일정 이상 오르면 과열로 기능 이상이 생기는 시스템. LOL의 럼블이 사용하는 스킬코스트가 대표적인 열관리
*5 게임성 : 원문은 playability인데 뭐라 적당히 옮길 말을 몰라서 '게임성' 으로 땜빵합니다.

------------------------------------------------------------------------------------------------------------

본문에 명시되어 있다시피 일련의 시리즈의 첫번째 파트입니다. 지금은 파트2까지 나와 있는데, 파트1만 봤을 때는 이게 시리즈 소개 글이라서 본론이 전혀 없다보니 퀄리티를 보장할 수 없는 & 근데 양은 많은 상황이라 주저하다가, 파트2가 나오고 여기에 ‘기대에 부응하는 수준’ 뭐 이런 뉘앙스의 댓글들이 달려있기에 상당한 분량에도 불구하고 해석을 시작한건데 ... 길긴 정말 기네요

일부 이런 작업들이 필요한 분들은 이와 유사한 장치를 손수 만들어서 쓰는 걸로 알고 있고 주변에서 많이 보긴 합니다만 ... 제가 직접 이런 작업을 할 때의 한계라면 내가 쓰는 – 일종의 - 모델링 방법이 맞는건지 틀린건지 몰라서 일종의 검산을 굉장히 꼼꼼하게 하게 되더라구요. 그러다보면 때로는 수작업으로 한 것과 크게 다를 바 없는 시간과 노력이 들 때도 있고 ... 하지만 여기서 언급하는건 꽤나 검증된 방법론으로 보이니까, 비슷한 도구를 이미 사용하고 계신 분들께도 조금이나마 도움이 되겠지 싶어서 ‘이 긴 분량’ 에도 불구하고 소개합니다.

- 어쨌든 다음 편이 궁금한 분을 위한 영어 원문 주소 : Decision Modeling and Optimization in Game Design, Part 2: Tax Rate Example

- 얼추 훑어보니 밥 아저씨가 그림 가르쳐주듯 난해한 시범 후에 '참 쉽죠?' 하는 식은 아닌 듯 합니다.

- 다음 편을 언제 해석할 지는 아직 미정입니다.