인벤토리 최대 한도보다 더 많은 아이템을 받을 때 처리

한동안 남 일 같지 않다, 요구사항이 불분명한 프로젝트의 일생, 달성되지 않은 목표에 대한 위기관리 같은 약간 어두컴컴한 이야기를 하느라 마음도 어두컴컴해진 것 같으니 오랜만에 이런 이야기 대신 게임디자이너들을 골치 아프게 만드는 간단한 문제를 한번 생각해봅시다.

게임에 인벤토리의 존재를 처음으로 정의해야 한다면 아마도 개발 전체로 보면 꽤 초반일 겁니다. 초반에는 흔히들 전투라고 부르는 코어 메커닉을 정립하느라 나머지 부분에는 딱히 신경 쓰지 않을 가능성이 높고 또 팀 빌딩 이전 단계에는 게임디자이너도 엔지니어도 모두 코어 메커닉을 위한 인력을 때가 많아 극 초반 두어 마일스톤을 보내 대강 게임에 레벨도 있고 레벨 위를 캐릭터들이 걸어다니고 또 자기들끼리 싸울 수도 있지만 아이템 비슷한 것도 없는 상황은 쉽게 일어납니다. 그런데 대강 상대 플레이어도 있고 몬스터도 있고 이들이 멀쩡한 레벨 위를 걸어다니는 것처럼 보이면 아직 이거 말고는 아무 것도 없다는 사실을 좀처럼 인지하지 못하는 스폰서로부터 난데없이 던전 플레이를 만들어 보자는 마일스톤 목표가 튀어나오기 일쑤입니다. 몬스터는 아직 제자리에서 로밍하다가 범위 안에 들어온 플레이어에게 돌진해 아무 스킬이나 난사하는 수준이고 던전 안에 조작 가능한 것은 아무 것도 없으며 심지어 던전을 클리어 해도 이 레벨을 던전이라고 정의할 수 있는 아무 기능도 없지만 당장 던전 한 바퀴를 돌고 나면 아이템을 얻고 이를 통한 최소한의 성장 기능을 만들어내라는 목표를 받으면 당황스럽긴 하지만 어쨌든 개발을 시작할 수밖에 없습니다.

지금까지 코어 메커닉에 집중하느라 그 나머지 부분이 어떻게 만들어져 있는지 살펴본 적도 없던 사람들이 부랴부랴 게임의 나머지 부분을 어떻게 만들기 시작할지 살펴보기 시작할 겁니다. 그 사이에 게임디자인 조직에서 할 일은 기존 테스트에 사용하던 레벨과 이번에 새로 제작할 던전 레벨 사이를 구분하고 이들 사이의 대략적인 기능 차이를 정의하는 것, 그리고 몬스터가 죽을 때 드랍하기 위한 아이템의 존재, 그리고 플레이어 별로 아이템을 받기 위한 인벤토리의 존재와 최소한의 동작을 정의해야 합니다. 좀 더 전통적인 조직에서 일했던 사람이라면 기획서 첫머리에 ‘아이템이란 무엇인가’ 같은 개인적으로는 매우 철학적이고 또 형이상학적이라고 생각하는 챕터 이름을 쓰기 시작할른지도 모르고 또 그런 조직에서 생산된 기획서를 본 적도 있지만 개인적으로는 ‘선수 끼리 어차피 뻔히 아는’ 항목을 쓰느라 시간을 낭비할 필요는 없다고 생각하는 입장입니다. 이런 입장이 장기적으로는 처음으로 일을 시작하는 스탭들을 곤경에 빠뜨릴 가능성이 있다는 사실을 알고 있지만 당장 한 마일스톤 안에 코어 메커닉조차 아슬아슬하게 돌아가는 빌드에 던전을 넣고 몬스터가 아이템을 드랍하고 던전을 클리어 하면 보상을 받는 단계까지 개발해야 하는 상황에 팀 빌딩이 어느 정도 마무리 된 다음에 일어날 일을 신경 쓰는 것은 적절하지 않다고 생각합니다.

