처음에는 아이디어가 제일 중요한 줄 알았다
게임 기획을 처음 할 때는 ‘구조’라는 말을 그렇게 깊게 생각하지 않았습니다.
보통 게임 기획을 떠올리면 이런 이미지가 먼저 떠오릅니다.
“사람들이 즐거워할 재미있는 아이디어를 내는 사람.”
저도 처음에는 그렇게 생각했습니다.
새로운 시스템, 신선한 이벤트, 재미있는 콘텐츠를 잘 떠올리는 게 기획자의 중요한 능력이라고 봤습니다.
물론 아이디어는 중요합니다. 재미있는 생각이 없으면 애초에 출발하기가 어렵습니다.
그런데 실제로 게임을 만들다 보면, 아이디어는 생각보다 빨리 한계에 부딪힙니다.
“이거 재밌을 것 같은데요?”
여기까지는 좋습니다. 문제는 그 다음입니다.
- 그래서 플레이어는 뭘 해야 하지?
- 몇 번 반복하게 만들지?
- 성공하면 뭘 주지?
- 실패하면 다시 하고 싶을까?
- 이걸 개발에서 어떻게 구현하지?
이 질문들이 나오기 시작하면 갑자기 분위기가 달라집니다.
방금 전까지는 재미있는 아이디어 회의였는데, 어느 순간 엑셀을 켜고 있습니다.
네. 게임 기획자의 현실은 생각보다 자주 엑셀에 있습니다. (혹은 ppt, 워드, 메모장일 수도 있겠죠)
일을 해보면서 느낀 건, 게임 기획에서 진짜 중요한 건 아이디어 자체보다 그 아이디어가 실제 게임 안에서 굴러가게 만드는 구조라는 점이었습니다.
어쩌면 제가 뒤늦게 배운 게임 기획의 기본도 이 지점에 있었던 것 같습니다.
재미는 말로 하면 쉬운데, 만들려고 하면 어렵다
“재미있게 만들자”는 말은 쉽습니다.
하지만 이 말만큼 위험한 말도 별로 없습니다. 너무 당연해서 아무것도 설명하지 않기 때문입니다.
기획자는 “재미”라는 말을 조금 더 작게 쪼개야 합니다.
- 플레이어가 이 콘텐츠에서 느껴야 하는 감정은 무엇인지
- 처음 1분 안에 무엇을 이해해야 하는지
- 어디에서 선택을 하게 만들 것인지
- 어느 정도의 피로감을 감수하게 할 것인지
- 보상을 받았을 때 만족감이 있는지
이런 질문들로 바꾸지 않으면 재미는 계속 두루뭉술한 말로 남습니다.
예를 들어 “협동의 재미를 주자”라고 쓰면 멋있어 보입니다. 그런데 막상 콘텐츠를 만들려면 바로 질문이 생깁니다.
어떻게 협동하게 할 건데?
그냥 두 명이 같이 때리면 협동인가? 한 명이 죽으면 어떻게 하지? 보상은 둘 다 똑같이 주나? 방장은 뭔가 더 받아야 하나? 중간에 나가면? 재입장은?
이런 것들을 정리하다 보면 깨닫게 됩니다.
그래서 저는 요즘 이렇게 생각합니다.
재미는 감상에 가깝고, 기획은 구조에 가깝다고요.
레벨 디자인을 하면서 배운 것
레벨 디자인을 할 때도 비슷했습니다.
처음에는 맵을 멋있게 만드는 것이 중요해 보입니다. 배경도 좋아야 하고, 분위기도 있어야 하고, 전투가 벌어지는 공간도 그럴듯해야 합니다.
그런데 실제로 미션을 만들다 보면 더 자주 고민하게 되는 건 이런 것들입니다.
- 플레이어가 어디로 가야 하는지 바로 알 수 있는가?
- 전투가 너무 갑자기 튀어나오지는 않는가?
- NPC를 따라가는 흐름이 답답하지 않은가?
- 컷신이나 대사가 플레이 흐름을 끊지는 않는가?
- 몬스터 배치가 그냥 많이 넣은 것처럼 보이지는 않는가?
예전에 MMORPG 미션 레벨을 작업할 때, NPC를 호위하면서 숲 지역을 지나가는 미션을 만든 적이 있습니다.
특히 숲 구간은 지형이 어둡고 비슷해 보일 수 있어서, 플레이어가 진행 방향을 잃지 않게 만드는 게 중요했습니다. 그래서 NPC 이동 경로, 몬스터 등장 위치, 컷신 타이밍을 최대한 같은 흐름 안에 묶으려고 했습니다. 기획서에서는 몇 줄로 끝나는 내용인데, 실제 툴에서 맞춰보면 생각보다 손이 많이 갔습니다.
NPC는 어느 정도의 속도로 이동해야 하는지, 플레이어는 어느 지점에서 적을 만나야 하는지, 전투가 끝난 뒤 다음 목표는 어떻게 보여줄지, 컷신은 언제 들어가야 자연스러운지 계속 생각해야 합니다.
여기서 동선 유도 구조가 약하면 플레이어는 바로 헤맵니다.
그리고 유저가 헤매기 시작하면 생각보다 오래 참아주지 않습니다. 게임은 친절해야 하지만, 유저는 그렇게까지 자비롭지 않습니다. (특히 요즘처럼 숏폼에 익숙해진 시대는 더욱 그럴 것입니다)
좋은 레벨은 플레이어에게 계속 설명하지 않아도 됩니다. 플레이어가 움직이고, 싸우고, 멈추고, 다시 이동하는 과정에서 자연스럽게 다음 행동을 알게 만들어야 합니다.
그게 제가 레벨 디자인을 하면서 처음 배운 구조였습니다.
협동 콘텐츠는 그냥 같이 한다고 협동이 아니었다
협동 콘텐츠도 비슷합니다.
겉으로 보면 간단해 보입니다. 두 명이 같이 들어가서 보스를 잡는다. 이렇게 쓰면 별로 복잡해 보이지 않습니다.
하지만 실제 기획서로 쓰기 시작하면 갑자기 문서가 길어집니다. 이상합니다. 분명 두 명이 보스 하나 잡는 이야기였는데, 페이지가 늘어납니다.
방은 누가 만드는지, 초대는 어떻게 하는지, 준비 완료는 어떻게 처리하는지, 전투 중 한 명이 나가면 어떻게 되는지, 죽은 플레이어는 관전하는지, 보상은 어떻게 지급하는지 같은 규칙들이 필요해집니다.
모바일 RPG의 협동 레이드 콘텐츠를 기획하면서도 이런 부분을 많이 고민했습니다.
특히 기억나는 건 전투 자체보다 예외 상황이었습니다.
방장이 시작을 누르기 전 파티원이 준비를 안 했을 때, 전투 중 한 명이 나갔을 때, 먼저 죽은 플레이어를 어떻게 처리할지 같은 것들이 계속 나왔습니다.
보스 패턴을 만드는 것도 일이지만, 사실 이런 자잘한 규칙을 정리하는 것도 만만치 않았습니다.
협동 콘텐츠는 전투에 들어가기 전부터 이미 경험이 시작됩니다. 로비에서 정보를 확인하고, 파티원을 초대하고, 준비를 누르고, 보상을 기대하는 과정도 전부 콘텐츠의 일부입니다.
이 구조가 불편하면 유저는 보스가 재미있기도 전에 피곤해집니다.
그러면 아무리 보스 패턴을 열심히 만들어도 이런 반응이 나올 수 있습니다.
“아니 그래서 입장 어떻게 하는 건데요?”
이 말이 나오면 기획자는 조용히 문서를 다시 열어야 합니다.
이벤트 기획은 보상을 많이 주는 일이 아니었다
라이브 서비스 게임에서 이벤트를 기획할 때도 구조가 중요했습니다.
이벤트는 겉으로 보면 보상을 주는 콘텐츠처럼 보입니다. 실제로 유저 입장에서도 보상은 중요합니다. 솔직히 보상 안 중요하다고 하면 거짓말입니다. 저도 유저일 때는 보상부터 봅니다.
그런데 이벤트 기획을 해보면, 보상은 그냥 많이 준다고 해결되는 문제가 아닙니다.
적게 주면 당연히 아쉽습니다. 그런데 너무 많이 줘도 문제가 생길 수 있습니다. 기존 성장 구조를 건드릴 수도 있고, 경제 밸런스에 부담을 줄 수도 있고, 다음 이벤트의 기대치를 이상하게 올려버릴 수도 있습니다.
말하자면 이벤트 보상은 약간 간 맞추기 같습니다.
싱거우면 맛없고, 짜면 물을 찾게 됩니다. 문제는 유저마다 입맛이 다릅니다. 쉽지 않습니다.
라이브 이벤트에서 중요한 건 “얼마나 많이 주느냐”보다 “왜 지금 접속해야 하는가”에 가깝다고 생각합니다.
- 이 시기에 유저가 원하는 보상은 무엇인지
- 하루에 어느 정도 참여하게 할 것인지
- 반복 플레이가 숙제처럼 느껴지지는 않는지
- 이벤트가 기존 콘텐츠와 자연스럽게 연결되는지
- 끝나고 나서도 좋은 기억이 남는지
이런 것들을 같이 봐야 이벤트가 단순한 보상 지급표에서 조금 벗어납니다.
결국 이벤트도 구조입니다. 접속 동기, 플레이 시간, 보상, 반복 부담, 유저 반응이 다 연결되어 있습니다.
PM 일을 하면서 구조를 또 다르게 보게 됐다
기획자로 일할 때 구조는 주로 플레이 경험을 만드는 일이었습니다.
그런데 PM 업무를 하면서는 구조를 조금 다른 방식으로 보게 됐습니다.
PM에게 구조는 팀이 일할 수 있게 만드는 방식에 가깝습니다.
회의에서 좋은 이야기가 많이 나와도, 그게 실제 일감으로 정리되지 않으면 결국 흩어집니다. 누가 할지, 언제까지 할지, 무엇을 먼저 할지, 어떤 팀과 협의해야 할지 정리되지 않으면 좋은 아이디어도 그냥 회의록 안에서 잠들어버립니다.
회의록 공동묘지 같은 게 생깁니다. 분명 좋은 말들이 있는데, 아무도 다시 안 봅니다. (실제로 정말 그렇습니다)
PM 업무를 하다 보면 그래서 계속 쪼개게 됩니다.
- 이 결정은 어떤 작업으로 바뀌어야 하는지
- 이 작업은 어느 팀이 먼저 해야 하는지
- 일정상 위험한 부분은 어디인지
- 지금 꼭 해야 하는 일과 나중에 해도 되는 일은 무엇인지
- 회의에서 나온 말 중 진짜 결정된 것은 무엇인지
예전에 IT 프로덕트 PM을 할 때도 비슷한 경험이 있었습니다. 업무가 문서와 구두 커뮤니케이션에 흩어져 있다 보니, 팀원들이 각자 어떤 일을 하고 있는지 파악하기 어려운 상황이 있었습니다.
그래서 문서는 Notion에 정리하고, 실제 업무 관리는 Asana 같은 협업 툴로 나누는 식으로 프로세스를 다시 잡았습니다.
도구 자체가 마법은 아닙니다. Asana를 쓴다고 갑자기 팀이 강해지는 건 아닙니다. 그런 거였으면 전 세계 모든 회사가 이미 평화로웠겠죠.
중요했던 건 팀이 같은 기준으로 일을 보게 만드는 것이었습니다. 어떤 업무가 진행 중인지, 어디서 막혔는지, 다음에 무엇을 해야 하는지 보이게 만드는 것. 이것도 결국 구조였습니다.
게임 기획을 해보니, 결국 중요한 건 구조였다
지금도 저는 게임 기획에서 아이디어가 중요하다고 생각합니다.
재미있는 생각, 새로운 시도, 참신한 상상력. 이런 것들이 없으면 게임은 너무 안전하고 심심해질 수 있습니다.
다만 일을 해보니 아이디어는 출발점에 가깝습니다.
그 아이디어가 실제 게임 안에서 작동하려면 목표가 있어야 하고, 규칙이 있어야 하고, 보상이 있어야 하고, 반복 구조가 있어야 합니다. 플레이어가 이해할 수 있어야 하고, 개발팀이 만들 수 있어야 하고, 운영 과정에서도 감당할 수 있어야 합니다.
말로 쓰면 너무 당연한데, 실제 현장에서는 이 당연한 것들이 자주 어렵습니다.
그래서 요즘은 게임 기획자를 이렇게 생각하게 됩니다.
기획자는 재미있는 아이디어를 내는 사람이기도 하지만, 그보다 더 자주 하는 일은 재미를 구조로 바꾸는 일에 가깝다.
아이디어를 플레이어가 실제로 경험할 수 있는 흐름으로 만들고, 팀이 구현할 수 있는 작업 단위로 정리하는 사람.
조금 덜 멋있게 말하면, “이거 재밌겠다”와 “이거 만들 수 있겠다” 사이를 계속 왔다 갔다 하는 사람입니다.
그리고 생각보다 그 사이가 꽤 멉니다.
아마 게임 기획 일을 해본 분들이라면 이 말에 조금은 공감하시지 않을까 싶습니다. 아니면 저만 그랬을 수도 있습니다…
다음 글에서는 제가 레벨 디자인을 배울 때 인상 깊게 봤던 하프라이프 2 이야기를 해보려고 합니다.
밸브가 플레이어에게 직접 설명하지 않고도 자연스럽게 길을 찾고, 규칙을 배우게 만드는 방식에 대해 가볍게 정리해볼 생각입니다.