[아카이브] 게임 디자인에서 추상화의 단계

[Zerasion 4]

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

---

 

Levels of Abstraction in Game Design

게시판 사정상 그림 사이즈를 좀 줄였습니다. 자세히 보고싶으신 분은 아래의 '원문주소'링크를 따라가 그림을 클릭하시면 큰 사이즈로 나옵니다

원문주소 : 
http://blog.sergeymohov.com/levels-of-abstraction-in-game-design/

게임 디자인은 게임 개발 과정에서 종종 아이디어에 의해 주도되는 분야로 인식되곤 한다. 아울러 많은 이들이 게임 디자인을 순수하게 창의적인 측면에서만 생각하는 함정에 빠져 기술적 측면을 방치하는 경향이 있다. 아이디어를 갖는다는건 멋지고 유용한 일이지만, 모든 이들이 자기만의 아이디어를 가지고 있으며 아이디어 그 자체로는 아무런 가치도 없음을 기억하는 것도 중요하다. 정작 중요한 것은 아이디어의 적용이다. 컨셉 문서를 쓰거나 게임을 구상하는 것도 재미있는 일이긴 하지만, 그건 어떤 프로젝트에서든 게임 디자이너가 해야하는 실질적인 업무의 아주 작은 일부에 불과하다. 

아이디어, 컨셉, 팀 브레인스토밍과 창의력에 대해서는 더 깊이 파고들지 않겠다. 이들은 각기 새로운 포스팅이 하나씩 필요할 정도로 광범한 주제들이다. 이 포스팅에서는 게임 디자인의 기술적 측면들과, 다양한 상황들에 적용될 수 있으며 게임 디자이너가 더 적은 노력으로도 더 정확하게 복잡한 문제를 풀 수 있도록 도와줄 다양한 프로덕션 테크닉들에 대해 다룰 것이다. 진정한 게임 디자인 작업은 개발팀 (심지어 1인 팀이라고 해도)이 컨셉에 동의한 이후에 시작되기 마련이며, 그렇다해도 여전히 프로덕션 테크닉을 수박 겉핥기 하고 있는 정도이다. 

당신도 나와 비슷한 생각을 하고 있다면 게임 디자인 레시피와 파편적 의견들, 포스트모템을 계속해서 찾아 헤매왔을 것이다. 아울러 제시 쉘(Jesse Schell), 브렌다 로메로 (브레쓰웨이트)(Brenda Romero(Brathwaite)), 이안 슈라이버 (Ian Schreiber), 대니얼 쿡 (Daniel Cook) 및 그 외 많은 이들의 놀라운 업적과 친숙할 것이다. 이런 짤막한 블로그 아티클에서 게임 디자인을 재고하려 노력하려는 것은 아니다. 내가 지금 다루려는 주제는 이런 대단한 업적들과 충분히 병립할 수 있으며, 시작부터 이미 그런 업적들에 의존하고 있는 요소이다. 나는 이 지면에서 내가 수년간에 걸쳐 쌓아 온 방법론적 측면의 몇몇 생각들을 공유하려는 것이다. 나는 이들을 한데 묶어 단일한 이론틀로 정리했으며, 추상화 단계 (Levels of Abstraction : LOA)라 부르려 한다. 

LOA에 가장 가까운 비유는 아마도 나와 내 팀동료들이 파라디스 페르두스 (Paradis Perdus)를 작업하며 매일 보아왔던 유튜브 영상일 것이다. 이 영상은 인터넷의 어떤 측면을 반쯤 비웃자는 의도로 만들어진 것인데, '큐일 이론'에 따라 큐일 (현실에서의 추상화의 단계) 숫자가 증가함에 따라 텍스트가 점점 더 추상적이 되어가는 과정을 보여준다. 

http://www.youtube.com/watch?v=nfdEdE96En0

단순하게 보자면, LOA란 게임 디자이너가 자신들의 분석기법을 가능한한 유용하게 쓸 수 있게 해주는 프레임웍이다. 추상화란 게임 시스템을 올바르게 이해하고 밸런싱하는데 중요한 요소이며, 서로 다른 상황들은 서로 다른 추상화 단계를 필요로 한다. 게임 디자이너는 어떤 순간에든 자신들에게 가장 적합한 추상화 단계를 선택할 수 있으며, 따라서 자기 업무의 효율을 담보할 수 있다. 예를 들어 어떤 매커니즘을 설명하는 가장 좋은 방법은 간단한 스케치를 그려보이는 것이며, 이를 필요로 하는 특정한 팀원에게 보여주면 된다. 이때 최고의 방법으로 쓰인 것은 스케치이지만, 스케치는 때로 스프레드시트가 될 수도, 글로 쓰인 메모가 될 수도, 순서도나 프로그래밍 코드가 될 수도 있다. 