그러면 문서를 읽는 사람들이 당연히 다른 게임에 나타나는 아이템 개념, 주로 사용되는 형태, 아이템 기능을 지탱하기 위해 필요한 보상 설정과 실행 기능, 그리고 보상을 플레이어가 가질 수 있게 해 주는 인벤토리 기능이 필요하다는 최소한의 공감대는 있다고 가정하고 필요한 기능을 정의하기 시작합니다. 온라인 MMO 게임에서 플레이어가 자신이 인게임에서 획득한 자산을 저장하는 방법에는 여러 가지가 있지만 가장 근본적으로 아이템이 있습니다. 인게임에서 아이템은 종류에 따라 다양한 가치를 가지고 또 여러 다른 가치 사이에 전환을 위한 매개로 동작합니다. 좀 더 간단하게 이야기하면 아이템은 게임의 표준 가치 저장 매체라고 할 수 있습니다. 여기서 표준이란 지금 당장은 인벤토리에 한 칸을 차지하거나 한 칸에 여러 개로 쌓일 수 있고 몬스터가 아이템 단위로 보상을 드랍하며 던전이나 기타 컨텐츠를 클리어 할 때에도 아이템 모양으로 보상을 전달하고 또 미래에 게임에 생길지도 모르는 거래소 같은 교환 시스템에도 현재와 똑같은 모양으로 사용될 수 있음을 의미합니다. 초창기 MMO 게임은 게임에 통용되는 화폐나 입장권 같은 것들도 아이템 모양을 유지하며 인벤토리에 나타나고 또 다른 아이템과 완전히 같은 모양으로 처리하곤 했습니다. 시간이 흐르며 골드, 입장권, 다이아 같은 나머지 아이템과는 다른 방식으로 처리해야만 하는 요구사항이 생기며 이들을 아이템으로 분리해 ‘재화’라는 별도 형태로 개발하기 시작하면서 MMO 게임에서 자산을 저장하는 근본적인 방법으로 기존 아이템 뿐 아니라 재화 형태가 추가됩니다.

골드를 초창기 MMO 게임처럼 쌓을 수 있는 아이템과 똑같은 형태로 처리하다가 이런 아이템을 아이템이 아닌 별도의 숫자로 처리하는 쪽으로 방향이 변경된 이유는 ‘행동력’처럼 특정 행동을 하면 감소하고 일정 시간이 지날 때마다 충전되면서도 최대 수량에 도달하면 더 이상 충전되지 않는 식으로 완전히 별도의 규칙이 나타났기 때문입니다. 여전히 행동력을 아이템 모양으로 유지하며 같은 규칙을 적용할 수도 있었겠지만 인벤토리에 있는 아이템은 온갖 예외를 일으킬 수 있습니다. 가령 한때 MMO 게임에서 아이템을 필드에 떨어뜨려 버릴 수 있었는데 이는 실제 세계의 규칙과 완전히 동일해 이해하기 쉬워 초창기에는 이 규칙이 당연했지만 여러 플레이어가 공존하는 필드에 아이템을 버리기 시작하면 주변의 모든 플레이어에게 이를 전파하느라 서버와 클라이언트에 부하를 유발했고 또 아이템을 소유권이 없는 상태로 필드에 내려 놓을 수 있다는 규칙 자체가 해결하기 어려운 온갖 이상한 문제를 일으켰습니다.

가령 몬스터가 드랍한 보상을 획득하려 할 때 인벤토리가 가득 찬 상태여서 잠깐 아이템을 정리하기 위해 바닥에 아이템을 내려 놓는 사이 주변을 지나가던 다른 플레이어가 바닥에 떨어진 아이템을 주을 수 있었는데 이 역시 실제 세계의 규칙과 동일한 어떻게 보면 당연한 동작이지만 이런 일을 당한 고객 입장에서는 경찰을 부를 수도 없는 세계에서 이런 경험은 게임에 대한 나쁜 감정을 만들기에 충분합니다. 게다가 인벤토리에 아이템 모양으로 들어 있는 행동력을 규칙에 따라 수량을 증가 시키고 또 최대 수량에 도달하면 제거하는 규칙은 고객이 인벤토리에서 행동력 아이템을 건드릴 수 있게 되는 순간 행동력의 무결성을 보장할 수 없게 됩니다. 가령 행동력이 충전되려는 그 순간 잠시 행동력 아이템을 바닥에 내려 놓았다가 행동력이 충전된 다음 아이템을 다시 획득하면 어떻게 될까요?

