• Announcements

    • Zerasion

      GDF 기본 공지 사항   2017년 11월 23일

      이전 (phpbb & Ruby를 쓰던) GDF에 올라왔던 공지사항들을 새 형식에 맞게 수정했습니다.   인벤과 GDF에 대하여 일단, 도메인 주소에서 보실 수 있듯, 이 포럼은 인벤 (inven.co.kr) 에서 제공하는 서버를 통해 돌아갑니다.
      그러나 회원 DB나 운영은 완전히 별개로 독립되어 있습니다. 
      즉 인벤 아이디로 GDF에 로긴하거나, GDF 아이디로 인벤에 로긴하는 등의 일은 불가능합니다. 
      아울러 운영진 또한 인벤직원이 아닙니다. 
      이는 즉 인벤과는 전혀 다른 운영정책을 취하고 있다는 의미입니다. 
      행여나 이 포럼에서 생긴 일에 대한 문의나 요청이 인벤측으로 가거나, 
      반대로 인벤에 대한 문의 또는 요청을 이쪽에 주셔도 저희로서는 어떻게 해드릴 수가 없습니다.
      혹시나 도메인 주소 때문에 오해하시는 분들이 있을까봐 부연합니다.   GDF의 취지 게임 개발자의 역할을 나누는 데는 여러 방법이 있지만, 최근 한국의 게임업계에서는 디자이너, 프로그래머, 아티스트 중심의 구분이 어느 정도 보편적으로 자리 잡았습니다. 하지만 실력 있는 프로그래머, 실력 있는 아티스트에 대한 평가 기준과 거기까지 도달하는 방법론이 비교적 뚜렷한 것과는 달리, 어떤 게임 디자이너가 유능한 디자이너이며 그렇게 되려면 어떤 노력을 해야 하는지에 대해서는 아직까지 수많은 이견이 있을 뿐입니다. 물론 팀의 성향과 개발 여건에 따라 게임 디자이너에게 요구되는 소양은 타 직군에 비해 다양할 수 있습니다. 재미있는 아이디어를 뽑아내는 창의력, 다른 파트와 유연하게 소통하는 커뮤니케이션 능력, 누구나 이해하기 쉬운 문서를 만들어 내는 능력 등은 때로 가장 중요하게 손꼽히기까지 합니다. 그러나 게임 디자이너가 자신의 전문 분야로 삼아야 할 것은 무엇보다 '게임 디자인 능력' 이라 할 수 있겠습니다. 재미있는 게임을 디자인 해내는 능력이야말로 기본이자 필수입니다. 그러나 정작 '어떻게 해야 게임 디자인을 잘 할 수 있는지' 공부하는 길은 그리 만만하지 않습니다. 애초에 '어떤 것이 잘한 게임 디자인인지' 판단하는 것부터도 어렵습니다. 물론 찾아보려 마음 먹는다면 생각보다 많은 정보 더미를 얻을 수야 있겠습니다만, 그것은 말 그대로 건초에서 바늘 찾기입니다. 인터넷만 뒤져본다고 얻을 수 있는 것도 아닙니다. 그 정보들은 누군가의 하드디스크에, 어딘가의 클라우드 서버에, 때로는 오직 인쇄된 문서로만 존재하니까요. 그리고 아마, 가장 중요한 정보들은 수많은 게임 디자이너들이 '내가 이 삽질을 다시 하나 봐라!' 하고 결심하는 그 순간의 뇌리에만 존재할 겁니다. 빠르게 변하는 현대 사회 중에도 최고의 속도를 자랑하는 이 업계에서는, 분명 많은 유저에게 재미를 주던 검증된 게임 매커니즘도 불과 몇 년 사이에 닳고 닳아 진부한 것이 되기 일쑤입니다. 또한 잘 만들어진 게임일수록 그 안의 모든 시스템이 유기적인 관계를 맺고 있어, 몇 개의 디자인 장치를 떼어내 다른 게임에 갖다 붙인다 해서 성공적인 결과가 나오지 않습니다. 결국 이 모든 일은 게임 디자이너들에게 끊임없이 공부할 것을 요구합니다. 무얼 공부해야 할지, 어떻게 공부해야 할지는 사실 막막한 상황에서 말입니다. Game Design Forum은 그런 상황에 대한 하나의 방법론으로 만들어졌습니다. 이 곳에서 게임 디자인에 대해 공부하고 싶은 내용을 함께 나눌 수 있으면 좋겠다고 생각합니다. 눈에 잘 띄지 않는 멋진 게임 디자인 자료들을 찾아내어 공유하고 싶습니다. 자기만의 디자인 노하우나 경험담이 있다면 서로 나누고 싶습니다. 딱히 정답을 찾아내진 못하더라도, 서로 대화를 나누고 토론하는 과정에서 배우는 뭔가가 있을 것입니다. 그런 일을 하기 위해 마련한 자리입니다. 그래서 이 곳은 무엇보다 "게임 디자인"에 대해 토론하고 대화하는 공간이 되었으면 합니다. 이와 비슷한 취지로 만들어졌던 많은 커뮤니티들이 결국 게임 디자인에 대한 이야기에서 게임 개발 전반, 산업 전반에 관한 이야기로 옮겨가는 것을 보았습니다. 물론 게임 디자인 역시 게임 개발의 일부인 이상 그런 화제들을 아예 배제할 수는 없을 겁니다. 그러나 일단 이 곳에서 활동하시는 여러분께서 "GDF는 게임 디자인에 관해 이야기 나누는 곳" 이라는 사실을 분명하게 인지해 주신다면 이 곳의 정체성이 흔들리는 일은 없지 않을까 합니다. 언제나 그 점 기억해 주시면 감사하겠습니다. 지켜주세요 – GDF 사용 규칙 이 포럼을 사용하기 위해 숙지하고, 지켜주셔야 할 규칙들입니다. 
      다소 딱딱하게 느껴질 수도 있지만, 가능한한 최소화하려 노력했는데도 이정도네요. 
      이 규칙들을 의도적으로 또는 과하게 어겼다고 판단되면 적절한 조치를 취할 수도 있습니다. 
      잘 지켜주시면 감사하겠습니다. 1. 게시판의 용도를 지켜주세요.
      각 카테고리에 대한 간략한 설명입니다. Purple Board
      Green/Blue 에서 관리자가 추천하는 게시물이 옮겨진 게시판입니다.
      비회원을 포함한 모두가 읽을 수 있으며, Purple Panel(관리자)만 글을 작성할 수 있습니다. 댓글을 작성할 수 없습니다. Blue Board
      관리자에 의해 승급된 Blue Panel들이 게시물을 작성할 수 있는 게시판입니다.
      비회원을 포함한 모두가 읽을 수 있으며, Blue Panel들만 글을 작성할 수 있습니다. Green Board
      회원 가입 후 인증이 완료된 Green Panel들이 게시물을 작성할 수 있는 게시판입니다.
      비회원을 포함한 모두가 읽을 수 있으며, Green Panel들만 글을 작성할 수 있습니다. Free Board
      잡담 게시판입니다.
      비회원을 포함한 모두가 읽을 수 있으며, 모든 Panel 글을 작성할 수 있습니다. To GDF  운영진에게 부탁하고 싶은 내용, 궁금한 점, 건의 사항 등을 여기에 적어주세요. 
      비회원을 포함한 모두가 읽을 수 있으며, 모든 회원이 글을 작성할 수 있습니다.
      게시판의 의도와 관계없는 게시물은 운영진에 의해 적당한 다른 게시판으로 옮겨지거나 삭제될 수 있습니다.   2. 게시판 예절을 지켜주세요.
      게시판 이용자간에 서로 지나치게 적대적인 태도는 피해주세요. 
      존댓말을 기본으로 하며, 서로 아는 사이라 해도 반말의 사용을 자제해 주세요. (잡담 게시판 예외)
      물론 외부의 글을 옮겨오는 등의 경우에 불가피하게 평어체로 작성된 글은 무방합니다.   3. '포럼처럼' 사용해주세요.
      이곳이 다른 게시판이 아니라 굳이 '포럼' 의 형태를 취하는 이유는, 포럼의 기능을 잘 활용하기 위해서입니다. 
      다음과 같은 내용들을 염두에 두시면 됩니다.
      하나의 이슈에 얽힌 이야기는 하나의 글타래로만 다룹니다. 
      새로운 글타래를 매번 새로 만드실 필요가 없습니다. 꼭 댓글 형태로 달아주세요. 
      댓글을 아주아주 길게 달 수도 있으니 부담없이 이용하시기 바랍니다.
      새 글타래를 만들기 전에 검색을 해보시는 것도 좋습니다.
      이 사항이 지켜지지 않을 경우 강제로 게시물이 이동/삭제될 수 있습니다. 유의하세요.
      너무 오래 전에 올라온 글이라 의견을 달아도 아무도 보지 못할 것 같은가요? 
      이 포럼은 가장 최근에 댓글이 달린 게시물을 자동으로 최상단에 올려줍니다.
      아주 오래 전 이슈를 다시 언급하는 경우에도 새 글타래를 만드실 필요가 없어요.
