퀘스트 시스템에 대한 다른 접근
개인적으로는 신처럼 동작하는 퀘스트 시스템을 설계하기를 더 좋아하지만 완전히 반대 관점으로 설계된 시스템을 보고 영감을 얻었습니다.
비슷한 장르 게임을 여러 번에 걸쳐 만들다 보니 게임마다 비슷한 기능을 여러 번에 걸쳐 만들게 됩니다. 가령 게임들이 온라인 멀티플레이 환경으로 옮겨 간 초기부터 채팅이나 파티 같은 커뮤니티 관련 기능은 게임이 조금씩 달라짐에 관계 없이 거의 비슷한 형태로 들어가곤 했습니다. 회사는 이 점에 착안해 채팅, 길드, 파티 같은 여러 게임에 걸쳐 사용될 기능을 별도로 개발한 다음 게임마다 이를 사용하도록 하기도 했습니다. 웹 기반으로 개발된 이 시스템은 기획서를 쓸 필요도 없고 인프라를 준비하거나 게임에 더 어울리는 시스템을 고민할 필요 없이 게임에 어울리는 컬러 스킴을 설정하면 한 주 안에 인게임에서 동작하는 파티, 채팅, 길드 기능을 탑재할 수 있었습니다. 물론 파티나 길드를 활용하는 인게임 상의 경험과 목표에 따라 한계가 뚜렷했지만 언제나 비슷비슷한 오래된 채팅 기능을 매 프로젝트마다 이를 처음 담당하시는 주니어님들을 고생 시켜 가며 개발하는데 비하면 분명 장점이 있는 접근입니다.
게임마다 비슷한 또 다른 기능에는 캐릭터 커스터마이징, 매치메이킹, 인벤토리, 업적 같은 기능도 있습니다. 한동안은 게임마다 서로 다른 구조로 캐릭터를 만들어 어쩔 수 없이 커스터마이징을 각각 개발해야 했고 사실 현대에도 캐릭터 커스터마이징 기능을 각자 개발하고 있지만 현대에 가까워질수록 최소한 인간형 캐릭터는 게임마다 구조가 거의 비슷해져 이론적으로 서로 다른 여러 게임에 걸쳐 거의 같은 수준의 커스터마이징 기능을 제공할 여지가 있습니다. 여러 게임에 걸쳐 제각각 캐릭터 커스터마이징 기능을 개발해야 했는데 항상 이 기능의 정점에 도달한 다른 게임을 따라 하고 싶으면서도 그 게임에서 제공하는 불러오기와 저장, 프리셋, 언두와 리두 같은 보조 기능을 포함할라 치면 ‘굳이 이렇게 까지 해야 할까?’라는 질문을 받곤 합니다. 결국 간신히 체형과 최소한의 물량을 갖춘 의상을 교체할 수 있는 그저 그런 커스터마이징 기능을 개발한 다음 모든 사람들이 이 기능의 존재를 잊어버린 채 인게임 개발에 집중하다가 개발 후반이 된 다음에야 사장님이 꼴 사나운 그 상태를 보고 극대노하신 다음에야 갑자기 중요도가 높아져 이미 개발한 기능은 모두 그대로 두고 에셋 퀄리티에만 집중해 마무리되기도 했습니다.
매치메이킹은 이 기능이 필요한 게임으로부터 다양한 접근이 시도되고 또 그 결과가 멋진 모양으로 널리 공유된 덕분에 이 기능이 충분히 필요하지 않은 장르에서도 이를 도입하려고 하면서 이상한 일을 일으키기도 한 기능입니다. 주로 PvP 메커닉을 포함한 스포츠 장르에서 실력이 비슷한 플레이어들을 같은 게임에 매치메이킹 해 실력 차가 너무 심한 게임으로부터 이긴 사람도 재미 없고 진 사람은 기분 나쁜 상황에 빠지지 않도록 하기 위한 이 기능은 이를 필요로 하는 게임 장르가 상당히 한정됩니다. 이미 말했지만 플레이어들이 서로를 공격하는 PvP 메커닉이 있어야 하고 서로 성장 요소에 의한 유불리가 크게 갈리지 않는 장르일 때 매치메이킹 기능이 필요하고 또 유용합니다. 이런 조건을 만족하는 게임에서는 고객 각각의 실력을 평가하기 위한 여러 지표를 측정해 숫자 하나 혹은 몇 가지 중요한 숫자로 표현한 다음 이들이 동시에 한 게임에 참여하려고 할 때 적당한 수준의 승패 경험을 줄 거라고 예상하는 수준에서 매치메이킹을 수행합니다. 이상적으로는 모든 플레이어의 승률이 0.5에 가까워지는 것인데 이 목표를 달성하기 위해 여러 가지 숫자로 표현된 각자의 실력을 평가해 실력을 측정하는 지표를 개선하기도 하고 숫자를 계산하는 방법, 숫자를 비교하는 방법, 두 명 보다 많은 여러 플레이어가 동시에 게임에 참여할 때 적당한 실력의 범위를 계산하는 방법을 개선해 가야 했습니다.
하지만 항상 개발팀에는 이런 리서치를 진지하게 할 인력의 여유 같은 것은 전혀 없었고 라이브 도중 매 주 수식을 조금 고쳐 한 주 서비스 해보기를 반복할 뿐이었고 또 실험 결과를 분석해 개선할 여유도 거의 없었습니다. 애초에 고객들의 실력을 측정하기 위해 우리가 사용한 방법이 올바른지조차 판단하기 어려웠고 동시에 여러 플레이어가 팀을 이뤄야 하는 상황에서는 유명한 해외 개발자들이 공개한 수식을 가져다 거의 그대로 적용했지만 이게 우리들에게 적절한 방법인지 평가해볼 기회 역시 없었습니다. 각자가 경험하는 승률이 0.5에 근접하게 만드는데 집중한다면 실력 차이에 큰 관계 없이 몇 판을 플레이 한 고객들이 다시 매치메이킹을 시도할 때 항상 승리한 플레이어는 승리한 플레이어들과, 패배한 플레이어는 패배한 플레이어들과 게임을 만들었습니다. 경험에 더 적은 관심을 두면서도 승률을 목표에 근접하게 만드는 일종의 꼼수를 사용해 매치메이킹이 중요하다고 말하면서도 실제로 이를 리서치할 시간은 거의 없는 상황에 대응하기도 했습니다. 또 연승을 기록한 플레이어와 연패를 기록한 플레이어를 의도적으로 실력 차이가 나는 게임에 입장 시키기도 했는데 이는 이론적으로는 괜찮아 보였지만 실제로는 의도대로 동작하지 않았습니다.
이런 접근에는 온라인 멀티플레이 환경에서 플레이어를 조작하는 고객이 언제나 같은 사람일 거라는 가정이 깔려 있는데 고객들은 이 가정을 순식간에 파악해 항상 우리들보다 한 발 이상 앞서 나갑니다. 가령 연승을 기록하면 훨씬 높은 수준의 플레이어와 매치메이킹 된다는 사실을 파악한 고객들은 연승 기록이 유효한 일종의 쿨타임을 파악해낸 다음 계정을 여러 개 만들어 연승에 의해 나쁜 게임 경험을 강제로 제공 받기 직전에 다른 계정으로 전환해 플레이를 계속합니다. 한동안 게임을 플레이 하지 않아 실력이 감소한 고객들도 이전 기록에 근거해 매치메이킹을 하자 이 고객이 이전에 기록한 숫자와 현재의 플레이 사이에 큰 격차가 생겨 연패를 거듭한 다음 게임을 영원히 떠나기도 했는데 이를 반영해 한동안 플레이 하지 않은 고객들은 실력이 감소했을 거라고 가정한 매치메이킹을 수행합니다. 이를 눈치 챈 고객들은 의도적으로 한동안 플레이 하지 않은 계정을 준비해 뒀다가 평소보다 더 많은 경험치, 더 많은 보상을 획득할 수 있는 이벤트 기간이 되면 이 계정을 사용해 시스템이 제공하는 훨씬 유리한 입장에서 보상을 휩쓸었습니다.
하지만 매치메이킹이 가장 골치 아픈 순간은 이 기능이 잘 어울리지 않는 장르 게임에 이 기능을 ‘포함해야만’ 할 때입니다. 위에서 설명했다시피 매치메이킹은 이 기능을 필요로 하고 또 이 기능이 잘 동작하며 잘 동작해야만 하는 장르와 조건이 있습니다. 그런데 적어도 한국에서는 여러 회사에 걸쳐 꽤 비슷한 성장 개념이 있고 각자의 실력이 상대적으로 덜 중요한 장르에 집중하는 경향이 있었습니다. 이런 경향은 강산이 변하는 것 보다 더 긴 기간에 걸쳐 계속되었는데 이런 게임들은 일단 고객이 게임에 오래 머물도록 만들기 위해 성장 개념을 도입해 고객이 게임을 떠나기 전에 자신이 이룩한 성과를 보고 떠날 시점을 뒤로 미루는 의사결정을 하도록 만들었습니다. 또 의도에 따라 게임 속 내 캐릭터를 이동 시킬 수 있는 핵심 조작에 기반해 전투 외에도 온갖 메커닉을 도입해 흔히 백화점식 게임이라고 불리기도 합니다. 이는 특정 장르에 집중하기 보다는 개발 비용이 크고 성공 확률이 낮은 엔터테인먼트 업계 특성 상 기왕 높은 비용을 들이는 김에 최대한 넓은 범위의 고객들에게 관심을 끌기 위한 접근입니다. 이렇게 게임을 만들어 가다 보면 게임의 대부분에서는 매치메이킹 기능이 필요하지 않게 됩니다.
하지만 고객들은 계속해서 성장하고 또 최상위 그룹에서는 개걸스럽게 컨텐츠를 먹어 치워 PvE 환경만으로는 고객들을 더 이상 게임에 묶어둘 수 없습니다. 그래서 최상위 고객들을 위해 게임과 어울리든 어울리지 않든 PvP를 도입해 고객들이 스스로 컨텐츠를 만들어내도록 유도합니다. 만약 다른 장르였다면 쉽게 스포츠 타입 PvP를 고려할 수 있었겠지만 최상위 PvP에 도달하는 동안 계쏙해서 성장해 온 고객들에게 갑자기 지금까지의 성장을 모두 무시한 채 익숙하지도 않은 스포츠 스타일 플레이를 요구하기는 어렵습니다. 이런 이유로 성장 개념이 있는 게임의 최상위 컨텐츠에 함부로 스포츠 타입 메커닉을 도입하면 잘 동작하지 않습니다. 이렇게 PvP 컨텐츠에 각자의 성장 수준이 그대로 반영되고 또 각자의 실력 차이가 있는 난해한 환경에서 매치메이킹을 하려고 하면 여느 게임에서 매치메이킹 규칙을 설계해본 적이 있더라도 풀기 쉽지 않은 문제입니다. 어쩔 수 없이 개발하지만 우리들 스스로도 이 규칙이 잘 동작하지 않으리라는 사실을 이미 이해하고 있습니다.
한편 이렇게 여러 게임에 걸쳐 비슷한 기능을 만들어야 하는 사례에는 퀘스트도 있습니다. 지금까지 설명한 기능들은 종종 게임 장르에 따라 필요하지 않을 수도 있습니다. 매치메이킹은 성장 기반 장르에 잘 맞지 않고 커스터마이징은 캐릭터의 시인성이 중요한 게임에 잘 맞지 않으며 전통의 성장 메커닉은 여러 세션으로 구분되는 게임에 잘 맞지 않습니다. 퀘스트 역시 모든 게임에 잘 맞는 것은 아니지만 흥미롭게도 여러 회사에 걸쳐 퀘스트가 잘 어울리는 게임 장르에 집중한 덕분에 여러 프로젝트에서 비슷한 퀘스트 시스템을 만들어도 항상 게임과 잘 맞는 재미있는 상황이 일어납니다. 초기 퀘스트는 각 퀘스트마다 목표가 딱 하나만 있는 아주 단순한 모양이었습니다. 특정 NPC와 대화하기, 특정 몬스터 잡기, 특정 위치에 도착하기 같은 한 가지 목적을 달성하면 퀘스트를 완료하고 보상을 받았는데 이를 로직을 데이터 모양으로 표현한 간단한 스킬 시스템에 설명한 방식에 따라 엑셀 모양으로 만들면 한 줄에 퀘스트 하나를 만들 수 있어 단순한 퀘스트를 대량으로 양산할 수 있어 좋았습니다. 하지만 이렇게 퀘스트를 만드는 시대에도 여러 플레이어가 모여 알아서 컨텐츠를 만들어 가는 MMO 게임에 퀘스트가 그리 중요하다고 생각하지 않곤 했습니다.
이런 생각은 크게 에버퀘스트와 월드오브워크래프트에서 바뀌었습니다. 특히 월드오브워크래프트는 시작부터 마치 싱글플레이 게임 경험처럼 퀘스트에 의해 플레이어의 경험을 가이드했고 자연스럽게 게임의 주요 규칙, 세계관을 익히고 게임에 머무를 수 있는 수준으로 성장 시킬 뿐 아니라 자연스럽게 엔드 컨텐츠로 인도하는 모습을 보여줍니다. 월드오브워크래프트가 정식 서비스 되기 시작한 다음 몇 년에 걸쳐 출시된 MMO 게임들은 여전히 이런 자연스러운 가이드를 제공하지 못한 채 그 이전 시대의 고객들에게 극도로 불친절한 시스템을 고수했고 자연스럽게 고객 층을 넓히지 못한 채 사라져 갔습니다. 국내에서 개발한 어떤 MMO 게임은 원래 계획에 따라 퀘스트가 없는 모양으로 거의 개발해 출시에 가까워질 무렵 아무리 생각해도 이런 상태로는 시장에서 월드오브워크래프트와 이를 복제한 다른 제품과 경쟁이 불가능하다는 경영진의 판단에 따라 출시를 한참이나 뒤로 미루고 퀘스트가 없던 게임에 퀘스트를 넣기 위해 스토리를 쓰고 또 이를 인게임 경험으로 연결할 퀘스트 시스템을 급조하기도 했습니다. 이 게임은 비슷한 시대에 개발하던 여느 MMO 게임과 비슷하게 첫 마을과 첫 필드를 반복 개발하는데 제작비 상당 부분을 사용하는데 까지는 비슷했지만 막판에 원래 계획에 없던 퀘스트를 추가하면서 또다시 거대한 제작비를 사용해야만 했고 회사가 예측한 제작비를 한없이 초과해 버립니다.
여러 게임이 월드오브워크래프트에 의해 예정에 없던 퀘스트 시스템을 개발하느라 고통 받았지만 MMO 게임에 당연히 퀘스트 기능이 필요하다는 인식을 자리 잡도록 만들어 어느 프로젝트에 가든 퀘스트 시스템을 설계할 일을 만들어 시스템을 개선할 기회를 준 것도 사실입니다. 게임에 따라 조금씩 달랐지만 한 퀘스트는 각각의 작은 목표가 있는 여러 스텝으로 구분되고 각 스텝은 순서에 따라 진행할 수 있습니다. 스텝 각각의 목표는 여전히 과거와 마찬가지로 NPC와 대화하기, 몬스터 잡기, 아이템 얻기, 지정한 위치에 도달하기 같은 단순한 것들이었습니다. 조금 더 욕심을 부린 프로젝트들은 여기에 웨이브 막기, 보스 처치, NPC 호위 같은 좀 더 개발 난이도가 높은 목표를 제안하기도 했는데 웨이브나 보스는 그럭저럭 멀티플레이 환경에서 돌아가도록 만들 수 있었지만 호위 목표는 대체로 멀티플레이 환경에 대한 이해가 낮은 스탭들로부터 제안되어 이 요구사항을 달성하기 위한 설계를 고안하는 사람인 저를 고통스럽게 만들곤 했습니다. 사실 현대에는 MMO 게임의 어지간한 퍼시스턴트 환경이라도 개인화된 퀘스트 환경을 자연스럽게 제공해 멀티플레이 환경에 대한 이해가 별로 없는 컨텐츠 디자이너로부터 나온 요구사항을 그럴듯하게 달성할 수 있지만 월드오브워크래프트가 그들이 처음은 아니었지만 본격적으로 인스턴스 개념을 적극적으로 사용하기 전에는 심지어 던전 마저도 퍼시스턴트이던 상황에서 NPC 호위, 필드에서 특정 조건에 따라 스폰되는 몬스터 처치 같은 요구사항은 정말 수용하기 쉽지 않았습니다.
시간이 흐르며 완고하던 서버 개발자들도 퍼시스턴트 환경의 개인화, 인스턴스에서 좀 더 강한 환경 변화와 연출을 받아들이며 퀘스트 시스템 역시 어느 정도 표준화 됩니다. 이제 퀘스트 하나는 어떤 완결된 작은 스토리를 설명하기 위한 용도에 할당되고 이를 구성한 스텝 각각은 스토리를 진행하기 위한 수단으로 활용됩니다. 또 프로젝트에 따라 스텝 하나에 여러 목표를 순서대로, 또는 순서에 관계 없이 수행하도록 해 퀘스트 하나의 스토리 진행을 크게 해치지 않으면서도 가까운 목표부터 차례로 수행하거나 순서대로 목표를 수행하다 보면 자연스럽게 동선이 연결되는 경험을 만들 수 있게 됐고 이 정도 수준이 업계 표준으로 자리잡습니다. 퍼시스턴트와 인스턴스 곳곳에 흩어져 있는 퀘스트 대상을 가리키는 방법도 이전에 비해 훨씬 정교해져 이전에는 그저 대상의 인스턴스화 되지 않은 일종의 템플릿 구분자를 가리켜 세계 전체에 그 대상은 단 하나만 있어야 하는 제한이 있을 때도 있었습니다. 가령 어느 마을 촌장님과 대화한다면 엑셀 데이터시트에 있는 촌장님의 NPC 아이디인 128번을 스텝 목표로 설정한다면 이 128번 NPC는 이 세계에 오직 한 명만 있어야 합니다. 만약 같은 촌장님이 세계에 두 명 있다면 플레이어는 어느 쪽 촌장님과 만나도 퀘스트가 진행되어 이상한 경험을 하게 될 수 있습니다.
이런 제약은 세계 전체가 퍼시스턴트로 구성되어 있을 때는 아무 문제도 없었지만 세계 곳곳이 개인화되고 또 인스턴스화 되면서 같은 128번 NPC가 서로 경험 시점이 다른 여러 공간에 위치하기 시작했는데 이를 위해 서로 다른 시공간에 있는 같은 NPC를 가리킬 개선된 방법이 필요했고 퀘스트 데이터 상에서 런타임에 인스턴스화 될 NPC 각각을 가리킬 수 있는 방법이 고안됩니다. 때때로 이런 방법이 이미 고안되어 다른 프로젝트에 널리 사용되고 있음에도 서로 다른 여러 시공간에 있는 촌장님을 서로 다른 NPC로 만들어 각각을 퀘스트에서 사용하도록 고집하는 프로젝트도 있었는데 이는 전통의 구현 방법을 그대로 사용할 수 있는 장점이 있었지만 데이터를 입력하는 게임디자인 입장에서 같은 촌장님을 데이터 상으로 여러 명 만들어 관리해야 했고 또 외형이나 동작이 똑같은 촌장님을 각각 분리해 정확한 장소에 정확한 촌장님을 배치해야 해서 직관적이지 않아 실수 여지가 많았습니다.
이렇게 조금씩 발전해 오던 퀘스트 시스템은 크게 코드를 작성하기 어려운 게임디자이너들이 퀘스트를 양산하도록 하기 위한 로직의 데이터화, 그리고 겉으로는 MMO 게임처럼 보이지만 근본은 매니지먼트 장르여서 고객이 캐릭터를 직접 조작해 플레이하기를 선택적으로 요구하는 게임의 등장으로 양상이 크게 바뀝니다. 퀘스트를 본격적으로 도입하던 초기에는 퀘스트의 다양한 요구사항과 미래의 확장성을 고려해 게임디자이너들에게 스크립팅 환경을 제공하기도 했지만 이는 실무 환경에서 잘 동작하지 않았고 또 인프라 비용을 극적으로 상승 시켜 지속 가능하지 않기도 했습니다. 먼저 해외의 성공적인 사례에서는 퀘스트를 스크립트 기반으로 개발했다고 알려졌지만 퀘스트를 만드는 모든 게임디자이너가 스크립팅을 할 수 없어 스크립팅을 전담하는 별도 직군을 두기 일쑤였고 또 테스트, 디버깅 환경이 열악해 단순한 문제를 해결하는데 하루를 쉽게 날려 생산성 문제가 제기되기도 합니다. 국내에서만 그랬던 것인지는 잘 모르겠지만 서버 개발자의 실력을 한 서버 군이 동접자를 얼마나 처리해낼 수 있는지에 근거해 판단하는 문화로 인해 스크립트를 수용할 수 있는 고사양 장비를 요구하는 인프라를 회사에 요구하기 어려울 때가 많았고 결국 스크립트 환경은 로직을 데이터 모양으로 정규화한 모양으로 바뀌어 현대에 이르기까지 비슷한 방법을 사용하고 있습니다.
매니지먼트 장르의 도래 이전까지는 퀘스트 로직에 의해 게임이 플레이어의 동작을 기다리는 방식으로 동작했다면 모바일 기기가 보급되고 본격적으로 자동 플레이가 등장하면서 같은 퀘스트 데이터를 해석하는 방법이 완전히 달라졌습니다. 이제 똑같은 퀘스트 데이터를 보고 전과 같이 플레이어의 동작을 기다릴 수도 있지만 이제 스텝 목표에 따라 기계가 직접 플레이어를 조작해 퀘스트를 수행할 수도 있어야 합니다. 이전 시대에는 플레이어를 고객이 직접 조작하기 때문에 내비게이션 메시에 기반해 이동 불가능한 곳에는 아예 접근할 수 없는 환경에서도 간단한 퍼즐이나 클라이언트의 물리 시뮬레이션에 기반한 떨어질 수 있는 레벨디자인 같은 요소를 사용할 수 있었습니다. 자동 기능을 감안하면 퀘스트 시스템은 그대로 사용할 수 있었지만 이 시스템에 기반해 수행하는 행동에는 여러 가지 제약이 생깁니다. 한번은 PC용으로 출시된 직접 조작하는 MMO 게임을 모바일로 옮겨야 했는데 모바일로 옮기면서 자동전투와 자동이동, 그리고 자동퀘스트 기능을 넣으면서 이상한 일을 겪기도 합니다. PC용으로 출시된 게임은 중간 중간 퍼즐 요소가 들어 있었는데 이를 유지하면서도 자동 퀘스트를 유지할 방법을 찾기 아주 어려웠습니다.
이런 퀘스트 시스템을 설계하는데는 크게 두 가지 접근 방법이 있다고 생각합니다. 먼저 개인적으로 선호하는 방법은 퀘스트 시스템이 게임 전체를 지배하는 마치 신과 같은 존재로써 동작하는 것입니다. 평소에는 퀘스트와 아무 상관 없이 필드를 거니는 몬스터들, 마을의 어느 한 자리에 영원히 서 있어야 하는 형벌을 받는 중인 마을 사람들도 퀘스트에 의해 순간 완전히 다른 행동을 하고 완전히 다르게 대할 수 있습니다. 평소 똑같은 인사말만 반복하던 마을 사람이었지만 퀘스트를 받은 상태로 다가가면 평소의 인사 대신 갑자기 자신이 마을 밖에서 본 신기한 몬스터에 대해 이야기하고 이 상태로 마을 밖에 나가 보면 평소에는 플레이어를 공격하지 않던 순한 몬스터들이 갑자기 플레이어를 공격하는데 신기하게도 퀘스트를 가진 플레이어만 공격할 뿐 다른 플레이어들에게는 아무 관심도 없습니다. 퀘스트가 신처럼 동작할 때 이런 동작은 퀘스트 시스템에 의해 직접 제어되며 퀘스트에 의해 일어나거나 일어나야 하는 모든 일이 퀘스트 데이터에 직접 기술됩니다. 퀘스트 데이터에 특정 상황에서 마을 사람이 해야 하는 평소와 다른 말, 평소와 다른 몬스터의 행동이 모두 기술되기 때문에 퀘스트 데이터를 보면 퀘스트 전체에 걸쳐 무슨 일이 일어나야 하는지 파악할 수 있고 여러 데이터를 오갈 것 없이 퀘스트 데이터에 집중해 데이터를 만들 수 있습니다.
단점도 있는데 이런 게임 전체에 걸친 각 기능을 퀘스트가 오버라이드 할 수 있도록 하려면 오버라이드 할 각 기능이 이미 완성되어 있어야 합니다. 어떻게 생각하면 당연한데 대부분의 프로젝트에서 퀘스트는 기반 시스템이 모두 구축된 다음 개발하기 시작합니다. 이럴 때는 신처럼 행동하는 방식으로 퀘스트를 설계할 수 있습니다. 그런데 종종 그렇지 않은 경우도 있습니다. 이전에 경험한 한 프로젝트에서는 아직 게임에 아이템 개념도 없어 보상을 받을 수도 없는 시점에 당장 퀘스트를 만들어 미래에 게임 초반이 동작하는 모양을 보기를 원하는 경영진에 의해 처음부터 퀘스트 시스템을 만들어야만 했습니다. 이 때에도 제가 선호하는 바에 따라 퀘스트를 신처럼 행동하도록 설계했는데 아직 게임 기능이 아무 것도 없었기에 신이 할 수 있는 일이 거의 없었습니다. 나머지 기능이 조금씩 개발되어 감에 따라 신의 능력이 점점 확장되었지만 다른 게임의 퀘스트 수준에 도달하는데는 지리하고 고통스러운 시간이 필요했습니다.
이번에 온보딩 하는 과정에서 이미 개발된 퀘스트 시스템을 따라 잡고 있는데 퀘스트 데이터는 이전에 개발해 온 모양들에 비해 훨씬 간결해 이해하기 쉬웠습니다. 하지만 의문도 있었는데 퀘스트에는 여러 목표와 보상이 있을 뿐이어서 오직 이 데이터만으로 동작한다면 여러 게임이 온라인 멀티플레이 환경으로 넘어가던 시대의 단순한 퀘스트 이상의 뭔가가 나오기는 어려울 거라고 생각했습니다. 가령 퀘스트가 신처럼 동작하도록 만들어 온 사람 입장에서 대화 상대의 대사가 없는 대화 목표를 보고 ‘그럼 이 사람은 퀘스트 도중에도 평소에 하던 말을 그대로 하는 건가?’ 하는 의문을 가질 수밖에 없었습니다. 하지만 데이터를 따라가다 보니 이 퀘스트 시스템은 게임 전체에 걸친 여러 시스템 각각이 퀘스트의 존재를 알고 있고 이들이 퀘스트를 인식해 서로 다른 행동을 하는 방식으로 만들어져 있었습니다. 신처럼 행동하는 퀘스트는 퀘스트 스스로가 이미 무슨 일이 일어나야 할 지 그 모든 것을 알고 있었지만 퀘스트에 사용되는 몬스터나 NPC, 인스턴스, 개인화된 영역 등은 자기 자신이 어느 퀘스트에 어떻게 사용되는지 전혀 알고 있지 못합니다. 저 자신이 NPC이고 항상 회사에서 제 자리에 앉아 있는 역할이라면 특정 퀘스트를 가진 사람이 저에게 다가오더라도 저는 그 사람에게 무슨 말을 해 줘야 할 지 모릅니다. 그런데 상대가 저에게 말하기 시작하면 갑자기 퀘스트의 신이 빙의되어 저는 들어본 적 없는 말을 갑자기 유창하게 한 다음 사라지고 저는 다시 무슨 일이 일어났는지 모른 체 컴퓨터 앞에 앉아 있는 신세가 됩니다.
한편 게임 전체를 구성하는 여러 시스템에 걸쳐 각 시스템이 퀘스트의 존재를 알고 있고 퀘스트마다 어떤 행동을 수행해야 할 지 알고 있는 형태의 설계에서는 반대로 퀘스트는 그 스스로가 세계에 어떤 영향을 끼쳐야 할 지 모릅니다. 이전에는 퀘스트 데이터에 퀘스트로부터 일어나야 할 모든 세계의 변화가 기술되어 있었지만 이번에는 퀘스트에 오직 퀘스트의 목표와 보상이 적혀 있을 뿐입니다. 대신 이번에는 마을 사람, 몬스터, 인스턴스 던전 등이 퀘스트의 존재를 알고 있으며 퀘스트를 가진 플레이어가 다가오면 무슨 행동을 해야 할 지 알고 있습니다. 컴퓨터 앞에 앉아 있던 저는 퀘스트에 의해 저에게 말을 건 사람이 어떤 퀘스트를 가지고 있는지 확인한 다음 대본을 넘겨 그 퀘스트에 맞는 대사를 말합니다. 이 경우 게임의 각 구성요소를 만드는 스탭들이 이 구성요소가 퀘스트에 의해 어떻게 제어되는지 자신의 업무 영역 안에서 파악할 수 있고 게임의 보다 넓은 영역에 퀘스트가 적용되도록 기능을 야금야금 넓혀 갈 수 있다는 장점이 있습니다. 다만 퀘스트를 제작하는 입장에서는 이 퀘스트가 실제 세계에서 각 구성요소와 상호작용 할 방법을 퀘스트 데이터만으로 파악할 수 없기 때문에 때로는 단지 퀘스트 데이터만 만들어 더 편할 수도 있지만 때로는 퀘스트 데이터 뿐 아니라 퀘스트 데이터에 기술되지 않은 게임 전체에 걸친 구성요소의 모든 퀘스트 관련 데이터를 파악해야만 하는 어려움이 있을 수도 있습니다.
개인적으로는 더 익숙하기도 하고 퀘스트를 만드는 사람 입장에서 마치 대본을 읽는 것처럼 게임 전체에 일어날 일을 한 자리에서 파악할 수 있고 이를 자동 퀘스트로 확장하기도 상대적으로 편하고 안전한 신처럼 행동하는 퀘스트 설계 접근을 선호하기는 하지만 완전히 반대 방향에서 접근해 설계한 퀘스트 시스템을 직접 보고 설계 철학을 추측하고 또 퀘스트의 존재를 알고 있는 각 구성요소의 데이터를 확인한 다음 이들을 머리 속에서 조립해 퀘스트 하나가 동작하는 상상을 하는 과정은 여러모로 재미있었습니다. 이전 까지는 퀘스트를 설계하게 된다면 기계적으로 신처럼 행동하는 퀘스트를 만들려고 했겠지만 이번에 완전히 다른 철학에 기반해 설계되고 개발된 퀘스트 시스템을 본 다음에는 같은 의사결정을 할 때 좀 더 고민해보게 될 것 같습니다.
이번 47호에도 다섯 가지 다른 이야기를 준비했습니다.
개인적으로 일에 집중하기 시작하면 화장실에도 안 가고 물도 안 마시고 작은 단위의 일을 마칠 때까지 그 자리에 앉아있습니다. 이런 행동은 장점으로 동작할 때도 있지만 더 많은 사람들과 이야기해야 하는 입장일 때는 썩 바람직하지 않을 수 있습니다. 저에게 사람들이 찾아오지만 제가 먼저 찾아갈 때 상황이 더 좋아질 여지가 있기도 합니다. 만약 제가 하루 종일 여러 짧은 대화와 회의로 자리를 계속해서 비운다면 사람들이 저를 어떻게 찾을 수 있을까요.
이런 생각을 해봤습니다. 만약 제가 에어태그를 들고 다니며 이 태그를 저를 찾으려 하는 사람들에게 공유하면 사람들이 제가 넓은 사무실의 어디 쯤에 있는지, 혹은 어느 회의실에 있는지 굳이 일정을 열어보거나 연락하지 않아도 쉽게 알 수 있지 않을까요? 단점은 안드로이드 사용자들에게는 어떻게 해야 할지 모르겠다는 점입니다. 아직 실행하지는 않았지만요.
이전에 가방 안에 넣어 두려고 사봤는데 국내에선 위치를 알 수 없을 뿐 아니라 닌자 퇴근술을 오랫동안 실천하면서 아무 것도 들고 다니지 않게 되면서 필요 없어진 에어태그로 제가 자리에 없을 때 저를 쉽게 찾을 수 있는 방법으로 사용할 수 있지 않을지 진지하게 고민하고 있습니다.
요즘 주변에 감기에 고생하시는 분들이 계십니다. 여기까지 읽어 주신 모든 분들도 감기 조심하시고 또 다음 주에 뵙겠습니다. :)