게임 상의 자산을 아이템 모양으로만 나타내기에는 규칙이 충분히 복잡해지며 별도의 규칙을 사용하는 숫자들의 모음 모양으로 만들기로 결정했는데 이를 흔히 재화라고 부릅니다. 재화는 아이템이 아니어서 인벤토리에 나타나지 않지만 별도의 인터페이스를 통해 그 수량을 볼 수 있고 게임 규칙에 따라 숫자가 증가하거나 감소합니다. 가령 유료로 충전한 다이아는 과거에는 인벤토리에 들어 있던 골드처럼 아이템 모양으로 인게임에 저장할 수도 있었겠지만 아이템 모양이 호환되는 온갖 메커닉에 의한 의도하지 않은 동작을 일으킬 수 있어 재화로 처리합니다. 특히 유료 재화는 인게임에서 이와 똑같이 생긴 재화를 지급할 때 유료로 구입한 재화와 무료로 제공한 재화를 구분하기 위해 반드시 아이템과는 별도의 규칙으로 처리해야 하기도 합니다. 더이상 아이템이 아니기 때문에 앞에서 소개한 행동력을 규칙에 따라 충전하고 사용하면서도 의도하지 않은 동작을 걱정할 필요가 없게 됐고 또 다이아 사례처럼 유료 재화와 무료 재화를 내부에서 구분해 처리하며 유료 고객들을 보호할 수도 있게 됩니다. 그래서 개발 초창기에 아이템 개념을 정의하고 이를 지급하고 획득하기 위한 보상과 인벤토리를 정의하다 보면 자연스럽게 재화를 함께 개발하게 되었습니다. 몬스터가 죽을 때 들고 있던 무기만 드랍한다면 아이템만으로 충분하지만 여기에 골드를 추가로 드랍하는 순간 아이템만으로는 처리할 수 없어 재화를 함께 정의해야 합니다. 하지만 급하면 재화를 따로 개발하기 전까지는 임시로 골드를 아이템 모양으로 처리하기로 협의하면 재화를 정의하고 개발할 시간을 벌 수 있으니 재화에 대한 이야기는 나중에 하기로 하고 일단 아이템과 인벤토리에 집중해 보겠습니다.

인벤토리 기능을 정의하려 할 때 게임디자이너가 받게 될 가장 곤혹스러운 질문은 인벤토리 크기에 제한이 있는지 일 겁니다. 아이템 하나가 인벤토리에 여러 칸을 차지하는지, 아이템에 무게 개념이 있는지, 아이템을 바닥에 버릴 수 있는지 같은 질문은 이미 이 단계에 도달하기 전에 대체로 게임의 특성에 따라 설명할 수 있습니다. 가령 아이템 하나가 인벤토리에 여러 칸을 차지하는 규칙은 실제 세계의 규칙과 비슷해 오래된 게임에 종종 사용되었지만 현대에 가까워지며 인게임 규칙이 실제 세계의 규칙을 따를 필요가 없고 또 아이템 획득과 사용 외에 ‘정리’라는 명시적인 행동을 요구하지만 이 행동이 고객이 게임에 관심 있어 하는 어떤 변화와도 무관해 더 이상 아이템 하나가 인벤토리의 여러 칸을 차지하도록 만들지 않고 있습니다. 아이템을 바닥에 버릴 수 있는지 여부 역시 과거에는 실제 세계의 규칙을 모방하느라 현대 관점으로 볼 때 개발자의 게임 내 재화 흐름에 대한 통제력을 상실하게 만들고 또 의도하지 않은 부하를 일으키며 인벤토리 안에 있는 아이템의 수량을 제어하려고 할 때 의도하지 않은 동작을 하게 만드는 대신 간단히 인벤토리를 비우고 싶으면 즉석에서 비가역적으로 아이템을 파괴하게 만들고 있어 답변하기 어렵지 않습니다.