상황에 따라 적절한 LOA 수준은 팀, 예산, 개발 스케쥴, 개발 단계, 게임의 종류와 그 외에도 십여가지의 요소들에 따라 달라질 수 있다. 각각의 LOA는 게임 디자이너로 하여금 게임 시스템을 더 나은 방식으로 공식화하거나 커뮤니케이션하게 해주는 도구이며, 따라서 공식화와 커뮤니케이션을 더 잘 다루게 해준다. 나는 독립 작업, 또는 협력 프로젝트를 하면서 가장 빈번하게 만났던 5 가지의 LOA에 대해 얘기하려 한다. 참고로 같은 프로젝트, 때로는 같은 매커니즘을 대상으로도 복수의 LOA가 사용될 수 있음 (또는 사용되어야함) 을 기억하길 바란다. 

이에 대해 더 깊은 논의를 할 수 있다면 좋겠다. 아울러 이 목록에 추가할 것이 있거나 여기에서 소개하는 LOA에 대해 말할거리가 있다면 메일을 주거나 댓글을 다는데 주저하지 말기를 바란다. 나는 이 포스팅을 이후에도 자주 인용할 것이므로, 필요하다면 언제나 최신 버전으로 업데이트하고 개선할 것이다. 

단계 1 : 실증적

그 자체로서 평이한 언어적 표현이 그대로 스스로를 설명하는 추상화 단계이다. 아마도 게임 매커니즘을 설명하기 위해 가장 흔하게 쓰이는 방법이자, 때로 게임 디자인 문서나 웹사이트의 의 서두에 사용되며, 팀 동료들 간의 커뮤니케이션에 자주 쓰이는 방법일 것이다. 

캐릭터는 숙주를 감염시키지 않으면 아무것도 할 수 없으며, 움직일 수조차 없다. 적들 중 하나가 캐릭터에게 충분히 가까이 오면 플레이어는 액션 버튼을 눌러 캐릭터로 하여금 적을 감염시키게 할 수 있으며, 적이 할 수 있는 일들에 기반하여 플레이어도 새로운 능력을 발휘할 수 있게 된다

이런 방식의 설명은 종종 게임 매커니즘의 동작을 보여주는 간단한 그림을 곁들이게 되는데, 이를 통해 설명은 좀더 명확해진다. 이때 사용되는 그림들에는 디테일이 별로 없으며 많은 경우 게임의 특정한 장면을 묘사하는 단순한 모형에 설명을 위한 몇몇 그림을 추가한 수준이다. 

LOA1은 어떤 공식이나 값도 포함하지 않으며 뭔가를 써서 표현해야 할 상황에 사용된다. 일반적으로 게임 디자이너는 이후에 다시 찾아보기 위해 뭔가를 기록해두거나, 어떤 기술적 정보도 포함하지 않는 단순한 용어들로 매커니즘을 설명해야 할 필요가 있기 때문이다. 

그러나 LOA1이 어떤 게임 매커니즘을 설명하는 유일한 방법으로 이용된다면, 나중에 게임 디자이너가 돌아왔을 때를 위해 실제로 그 매커니즘이 어떻게 동작하는지를 정의하고, 맞는 공식과 더미값이 무엇인지를 알아내야 하는 것은 프로그래머이다. 이 방법으로 일을 진행하면 종종 재반복(reiteration)이 필요하긴 하지만, 각각의 멤버들이 게임의 여러 분야에 손을 대야하는 작은 팀 (또는 일인 팀)의 경우에는 그럼에도 좋은 아이디어라고 할 수 있다. 그러나 큰 팀의 경우에는 재반복에 소요되는 시간으로 인해 문제가 될 수 있다. 

단계 2 : 도식적

이 단계는 좀더 나아가서 게임 매커니즘이나 게임플레이를 표나 그래프로 표현하게 된다. 따라서 추상화의 단계는 높아지고 게임 플레이는 보다 공식적으로 서술된다. 어떤 시스템을 공식적으로 표현하기 위한 방법의 하나로 LOA1과 병행해서 흔히 쓰인다. 어떤 매커니즘 또는 게임적 상황은 2단계를 통해 더 잘 묘사될 수 있으며, LOA1이 전혀 필요치 않은 경우도 있다. 

이는 또한 어떤 3D모델링도 없이 작은 지역(미션) 또는 전체 지역(월드)의 레벨 디자인을 묘사하는 흔한 방법이기도 하다. 한편 수치가 적용되는 행동과 스킬을, 적용된 공식을 바꾸지 않고 밸런싱하는데 쓰이기도 한다. 

실증적 추상화 단계로 써내려가거나 설명하기에는 너무 긴 시간이 걸릴만한 큰 데이터를 비교하거나 보여주기 위해 LOA2를 사용하는 것은 괜찮은 생각이다. LOA1과 마찬가지로 LOA2 또한 게임 디자이너가 만든 공식을 사용하여 게임 매커니즘을 직접 바꿀 수는 없다. 그러나 이미 존재하는 공식을 사용하여 데이터를 보여주거나 계산하는데에는 사용할 수 있다. 

단계 3 : 수학적

수치가 사용된다는 점에서는 LOA2와 유사하지만, LOA3에서는 디자이너가 자신의 공식을 사용하여 게임 매커니즘을 설명할 수 있다. 더 높은 추상화 단계를 사용함으로써 디자이너는 더 높은 단계의 통제가 가능해지고 더 나은 시각을 가질 수 있다. 

