문제인식

오래 전 제가 작성해야 하는 문서와 똑같은 결과물이 이미 구현된 다른 프로젝트가 있어서 사내 시스템을 통해 문서 열람을 요청했습니다. 분명 시간을 절약할 수 있을 거라고 예상했거요. 하지만 결재선이 일곱개인 거대한 기안문서를 마주하게 되었습니다. 결재선에 있는 여러 사람들은 각자 결재문서를 받을 때마다 바로바로 승인해 주셨지만 결국 2주가 지난 뒤에 문서를 열람할 권한을 얻었습니다. 하지만 기안을 올린 날 저녁에 문서를 완성했고 다른 프로젝트의 문서는 열어보지도 않았습니다. 이 경험 후에는 다시 다른 프로젝트의 문서 열람을 시도하지도 않았고요.

상업용 게임을 개발하면서 다른 프로젝트의 다른 직군 산출물에는 접근할 기회가 있는 반면 게임디자이너들이 주로 작성하는 소위 ‘기획서’에는 접근할 기회가 거의 없었습니다. 제가 본 공개된 기획서는 주로 게임디자인을 지망하시는 분들이 작성하셔서 범위나 형태가 실제 개발과 맞지 않거나 30년쯤 전에 업계의 전설들이 작성한 지금 환경과는 완전히 맞지 않아 도저히 참고할 수가 없었습니다.

유능한 예술가는 모방하고 위대한 예술가는 훔친다고 합니다만 모방이라도 해서 유능한 단계에 가까워지기라도 하려면 모방할 대상이 있어야 합니다. 기획서는 이럴 기회가 상대적으로 드물었습니다. 그래서 아주 좁은 범위의 기능을 대상으로 문서를 작성해 공개하고 의견을 받아 고치기를 반복하며 이 과정과 결과를 공개해둔다면 저 자신을 포함한 누군가는 도움을 받을 수 있지 않을까 하는 생각을 하게 되었습니다.

그럼 좀 어때?

처음에 트윗²⁾을 올리고 나서 다행히도 여러 의견을 보게 됐습니다. 아무 관심도 못 받고 그냥 지나갈 거라고 예상했거든요. 의견 중 일부는 뭔가 거창한 것을 시작하려는 의도로 해석하신 것 같았습니다. 여기서는 아주 작은 문서를 공개하고 아주 작게 시작하려고 합니다. 망한 게임이든 흥한 게임이든 작은 UI로 된 메커닉은 있을테고 그걸로 작은 기획서를 쓸 수 있을 겁니다. 그게 기대에 미치지 못하는 보잘것 없는 물건이면 좀 어떤가요.

기획서를 공개된 장소에 작성하는 것은 마치 사람으로 가득한 광장에서 용변을 보는 것 같은 불편한 기분이 들게 만듭니다. 사실 아무것도 안하면 쉽고 편하지만 여전히 개인의 경험에 기대 아주 느리게 발전할 수밖에 없게 됩니다. 차라리 광장에서 수모를 겪으며 앞으로 나가는 쪽이 낫다고 생각합니다. '아. 저 사람은 겨우 저 정도 수준이구나' 하고 알려지는 것이 여전히 두렵기는 합니다만 그럼 좀 어떤가요.

요약

게임디자이너들이 매일매일의 작은 업무에 참고할만한 저작권으로부터 안전한 좁은 범위의 기획서를 만들어 공개하고 개선한다.

목표

• 개인적으로는:

  • 같은 프로젝트에서 일하는 사람 말고 외부 사람들의 의견을 듣고 문서를 고칠 기회를 얻을 수 있습니다.

• 다른분들께는:

  • 제 기준으로 현업에서 사용하는 것에 가까운 형식의 공개된 문서를 참고할 수 있습니다.

  • 의견을 낼 수 있고 직접 수정할 수도 있습니다.

    • (직접 수정하는 부분이 잘 동작할 거라고 예상하지는 않습니다.)

방법

기획서의 형태

보조시스템 기획서

'게임디자인문서' 혹은 '게임기획서'라고만 적어놓으면 범위가 넓어 온갖 문서를 포괄할 수 있습니다. 팀이나 프로젝트에 따라 정말 온갖 종류의 문서가 이 범위에 포함될 겁니다. 이 범위를 좁혀야 실제로 문서를 작성할 수 있고 예상할 수 있는 문제를 줄일 수도 있습니다. 때문에 일단은 '보조시스템 기획서'를 작성해 보려고 합니다.

보조시스템 기획서는 게임마다 흔히 발견할 수 있는 소위 '뻔한' 구성요소를 설명한 문서입니다. 가령 모바일 MMO 게임이라면 화면 상의 비슷한 위치에 캐릭터 정보가 표시되고 비슷한 위치에 메인메뉴가 있습니다. 또 화면 전체를 덮는 캐릭터정보 화면이나 인벤토리 화면이 있습니다. 이들은 게임의 핵심 메커닉 - 흔히 '전투시스템'이라고 부르곤 하는 - 과 거리가 있지만 작성하기 상대적으로 쉬운 편이고 접근하기도 쉽기 때문에 개선 의견을 받을 여지도 더 많습니다.

때문에 '보조시스템 기획서'를 위주로 시작하려고 합니다.

역기획서