또 아이템에 무게 개념이 있는지 여부는 지금까지 설명한 오래된 관습에 비해 가장 오랫동안 살아남은 편이지만 이 역시 현대적인 개념으로 보기는 어렵습니다. 무게 개념은 역시 실제 세계의 규칙과 동일해 받아들이기 어렵지 않고 또 물건에 따라 아주 무거워 인벤토리가 비어 있음에도 이 아이템 하나를 들면 더 이상 아무 것도 들 수 없는 설정은 흥미롭기는 하지만 고객 입장에서 직관적이지 않습니다. 인벤토리가 텅텅 비어 있는데 무게 제한으로 아이템을 받을 수 없는 상황은 시각적으로 텅텅 빈 인벤토리와 그 밑에 작은 숫자로 표시된 무게 제한의 조합으로 나타날텐데 과거에는 고객이 이런 상황에서 직관적으로 무게 초과를 인지하고 적절한 조치를 취할 수도 있었겠지만 현대에는 텅텅 빈 인벤토리 이외의 정보는 고객을 크게 실망하게 만들 수 있습니다.

하지만 인벤토리 크기에 제한이 있는지는 다른 질문들과 달리 당장 결정하기 어려울 수 있습니다. 가령 과거에는 인벤토리 크기에 제한이 있어 일정 시간에 걸쳐 플레이 하고 나면 인벤토리를 가득 채운 아이템을 정리하기 위해 마을에 돌아가는 행동을 의도하기도 했습니다. 그래서 인벤토리 크기를 늘리거나 줄여 게임 템포를 변경해 가벼운 던전은 여러 번 돌 수 있지만 좀 더 본격적인 던전은 출발하기 전에 인벤토리를 비우도록 강제할 수도 있었습니다. 하지만 이런 방식은 시간이 지나며 고객들이 한 가지 목표에 집중하는 플레이를 크게 방해하게 됩니다. 가령 특정 성장 재료를 모으기 위해 이 재료를 드랍하는 던전을 반복해서 도는 상황에서 인벤토리가 잡다한 아이템으로 가득 찼다는 이유만으로 마을에 돌아가야만 할 때 고객은 큰 실망을 느낄 수 있습니다. 과거에는 몬스터가 아이템을 바닥에 드랍했기 때문에 목적으로 삼지 않은 아이템은 먹지 않을 수도 있었겠지만 아이템을 바닥에 버리지 않으면서 자잘한 아이템은 알아서 획득하는 규칙을 적용하면서 그럴 수도 없게 됐습니다. 때문에 한때 인벤토리를 영구적으로 확장하는데 과금하기도 했지만 이는 고객이 실망하는 시점을 낮출 뿐 근본적인 상황을 개선하지 못하며 인벤토리를 최대한 확장한 고객에게는 돈 내고도 기분이 나쁜 이상한 상태를 만들게 됩니다. 또 게임에 따라서는 처음부터 반복 파밍을 요구하는 상황에 균열 끝의 대장장이처럼 반복 플레이를 끊지 않고 인벤토리를 정리할 간단한 장치를 제공하기도 합니다. 여기까지 따라오신 분들이라면 현대에 인벤토리 칸 수를 어느 정도로 제한해야 할 지 결정하기 꽤 난감하다는 점을 납득하실 수 있을 겁니다.

지금까지의 맥락에 핵심은 과거에는 실제 세계의 동작으로부터 힌트를 얻은 규칙을 별 생각 없이 게임에 적용했고 고객들 역시 이 규칙을 받아들였지만 시간이 흐르며 게임 규칙이 복잡해져 실제 세계의 규칙에 기반한 기능만으로는 게임을 통제하기 점점 더 어려워졌고 고객들 역시 가상 세계의 규칙을 받아들이는데 점점 더 익숙해져 실제 세계의 동작과는 전혀 다른 가상 세계의 동작에도 잘 적응하게 됐다는 점입니다. 이런 관점에서 개인적으로는 현대 MMO 게임에 플레이어 각각의 인벤토리 크기 제한은 더 이상 의미가 없다는 입장입니다. 인벤토리 크기 제한은 딱히 인벤토리 확장에 돈을 지불하게 만들어도 매출에 별 의미를 가지지 못하는 수준이고 앞에서 설명한 대로 돈을 낸 고객들을 기분 나쁘게 만들 수 있으며 플레이 템포를 조절하는데 기여하지도 못합니다. 이런 관점에서 MMO 게임을 바닥부터 만들며 아직 게임의 큰 규칙들이 정의되기 이전일 때 인벤토리 크기는 이론적으로 제한이 없어야 한다고 생각합니다. 어차피 수량이 훨씬 많고 또 다양한 통제 규칙을 적용 받는 요소들은 인벤토리에 넣는 대신 재화 모양으로 처리하고 인벤토리 크기를 확장해 매출에 기여하지도 않으며 인벤토리의 빈 공간과 무게를 연관 시키지도 않고 게임 플레이를 계속하거나 잠깐 쉬어 가는 행동을 이끌어내지도 않는다면 인벤토리 크기 제한은 이제 현대적인 MMO 게임에서 아무런 의미가 없습니다. 폴아웃이나 스카이림에 널리 사용하는 모드에 항상 인벤토리 크기 제한을 없애는 기능이 포함되어 있음을 생각해 보면 이런 결정은 자연스럽다고 생각합니다.