인용

DifficultyOfTransition = NumberofTagsPerCondition / (N*NumberOfConditionsPerTransition * NumberOfWordsPerTag);

이 단계의 추상화는 적용되기 전에 대규모의 테스트가 필요하다. 종이에 써서든 디지털 프로토타입이든, 실시간으로 공식을 바꾸거나 값을 변경할 수 있는 종류의 테스트를 해봐야 한다. 이 방식의 장점은 게임 디자이너라 이런 방법으로 매커니즘을 묘사해봄으로써 정확하게 자신들이 원하는 결과를 얻을 수 있다는 점이다. 이를 통해 더 정밀한 미세조절과 정확한 밸런싱이 가능하다. 한편 단점은 매커니즘의 적용이 시작되기 전에 프로토타입으로 테스트를 해봐야 하기 때문에, 프로그래머가 실제로 이를 코딩하기 위해서는 약간의 시간이 필요하다는 점이다. 

일반적으로 LOA3 는 수학만이 문제가 되는 분야에 사용하기에 좋다 : 논리적 퍼즐, 롤플레잉 요소 등 게임플레이에 심각한 변화를 주지 않고 종이에 쓰면서 쉽게 프로토타입이 가능한 경우가 이에 속한다. 점프, 이동, 또는 그 외 속도나 가독, 물리적 변수들이 개입되는 여러 요소에 쓰기에도 괜찮을 것이다. 

단계 4 : 알고리즘적

4번째 추상화 단계에서 게임 디자이너는 게임 매커니즘을 순서도, 의사코드 (pseudocode), 또는 명확한 안내가 기재된 동작의 순서를 통해 공식화한다. 

이 LOA를 밸런싱에 사용하기는 어려운데, 이는 데이터 표현에 내재된 기본적 속성 때문이다. 그러나 게임 매커니즘 동작의 논리적 구성에 문제가 없는지 확인하고 동작이 순서에 맞게 일어나는지를 확인하기에는 좋다. 복잡한 게임 시스템에서 이런 문제들이 초기에 발견되지 않으면 이후에는 아주 곤란한 지경에 처할 수 있으며, 그때가서 이를 수정하기 위해서는 훨씬 더 많은 비용이 필요하게 될 것이다. 

LOA4는 특정한 값이나 공식을 찍어낼 수 있다. 물론 디자이너가 그렇게 사용하지 않는다면 그럴 수도 있다. 그러나 LOA4의 사용에 있어 한 가지는 반드시 고려해야 한다. LOA4를 사용하려는 이유가 어떤 매커니즘을 실제 게임에 적용되었을 때와 정확히 같은 방식으로 종이 위에서 테스트하려는 것이라면, 실제 변수와 공식을 사용하는 것이 좋다는 점이다. 이 경우 플레이메이커 (Playmaker)와 같은 유니티를 위한 자동화 제한상태머신 툴이라면 아마 도움이 될 것이다. 한편 LOA4를 특정한 매커니즘에 기반한 로직이 제대로 동작할지 확인하거나 잘못된 처리 순서에 의해 발생할지 모르는 위험을 완화하기 위해 사용할거라면, 각각의 상태에 대해 지나치게 자세한 곳까지 들어가지 않고도 간단한 순서도나 순차적 알고리즘을 이용해서 해볼 수 있다. 

내 경험상, 큰 프로젝트든 작은 프로젝트든 LOA4를 사용함으로써 득을 볼 수 있다. 그러나 복잡한 시스템을 이런 알고리즘으로 공식화하여 써내려가는 데는 긴 시간이 소요되므로 디자이너들은 이 점에 유의해야 한다. 

단계 5 : 프로그램 코드

때로 어떤 매커니즘 (또는 매커니즘의 일부)를 LOA4를 지나쳐 직접 코드로 써내려가는 것이 좋은 생각일 수도 있다. 복잡한 시스템을 알고리즘적 구조로 공식화하는 데에는 상당한 시간이 소요되며, 그 자체로서 최종적 결과물이 아니기 때문에 불필요한 일이 될 수도 있어서이다. 코드로 직접 쓴다면 쉽게 표현될 수 있으며 더 적은 공간을 차지하고 디버깅에 소요되는 노력도 더 적은, 단순하고 작은 동작들이 굉장히 많이 포함된 알고리즘의 경우에 특히 그렇다. 아래의 이미지는 때로 한 줄의 코드가 제한상태머신의 여러 동작을 대체할 수 있음을 보여준다. 

매우 특정한, 또는 매우 독립적인 매커니즘을 이런 방식으로 써내려가는 것은 꽤 괜찮은 일이다. 게임 디자이너가 직접 코딩을 하는게 아니라면 이 방법은 매커니즘과 그에 대한 설명을 그 자체로 실제 적용할 사람들, 즉 프로그래머에게 제시하는 일이 될 것이다. 물론, 게임 디자이너 스스로 생각하기에 그게 가장 쉬운 길이라 여길 때는 말이다. 

아, 그나저나 이런 말 혹시 들어보았는가? 게임 디자이너는 코딩하는 법을 알아야만 한다.