어디까지나 개인적인 경험에 비추어 이야기 하는 것임에 유의하세요.
***
게임기획자가 되고 싶은 사람들 중에는 의외로 퀘스트를 멋지게 만들고 싶은 분들이 많습니다. 그러나 대부분 머릿속에서 재미있는 연출만을 떠올릴 뿐, 그것을 어떻게 만들 것인가에 대해서는 그다지 고민하지 않는 경우가 많습니다.
머릿속에 아무리 좋은 아이디어가 있다 해도, 게임에서 그것을 구현하려면 적절한 시스템을 갖춰야 합니다. 그러니 퀘스트의 질을 높이고 싶으신 분은 그만큼 시스템에 대한 이해가 필요합니다.
사실 시스템은 나중에 따로 얘기하려고 했지만,
이왕 퀘스트에 대한 이야기를 시작했으니 퀘스트 시스템에 대한 것만 살짝 정리해볼까 합니다.
아 그리고!
우선 시스템을 익히려면 간단한 컴퓨터 순서도 정도는 익히는 것이 좋습니다.
***
퀘스트 시스템은 크게 3가지로 체계로 분류됩니다.
아마 사람마다 부르는 명칭에 차이가 좀 있긴 하나 ‘퀘스트를 받고, 임무를 수행하고, 퀘스트를 완료한다.’라는 점에 대해서는 따로 이견이 없을 것입니다.
퀘스트 시스템은 이 3가지를 어떻게 꾸미느냐에 따라 달라집니다.
너무 단순하죠?
하지만 실제 작업에 들어가면 이 3요소가 그리 단순하지 않습니다.
이 3요소를 응용해서 여느 게임에서 볼 수 있는 기본적인 퀘스트 시스템을 짜보겠습니다.
***
예1) 사냥꾼에게 토끼 10마리를 가져다줘서 보상으로 활을 받는다.
대략적인 정리가 되었습니다.
그러나 이것은 사냥 퀘스트의 과정을 보여주었을 뿐.
이것을 시스템화 시켜야 합니다.
여기서 잠시 시스템에 대해 한 가지 비유를 들자면...
‘라면을 끓여 먹는다.’ 라고 했을 때.
시스템은 ‘라면’도, ‘가스렌지’도, 아닌 ‘라면을 끓이는 방법’이라고 할 수 있습니다.
자 다시 위의 순서도를 간단하게 시스템화 시키겠습니다.
예2) 시스템화 시킨 사냥 퀘스트
자... 순서도에 사냥꾼이나 토끼 같은 명사가 “()” 로 대체되었습니다.
이 “()” 에는 프로그래머가 ‘변수 값’을 집어넣을 것입니다.
“()” 에 사냥꾼을 넣을 수도 있고, 임금을 넣을 수도 있고, 앞집 강아지를 넣을 수도 있습니다.
이렇게 ‘시스템’화 시킨 것이죠.
그래서 이것을 활용하면...
예3) ‘시스템화 시킨 사냥 퀘스트’에 값을 입력
이렇게도 만들 수 있습니다.
그러나 내용이 이상합니다.
앞집 강아지와 대화에서 커플을 5명 죽이고, 변태에게 보고해서 팬티를 보상으로 받는다...?
대체 이게 뭔지!?
이게 바로 시스템의 예외 상황이라고 할 수 있습니다.
비유를 하자면, 라면을 끓이는 방법을 아무리 완벽하게 익히고 있다고 해도 그 방법으로 비빔면이나 뿌셔뿌셔를 끓이면 매우 끔찍한 라면이 나오는 경우라 할 수 있습니다.
이 때문에 시스템에서는 규약을 만들거나, 루틴을 추가하여 예외 상황을 최소화하거나 방지합니다.
***
예4) ‘시스템화 시킨 사냥 퀘스트’에 규약이나 주석을 삽입하여 예외 상황을 최소화
이런 식으로 규약이나, 주석을 알려줘서 시스템을 사용할 때 오류를 최소화하기도 합니다.
[a는 1>a>10 사이의 정수이다.] 라고 선언하는 것과 비슷합니다.
그 외에도 좀 더 근본적인 차단을 위해 루틴을 추가하는 수도 있습니다.
예5) ‘시스템화 시킨 사냥 퀘스트’에 루틴을 추가하여 예외상황을 최소화
아주 약간의 과장과 비약이 있지만...
대충 이런 식으로 검증절차 등을 삽입하여 시스템의 완성도를 높입니다.
아마 시스템을 하게 된다면 이러한 예외 상황과 처리과정 등을 두고 프로그램 쪽과 많은 회의와 토의가 오갈 것입니다.
최종적으로는 이러한 순서도로 다 표현하기 힘들 정도로 복잡하고, 세심한 구조가 완성되고,
그 시스템을 통해 퀘스트를 입력할 수 있는 퀘스트 툴, 스크립트 함수, 템플릿 등을 만듭니다.
하지만 완성된 시스템도 개발상황에 따라, 또는 유저의 똘끼(!?) 등에 따라 계속 변화하고 진화합니다. 심지어는 게임이 서비스 되고 있는 도중에 개발이 진행되기도 합니다.
***
이상 간략하게 퀘스트 시스템의 기본에 대해서 알아보았습니다.
[퀘스트 시스템은 어떠한 과정을 체계화 시키는 것이 매우 중요합니다.]
어찌 보면 규칙을 만드는 것이라고도 할 수 있으나~ 세상이 규칙만으로 잘 돌아가지 않듯이
[예외상황을 인지하고 그것을 처리하거나 대처할 수 있게 조치] 하는 것도 하나의 퀘스트 시스템 작업이라 할 수 있습니다.
***
퀘스트 시스템을 맡을 정도면 이 계통에서 상당히 구르고 구른 기획자일 가능성이 높습니다.
할 수 있는 사람이 적어서 그냥 프로그래머들에게 맡기는 경우도 많습니다.
그럴 경우 매우 안정적인 퀘스트 시스템이 만들어지기는 하지만 어딘가 아쉬운 것들이 만들어지거나, 어딘가의 퀘스트 시스템을 그대로 가져오는 경우가 많습니다.
프로그래머를 비하하려는 의미가 아니라 그 분들의 입장에서는 그럴 수밖에 없기 때문입니다.
기획자가 프로그래머에게 멋진 퀘스트 시스템을 부탁하는 것은 위와 같음.
만약 표현 욕심이 있는 기획자가 퀘스트 시스템을 맡게 된다면 여러 가지 난관에 부딪칠 가능성은 높지만 그만큼 의미 있는 성과물이 나오지 않을까 해서 ‘퀘스트 시스템’의 기본에 대해서 적어보았습니다.
기획자가 직접 설계하고 프로그래밍까지 하라는 의미는 아닙니다.
최소한 프로그래머랑 상의하고 아이디어를 나눌 수 있을 정도의 준비는 갖춰야 퀘스트 시스템의 발전이 있을 거라 생각하기 때문입니다.