물론 게임디자이너의 짧은 언어 실력으로 인해 인벤토리 크기에 제한을 두고 싶지 않다는 말을 ‘인벤토리 크기는 무한해야 한다’고 함부로 말했다가는 엔지니어 조직의 강력한 반발을 마주할 수밖에 없습니다. 분명 게임디자이너는 어지간한 게임 플레이에 인벤토리가 가득 차는 상황을 거의, 전혀 겪지 않도록 해야 한다는 현대적인 관점에서 올바른 요구사항을 수학적으로 엄밀하지 않은 표현을 사용해 말했을 뿐입니다. 하지만 엔지니어들은 수학적으로 엄밀하지 않은 표현을 딱히 수학적으로 받아들이지 않았으면서도 본능적으로 무한, 또는 제한이 없다는 표현에 거부감을 느낄 수밖에 없습니다. 코드를 만들며 선언하는 변수에 해당하는 제한된 메모리 영역은 그 크기에 따라 표현할 수 있는 숫자에 한계가 있고 또 여러 아이템을 기록할 데이터베이스 역시 관계형일 때 물리적으로 선언할 수 있는 칼럼 수자 레코드 수에 한계가 있습니다. 한계 안에서 사용한다 하더라도 실제 수많은 플레이어들의 수많은 아이템을 빠른 속도로 처리할 수 있을지 여부를 장담할 수 없는 상황에서 이런 여러 한계에 근접해야만 할 것 같은 수학적으로 엄밀하지 않은 표현을 들으면 게임디자인의 요구에 협조적으로 나오지 않을 수도 있습니다. 게임디자이너는 수학적으로 엄밀하지 않은 제한 없음을 말했고 엔지니어는 자신을 둘러싼 여러 기술들의 한계에 근접한 큰 크기를 함부로 사용할 수 없음으로 대답했을 뿐이지만 이 요구사항은 서로 기묘하게 와전되어 ‘인벤토리 크기에는 반드시 한계가 있어야 한다’는 당연한 결과를 도출하는데 긴 시간이 걸리게 만듭니다.

이 상황을 해결할 적당한 요구사항은 이전에 경험했던 여느 MMO 게임에 비해 인벤토리가 훠어어어얼씬 커서 어지간하면 인벤토리 크기 제한에 따른 불편을 겪지 않도록 해야 한다는 것입니다. 게임디자이너는 이 요구사항을 달성하기 위해 최대한 큰 숫자를 말하고 싶어할 테니 엔지니어는 데이터베이스 한계 안에서, 그리고 자신의 경험 안에서 말할 수 있는 꽤 큰 숫자를 말하면 됩니다. 여기에 인벤토리는 그 안에 있는 아이템의 종류와 수량, 상태를 짧은 주기로 검사해야 할 수 있으므로 데이터베이스의 한계 안에서 큰 숫자를 말했다가는 서버에 큰 부하를 줄 수 있으니 이를 고려한 적절한 숫자를 말해야 하고 또 짧은 주기로 검사해야만 하는 아이템을 별도로 모아 놓는 ‘퀘스트 아이템 인벤토리’ 같은 개념을 먼저 제안해 거대한 인벤토리 전체를 짧은 주기로 검사하는 불행한 코드를 만드는 상황을 피해야 합니다.