굳이 문서가 아니더라도 회사에서 업무시간에 업무용 장비를 가지고 하는 모든 작업 결과물은 회사의 소유입니다. 때문에 회사의 그 어떤 작업도 회사의 동의를 거치지 않고서는 회사가 승인하는 범위를 초과해서 이동하거나 공개할 수 없습니다. 당연하게도 실제 작업에 사용하는 문서는 '절대로' 공개할 수가 없습니다. 그래서 기획자가 포트폴리오를 만들 때 자주 사용하는 방법은 역기획서를 작성하는 겁니다. 이미 출시된 게임의 일부분을 개발한다고 가정하고 역기획서를 작성하면 이 문서는 방금 이야기한 몇 가지 위험을 줄일 수 있습니다.

이미 공개된 게임의 보조시스템 중 일부를 짧은 개발기간 내에 개발한다고 가정하고 역기획서를 작성해 공개하는 식으로 시작하려고 합니다.

좁은 범위의 기능을 대상으로

기획서는 여러 가지 범위를 대상으로 작성할 수 있습니다. 가령 전투 시스템 기획서처럼 굉장히 넓은 범위를 대상으로 작성해 거대하게 만들 수도 있고 파티장에게 추방 권한 추가와 같이 이미 완성된 시스템에 기능을 추가하기 위한 짧은 문서를 작성할 수도 있습니다. 여기서는 뒤쪽에 가까운 문서를 위주로 작성하려고 합니다. 이미 출시된 게임의 특정 시스템을 대상으로 '역기획서'를 작성하고 이 시스템의 일부를 개선할 목적으로 기존 문서를 수정하거나 작은 문서를 수정하는 과정을 보일 겁니다.

운영

https://github.com/neoocean/OpenGameDesignDocument

• 현재 위 주소에서 작성을 시작했습니다.

  • 이슈에 의견을 주실 수 있습니다.

이후 진행

계획

1. 이 페이지를 공개하고 의견을 받아 계획을 완성합니다.

2. 위 솔루션 후보 중 하나를 선택해 사이트를 구축합니다.

3. 시험 삼아 아주 좁은 범위의 기획서 몇 개를 작성합니다. (여기 진행중)

4. 사이트를 공개합니다.

5. 의견을 받아 수정하기 시작합니다.

   • 이 과정을 반복합니다.

현재 진행상황

• 아주 좁은 범위의 기획서를 써보고 있는데 기반이 없는 상태에서 범위가 좁은 + 기반이 아닌 문서를 작성하다 보니 문서 중간에 갑자기 뜬금없는 기반설명을 해야 해서 난감하긴 합니다만 문서가 쌓이면 완화될 것으로 예상하고 있습니다.

FAQ

게임디자인이 문서만으로 진행되는건 아니잖아요?

상업 개발팀의 현실을 생각해봤습니다. 업무를 문서만으로 진행할 수 없는 형태로 고정하고 개인의 역량에 의존하 재현이 어려운 방법을 제시하곤 합니다. 이런 방법들은 대체로 훌륭합니다. 하지만 우리가 매일 그렇게 일하지는 않습니다. 매 업무마다 거대한 에너지를 필요로 하며 그러기에 충분한 시간이 주어지지 않는 경우가 많습니다. 반면 실제 업무는 문서로 시작하고 끝나지 않을 수 있지만 문서로부터 시작되고 문서에 의해 총 의사소통비용을 가늠할 수 있습니다.

게임디자이너는 게임디자인과 개발진 업무가 핵심이고 일상의 의사소통수단은 텍스트를 기반으로 한 문서입니다. 유효한 문서를 작성하지 않으면 예측되지 않은 불필요한 의사소통비용을 사용해야만 합니다.

기획서는 쓰는 사람마다, 프로젝트마다 다릅니다만

맞습니다. 쓰는 사람마다 다르고 프로젝트마다 다르고 또 종종 회사마다 다르기도 합니다. 하지만 이 현상을 관측하기만 하고 아무것도 하지 않아 생기는 의사소통비용의 낭비는 문제라고 생각합니다. 게임디자인 직군의 산출물 이외에는 어느 정도 표준화가 이루어지고 있습니다. 특정 엔진을 사용하면서 리소스 구성이나 구현 방법은 어떤 형태로부터 시작되어야 할지 폭넓은 공감대가 형성되었고 덕분에 새로운 사람들과 새로운 프로젝트를 시작하더라도 이전에 사용해본 엔진을 사용한다면 많은 부분이 자연스럽게 표준화되어 비용을 줄일 수 있습니다.

기획서가 상황에 따른 표준화가 아예 불가능하다고 덮어놓고 이야기하기에는 기획서 역시 다른 산출물과 크게 다르지 않다고 생각합니다. 비슷한 시스템을 만들기 위한 문서가 프로젝트마다 아주 많이 다를 거라고 생각하지 않습니다.

선택한 솔루션은 슬라이드를 배제하고 있는데요

제 관점에서 슬라이드는 형식 중 하나입니다. 문서의 본질과는 차이가 있고요. 문서는 표준 용지에 인쇄할 수 있는 형식이거나 아래로 계속해서 스크롤할 수 있는 형식이거나 또 한장씩 넘겨가며 보는 슬라이드 형식일 수도 있습니다. 여기서는 텍스트와 테이블, 이미지로 구성된 '형식'을 기준으로 삼으려고 합니다. 이런 문서는 또 다른 '형식'인 슬라이드 형태로도 표현할 여지가 있으며 그건 제가 아닌 다른 누군가가 할 수도 있습니다.