퀘스트 한 스텝에 목표 여러 개를 넣을 수 있도록 할 것인가, 아니면 스텝 하나에는 목표 하나만 넣을 수 있게 할 것인가. 제 기준에서는 결정하기 쉽지 않은 문제였습니다. 이전에 참여했던 한 프로젝트는 처음에 이런 시스템을 단순하게 만들어 빠르게 개발하는 것이 목표였습니다. 시장은 항상 성공적인 한 장르가 출시되면 이후 몇 년에 걸쳐 비슷한 게임들이 범람하고 그들 중에는 또 다른 성공하는 게임이 나오기도 하지만 시간이 지남에 따라 장르 자체에 대한 피로가 쌓여 장르 자체의 수명이 끝나게 됩니다. 이 장르가 다시 시장에서 유효한 수명을 되찾는데까지는 다시 몇 년이 필요합니다. 이런 상황에서 선두주자가 아니었던 우리는 플레이에 큰 영향을 주지 못할 것 같은 복잡한 기능을 배제하고 뭐든 단순하게 만들기로 했었습니다. 그런 관점에서 퀘스트 한 스텝에는 목표를 하나만 허용하기로 했습니다.

시간이 흐르면서 게임의 방향이 변했습니다. 단순하고 빠르게 만들어 출시하자는 목표에서 출시가 늦어져도 좋으니 최대한 다채롭게 만들고 이로 인한 복잡도를 감수하게 되었습니다. 여러 변경이 일어났는데 그 중 하나는 퀘스트의 스텝 하나에 동시 진행할 수 있는 목표 여러 개를 넣을 수 있게 만들자는 것이었습니다. 퀘스트 데이터가 상당히 복잡해지고 관리하기 어렵게 되기도 하고 또 동시에 여러 목표를 수행하는 자동퀘스트를 만들기 까다로울 거라고 예상해 개인적으로 반대했습니다. 단일 퀘스트 스텝에서 늑대 열 마리를 잡고 다음 스텝으로 넘어가는 것과 늑대 열 마리와 오크 네 마리를 잡고 다음 스텝으로 넘어가는 경험 사이에 큰 차이가 없다고 생각했습니다. 게다가 자동퀘스트에 의해 진행되면 그냥 캐릭터가 주변의 몬스터를 공격하고 있을 뿐 이것이 동시에 늑대와 오크를 섞어서 잡고 있는 상태가 다른 의미를 가지지 않는다고 생각했습니다.

결국 한 스텝에 여러 목표를 수행하도록 하기로 결정해 개발을 진행했씁니다. 퀘스트 데이터를 엑셀에 입력하고 있었는데 한 스텝에 여러 목표를 수행하게 만들기 위해 그렇잖아도 복잡한 엑셀 퀘스트 데이터는 이전보다 훨씬 더 관리하기 어려운 모양으로 바뀌었습니다. 가로로 길게 펼쳐진 수많은 칼럼들은 모니터 두 대에 걸쳐 엑셀을 띄워도 한 번에 모든 칼럼을 확인할 수가 없었습니다. 또 자동퀘스트 입장에서도 상당히 복잡해졌고 또 여러 예외 상황을 정의해야 했습니다. 또 여기에 맞춰 몬스터 배치도 수정되었는데 기존에는 늑대만 깔려 있던 필드에 이제 오크를 섞어서 배치하는 식이었습니다. 말로 하면 간단하지만 이 계획을 실행하는 사람들은 기존에 배치된 몬스터를 모두 제거하고 그 자리에 몬스터를 섞어서 배치해야 했는데 손이 상당히 많이 가는 일이었습니다. 이 모든 작업에 몇 주를 써야 했고 그 사이에 게임은 정상 동작하지 않았습니다.

하지만 이런 변화를 거친 결과를 보고 제 생각이 틀렸다는 것을 알게 되었습니다. 자동퀘스트를 하는 내 캐릭터를 지켜보고 있었는데 불타는 마을에서 몬스터를 처치하고 사람들을 구출하는 퀘스트를 진행하며 내 캐릭터가 한번에 몬스터를 몰아서 잡고 몬스터를 다 잡고 나서 사람들을 몰아서 구하는 대신 몬스터를 처치하는 사이사이에 구할 수 있는 사람들이 있다면 다가가서 구하고 또 몬스터가 다가오면 전투를 계속했습니다. 자동전투에 의해 이 그림이 꽤 그럴싸해 보였고 또 몬스터만 몰아서 잡는데 비해 다채로워 보였습니다. 그러는 사이사이에 사람들이 도망칠 길을 가로막은 장애물을 파괴하기도 하고 또 바로 뒤로 돌아 몰려오는 몬스터를 공격하기도 했습니다. 이전과는 완전히 다른 모습이었습니다.

사실 지금도 같은 결정을 다시 한다면 많이 고민할 것 같습니다. 우리는 멋진 게임을 만들어야 하지만 동시에 비용과 시간 제한 안에서 게임을 만들어 출시해야만 합니다. 이 제한 안에서 개발하기 위해 시스템의 복잡도를 제한해야 하는데 복잡도 제한과 더 나은 게임을 개발하는 목표 사이에 어느 한 쪽을 쉽게 선택할 수는 없을 겁니다. 다만 이 한 스텝에 여러 목표를 동시에 진행하는 사례는 단순히 늑대와 오크를 섞어 잡는 것이 무슨 의미인지를 묻던 제 자신의 상상력 부족을 반성하는 계기가 되었습니다.