하지만 인벤토리를 개발할 엔지니어가 항상 데이터베이스의 한계, 실시간으로 무난히 검사할 수 있는 인벤토리 크기, 수많은 플레이어들을 동시에 처리할 때 보장할 수 있는 성능에 대한 경험을 항상 가지고 있지는 않으므로 게임디자이너가 큰 숫자를 찍기를 바랄 수도 있습니다. 개인적으로는 기술적으로 가능한 큰 숫자를 엔지니어가 결정해줬으면 싶지만 엔지니어 역시 규모를 예측하기 어렵고 또 자신의 결정을 책임지기를 원치 않을 수 있으니 이럴 때 게임디자인에서 무책임한 큰 숫자를 부르면 일단 이에 맞춰 개발하고 미래에 문제가 생기면 일단 책임을 게임디자인에 떠넘긴 다음 상황을 해결하는데 집중할 테니 그리 나쁜 딜은 아닙니다. 게임디자인에서는 인벤토리 크기 치고는 꽤 큰 숫자처럼 보이는 1000 정도를 제안하겠습니다.

하지만 인벤토리 요구사항을 정의하는 일은 이걸로 끝나지 않습니다. 게임디자인의 의도는 인벤토리 크기가 아주 커서 고객이 게임을 플레이 하는 도중 인벤토리가 가득 차 플레이가 중단되는 상황을 만들지 않는 것입니다. 이 의도에 기초하면 사실상 인벤토리에는 한때 사용되던 아이템을 바닥에 버리는 기능을 대신하는 아이템을 영구적으로 파괴하는 기능을 넣을 필요조차 없고 이 기능을 위한 작디작은 버튼이 들어갈 영역을 확보할 수도 있으며 아이템을 영구적으로 파괴하기 위해 고객에게 여러 번 확인을 거칠 필요도 없고 실수로 중요한 아이템을 영구적으로 파괴한 고객이 게임으로부터 깊은 실망감을 느낄 필요도 없습니다. 이런 상황을 가정하면 인벤토리가 가득 찰 때 동작을 정의할 필요도 없습니다. 하지만 현실은 그렇지 않으며 앞에서 인벤토리 치고는 꽤 큰 크기인 1000을 제안했음에도 이 크기는 이를 고려하지 않은 게임의 나머지 부분들에 의해 가득 차는 상황을 마주하게 될 겁니다. 또한 엔지니어들은 감사하게도 의심이 병적으로 많은 사람들이어서 인벤토리가 가득 찰 일이 없다는 게임디자인의 말을 절대 신뢰하지 않을 겁니다. 인벤토리 크기가 아무리 커도 언젠가는 가득 차는 상황이 생기며 이를 처리하지 않으면 의도하지 않은 이상한 동작을 할지도 모르니 뭔가 준비해야 합니다. 앞서 인벤토리 크기를 기술적인 관점에서 결정하는 대신 책임소재를 확실히 하기 위해 기술적 제한과 무관하게 게임디자이너가 결정한 것과는 달리 인벤토리가 가득 찬 상황의 처리는 철저히 게임디자인 관점에서 그 동작을 정의해야만 합니다.

재화 시스템에 의해 핵심 보상은 이미 재화로 지급하는 상황이라도 보상을 받아야 하는 상황에서 인벤토리가 가득 차 있다면 이건 꽤 심각한 상황입니다. 한때 인벤토리가 가득 찬 상태에서 아이템을 획득하면 새로 획득한 아이템이 임시 인벤토리에 들어가 일정 시간 동안 유지되며 이 시간 안에 인벤토리를 정리한 다음 아이템을 획득하는 규칙을 사용하기도 했습니다. 하지만 설명을 보면 알 수 있듯 이는 실제 세계의 규칙을 따르기 위해 바닥에 아이템을 내려 놓을 수도 있고 또 몬스터가 드랍한 아이템을 선택적으로 획득할 수도 있는 세계에서 지극히 선택적으로 유효한 동작으로 고객에게 일시적이기는 하지만 그리 편안하지 않은 상태를 만들고 만약 제한시간이 지나 아이템이 사라지면 그 편안하지 않은 상태는 훠어어어얼씬 더 편안하지 않은 상태가 될 겁니다.