이 글을 팔로우하기  
팔로워 0
Zerasion

[아카이브] 가죽 장화를 통해 추리해 본, 듀랑고식 아이템과 가공

1 post in this topic

개인 블로그에 포스팅한 듀랑고의 아이템과 가공 구조에 대한 글을 포럼에 옮겨봅니다.

블로그 원문 주소: http://zerasionz.tistory.com/73


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


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

1. 가죽 장화

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

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

 

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

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

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

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


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


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

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


1f24b461db6030de.png
[두들갓 조합식 화면]

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

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


5d94e181c291c216.jpg
[몬스터 헌터 장비 스킬 테이블 화면]

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

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

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

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

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


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

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


749ee6e42052d124.png
[상태전이 테스팅 모델 예시]

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

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

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

인용

 

1) 생성 조건을 파악한 뒤 조건에 맞는 아이템 초기값을 제너레이팅 (생성)

2) 각각의 레시피들이 초기값을 변경하거나 새로운 정보를 더하거나 기존의 정보를 뺌. (가공)

 


3cd40d55a3e66760.gif
[하스스톤의 게임 화면]


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


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

4. 고민해볼 내용들

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

1) 가공 구조의 규격화

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

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

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

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

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

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

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

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

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

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

인용

 

레시피 ID

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

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

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

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

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

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

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

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

 



정도네요.

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

2) 변수의 저장 방식

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

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

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

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

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

마무(으)리

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

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

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

2 현기증 난단 말이에요

3 엉엉

95d121092a01b862.jpg

0

Share this post


Link to post
Share on other sites
이 글을 팔로우하기  
팔로워 0