어떤 정보를 서버에 기록해야 할지 어떻게 결정할까

소위 게임디자이너로 분류되는 직군의 사람들은 당연히 엔지니어 직군에 비해 기술적인 이해도가 떨어진다고 알려져 있습니다. 한편 게임디자이너들이 엔지니어 직군에 비해 가지는 강점은 의도를 스스로 정의하고 그 의도를 설명할 수 있는 것입니다. 이는 강점이나 특징이라기 보다는 게임디자이너의 의무이자 존재 이유라고도 말할 수 있습니다. 하지만 팀에서 주니어 디자이너들은 종종 스스로 의도를 만들어낼 만한 상황에 놓이지 않기 때문에 요구사항을 정의하더라도 요구사항의 목적과 의도를 제대로 이해하지 못해 개발을 진행 시키는데 어려움을 겪기도 합니다.

몇몇 온라인 게임 프로젝트에 참여하면서 자주 마주친 사례 중 하나는 초반에 서버에 저장할 정보와 클라이언트에 저장할 정보를 정의하는 것입니다. 한때 서버에 정보를 저장하는데 비용이 높아 플레이어의 성장과 인벤토리 상태를 제외하고는 도통 서버에 정보를 저장하기 어렵던 시대가 있었습니다. 이 시대에는 게임의 단축키 설정마저도 클라이언트에 기록해 다른 컴퓨터에서 게임을 실행하거나 PC방에서 좀 플레이 하려면 처음 한동안을 단축키 설정을 하며 시간을 낭비하기도 했습니다. 시간이 흘러 비정형 데이터를 저장하는 방법이 등장해 이전 시대에 비해 정보를 서버에 저장하는데 이전 시대만큼 반발을 겪지 않지만 여전히 이전 시대의 습관이 남아 어떤 정보를 서버에 기록해 사용하는 기계에 관계 없이 항상 같은 경험을 주려는 의도를 의심 받을 때가 있습니다. 이는 특히 온라인 게임의 구성에 대한 이해 수준이 아직 높지 않은 분들이 협업을 진행하는데 어려움을 겪게 만들기도 합니다.

어느 날 엔지니어로부터 ‘플레이어 캐릭터의 현재 위치를 서버에 저장해야 하나요?’라는 질문을 받았습니다. 이 질문의 의미는 플레이어는 계속해서 이동하는데 이동할 때마다 현재 위치를 서버에 저장할 필요가 있느냐는 것입니다. 또 한편으로는 플레이어가 접속을 종료했다가 다시 접속하면 어디서 게임을 다시 시작해야 하는지 알고싶다는 의도가 포함되어 있습니다. 하지만 엔지니어도 게임디자이너도 당장의 궁금함을 주고 받을 뿐 그 궁금함 너머의 정확한 의도를 주고 받는데 익숙하지 않으므로 이런 질문을 받은 게임디자이너를 당황 시킬 수 있습니다.

플레이어의 현재 위치를 서버에? 왜? 그냥 다른 사람들에게 실시간으로 동기화 되니 애초에 서버에 있는 정보 아닌가? 그걸 저장? 저장하는 것과 저장하지 않은 것 사이에 무슨 차이가 있지? 같은 질문을 머릿속에 떠올리며 ‘확인해본 다음 알려주겠다’고 답할 텐데 이 상황에 올바른 대응이기는 하지만 답변을 할 수 있었다면 장기적으로 협업 부서들 사이에 신뢰를 조금 올리는데 도움이 되었을 겁니다. 정확한 의도를 담아 질문을 주고 받으면 가장 좋지만 그건 꽤 고급 기술이니까 나중에 기회가 있을 때 이야기하기로 하고 여기서는 어떤 정보를 서버에 기록해야 할 지 말 지를 결정하는 요령을 설명하겠습니다.

