GDF에 작성했던 포스팅을 블로그로 옮겨 봅니다.

GDF 원문 주소: http://gdf.inven.co.kr/t/topic/493

==========================================================================================================================================

 

저는 어제 SNS에 이런 글을 남겼었습니다.

> "듀랑고의 자원 회수" 건에 대해 신묘하고 확고한 아이디어가 있지만, 프로그래밍 지식이 부족해 창피를 당할까 염려도 되고 트위터 여백도 부족하니 적지 않기로 한다.
(원문링크: https://twitter.com/zerasion/status/494380401666703360)

스레드에서 많은 분들이 의견을 피력해주셨지만 신비주의라거나 거창하고 엄청난 아이디어라서 말씀을 안드린 건 아니고 단지 제가 어제 마감을 치느라 자정까지 혹독한 일감을 치러내야했기 때문에 시간이 없어서 말씀을 못드렸던 것이니 이 자리를 빌어 심심한 사과의 말씀을 전달 드립니다. 죄송합니다. (흑흑)

사실 shotbyshot 님과는 개인적으로 이 방안에 대해 논의한 적이 있었고, 당시에는 크게 환영받지 못하는 분위기였습니다만.. (훌쩍) 생각했던 내용을 온전히 전하지 못했기 때문은 아닌가라는 생각에 다른 내용들을 더 보강해 보았고 그 내용을 지금부터 풀어내볼까 합니다.

우선 두 가지 방식으로 이 건에 대해 접근해 보았습니다.

첫째, 시스템 구조적인 접근.

논리적으로 자원을 회수할 수 있는 방법에 대해서 생각해 봅니다.

둘째, 사용자 경험적인 접근.

심리적으로 사용자의 자원을 회수하는 것에 대한 저항감에 대해서 생각해 봅니다.

먼저 듀랑고의 자원 구조에 대해 NDC 2014를 통해 알 수 있는 사실은, 듀랑고의 자원은 "에너지"라는 단위로 크게 묶여있는 것으로 추정할 수 있습니다. 그리고 소위 "닫힌 계"라고 불리는 완전한 순환을 지향하는 에너지 순환 구조가 도입될 것으로 예상됩니다. 즉, 플레이어가 계속해서 시스템으로부터 일방적으로 자원을 축적시키는 것을 원천봉쇄하는 것을 목표로 삼고 있다고 생각됩니다. 그리고 이 과정에서 반드시 플레이어에게 제공되었던 자원은 다시 시스템에게 반납되야하는 대상으로 취급됩니다. 일반적인 인플레이션 경제 체제를 도입한 많은 온라인 게임들에서 사용하는 "경제 하수구"라는 개념과는 그 목적이 유사할 수도 있지만 본질적으로 다르다고 생각됩니다. 대체 자원을 회수하는 것이 아닌, 발급한 자원 자체를 다시 회수하는 것이 근본적으로 다르다고 생각되는데요.

첫째, 시스템 구조적인 접근법에 대해 생각해 보겠습니다.

제가 키워드로 사용하고 싶었던 것은, 위 인용구의 원문 링크 스레드에서도 언급했다시피 '어음 발행'입니다. 하지만 어음 발행에 대해 제가 이해하고 있는 바가 정확치 않을 수도 있으니, 그냥 참고 정도만 해두시길 바라며 본론으로 들어가겠습니다.

목표는 이렇습니다.

 - 자원이 쌓이지 않고 계속 순환되게 한다.
 - 접속 중이 아닌 플레이어의 자원도 회수한다.

그리고 이 과정에서 전제한 내용은 이렇습니다.

- 자원의 생성과 소멸에 대한 정보는, 클라이언트에서 처리하기 위험할 수 있다. (변조 위조 등의 이유)
- 따라서 이 정보는 서버와 DB를 통해 관리될 필요가 있다.
- 접속하지 않은 플레이어의 데이터를 직접 변경하는 것은 기술적으로 어려움(또는 위험)이 따른다.

그래서 다음과 같은 방법으로 이 부분을 타개해보고자 했습니다.

1. 자원 생성(시스템이 플레이어에게 넘겨주는) 시점에 소멸(시스템이 플레이어로부터 돌려 받는) 시점을 함께 발급한다.
듀랑고의 자원 생성은 순수한 Create가 아니라 시스템이 가지고 있는 자원을 플레이어에게 넘겨주는, 일종의 소유권 이전과 같다는 해석을 했었습니다. 이 해석은 저의 다른 글인 [가죽 장화를 통해 추리해 본 듀랑고식 아이템과 가공](http://gdf.inven.co.kr/t/topic/409)에서 찾아보실 수 있습니다.
그리고 레시피라는 가공 방식을 생성 시점에도 동일하게 적용하는 것으로 파악되었기 때문에, 이같은 정보를 태그해두는 것이 가능한 환경이라고 생각됩니다.

- 한 번 발급받은 소멸 시점은, 재가공 시 또는 직접적인 해당 자원의 연장을 통해 갱신한다.
이 과정을 통해 아이템의 가공 단계와 무관하게 최초 원재료가 생성된 시점에 이후의 자원 생명이 연계되는 것을 방지할 수 있습니다. 그리고 활성화 된 자원을 파악하는 데에도 요긴하게 활용될 것입니다. 게임에 접속하지 않은 상태에서는 이 갱신을 시도할 수 없기 때문입니다.

- 소멸 시점을 갱신하지 않은 상태로 소멸 시점이 도래하면, 해당 자원은 "회수 대상"으로 판단한다.
여기서 중요한 부분은 큰 따옴표로 구분한 "회수 대상으로 판단한다"는 표현입니다. 이 부분이 온라인과 오프라인 상태 모두의 플레이어에게 유효하게 대응하기 위한 핵심 방안입니다.
먼저, 온라인 플레이어의 경우는 이미 서버와 클라이언트가 접속된 상태이기 때문에 즉시 자원을 회수할 수 있습니다. 이 과정은 이미 다른 많은 게임들에서 사용하고 있기 때문에 깊게 논하지 않도록 하겠습니다.
다음으로, 오프라인 플레이어의 경우는 온라인의 경우처럼 즉시 회수되기 어렵습니다. 이 부분은 앞서 전제했던 조건들 중 세 번째인 "접속하지 않은 플레이어의 데이터를 직접 변경하는 것은 기술적으로 어려움(또는 위험)이 따른다."라는 부분 때문입니다.
따라서, 오프라인 플레이어의 경우는 즉시 회수하지 않습니다. 다만 시스템 입장에서 "회수 대상"으로 분류하고, "잠정적 회수 자원"으로 판단하는 것입니다. 회수할 시점은 해당 플레이어가 게임에 접속하는 순간이며, 소멸되는 아이템을 가진 많은 F2P 게임들이 사용하는 방식이기 때문에 이 부분에 대해서도 깊게 논하지는 않겠습니다.

- 회수 대상으로 판단되는 자원은 그 즉시 시스템에 자원을 돌려준다.
사실 돌려준다라고 표현했지만, 실제로는 플레이어에게 마이너스(-)한 자원량만큼, 시스템에게 플러스(+)한다라고 나누어 표현하는 것이 맞습니다. 그래야만 하는 이유는 역시 오프라인 플레이어의 자원 때문인데요. 온라인 플레이어는 플레이어에게서 빼고, 시스템에 더하는 것을 즉시 수행할 수 있어 크게 문제가 되지 않습니다. 하지만 오프라인 플레이어의 자원은, 위 3.번 과정에서 "즉시 빼지 않을거다"라고 정했었죠. 하지만! 중요한 것은! 회수 대상으로 판단되었기 때문에 어차피 그 것은 돌려받을 것이라고 생각하고, "일단 시스템에 자원을 더한다"는 점입니다. 이 방식은 시스템이 플레이어에게 받을 자원을 담보로 일종의.... 자원 가불 또는 대출한 상태로 볼 수 있습니다.
이 방법으로 창고에 막대한 자원을 쌓아두고 사라져버린 휴면 플레이어 때문에 시스템이 자원 총 량이 묶이는 일을 방지할 수 있습니다. 그 사람 창고에 자원이 있건 없건, 소멸 시점이 지나 회수 대상으로 분류됐다면 시스템의 자원량은 회복될 테니까요. 하지만 이 부분에서 조심스럽게 다뤄야할 부분은, "그래서 그 창고지기가 실제로 게임에 접속해서 자원이 사라지기 전까지는, 실제 게임 내 자원 총 량은 초과 상태이다"라는 점입니다.
하지만 전체 자원량을 계산하지 않고, "가용 자원"만을 계산한다면, 회수 대상 자원은 이미 가용 자원이 아니기 때문에 자원의 융통에는 문제가 없지 않을까 생각하고 있습니다.

쓰다보니 예상보다 말이 몹시 길어진 것 같아 죄송스럽습니다. 역시 글을 짧게 쓰는 재주는 일단 제 것은 아닌 게 확실한 것 같습니다. (흑흑)

다음으로 사용자 경험적인 접근 방법에 대해 생각해 보겠습니다.

일단 가장 먼저 우려되는 부분은, 많은 분들도 예상하시겠지만 "(플레이어 입장에서)게임이 내 자원을 뺏어간다."라는 부정적인 느낌을 받을 수 있다는 점일 것입니다. 이미 많은 플레이어들이 기존의 다른 게임들로부터, "캐릭터와 장비는 영구 자산이다"라는 RPG의 문법이 학습되어 있기 때문일텐데요.
그렇기 때문에 저는 이 부분에서 가장 중요한 부분이 "플레이어의 인식을 바꾸는 것"이라고 생각합니다.
플레이어의 인식을 어디로 바꿀 것인가?라는 부분에 대한 제 해법은 이렇습니다.

"(듀랑고의)장비는 원래 소모품입니다, 고객님."

이에 대해 몇 가지 다른 게임의 예시를 들어보겠습니다.

1. EVE Online
제가 순환과 자원에 대한 이야기가 나오면 항상 빠뜨리지 않고 언급하는 게임이 있지요. 네, EVE 온라인 입니다. 이 게임의 굉장한 매력 중 하나가 바로 플레이어에게 기존 문법을 새 문법으로 교정시키는 일을 성공적으로 수행했다는 점에 있는데요. 바로 "당신이 가진 모든 것(부품, 함선, 심지어 캐릭터조차도)은 소모품입니다."라는 것을 인식시켜주기 때문입니다.
보통 RPG 게임에서 PvP 컨텐츠를 플레이하려면, 경쟁에서 우위를 선점해야하기 때문에 자신이 가지고 있는 가장 강력한 장비들을 동원하는 경우가 일반적이겠죠. 하지만 EVE 온라인에서는 "전투에 나가면 모두 소비될 것이다"라는 걸 이미 플레이어들이 알고 있기 때문에, 소비되도 다시 복구할 수 있는 규모(그 규모는 각자의 재정력에 따라 다르겠지만)의 부품과 함선들로 전투에 참가합니다. 부수적으로는 이와 같은 이유로 낮은 등급의 자원들에서도 끊임없이 수요/공급의 순환이 이뤄진다는 이점이 있지만 이 스레드에서는 논하지 않겠습니다.

2. Minecraft
그리고 로그라이크인듯 로그라이크아닌듯 로그라이크같은 썸을 타는 게임이 하나가 있는데요, 세계적으로 인디 신드롬을 불러일으킨 마인크래프트(Minecraft)가 그것입니다.
마인크래프트에서는 캐릭터가 사망하면 아이템을 모두 바닥에 떨어뜨리고 경험치가 전부 날아가는 그야말로 로그라이크같은 면모를 볼 수 있습니다. (아니? 마인크래프트에 경험치가 있었다고?같은 소소한 발견은 넘어가도록 하겠습니다. 사실 경험치를 뭐에 쓰는 지는 저로선 전혀 모르겠습니다.) 그럼에도 불구하고 로그라이크가 아닌듯한 냄새는 "마인크래프트에서 중요한 건 레벨과 자원이지 캐릭터나 장비가 아니잖아?"라는 부분에서 느낄 수 있다고 생각합니다. 그리고 모두들 아시겠지만, 마인크래프트의 장비(전투 장비 말고 채집 장비요)는 모두가 소모품이죠. 그래서 서바이벌 모드에서 삽질을하고 곡괭이질을 하는 모든 행위를 할 때, 많은 분들이 한 번에 여러 벌의 도구들을 만들어서 인벤에 담고 작업장으로 이동하게 됩니다. 이 때 장비 내구도가 다해서 소모되었다고 해서 "시스템이 내 자원을 뺏어갔어!"라고 느끼는 분은.. 없다곤 못해도 많진 않으시겠죠?
(물론 캐릭터나 장비는 소모품으로 인지될 수 있지만, 앞서 말한 레벨과 자원이 중요하기 때문에 선인장 괴물 같은 게 내 피와 땀으로 빚어낸 소중한 건축물을 파괴시키면.. 음... 네. 애도해드려야죠.)

3. Diablo lll (Hardcore)
현 세대에서 로그라이크란 꽤 매니악하고 클래식한 취향처럼 보일 수 있다고 생각합니다. 그도 그럴 것이, 메이저한 로그라이크 게임이 로그라이크가 성행하던 레트로(..?) 시절에 비해 그리 많지 않기 때문일텐데요. 그럼에도 불구하고 굴지의 메이저 개발사 블리자드에서 로그라이크"만"을 제공하진 않았지만, 로그라이크"도" 제공해준 게임이 있었으니, 다들 너무나도 잘 알고 계실 디아블로 시리즈가 그것입니다. 2편부터 3편까지 이어진 이 "하드코어 캐릭터"라는 모드는 캐릭터에게 유일성의 생명을 부여하고 있는데요, 이 덕분에 영원한 인플레이션 속에서 고통받는(?) 스탠다드 캐릭터에 질린 매니아들에게 큰 사랑을 받고 있습니다.
저도 요즘은 하드코어 캐릭터를 열심히 육성하고 있지만, 사실 3편 오리지널까지만 해도 죽음에 대한 두려움이 커서 쉽게 진도를 나가진 못했습니다. (오리지널 당시에는 일반-악몽 난이도를 클리어하는 정도에서 멈췄지만, 확장팩 적용 이후에는 최고레벨 캐릭터를 두 개 육성했습니다.) 하지만 2.0 패치와 확장팩 컨텐츠를 통해 이같은 죽음에 대한 완화 장치들을 다수 마련해놓았고, 캐릭터의 "재육성"에 대한 부분을 전폭적으로 지원해 준 덕분에 용기를 내서 진행할 수 있었다고 생각됩니다.
가장 큰 심리 저항 완화 장치는 아무래도 "정복자 시스템"이었다는 생각이 드는데요. 예전에는 각 캐릭터마다 별도의 정복자 레벨이 적용되면서, 단지 60레벨 이후의 추가 성장이라는 "더 깊은 육성 요소"로만 동작했었습니다. 덕분에 높은 정복자 레벨의 캐릭터일 수록, 사망 시의 충격 또한 컸고요. 하지만 개편된 정복자 2.0 시스템은 계정 내 같은 모드(스탠다드/하드코어)의 모든 캐릭터가 공유하는 "계정 성장 요소"가 됨으로써 캐릭터가 사망해도 유의미하게 남길 수 있는 요소와, 재육성 시 직접적으로 부스트해주는 요소로 멋지게 동작하고 있습니다.
그리고 오리지널 시절부터 유지되는 공유 요소로는, 창고와 장인 레벨이 공유되기 때문에 완전히 모든 것을 처음부터 시작하는 정도까지 플레이어를 내던지지는 않습니다.
디아블로3의 하드코어 모드로 이어지는 시스템의 연계 흐름에 대한 더 자세한 정보는, 저의 다른 글인 [디아블로3의 완성, 2.0 패치 살펴보기](http://gdf.inven.co.kr/t/3-2-0/393/7)에서 확인하실 수 있습니다.

위의 세 게임들을 예시로 꼽으면서, 제가 정리한 "플레이어의 인지를 바꿀 수 있는 방법"은 다음과 같습니다.

- 목표: 플레이어로부터 "장비는 소모품"이라는 인지 변화를 이끌어낸다.
- 방법1: 손쉬운 복구를 지원한다.

예를들어, 이브온라인의 경우는 플레이어 본인이 쉽게 복구할 수 있는 정도의 자원만 소비하는 형태로 우선 제어가 됩니다. 그리고 일단 그것을 복구하는 과정 자체는 앞서 설명드린대로 낮은 단계의 물건들도 수요/공급 순환이 꾸준하기 때문에 본인이 자본만 있다면 복구하는 절차 자체는 어렵지 않습니다.
그리고 마인크래프트의 경우, 레벨에 변화를 일으키는 것이 주된 목적이라고 가정했을 때 그 변화를 "손쉽게 도와주는 것"이 도구일 뿐이지 도구가 없다고 전혀 그 기능을 사용할 수 없는 것은 아닙니다. 극단적이긴 하지만 맨손으로 흙도 파고 나무도 베고 돌도 캘 "수는" 있으니까요. 그리고 설치된 작업대와 약간의 재료만 있다면, 얼마든지 나무나 돌로 된 도구들은 복구할 수 있어 부담이 적기도 합니다.
디아블로의 경우도, 계정 간 승계되는 정복자 포인트라는 성장 포인트와 창고를 통해 사용 가능한 고단계 보석 등을 통해 생짜 1레벨 캐릭터보다 훨씬 강력한 캐릭터를 세팅할 수 있고, 이를 통해 높은 난이도의 플레이를 통해 빠른 성장이 가능하도록 지원하고 있습니다.
듀랑고에서도 회수된 자원을 다시 복구하는(완전히는 아니고 어느 정도까지는) 과정이 쉽게 이뤄질 수 있도록 게임이 제공하고 있다면, 방법1을 달성할 수 있을 것으로 생각됩니다.
- 방법2: 소멸하지 않는 것을 분리한다.
이브온라인은 아바타 클론이 없다면 그야말로 태초의 상태로까지 돌아갈 수 있는 잔인한(..) 시스템이므로 소멸하지 않는 무언가는 생각나지 않아 제외하겠습니다.
마인크래프트에서도 결국은 모든 것이 소멸 가능한 것들이긴 하지만(뎀! 선인장 괴물!), 장비와 캐릭터가 소멸된다고 해도 내가 변화시켜둔 레벨은 레벨에 어떤 변화가 가해지지 않는 이상 캐릭터의 사망과는 전혀 별개의 요소로 존재하기 때문에 캐릭터의 사망과 장비의 소멸이 별로 신경쓰이는 요소가 아닐 수 있다고 생각합니다.
그리고 사실 디아블로3의 정복자 포인트 때문에 이 항목을 언급했다해도 과언이 아닐텐데요, 가령 예를 들어서 듀랑고에서 퍼머데스(Permanent Death;영원한 죽음)를 적용한다 할 지라도 계정 단위의 어떤 누적 성장 요소가 있다거나, 하우징은 특별한 사유가 아니면 보존된다거나 하는 장치가 구비되어 있다면, 더 중요한 요소가 존속된다는 안도감으로 덜 중요한 요소가 소멸되는 것에 플레이어의 관심이 쏠리지 않게 이끌 수 있을 것 같습니다. 써놓고보니 이건 러스트(Rust)에서 좀 더 투박한 형태로 지원하는 방식이기도 하네요.(역시 폴리곤 마인크래프트!)


정리하자면 이렇습니다.
흔한 RPG 게이머들이, 인벤토리에 물약을 200개 쯤 쌓아놨다가 보스 전투 중에 몽땅 다 써버렸다고해도, 모든 걸 잃은 것처럼 허망해하지는 않을 것입니다. 물약은 원래 쓰라고 있는 소모품이라는 걸 이미 알고 있었을테니까요. 소모품이 소비되어 없어지는 것을 전혀 이상하지 않게 인지한다는 것입니다.

하지만 장비는 왜 영원 불변해야 한다고 생각할까요? 심지어 리니지 시리즈에서는 강화에 실패해 소멸되는 장비가 지금 이 순간에도 수 백 기에 달할 수도 있는데, 그럼에도 불구하고 왜 분노하게 될까요?
저는 이 부분은, "그 게임 사회가 바라보는 장비의 가치" 때문이라고 생각합니다.
단순히 자주 소비된다고 해서 그것을 소비되는 것이 당연한 소모품이라고는 생각하지 않을 것입니다. 이 점이 개발자로부터 의도된 그리고 부여된 아이템의 가치라고 생각합니다. 그리고 앞서 언급한 리니지 시리즈의 경우는, 그런 아이템의 가치를 보존하는 것이 처음부터 의도된 게임이기 때문에 숱하게 소비되는 장비라 할 지라도 항상 소멸될 때마다 슬퍼하거나 분노하게 된다고 생각합니다.

물론 모든 장비가 소모품이니까 낮은 가치를 지녀야 한다는 이야기는 아닙니다. 당연히 귀하고 높은 가치를 지닌 장비가 있을 수 있고, 또 있어야 하겠죠. 하지만 중요한 점은 그럼에도 불구하고 "(듀랑고에서)장비라는 것은 소모품이다"라고 인지될 수 있는 일종의 정책적인 밸런싱 기조 같은 것이라고 생각합니다.

음식은 시간이 지나면 모두 상합니다.
어떤 방법들을 통해서 좀 더 오랫동안 상하지 않게 처리할 수도 있죠.
그리고 개중에는 값비싼 음식도 있습니다.
하지만 값비싼 음식이라고 해서, 영원히 상하지 않을 것이라고 생각하지는 않습니다.

듀랑고의 장비에게도, 이와 같은 방법을 적용시켜보면 성공적으로 저항감 낮게 자원을 회수할 수 있지 않을까 추측해봅니다.

글이 길어졌지만, 그럼에도 염치불구하고 여러분의 많은 스레드 참여를 부탁드리면서 또 기대해 봅니다. (꾸벅)

 


WRITTEN BY
zerasion
디자이너의 의도는 플레이어의 의미가 된다.

,

 

이 포스팅은 GDF에서도 보실 수 있습니다.

 

GDF 주소: http://gdf.inven.co.kr/viewtopic.php?f=14&t=421

 

=========================================================================================================================================

 

 

["듀랑고:야생의 땅" 일러스트레이션]

 

 

1. 가죽 장화

 

지난 5월 27일, 판교 테크노밸리의 한 건물 지하에 마련된 강연장.
그곳에 모인 수많은 사람들의 관심과 기대 속에 시작된 패기와 재치 넘치는 한 게임 디자이너의 이야기는 순식간에 업계 전체를 뜨겁게 달궜습니다.

 

이번 NDC에서는 업계인들 뿐만 아니라 게이머들 사이에서도 유명인사인 닉네임 파파랑의 이은석 디렉터, 그의 신작 "듀랑고:야생의 땅"과 관련된 내용이라는 이유만으로도 이미 뜨거운 관심을 받고 있던 강연들이 많았지만, 그 중에서도 유독 많은 이들의 눈길과 발길을 사로잡은 것은 "가죽 장화 시리즈"로 불리는 "가죽 장화를 먹게 해주세요 / 가죽 장화를 먹게 해달라고?"의 두 연작 강연이었습니다. "가죽 장화를 먹는다"는 파격적인 소재와 "해주세요-해달라고?"라는 게임제작인들에겐 끝나지 않는 RvR 소재인 게임 디자이너 vs 프로그래머라는 대결 구도의 강연 배치까지. 무엇 하나 관심을 가지지 않을 이유가 없어보였죠. 그리고 그것에 대한 방증처럼, 무려 문명 온라인과 관련된 내용을 들고 나온 송재경 대표의 강연이 동시간이라는 것도 무색할 정도로 가죽 장화의 강연장은 의자에 앉지 못한 참석자들이 통로 바닥에 앉아서 들어야할 정도로 인산인해를 이뤘습니다.

 

 

 

[NDC2014 가죽 장화를 먹게 해주세요 프레젠테이션]

 

뚜껑을 연 가죽 장화 이야기는 오랫동안 많은 개발자들이 "이런 걸 해보면 어떨까? 근데 될까?"라고 고민만 하던 내용들을 "그래서 우리는 이렇게 해봤습니다."라고 덤덤한 어조로 전달하며 큰 충격을 안겨줬다는 점에서 마치 콜럼버스가 탁자에 달걀을 깨뜨리는 모습 같았습니다. 강연 시작 전에는 많은 사람들이 자신들이 알고 있는 온갖 방식을 떠올리며 "이렇게 했을까? 아니면 저렇게 했을까?"하는 추측들을 떠올렸던 것 같은데요, 디자이너가 설명해 준 사고의 흐름과 정리된 개념들을 보면서 무릎을 탁 치는 사람들이 많았습니다. 콜럼버스의 달걀에 대한 비유와 무릎을 탁 친다는 표현에서 알 수 있듯, 듣기 전까지는 떠올리지 못했지만 듣고 나면 한 번에 이해할 수 있는 그런 종류의 아주 멋진 해법을 보여줬다고 개인적으로는 생각합니다.

 

 

 

2. 아이템의 구성, 속성과 특성

 

두근거림에 대한 서론은 이쯤에서 마무리하고, 제가 이해한 듀랑고의 아이템 구조에 대해 정리해보겠습니다.


이 매커닉이 출발한 발상의 기점은 강연 초반에 나온 "아이템의 용도를 결정하는 주체가 개발자가 아닌 플레이어이길 바랐다."는 부분이라고는 생각되는데요, 이는 이후 29일 발표된 이은석 님의 "창발적 디자인"이 듀랑고의 핵심 요소라는 걸 감안할 때 굉장히 많은 이야기를 함축적으로 담고 있는 문장이라고 생각합니다. 플레이어가 게임플레이를 주도할 수 있도록 상향식(Bottom-up)과 블랙리스트 기반 디자인을 사용한 듀랑고이기에 디자이너는 공통적으로 사용할 수 있는 뼈대가 되는 규칙들을 설정하고, 각각의 요소들이 명확한 규칙 안에서 제한 없이 플레이어의 바람에 따라 흘러갈 수 있도록 아이템을 디자인했다는 것을 추측해볼 수 있습니다.

 

 

[NDC2014 가죽 장화를 먹게 해주세요 프레젠테이션]

 

강연자였던 왓!스튜디오 이정수 디자이너의 정리에 따르면, 듀랑고의 아이템을 구성하는 요소는 크게 "속성""특성"으로 분류됩니다. 속성은 다른 게임들의 아이템들이 가지는 속성과 다른 새로운 성질의 것들로 이뤄져 있는데 대표적으로 "날카로움", "딱딱함", "에너지가 있다"와 같은 것들이 그것입니다. 그리고 특성은 이러한 속성들이 모여 어떠한 구분점을 갖는 것들을 지칭하는데, "입을 수 있다", "먹을 수 있다", "가죽" 등이 그것입니다. 아이템 1.0으로 명명한 첫 번째 단계에서는 속성과 특성이 각각 별도로 관리되며, 디자이너가 직접 수동으로 특성을 입력하는 태깅Tagging 방식으로 구현됐다고 합니다. 하지만 규칙을 간단한 수준으로 정리하기 어려웠고, 일일이 수동으로 부여되는 태그 덕분에 데이터 안정성에 문제점이 발생하면서 디자이너 또는 시스템이 통제 가능한 범위로 내용을 정리해, 태그 속에 속성들이 포함되는 이전 보다 딱딱한 규칙으로 구현 방향을 돌렸고 이것을 아이템 2.0으로 명명했습니다. 하지만 의외성 부족으로 인해 창발성이 심각하게 훼손되는 결과가 나타났고 이를 보완하기 위한 아이템 3.0이 진행중이라고 했습니다.

 

[두들갓 조합식 화면]

 

이같은 속성과 특성의 관계를 보고 처음 떠오른 것은 두들갓Doodle God 이라는 게임이었습니다. 두들갓은 미리 정해진 조합식에 따라 두 원소를 합치면 새로운 원소를 발견할 수 있는 게임인데, 특정 원소를 만들기 위한 여러 가지의 조합식이 존재합니다. 예를 들어 불에 타는 원소는 무엇이라도 불과 섞으면 재Ash를 발견할 수 있습니다. 아니면 천적 관계의 두 생명체를 섞으면 대체로 시체 또는 피를 발견할 수 있고요. 하지만 이 게임의 조합은 상향식으로 디자인된 하위 단계의 규칙들로 만들어진 것이 아니기 때문에, 하나하나 미리 설정된 조합식에 따라서만 조합을 실행할 수 있습니다.

 

하지만 곧바로 이어진 프로그래머의 강연에서 아이템 3.0을 간략하게 소개받을 수 있었고, 이 단계에서 속성과 특성의 관계는 속성들이 모이는 규칙에 따라 특성이 자동으로 발생하는 방식으로 정리된 것으로 보였습니다. 이 단계부터는 직전까지 추측했던 두들갓 방식의 조합 구성이 더 이상 유효하지 않았습니다. 이해를 돕기 위한 적절한 예시 게임과 시스템이 없을까 고민하던 중, 오래지않아 어느 유명 게임의 시스템이 떠올랐습니다. 그것은 바로 몬스터헌터의 장비 스킬 시스템.

 

[몬스터 헌터 장비 스킬 테이블 화면]

(몬스터 헌터 스킬 계통과 스킬 페이지: http://www.nintendo.co.kr/3DS/MH4/manual/c07s03.php)

 

몬스터헌터의 장비는 그 하나 하나를 착용한다고 해서 어떤 스킬(옵션)이 적용되지 않습니다. 몬스터헌터의 장비 정보를 살펴보면 여느 RPG 게임 아이템처럼 "무슨 능력치 플러스 몇(ex. 지능 +3)"과 같은 옵션 정보를 찾아볼 수 없습니다. 대신 검술, 통격, 귀마개, 배부름처럼 독특한 이름의 "스킬포인트"가 정수(양수와 음수를 포함) 형식으로 적혀있는 것을 보실 수 있을텐데요, 바로 이런 스킬포인트들이 모여 일정한 수치에 도달했을 때, 비로소 각각의 스킬들이 발동되는 구조를 가지고 있습니다. 예를 들어 공격력에 영향을 주는 "공격" 포인트의 경우, +10/+15/+20 포인트를 만족했다면 각각 "공격력UP 소/중/대" 스킬이 발동하고, 반대로 -10/-15/-20 포인트를 만족했다면 각각 "공격력DOWN 소/중/대" 스킬이 발동합니다. 따라서 플레이어는 자신에게 유리한 스킬을 발동시키면서 불리한 스킬은 발동시키지 않기 위해 장비를 세팅하게 됩니다. 그리고 플레이어의 이런 장비 선택 고민이 유의미할 수 있도록 각각의 장비 파츠들은 + 포인트와 - 포인트를 함께 가지는 경우가 많습니다. 발동시킬 스킬만 집중하면서 장비를 세팅하다보면, 어느새 나쁜 스킬들이 한가득 따라오는 경우가 심심찮게 발생합니다. 기본 규칙은 심플하게 디자인한 뒤, 컨텐츠 단계에서 다양성을 확보해 플레이어에게 풍성한 경험을 가능하게 한다는 점에서 상향식 디자인의 성공 사례로 볼 수 있을 것 같습니다.

 

바로 이런 몬스터헌터의 스킬 발동 매커닉처럼, 듀랑고에서는 속성들이 모인 상태에 따라서 각각의 특성들이 "발동(발현)되는" 형태가 될 가능성이 높다고 생각합니다. 다만 각각의 스킬 포인트가 하나의 스킬 발동과 1:1로 연결된 몬스터헌터와는 달리, 듀랑고의 경우 여러 속성들의 조합 상태에 따라 특성이 발현되는 방식이라면 동시에 여러 종류의 특성이 발동되기 때문에 디자이너의 컨텐츠 통제가 훨씬 어려워진다는 문제가 발생할 것으로 보입니다. 따라서 양립할 수 없는 두 개의 특성이 한 개의 아이템에 동시에 발현되는 등의 예기치 못한 문제가 발발하지 않도록 특성들의 발현 조건을 보다 섬세하게 조율하는 작업이 디자이너에게 요구될 것 같습니다.

 

 

 

3. 아이템의 가공, 레시피

 

듀랑고에서는 태그라는 이름의 특성들을 통해 그 안에 담겨 있는 아이템의 속성을 파악하고 가공하는 일련의 과정들을 "레시피"라고 통칭하고 있습니다. 여러 강연 자료를 통해 볼 수 있는 "도끼를 만드는 방법"처럼, 날붙이, 접착제, 막대라는 태그를 가진 아이템들을 모아 레시피를 통해 고유한 무기로 "상태를 변경"할 수 있어 보입니다. 레시피의 가장 큰 특기 사항은 이것이 단지 다른 게임에서 "아이템 조합"이라고 불리는 시스템을 대체하는 수단이 아니라, 생산과 건설 시스템을 포함하는 포괄적인 대체 수단의 개념이라는 점입니다. 월드에 배치된 모든 식생들은 그 자체로 아이템이거나 아이템을 가지고 있고, 생산 레시피를 통해 "상태를 변경"하는 구조로 추측됩니다. 즉, 아이템을 생산 또는 채집해 플레이어가 손에 넣는 시점에서 이미 그 아이템은 최초의 아이템이 아닌 이미 가공된 아이템이 되는 구조로 생각됩니다.

 

 

[디아블로3의 전리품 2.0이 적용된 아이템 툴팁 화면]

 

아이템 제너레이팅 방식만 놓고 보면, 이러한 방식은 전혀 낯선 것만은 아닙니다. 어쩌면 아주 익숙한 방식일 수도 있고요. 디아블로3 전리품 2.0 시스템의 스마트 드랍을 생각해보시면, 우선 사용자의 조건(현재 플레이 중인 캐릭터 레벨과 클래스)을 판단한 다음, 해당 조건을 만족하는 옵션의 종류와 성능의 범위Boundary 안에서 아이템의 최종 속성들이 결정되는 것은 이미 익숙하실 거라고 생각합니다. 여기서 사용자의 조건을 판단하는 부분을 어떤 경로와 도구로 아이템을 생성하려고 했는지 판단하는 것으로, 옵션의 종류와 성능의 범위를 부여할 속성의 종류를 결정하는 것으로 각각 대입해보면 레시피의 가공 구조를 개념상으로나마 대략적으로 이해할 수 있다고 생각합니다.

 

[상태전이 테스팅 모델 예시]

(출처: http://sten.or.kr)

 

하지만 앞서 아이템이 레시피를 통과하는 동작을 "상태의 변경"이라고 표현한 부분이 제가 파악한 듀랑고 아이템 시스템의 핵심적인 차별점이었습니다. 강연에서는 "분해"라는 표현을 사용했었는데요, 다른 게임의 분해라는 컨텐츠처럼 전혀 다른 아이템으로 교환해주는 방식이 아닌, 마치 Windows OS에서 Ctrl+Z 키를 누른 것처럼 레시피를 거꾸로 돌려 아이템의 상태를 "되돌리는 방식"을 의미하고 있었습니다. 이같은 상태의 변경은 마치 어떤 순환 고리를 가지고 있는 것처럼 보였고, 물의 순환(구름-비-강-바다-다시 구름)이나 QA 시절 배웠던 상태전이 테스팅(State Transition Testing)같은 것들이 생각났습니다.

 

여기까지의 내용에서 파악해 본 레시피의 구조는 다음과 같습니다.

1) 생성 조건을 파악한 뒤 조건에 맞는 아이템 초기값을 제너레이팅 (생성)
2) 각각의 레시피들이 초기값을 변경하거나 새로운 정보를 더하거나 기존의 정보를 뺌. (가공)

 

[하스스톤 게임 화면]

 

블리자드의 카드 게임 하스스톤을 예로 들어보면, 맨 처음 어떤 하수인 카드를 전장에 냈을 때 그 카드의 기본 공격력과 생명력이 흰 색으로 적용될 것이고 이 부분이 (비록 랜덤 및 계산과 같은 프로세스의 개입은 없지만) 듀랑고의 아이템 생성 단계와 같다고 볼 수 있을 것입니다. 만약 카드를 내는 순간 기존의 다른 주문 등의 영향으로 기본 공격력/생명력 값에 변화가 생긴 상태로 전장에 배치가 됐다면 이는 특수한 조건이 만족된 상태(수확량이 좋은 계절에 채집을 했다거나 좋은 수집 도구를 썼다거나)에서 아이템을 생성한 것과 유사하지 않을까 생각됩니다.


그리고 이렇게 초기값으로 배치된 카드에 주문 또는 특수 능력을 가진 하수인의 효과를 적용해 값에 변화를 준다면, 증가한 값은 녹색으로, (생명력의 경우) 감소한 값은 적색으로 나타나게 되고, 마찬가지로 이를 듀랑고의 레시피를 통한 아이템 가공 단계와 같다고 볼 수 있을 것입니다. 이처럼 단순히 수치를 올리거나 내리는 것처럼 초기값의 일부 또는 전체를 다른 값 또는 상태로 변화시키는 정도가 있을 수 있고, 직접적인 언급은 없었지만 생성 단계에는 없었던 정보를 추가하거나 있던 정보를 제거하는 일도 가능할 것 같습니다. 하스스톤에서 다른 하수인에게 도발, 돌진, 천상의 보호막, 죽음의 메아리 등의 효과를 추가로 부여하는 것처럼요. 그리고 하스스톤에서 침묵 주문이 가지고 있는 효과를 크게 두 가지로 나눠볼 수 있는데, 하나는 WoW의 그것과 같은 "더 이상 주문 능력을 사용할 수 없음"이고, 다른 하나는 "지금까지 적용된 변화(그 중 버프류)를 되돌림"입니다. 듀랑고에서 레시피를 역으로 돌려 이전 상태로 되돌리는 분해 행동은 이 중 후자의 효과와 일맥하는 부분이 있습니다.

 

 

 

4. 고민해볼 내용들

 

하지만 여기서 구현 시 중요한 부분을 몇 가지 생각해볼 수 있을 것 같은데요, 하나씩 살펴보자면 다음과 같은 내용들을 꼽아볼 수 있을 것 같습니다.

 

1) 가공 구조의 규격화

 

우선 레시피라는 개념을 좀 더 생각해보겠습니다.

위에서 파악해 본 레시피의 특징은 데이터 단계에서 아이템이 본래 가지고 있던 정보를 가공하는 것인데요, 가공하는 대상의 존재 유무에 따라 두 가지 상황을 예측해볼 수 있습니다.

 

(a) 데이터에 있는 정보를 변경:

이 때에는 어렵지 않게 미리 아이템 데이터에 포함된 속성들의 값 또는 종류를 바꿔줄 수 있을 것입니다. 레시피를 적용하기 전에 레시피가 가공할 속성을 가지고 있는 지 먼저 검사하는 조건만 있다면 적용 전의 아이템을 선별하는 것과 적용된 후의 아이템 상태를 예측하는 것 모두 디자이너의 인지 범위 안에 있을 것입니다.

 

(b) 데이터에 없는 정보를 가감:

이 때에는 아이템 데이터에 해당 속성이 이미 있었는 지 없었는 지 판단하지 않고, 레시피가 어떤 속성을 부여하거나, 기존에 데이터에 존재하는 속성을 제거하는 등의 가공이 가능할 것입니다. 하지만 이 경우 최초 아이템 데이터에 설정한 속성들에서 크게 벗어날 우려가 있고, 그 때문에 가공 단계를 여러 차례 거칠 수록 디자이너의 인지 범위를 벗어날 가능성이 점차 증가할 것입니다.

 

듀랑고는 현재까지 이같은 가공 방식에 대한 규격화가 진행되지 않아 각 레시피마다 서로 다른 동작 방식을 가진 상태고 그에 따라 디자이너가 일일이 스크립트로 제작해야 하는 생산과 관리 양 쪽 모두의 어려움을 겪고 있는 것 같습니다. 강연 초반에 보여준 "[플레이어]가 [대상]에게 [행동]한다"같은 포괄적인 개념 정리 방식을 도입해보면 꼭 2차원 데이터 테이블 형식이 아니더라도 그 가공들의 공통된 규칙을 정리할 수 있을 것이라고 생각됩니다. "[레시피]는 [속성]을 [가공]한다"처럼요.

개인적으로는 액셀성애ㅈ..아니 데이터 테이블 애호가이기 때문에, 블로그의 다른 글에서 언급했던 "조건에 따른 컬럼의 활용법"을 통해 어떻게든 구현해볼 수 있지 않을까하는 생각을 가지고 있습니다.

 

([Z] 당신의 소중한 Data Table 컬럼, 이제 아껴쓰세요: http://zerasion.tistory.com/41)

 

문득 떠오르는 컬럼들의 내용들을 읊어보자면...

 

레시피 ID

레시피 이름 (내부명칭을 쓰는 공간과 실제 스트링을 불러올 공간은 구분이 필요)

레시피 종류 (생산, 조합, 건설 등등)

가공 방식 (있는 걸 바꿀건지, 없는 걸 넣을 건지 등)

요구 속성 (있는 걸 바꿀 경우, 어떤 속성이 있어야 레시피가 동작할 건지)

속성 보존 (요구 속성에 기입한 항목을 레시피를 통해 변경할 건지, 레시피 필요 조건으로만 체크하고 속성을 유지할 건지)

변경 속성 (다른 속성으로 바꾸려는 경우, 어떤 속성으로 변경할 건지 or 없는 걸 넣을 경우 어떤 속성을 넣을 건지)

값 연산 종류 (값만 변경하려는 경우, 합연산을 할 건지 곱연산을 할 건지)

(얼만큼 값을 변경할 건지)

정도네요.

물론 저는 듀랑고의 아이템이 어떤 종류를 얼마나 포함하고 있는지, 그리고 디자이너가 아이템의 가공에 대해 어떤 의도를 가지고 있는지까지는 알지 못하기 때문에 전혀 부적절한 내용이 될 수도 있겠지만.. 강연을 통해 유추해 본 내용상으로는 이런 정보들을 포함하고 있지 않을까 싶습니다.

 

 

2) 변수의 저장 방식

 

앞서 하스스톤의 예시에서처럼, 최초에 데이터 단에서 설정된 아이템의 초기 값(흰 색 숫자)이 있을 것이고, 그리고 각종 주문과 전투의 결과들에 의해 변화된 현재의 값(녹색 또는 적색 숫자)이 있을 것입니다. 여기서 전자를 초기값, 그리고 후자를 변수라고 불러보겠습니다.

 

초기값은 미리 데이터에 심겨진 내용이며 업데이트나 패치로 인해 데이터가 변경되기 전까지는 변하지 않는 값이기 때문에 각각의 정보가 고유하게 관리될 필요가 거의 없습니다. 그냥 "누가 뭘 몇 개 가지고 있다더라" 정도의 정보가 필요할 뿐이겠죠. 그리고 하스스톤의 카드들 역시 게임이 진행되지 않는 동안에는 이런 초기값들만 유효하기 때문에 덱에 어떤 카드를 몇 장 세팅했는지 정도만 저장할 공간이 확보되면 됩니다. 게임을 진행하면서 주문과 전투로 변경된 상태들이 각각 "이 카드는 지금 어떤 어떤 상태야"라는 게 저장될 필요가 없으니까요.

 

하지만 이런 변수들이 각각의 상태에서 저장되야 하는 게임들이 있습니다. 아이템의 내구도가 손상된다거나 강화나 마법부여 등으로 아이템의 능력치가 변경되는 RPG류의 게임들이 이런 게임에 속하죠. 그리고 단일 아이템에 영향을 주는 변수들이 한 개가 아니라 두 세개 이상인 경우가 많기 때문에(예를 들어 내구도, 강화 단계, 옵션 부여 종류, 재연마 상태, 보석 홈 갯수, 박혀있는 보석의 종류 등) 각각의 변수들을 곱한만큼 경우의 수는 비약적으로 늘어나게 됩니다. 듀랑고의 경우 아이템의 생성과 가공이 이같은 변수 방식으로 판단되고 있다면, 각각의 상태들을 저장해줘야만 하고 저장 공간이 변수의 종류와 숫자만큼 많이 필요할 수 있습니다. (물론 경우의 수를 조합해서 임의의 ID를 부여해 숫자만 관리하는 방식을 사용할 "수도" 있겠지만 창발적인 조합을 대응하는 방식으로는 적합하지 않을 듯)

 

만약 초기값과 변수의 "현재 상태"만 저장한다고 하면 그래도 어느 정도 기존의 게임들 구조와 유사한 수준으로 구현할 수 있을 것 같습니다. 중간에 어떤 어떤 형태가 있었는지는 판단하고 기억하지 않고, "그래서 지금 결과가 뭔데?"만 집중한다면 말이죠. 그런데 이 부분을 어렵게 만드는 한 단어가 있었으니, 바로 앞서 언급했던 "분해"가 그것입니다. 전혀 다른 재료 아이템으로 환원해주는 분해가 아닌, 이전 상태로 복원해주는 분해이기 때문에 모든 과정까지는 아니더라도 직전 얼마만큼 또는 별도로 설정된 어떤 값들 만큼은 "중간 변화 단계를 저장"해줘야 할 것으로 보입니다. 만약에 듀랑고의 아이템 분해가 하스스톤의 액션 히스토리(상대와 내가 수행한 모든 카드 액션이 왼쪽 바에 기록되는 것)처럼 처음부터 끝까지 모든 레시피 이력을 추적하는 것을 요구한다면, 구현을 위해 어마어마한 DB가 요구되거나 상부의 구현 승인이 떨어지지 않겠죠.

 

따라서 어느 정도 저장할 정보들을 덜어내는 절차가 필요할 것으로 보이는데요, 가장 심플하게 초기값과 현재 상태만 저장하는 것으로 하고 아이템 3.0에서 설명한 "발현되지 않은 속성 정보"라는 것이 중간에 레시피를 통해 심겨지기만 한다면, 디자이너 입장에선 아닐 수 있더라도 적어도 플레이어 입장에서는 예기치 못한 변화, 즉 돌연변이처럼 느껴지게 할 수 있지 않을까 생각됩니다. 그리고 문제 시 됐던 분해 시 되돌려 줄 정보의 경우는, 어차피 모든 정보를 고스란히 Ctrl+Z 해주는 방식은 아닐 것으로 추측되니 별도의 분해를 대비하기 위한 저장 공간을 확보해 두고 그 곳에 분해 시 다시 심어줄 속성 정보만 별도로 관리해도 가능할 것 같습니다. 그리고 마치 필요한 데이터를 쿼리를 통해 DB에서 추출하는 과정처럼, 분해 역시 역(逆) 레시피를 통해 지정된 속성들만 꺼내서 복원시켜준다면, 모든 히스토리를 저장하지 않아도 적정 수준의 되돌림을 구현할 수 있지 않을까 생각됩니다.

 

 

 

마무(으)리

 

여기까지가 제가 듀랑고의 디자인 강연 발표들을 토대로 이해하고 추측해 본 아이템의 구성과 가공 구조입니다. 어디까지나 제한된 정보를 토대로 추리에 가까운 형태로 재구성한 내용들이기 때문에 실제 구현 내용과 많은 차이가 있을 수 있겠지만, 이런 방식의 매커닉을 한번 쯤 디자인해보고 싶다는 생각을 해본 게임 디자이너가 비단 저 뿐만은 아닐 거라는 생각이 듭니다. 이와 관련하여 다른 디자이너 분들은 어떤 생각들을 가지고 계신지 무척 궁금하네요. =)

무척이나 두서 없는 글이었지만 굳이 결론을 세 줄 요약해보자면...

 

 

 

 

1 듀랑고 빨리 출시해주세요,

 

2 현기증 난단 말이에요

 

3 엉엉

 


WRITTEN BY
zerasion
디자이너의 의도는 플레이어의 의미가 된다.

,