4. 흥미 보다는 정보성

읽기에 재미있는 게임 설계 문서는 지루한 문서보다는 경쟁력 있을 것입니다. 그러나 흥미가 본위가 되고 전달하고자 하는 내용이 불충분하거나 불명확하다면 많은 문제가 발생할 수 있습니다.

개발 현장에서는 실제로 ‘흥미’나 ‘재미’ 위주로 문서를 작성하는 게임 디자이너를 어렵지 않게 볼 수 있습니다. 즐겁게 읽고 나서, “그런데, 내가 할 일이 정확히 무엇인지? 어떤 과제를 연구하고, 수행해야 하지?”라는 질문이 생기는 경우가 발생할 수 있습니다.

실무자는 ‘자신에게 유용하고 필요한 정보’를 원하는 것이지 시간을 즐겁게 보낼 수 있는 소설이나 에세이를 원하는 것이 아닙니다. 재미있게 구성한다고 장황하며 애매한 내용으로 가득 차 있는 서술문을 삽입한다면, 설계 문서를 다시 작성해야 하는 상황에 직면하게 될 것입니다.

게임의 분위기나 세계관, 기타 상황 연결을 위한 스토리 등은 흥미롭게 읽을 수 있도록 구성하는 것이 유용할 수 있습니다. 그러나, 프로그래머가 구체적인 알고리즘을 구상하고 기술적으로 구현해야 하는 부분은 가급적 정량적으로 간결하면서도 명확하게, 흔히 이야기하는 ‘딱딱하고 공식적으로’ 작성해야 합니다.

5. 신뢰도

전달하고자 하는 내용이 최우선입니다. 그러나, 철자의 맞춤법을 틀리거나 영어 단어의 스펠에 오류가 있다면, 팀 멤버들로부터 신뢰를 잃을 수 있다는 점을 명심해야 합니다. “철자도 틀리는 친구가 다른 아티클(Article )이나 페이퍼(Paper )를 정확히 읽어낼 수 있는 능력은 갖고 있나?”라며 연계되는 다른 능력에 대하여 의심을 받을 수 있기 때문입니다.

또한 게임 설계 문서는 내부에서 개발팀만 사용하지 않고 유통사, 투자자, 그리고 관리 부서에서도 열람할 수 있다는 사실을 항상 명심해야 합니다. 기본적인 맞춤법도 제대로 갖춰지지 않은 문서에 대하여 투자자들이 어떤 생각을 가질지는 스스로 반문하여 보십시오.

상황에 따라서, 내부 개발팀이 참조할 게임 설계 문서와 외부 투자자나 기타 관리 부서가 열람할 게임 설계 문서의 버전을 달리하여, 각 각 작성하는 경우도 많습니다. 내부 개발팀은 실무적인 ‘정보’를 원하고, 자신이 수행할 과업을 중심적으로 보는 반면, 투자자는 제품으로써의 게임의 사업성과 시장성을 중점적으로 판단하며, 관리부서는 철저하게 수익률 위주의 ‘단기적’인 시각에서 문제에 접근하기 때문입니다.