온라인 멀티플레이 게임은 크게 두 가지 측면에서 정보 저장 여부를 검토해야 합니다. 첫째. 플레이어가 게임을 중단했다가 재시작 할 때 어디서 어떻게 시작할 것인지에 따라 다릅니다. 온라인 멀티플레이 게임은 플레이어가 게임에 접속해 있든 말든 어쨌든 게임 세계는 계속해서 움직이고 있습니다. 반면 플레이어는 24시간 365일 게임에 접속해 있지는 않기 때문에 게임에 재접속 할 때 어디서 어떻게 재시작 할 지 정의해야 합니다. 가령 종료한 그 자리에서 재시작 할 수 있습니다. 규칙 자체는 가장 단순하고 또 이해하기도 쉽습니다.

하지만 종료한 자리 근처에 선공 몬스터가 돌아다니고 있거나 PvP를 허용하는 지역이라면 규칙은 그리 단순하지 않을 수 있습니다. 클라이언트 로딩이 끝나기 전에 다른 플레이어나 몬스터에 의해 플레이어가 이미 죽어 있을 수도 있고 다른 플레이어의 전투 한 복판에 갑자기 나타날 수도 있습니다. 물론 이 상황 자체를 게임의 일부로 정의할 수도 있지만 그렇지 않다면 일시적으로 플레이어를 보호해 불리함을 줄이는 복잡한 규칙을 마련해야 합니다.

한편 종료한 자리에서 바로 재시작 하면 그 장소에 도달하기 위한 비용을 원활하게 부과할 수 없게 됩니다. 마을에서 어떤 사냥터까지 이동하는데 높은 비용을 요구하고 있다고 하면 그 사냥터에서 하는 플레이는 이 곳에 도달하는데 사용한 비용만큼의 효율을 얻을 수 있어야 합니다. 만약 누군가 그 사냥터에서 더 이상 마을에 돌아가지 않고 플레이를 지속할 수 있는 효율에 다다랐다면 이 플레이어는 이제부터 이 사냥터에 도달하기 위해 부과하던 비용을 더 이상 지출하지 않고 사냥터를 사용할 수 있게 됩니다. 그래서 종종 플레이 하던 레벨만 기록했다가 게임을 재시작 하면 레벨 입구로 돌려 보내거나 아예 마을로 돌려 보내 이동 비용을 다시 부과하기도 합니다.

둘째. 유저가 서로 다른 장치를 통해 게임에 접속할 때 서로 같은 경험을 줄 것인지 여부에 따라 다릅니다. 아주 먼 과거에는 유저 한 명이 게임을 실행할 수 있는 기계가 한 대 뿐인 경우가 많았습니다. PC 한 대, 콘솔 한 대 같은 식으로요. 하지만 PC방이 생기면서 유저 한 명이 두 대 이상의 기계를 통해 게임에 접근할 수 있게 되었습니다. 또 현대에는 PC와 모바일 기계를 각각 사용해 게임에 접속할 수 있기도 합니다. 그래서 서로 다른 기계를 통해 게임에 접근할 때 같은 경험을 줄 지 여부에 따라 서버에 기록할 정보가 달라집니다. 가령 기계마다 사양이 다르므로 그래픽 옵션을 서버에 기록할 필요는 없을 겁니다. 반면 단축키 설정이나 게임플레이 옵션은 기계가 달라지더라도 적어도 PC끼리는 같은 환경을 원할 가능성이 높으니 서버에 기록해 두면 PC방에 가서도 설정을 다시 조절하는데 시간을 쓸 필요 없이 바로 게임을 시작할 수 있을 겁니다.

정리하면 플레이어가 서버에 재접속 할 때 어떤 상태로 게임을 재시작 해야 하는지에 따라, 유저가 서로 다른 기계를 통해 게임에 접속할 때 얼마나 같은 경험을 하게 해 줄 지에 따라 서버에 기록할 정보가 달라질 수 있습니다. 가장 이상적인 상황은 엔지니어와 게임디자이너가 서로 질문을 주고 받을 때 질문의 의도를 명확히 하는 것이지만 실생활에서 그러기 어렵다면 이 두 가지 조건을 고려해 의도를 만들고 이에 따른 기술적인 의사결정을 할 수 있습니다.