만약 개발이 좀 더 진행된 상태여서 현대적인 우편 시스템을 갖추고 있다면 애초에 보상을 지급하기 전에 인벤토리를 검사한 다음 보상을 한 번에 지급할 공간이 부족할 경우 이를 우편을 통해 획득하도록 할 수 있습니다. 종종 무슨 보상이든 우편을 통해 들어온다는 점에 불만을 가지는 고객들도 있지만 우편 시스템은 게임 만드는 사람 입장에서 보상을 지급할 때 일어나는 온갖 이상한 문제를 아주 편안하게 해결해 주는 좋은 접근입니다. 특히 패키지 상품을 구입하고 또 이를 환불 처리할 때 제품의 사용 여부와 환불 처리 범위를 결정하는데 아주 큰 도움을 주고 있습니다. 하지만 앞에서 상황을 정의한 것처럼 이제 겨우 던전 개념을 정의하고 처음 인벤토리를 개발하려고 하는 시점에 우편 시스템이 있을 가능성은 낮습니다.

인벤토리 크기가 크긴 하지만 가득 찰 수 있고 인벤토리가 가득 찬 상태에서 아이템을 획득하기 위한 우편 시스템이 존재하지도 않을 때 이런 상황을 처리할 별도 규칙을 고안하기를 요구 받으면 당황할 수 있습니다. 사용할 수 있는 다른 시스템이 전혀 없기 때문인데 그렇다고 인벤토리가 가득 찬 상태에서 새로운 아이템 획득을 모두 무시하기에는 그래도 될지 확신하기 쉽지 않을 겁니다. 특히 인벤토리가 가득 찬 상태에서 새로운 아이템 획득이 모두 실패한다는 규칙을 정의해 놓으면 엔지니어들 뿐 아니라 게임디자인 조직에서도 온갖 사람들이 이거 괜찮느냐는 질문 해 댈 수도 있습니다. 이런 상황을 생각해 뭔가 그럴싸한 규칙을 만들어야 할 것 같지만 실은 전혀 그럴 필요가 없습니다. 현재 상태가 아직 게임에 코어 메커닉과 최소한의 필드 이외에는 아무런 기능도 없는 상태라는 점을 기억해야 합니다. 근본적으로 인벤토리 크기가 커서 어지간하면 인벤토리가 가득 차는 상황을 겪지도 않겠지만 미래에는 인벤토리가 가득 찬 상태에서도 고객이 보상을 잃지 않도록 할 우편 같은 보조 시스템이 있을 겁니다. 미래에 이를 활용한 규칙을 만들면 됩니다. 개발 초반에는 그저 인벤토리가 가득 찬 상황을 팀 내 테스트 플레이어에게 알려주고 이 상황이 의도에 의해 통제되기만 하면 됩니다. 아직 다른 아무 기능도 없는 상태에서 인벤토리가 가득 찬 상황을 깔끔하게 처리할 멋진 요구사항을 처음부터 고안하기 위해 골치를 썩힐 필요가 전혀 없습니다.

개발 초반에 ‘인벤토리 최대 한도보다 더 많은 아이템을 받을 때 처리’방법을 고안해야 한다면 그냥 쿨하게 인벤토리 한도를 초과한 획득은 모두 실패하되 어떤 방법으로든 팀 내 플레이어에게 이 사실을 알려주는 것입니다. 디버그 문자열을 보여줄 수 있으면 그렇게 하고 혹시 적당한 인게임 메시지 표시 방법이 있다면 이를 사용하면 됩니다. 방법이 이렇게 단순한데도 이렇게 길게 설명한 이유는 종종 주니어 디자이너님들께 이 일을 맡기면 크게 ‘인벤토리 크기가 무한’이라는 점과 ‘인벤토리가 가득 찼을 때 처리’ 방법을 결정하고 협의하는데 어려움을 겪는 모습을 봤기 때문입니다. 사실 ‘무한’은 무한하지 않고 그저 플레이에 영향을 최소화하는 범위 안에서 최대한 큰 숫자를 의미할 뿐입니다. 또한 인벤토리가 가득 찬 상황에 대한 처리는 미래에 다른 보조 수단이 좀 더 개발되었을 때 훨씬 쉽게 처리할 수 있으나 지금 당장은 대 고객 서비스 수준의 깔끔한 처리 방법을 찾아내기는 사실상 불가능합니다. 때문에 그냥 새로 획득하는 아이템의 획득에 실패하고 이 상황이 통제되고 있음을 내부 고객에게 알려주는 수준이면 충분합니다. 처음부터 대 고객 서비스 수준의 불가능한 기능을 고안하려고 시간을 낭비할 필요가 없습니다.