어디까지나 개인적인 경험에 비추어 이야기 하는 것임에 유의하세요.
***
마지막으로 ‘트리거’와 ‘오브젝트’ 이야기 입니다.
음, 어찌보면 ‘퀘스트 시스템’에 이어서 하는 내용 같습니다.
이 두 가지를 이야기 하는 이유는 이 둘을 유심히 보면 해당 퀘스트 시스템의 가능성과 한계를 좀 더 명확히 알 수 있기 때문입니다.
자 지금부터 설명을 해볼까 합니다.
*** 트리거***
사실 퀘스트 시스템은 트리거의 모음이라 해도 과언이 아닙니다.
그래서 이 트리거가 뭐냐?
말 그대로. 방아쇠입니다.
총알이 아무리 많아도 방아쇠를 당겨야 총알이 나아가듯, 트리거가 있어야 퀘스트가 작동한다는 것입니다.
즉, 퀘스트를 작동시키는 방아쇠입니다.
그동안 만연했던 甲의 만행이 위의 한 사건을 트리거로 폭발!
마찬가지로 데이터와 리소스가 넘쳐도 트리거가 없으면 작동하지 않습니다.
하나의 퀘스트를 구상해보죠.
[1번 숲에 들어서면 자동으로 늑대 사냥 퀘스트가 뜬다.]
이런 퀘스트를 구상했다고 했다고 칩시다.
문외한 사람이 보면 별 문제 없는 요청 같지만, 시스템적으로 보면 매우 모호합니다.
이것을 확실하게 하려면 트리거를 집어넣어서 적어야 합니다.
[ 1번 숲 좌표X.X에 들어서고 캐릭터 LV X 이상이면 늑대 사냥 퀘스트가 뜬다.]
‘1번 숲 좌표 X.X’ 와 ‘캐릭터 LV X’ 이상 이라는 내용이 추가되었습니다.
이러한 것이 바로 트리거입니다.
이러한 조건이 맞아 들어가야 퀘스트가 시작되는 것이죠.
앞서 퀘스트 시스템 편에서 퀘스트의 3요소 중 하나인 [습득]에 대해서 얘기한 적이 있습니다.
MMORPG 게임을 해보신 분은 레벨이 오르거나, 아이템을 클릭하거나, 몬스터를 죽이거나 하면 퀘스트를 습득하는 것을 경험해보셨을 것입니다. 돌이켜 보면 모두 막연하게 실행되는 것이 아니라 뭔가 조건이 있다는 것을 알 수 있죠.
이 모든 것이 일종의 트리거입니다.
이러한 트리거 요소를 정리하면 바로 [습득 조건]이 되는 것입니다.
트리거 개념은 퀘스트에만 쓰이는 것이 아니라 시스템 전반에 걸쳐 사용되니 잘 숙지하는 것이 좋습니다.
이 트리거를 얼마나 잘 정리하고, 잘 응용하느냐가 퀘스트 시스템의 관건입니다.
퀘스트 몹을 잡기 위해 줄을 서는 유저들
트리거를 몇 개 응용하면 이러한 퀘스트의 편의성도 증가시킬 수 있습니다.
다만 퀘스트 시스템 뿐 아니라 몬스터 테이블도 같이 다뤄야 할 것입니다.
여러가지 의미로 상급자용~
***활성 오브젝트***
오브젝트는 물체입니다.
상자, 나무, 등등 맵 안의 물체들을 오브젝트라고 부릅니다.
(작고 자잘한 소품들은 프랍이라고도 부릅니다.)
활성 오브젝트는 어떠한 명령에 의해 움직이는(활성화 되는) 오브젝트를 뜻합니다.
보통 그 명령을 트리거라고 합니다.
당연한 얘기지만 앞에서 얘기한 트리거를 어느 정도 이해했다면 퀘스트와 오브젝트를 연동하는 것도 고려할 수 있습니다.
습득 또는 수행 중 오브젝트를 작동시키는 행위를 트리거로 삼는 것이죠.
예를 들면 레버, 버튼, 특수한 바닥, 파괴 등과 같은 것입니다.
이러한 요소를 넣으면 퀘스트를 미니게임과 같이 만들어 아기지한 재미를 넣을 수 있습니다.
허나... 섣불리 넣으면 난리 나는 게 바로 이 오브젝트 작동입니다.
섣부른 오브젝트 활용으로 인해 통탄하는 QA...
대체로 콘솔게임을 많이 즐기던 사람들이 오브젝트의 활용에 매우 둔감합니다.
콘솔게임에서는 상자를 뛰어넘고, 자동문을 통과하고, 벽돌을 깨뜨리는 등의 액션을 하는 것을 별 생각도 없이 당연하게 하는 경우가 많기 때문입니다.
허나 서버 기반의 게임에서는 이러한 행위가 엄청난 예외상황들을 발생시킵니다.
오브젝트 벽돌을 깼다.
주변에 자신의 캐릭터 말고 아무도 없다면 별 문제가 없을 것입니다.
허나 10명이 있다면 10명에게 벽돌을 깨는 것을 알려줘야 합니다.
100명이 있다면 100명에게, 1000명이면 1000명에게... 이게 다 서버에서 처리가 됩니다.
이런 행위 자체 하나하나가 서버에게 엄청난 스트레스로 작용할 수 있습니다.
그런데 깨지는 것 정도는 간단한 편입니다.
‘버튼을 눌러 바닥을 움직이게 해 이동한다.’ 이런 경우는 좀 더 심합니다.
움직이는 바닥에 맞춰 실시간으로 그 위의 플레이어들을 자동으로 이동시켜야 합니다.
그리고 그걸 다른 플레이어들에게 알려야합니다.
역시나 한 명이면 문제가 없으나 백 명, 천 명이 되면... 괴랄한 과부하가 벌어집니다.
불가능한 것은 아닙니다.
특별한 압축 기술로 데이터를 원활하게 하는 방법도 있고, 디아블로 같이 플레이어를 축소시키는 방법도 있고, 캐릭터 시야를 가려 알리지 않는 방법 등의 꽁수도 있습니다.
하지만 그러한 것을 처리하기 위해서는 많은 작업과 테스트가 필요하다는 것을 기획자는 미리 인지해야만 합니다.
건물이 무너지면서 가구와 캐릭터들이 마구 쓸려나가는 언차티드2의 게임장면.
위의 이미지처럼 어디서 멋진 콘솔게임을 보여주면서 다짜고짜 프로그래머들에게
“우리 게임도 이런 식으로 연출하면 안돼요?”
라고 하면 프로그래머들은 부드럽게 웃으면서 이렇게 답합니다.
“가능한데, 시간이 좀 걸릴 겁니다.” (시발 한 10년 정도 걸릴 거다.)
정리하자면...
퀘스트 시스템을 다루려면 트리거의 개념을 숙지해야 한다.
활성 오브젝트를 다루는 퀘스트를 만들 경우는 다방면으로 신중하게 알아봐야 한다.
입니다.
막상 정리해보니 마치 겁주는 것처럼 불가능하고 조심해야할 것들만 설명한 것 같습니다.
허나 이 불가능을 뛰어넘을 생각을 해야 발전시킬 수 있는 것입니다.
실제로 많은 게임들이 이러한 한계를 숙지하고 그것을 극복하기 위해 다양한 기술들을 발전시키고 있습니다.
***
그리고...
앞서 얘기한 트리거와 오브젝트를 어느 정도 숙지했다 하면 도전할 거리가 또 있습니다.
활성 NPC... 아니 호위 NPC라고 불리는 연출입니다.
쉽게 말해 WOW 구 스트라솔룸 던젼에서의 아서스 같은 NPC의 활용입니다.
아서스 리즈 시절, WOW도 리즈 시절...
호위 퀘스트는 현재 나온 퀘스트 부류 중에 최상급의 난이도를 자랑한다고 보시면 됩니다.
이에 대한 자세한 얘기를 하면 너무 길어지니 몇 개만 추려서 얘기하겠습니다.
저 인던에 있는 아서스는 게임 상으로 보면 한 명이지만 실제로는 10개가 넘어갑니다. 대기하는 아서스, 닥치시오 우서! 아서스, 마을에 들어가는 아서스 등등등...
아서스는 움직이는 트리거 덩어리입니다.
일부 아서스는 AI(FSM)가 따로 설정되어 있습니다.
기타 등등등...
이 아서스는 몇 번째 아서스일까요?
'퀘스트'작업이라고 하면 글 좀 쓰고 연출만 생각하면 된다고 생각하시는 분들이 있습니다.
허나 막상 퀘스트를 제대로 파고들면 해야 될 것도 많고, 고려해야 될 것들이 많습니다.
이러한 정보를 통해 퀘스트 작업에 대한 이해도를 높이고, 앞으로의 발전에 도움이 되었으면 합니다.
퀘스트의 발전과 빡셈은 아직도 무궁무진 합니다.
여러분도 하면 할수록...
크크크... 흐콰한다...
그러니 퀘스트 챕터는 끝!
