출처 : Tzvi freeman

나는 제품을 내놓아야 한다. 공포와 졸음 속에, 내 머리는 CRT에 처박히고 그 다음으로 내가 아는 것은 동으로 연기 속에서 지니가 램프 밖으로 나와 세가지 소원을 들어준다고 했다. 곧바로 나는 대답했다.

“나는 …… 재능 있는 ‘그래이트’한 팀, 숙련되고 헌신적인 엔지니어와 아티스트 (이해심 많은 아내를 포함해서)를 원해”
“충분한 시간과 돈”
“일류의 디자인 문서”

옛날 옛적에, 한 명의 프로그래머가 게임을 코딩하던 (어쩌면 아티스트 겸직의) 시절에, ‘네 맘대로’ 예산과 늘어지는 일정으로 일을 할 때. 문서는 심각하게 받아들여 질 필요가 없었다. 당신은 무엇을 만들 지를 알 수 있었고 그 것을 만들었다. 개발 도중 주요한 변화가 있었다면 불평할 사람은 당신 밖에는 없었을 것이다. 현재는, 완벽하고 읽기 쉬운 문서가 예산부족의 지옥과 천국의 길을 갈라놓을 수 있다.


시스템이 작동하는 방법

대부분의 게임은 개념과 디자인, 제작의 세 단계의 개발단계를 거친다. 이 단계들을 “번뜩이는 아이디어”, “문서” 그리고 “연마”로 생각해 보라.

첫 번째 단계에서는, 개요 문서는 당신에게 쓰는 편지 – 당신의 목표를 명확하게 잡아주어 초점을 잃지 않게 해준다. –와 시장에 판매할 사람들에게 보여주는 판매 도구의 두 가지 역할을 한다. 때때로, 이 단계는 실험할 기회를 주고 당신의 아이디어를 수정할 수 있는 프로토타입 같은 것을 포함한다.

디자인의 중간 단계는 아티스트, 애니메이터, 음악가, 그리고 기술자와의 무수한 회의를 포함한다. – 모든 것을 시도해 보고, 아이디어를 조직화하고 실현할 방법을 찾는다.

최종 단계에서, 제작 관리는 종종 특별한 대립이 없어도 유행에 상관없이 전문가에게 맡겨진다. 디자이너는 팀에서 빠질 수 없는 존재일지도 모르지만, 많은 사례에서 – 특별히 큰 회사에서 – 디자이너의 일은 외부 고문 정도로 끝나게 된다.

분명히, 디자인 문서는 프로젝트의 성장 방향에 지대한 영향을 미치는 부모와 같다. 비록, 디자이너가 프로젝트 매니저의 역까지 하기로 결정했더라 하더라도, 프로젝트를 마음대로 주무를 수 있다고 착각하지 말아야 한다. 대형 프로젝트는 재능을 가진 사람들이 많이 필요하다. 숙련된 프로그래머와 아티스트들은 자신들이 바라는 것을 게임에 넣으려는 경향이 있다. 만약 말을 만들 작정이라면, 아티스트는 유니콘을 생각할 지도 모르며, 프로그래머는 다양한 효과를 내는 낙타를 만들 생각을 할 수 있다. 좋은 문서는 당신이 계획한 것을 확실하게 말해 줄 수 있다. ‘그레이트’한 문서는 모두가 같은 느낌을 공유할 수 있게 해준다. 많은 사람들이 모여 만든 큰 재즈 밴드를 생각해보라 – 모든 사람의 생각이 일치하더라도, 애드립을 할 수 있는 기회는 충분하다.

문서는 일종의 현실과 상상 사이의 매개체이다. 그 것은 상상 속의 무엇인가를 현실에서 제어 가능한 것으로 바꾸어 주며, 그 결과물이 원래 생각했던 것이 될 것이다.

결론적으로, 신랄한 게이머가 입증할 속담을 기억하라 :

“그레이트한 예술은 디테일에 있다.”

눈부신 디테일은 처음 생각했던 대로 자연스럽게 일반적인 게슈탈트(경험의 통일적 전체)로 흘러간다. 그러나 한번 실천하려고 하면, 쉽게 활기를 잃을 수 있다.


도전

프로토타입을 만드는 것은 분명히 좋은 생각이다. – 하다못해 러프 스캐치라도. 더욱이 그런 세부 사항은 가치가 있다. 상상에 디테일을 좀 더 가질 수 있다면, 더더욱 훌륭한 작품이 될 것이다.

문서를 보며 일을 하는 것은 두 가지 면이 있다. 재미있는 게임의 개발은 재미있을 것이다.
많은 프로젝트의 가장 좋은 부분은 마감 공포의 열기 속에서 발견되었다. 진실로, 예산과 시간의 압력은 끊임없는 컨셉의 반복을 허락하지 않는다. 그러나 대작 게임이 건조기에서 나오듯, 예측할 수 있는 일이라는 것을 기대할 수는 없다. 디자인 문서를 만드는 도전은 프로젝트가 갑작스런 변경에도 원래의 방향과 목표를 잃지 않도록 해준다.
　

문서화의 3가지 단계
	내용	목적
1. 개요문서	장르; 목표 계층; 묘사; 가장 특징적인 기능; 시장 정보; 개발에 소요되는 기간과 비용	컨셉, 범위, 가치와 가능성을 정의; 고객, 퍼블리셔, 고용주, 그리고 밴쳐 캐피탈에 아이디어를 판매
2. 디자인문서	프로젝트의 디테일을 첨가하여 모든 것을 서술, 게임의 요소를 구현할 방법을 서술	만들고 싶은 제품 그대로 제작할 수 있게 해준다.
3. 제작문서	일정 관리표 (개인적인 스케쥴까지);업무 데이터베이스; 예산 스프레드시트; 기술적 사양서; Q/A 데이터베이스	디자인 도큐먼트를 시간과 예산에 맞추어 진행되도록 한다.

　 내용 목적
1. 개요 문서 장르; 목표 계층; 묘사; 가장 특징적인 기능; 시장 정보; 개발에 소요되는 기간과 비용 컨셉, 범위, 가치와 가능성을 정의; 고객, 퍼블리셔, 고용주, 그리고 밴쳐 캐피탈에 아이디어를 판매
2. 디자인 문서 프로젝트의 디테일을 첨가하여 모든 것을 서술, 게임의 요소를 구현할 방법을 서술 만들고 싶은 제품 그대로 제작할 수 있게 해준다.
3. 제작 문서 일정 관리표 (개인적인 스케쥴까지);업무 데이터베이스; 예산 스프레드시트; 기술적 사양서; Q/A 데이터베이스 디자인 도큐먼트를 시간과 예산에 맞추어 진행되도록 한다.


성공적인 디자인 문서를 위한 열 가지

1. 외관만을 설명하지 말고, 내부도 설명하라. 게임 개발이 자동 입/출력으로 만들어 지는 것이라면 – 코드를 짜서 그것이 어떻게 작동할 것인 지를 예견하는 것처럼 – 건조한 문체로 설명된 문서로 작업을 할 수 있을 것이다. 실제로 개발은 자신의 신념을 가진 많은 창조적 인재들이 이루어나간다. ; 대부분의 사람들은 자신의 신념을 자신이 하는 모든 것에 남겨 놓으려고 할 것이다.

작업의 진행은: 아티스트에게 스펙들을 제공해주고 그에 대한 토론을 한다. 그리고서는 프로그래머를 만나 그들에 스팩에 대한 일들을 처리해야 한다. 두 그룹은 모두 동의할 것이다.

그 날 밤, 새벽2시 쯤 되어서, C++의 성운이 서쪽에서 떠오를 때, 프로그래머들은 중년의 위기를 느끼며 생각을 시작할 것이다. “나는 이 짓을 계속해야 되나? 이것이 엄마가 나에게 원한 것인가? 왜 나는 다른 사람보다 디자인을 잘 하지 못하는 것일까?” 그리고서는 코딩작업을 계속할 것이다.

같은 시간에, 아티스트는 자신의 머신 앞에서 방금 일을 끝낸 상태일 것이고, 복잡한 3D 랜더링이 끝날 때까지 깊은 혼수 상태에 빠져들 것이다. Unsure and not really caring whether he's dreaming or is actually getting paid for all this, immersed in that wild world of artistic genius where fantasy and reality blend as one, the phosphors come together in ways previously unimagined - certainly not by you. (번역 안된 부분)

다음 날 아침까지, 말(馬)은 두 개의 낙타 혹을 가진 유니콘이 되어 있을 것이다. 창의적인 사람들에게는, 설명은 좋지 않다. 영감을 주는 것이 필요하다.

디자인 문서에서, 모든 문장과 뉘앙스에 들어있는 자세한 묘사에 대해서 스스로 만족하지 말아야 한다. 여유를 가지고 게임이 가져야 할 느낌을 묘사해야 한다. 각 요소의 뒷면에 숨겨진 용도와, 각각의 유저들이 가질 게임 경험, 그리고 다른 관점에서 게임의 내면(魂)을 상상하고 설명할 수 있어야 한다.

예를 들어, 당신이 슈팅 게임을 디자인한다고 했을 때, 확실한 도전에 직면하기 전에 플레이어를 훈련시키고 싶어할 것이다. 그래서 최소한의 위험성을 갖는 작은 도전들을 점점 커나가게 한다. 당신은 개발 팀 전체에게 이 것을 설명해야 할 것이다. 그리하면 그들은 왜 그런 방식으로 일을 진행시키는 지 이해하게 될 것이다. 그렇게 되면 설령 팀이 문서에 있는 당신의 아이디어들을 분해하고 가지고 놀 더라도, 결과물이 같은 느낌이나 비슷한 느낌으로 나올 것이라는 기대를 할 수 있다. 어쩌면 더 나를 지도 모른다.

2. 읽을 수 있도록 해라. 계속해서, 10포인트의 글자 크기와 라인당 80글자의 sans serif 폰트의 문서를 개발자들에게 제공하고, 그 것을 읽도록 요구하라. 문서와 함께 아스피린을 주고 싶을 지도 모른다. – 주문에 맞게 제작하려고 머리가 아픈 사람들을 위해서

아래는 좋은 페이지 레이아웃을 위한 지침이다.

많은 공백
본문에 Serif 폰트
제목은 Bold 폰트
단락 마다 공백을 넣는다.
글은 짧은 줄로
중요한 요소는 눈에 들어오도록 배치
계층적인, 2D 포맷을 사용하라

많은 사례들이 테이블, 스프레드시트, 차트로 표현될 수 있다. 그 것을 이용하고 확실히 눈에 띄도록 만들라.


3. 우선순위를 정하라. 이제는 또 다른 자아와 일하고 있다는 사실을 알아차렸을 것이다. 집요하게 확정된 게임 요소들에 테그를 붙이는 것의 진가를 무서울 정도로 알게 될 것이다. 실제로 게임제작에는 어떠한 보증도 없다, 그러나 테그를 적당히 드문드문하게 사용한다면, 그 항목을 주의를 끌 수도 있다. 그리고, 여기서 멈추지 않고. 아이디어에 테그를 붙이는 동안, 또한 하려고 마음먹은 일과 시간과 예산, 기술이 허용되면 할 일을 구분하고 싶을 것이다.

휴지통이 있다. – 훌륭한 듯 보였지만 대의를 위해 버려진 것들. 그 것을 명쾌하게 조사하고, 버려진 이유를 설명해라. 그렇게 하지 않으면, 그 것들이 되살아 날 수 있다. 여기에 테그의 리스트가 있다.

필요 불가결한
중요한
가능하면
기각된

이 것들을 나타내기 위해 시각적 심볼을 사용하고 싶을 지도 모른다. 문서가 언제나 컬러로 인쇄되는 것이 아니라면, 컬러에 의존하지 말아라.


4. 세부사항을 가져라. 세부항목이 없는 문서는 쓸모 없다. 일반적인 것은 누구에 의해서든 좋을 대로 해석할 수 있다. “살인하지 말지어다.”는 모세와 스페인 정복자들에게 서로 다른 의미가 되었다. 죽이지 말아야 할 사람과 상황을 세세하게 알려주는 것이 더 좋았을 것이다.

같은 이유로 문서도 그래야 한다. : 실제적인 디테일을 설명하고 예를 준다면, 아이디어는 더욱 구체적이 될 것이다-그리고 아이디어가 망가지는 일도 없을 것이다.

예를 들어, “청동으로 만든 새는 무적이다.”라고 말만하지 말고, 그것이 공격 당했을 때에 대한 모든 예에 대해 무슨 일이 이 창조물에 일어났는지, 그 후에 어떻게 회복되는 것인지 정확하게 설명해야 한다. 만약 애니메이터가 활기 없고 관록이 없는 사람이라면, 그가 기획서를 따르지 못할 것이란 걱정을 하며 지내야 할 것이다. 그러나 적어도 그가 명확하게 당신이 하려는 일을 알고 있다면 그가 변형시킨 부분은 게임의 다른 부분에 심각한 영향을 미치지 않을 것이다.

“여기서는 유저들이 벽을 오르기 위해서 점프 키를 방향키와 같이 눌러야만 한다.”라고 말만 하지 말아라. 플레이어들이 다른 일을 시도 했을 경우에 대해 벌어질 일을 설명하라. 왜 유저들이 당신이 제공한 콤비네이션(조작)을 알아낼 수 있을 지 당신이 생각하는 바를 표현해야 한다.

또 다시, 아티스트들은 다른 무엇인가를 완성해 낸다, 어쩌면 원래 상상했던 것보다 더 어울리는 무엇일지도 모른다. 그 것이 진정한 성공이다: 개발자들의 결과물이 문서에 표현할 수 있었던 처음의 생각에 비슷할 때. 그러나 이런 일은 먼저 명쾌하게 구상을 설명하지 않으면 일어나지 않는다.

그저 “Bongo Man은 Bongo Boy보다 힘이 세고, Bongo Boy는 빠른 반사신경을 가지고 있다.”라고 말하지 말라. 테이블, 스프레드시트, 차트를 사용하여 캐릭터의 실제적인 값(캐릭터의 움직임의 속도, 캐릭터의 체력, 공격력 등)들을 분배해라. 이 스프레드시트는 Q/A와 미조정(微調整) 단계에서 상당한 값어치를 지닌다.

그저 “모든 사람들이 게임을 쉽게 해결한다”고 말하지 말아라. 게임을 하는 집단에서의 예상되는 제품의 생명을 어떤 시점에서 다양한 기능들이 발견될 지를 나타내는 차트로 만들어라. 유저 테스트는 다음 게임을 디자인하는 데에 훌륭한 피드백을 제공해 준다.


5. 어떤 것은 반드시 증명되어야 한다. 가끔은 약간의 러프 스케치로도 충분하다, 그러나 아이디어가 당신의 프로젝트의 컨셉에 정말로 중요한 것이라면, 러프 애니메이션을 만들고 싶을 지도 모른다. 구성요소의 작용이 문서에 설명하기 너무 복잡하고 모호한 경우는, 프로토타입을 만들고 싶어 질 것이다. 프로토타입을 만드는 일은 프로젝트를 더 단순하고 훌륭하게 만들어 주는 좋은 솔루션이다.

애니메이션과 프로토타입을 만들었어도, 컨셉을 글로서 표현하라. 애니메이션은 기가바이트의 문자의 값어치를 가지지만, 글은 애니메이션으로는 불가능한 방법의 커뮤니케이션 방법이다. 글은 애니메이션을 보면서 놓칠 수 있는 중요한 뉘앙스를 전달해 줄 수 있다.


6. “WHAT”만이 아니라 “HOW”까지. 현실 세계에서는, “how”가 “what”을 결정한다. 예를 들어, 클레이 애니메이션을 만든다고 생각해보자. 이미지가 캡쳐되고 기록되는 과정을 살펴보자. 어떤 재질과 색갈이 배경이 될 것인가? 어떤 카메라가 왜 사용되어야 하는가? 캡쳐된 프레임을 가공하는 것은 어떤 단계인가? 그리고 계속되는 작업. 만약 당신이 질려버렸다면, 이러한 요소들이 결과에 심각한 영향을 미칠 수 있다는 것을 알게 될 것 이다.

또는, 모터 사이클 경주 게임을 만든다고 생각해 보자. 당신은 모터 바이크들의 pros와 cons를 다르게 하여 균형을 맞춰야 한다. 그리고 모터 바이크들의 밸런스를 보여주는 차트도 만들어야 한다. 그리고 나서 그런 조정이 필요한 지 발표해야 한다. 어떻게 조정을 할 것인지 발표하라-과정은 무엇인가? 게임의 메인 캐릭터가 오페라의 유령이라고 생각 해보자. 플레이어의 키보드가 어떻게 파이프 오르간처럼 배치되어야 할 것인지 설명하라. 각각의 키의 배치도를 제공하라. 얼마나 많은 채널의 사운드가 가능할 지 명확히 하라. 프로그래머와 이 문제를 끝까지 이야기하고 ‘어떻게’에 대한 모든 디테일을 작업하라. 그리고 그 것을 문서화하라. 두 가지 다른 “how”는 매우 다른 두 결과로 나타난다.


7. 대안을 제공하라. 프로젝트 관리자는 많은 시간을 간트 차트(간트가 발명한 일정표)와 퍼트(계획,조직의 관리기법)를 보며 지낸다. 개인적으로 필자는 이 일들이 게임 개발에 대체적으로 효과적이라고는 말할 수 없다. 왜냐하면 게임 개발에는 알 수 없는 것들이 많기 때문이다. 좀 더 근본적이고 선구적인 게임 테크놀러지는, 예측할 수 있는 개발 흐름이 될 것이다. 팀이 스케쥴의 마일스톤을 지켜나가기 위해서 당신이 할 수 있는 일은 한 가지 이상의 방법을 제공하는 것이다.

파이프 오르간’으로 돌아가보자. 당신의 기술자는 당신에게 사용자들(-한 시간을 준 50명의 사람들)의 마음에 깊이 다가갈 수 있는 파격적이고 장엄하며 거대한 힘을 가진 궁극의 방식을 말해줄 것이다. 모든 것이 우리가 검토한 것과 같을 때, 당신의 문서는 완벽한 것이 된다.

여기서 멈출 수는 없다. 이렇게 질문하라, “우리가 원하던 대로 정리된 다면, 어떤 것을 취해야 할까, 8채널 파이프오르간? 그리고 우리가 최소로 노출되기 위해 취해야 할 행동은 무엇인가? 또한 이것을 하기 위해 어떤 보조를 해야 하는가?” 그리고 나서 그 것들을 문서화하라.
FedEx 트럭이 마지막 수화물을 배달하려 도로를 달릴 때, “OK, C계획이다!” 하고 무사히 도망칠 수 있을 것이다.

내가 제품 디자인에서 범한 가장 큰 실수 중의 하나는 엔지니어들에게 “할 수 있겠어?”라고 물어본 것이다. 일류의 프로그래머에게 묻는 것이 아니라면 이런 질문은 쓸 모 없다. 좀 더 자세하게, 대답을 세가지 부류로 나누어 보겠다.

(형편없는 프로그래머) “물론, 문제 없습니다.”

(2류의 프로그래머) “아니오. 그렇게 되진 않습니다.”

(일류 프로그래머) “이런 식으로 할 수 있을 것 같습니다. 그리고 2주일이 걸릴 것 같습니다. 아니면 이런 식의 조그마한 변화를 만들어 낼 수 있을 것 같습니다. 이 것에는 5시간이면 됩니다.”

항상 한가지 이상의 대안을 요구하고 얼마의 시간이 걸릴지를 예측하라. 그런 다음 당신이 선호하는 것을 가리켜라 – 이런 일을 할 때는 시간이 많거나 그렇지 않을 때이다.


8. 생명을 주어라. 필자는 이미 영감을 죽이는 것과 당신 손에 살아 움직이는 재미있는 자발적인 창의력에 대해 경고했다. 당신은 문서를 변화에 적당하게 만들어야 할 것이다 – 당신이 고치던 (바라 건데 똑똑한) 다른 사람들이 고치던.

필자는 이 교훈을 British Columbia 대학의 음악 전공 과정에서 배우게 되었다. 수많은 삽질을 해대가며, 자랑스럽게 여기는 neo-renaissance 금관 악기의 5중주를 작곡했다. 담당교수도 그 것을 좋아했다. 우리가 리허설에 그 작품을 들고 갔을 때, 나는 공포와, 불신, 분노와, 의기소침의 계단을 10초간 걸어 올라갔다. 5중주 연주는 시작되었고, 곧바로 튜바 연주자의 신호에 의해 중단되었다. 녀석은 연필을 꺼내서 악보를 약간 고치고 나서, 모두들 연주를 계속했다. 그런 일은 여러 번 있었다.

담당 교수는, 갑작스런 내 건강 악화를 적어두며, 나에게 돌아서서 말했다. “걱정하지 말고, 그들은 모차르트 만큼 잘하고 있어. 그리고 그들은 항상 잘해왔지.”

사실은, 종이 위에서 좋아 보이는 것은 아무 것도 아니었다. 위대한 전문가는 객관적인 인지가 생길 때, 일을 수정한다. 그럼에도 불구하고, 당신은 디자인과 꿈이 무참히 강간 당하는 것을 목격하고 싶지는 않을 것이다. 오히려, 당신은 유기적인 성장을 기대할 것이다 – 아이디어는 외부에서 접목된 줄기나 가지 없이도 자연스럽게 당신이 심은 씨앗에서 자라날 것이다.

원래의 아이디어를 해치지 않고 개발 프로세스를 파괴하지 않고 변화를 받아 들일 수 있는 문서 만들 수 있는 팁들을 소개한다:

게임의 개념에 본질적인 관계를 지녀 절대로 변하지 말아야 하는 외관이 있다면 돌에 조각한 듯이 명확하게 해야 한다.
게임이 가져야 하는 필과 각각의 디테일의 목적에 대한 모두의 이해를 확실히 하라.
정보가 반복되었다면, 그것은 반드시 상호참조 되어야 한다. 그렇지 않으면, 변경 사항이 있을 때, 자가당착에 빠져 일을 끝내지 못할 것이다.
그리고 실제적인 실행을 위한 팁들을 소개하겠다:

변경사항이 암시 되었을 때, 디자인 문서를 다시 검토하여 게임의 ‘영혼’과 일치하는 지 보아야 한다.
이 것이 고립된 변화인지 아니면 주요하고 광범위한 효과를 가지는 것인지 검토해라. ("The Ecology of Improvement"를 보라) 작업 후반에 나온 사항이라면, 다음 프로젝트를 위해 모아 놓아라.
변화의 이유를 포함해서 디자인 문서를 업데이트 시켜라. 또는 변화가 없었다면, 왜 변화가 기각되었는지를 적어놓아라.변화와 삭제, 그리고 기각된 아이디어들은 같은 문제가 두 번 일어나는 것을 피하기 위해 마스터 문서에 보존되어야 한다.

모두가 같은 비전을 가지고 일해야 한다. 지나간 버전은 폐기 되어야 한다.
결정적이고, 중대하고, 긴급한: 디자인 문서는 한 사람의 관리하에 있어야 한다.


9. “어떠한 참고 사항도 찾을 수 없었기 때문에 이런 식으로 작업했다.”라는 말이 나와서는 안 된다. 필자는 페이지 수도 적혀있지 않은 문서를 보아 왔다. 그리고는 (그들은-문서작성자) 다른 사람들에게 지침을 따르지 않았다고 불평한다. 좋은 워드프로세서라면 자동으로 패이지 수를 매겨주고 문서에 인쇄해 줄 것이다. 어떤 것은 자동으로 장(章)이 바뀔 때 헤더를 바꾸어 주는 것도 있을 것이다. 중요한 부분에는 bold체를 사용해 바로 눈에 들어오게 해야 한다. 반복해서 읽고 싶은 만큼 문서의 다른 부분들을 읽고, 상호 참조하여 모든 내용을 골고루 업데이트 할 수 있어야 한다. 철저한 내용의 표를 만들어라.

어쩌면 HTML을 이용해 문서를 작성하고 링크를 제공하고 싶을 것이다. 어떤 혁신적인 워드프로세서들은 HTML 없이도 링크를 제공하는 기능을 가지고 있다. 그러나 대개 사람들은 오히려 하드 카피를 좋아한다는 것을 기억하라. (빈번한 시스템 충돌 후의 리부팅 시간에 읽을 수 있다.)
　

10. 좋은 조건으로 전달하라. 요컨대, 어떤 수단이던지 읽기 편하고 쓰기 쉽게 해주는 것이라면 해야 할 필요가 있다. 파일로 된 문서는 읽히지 않는다-별로 중요하게 보이지 않기 때문이다. 하드 커버로 장식되어 있는 것이 중요하게 보일 것이다.

복사를 필요로 할 것 같은 사람들의 명단을 만들고 보관하고 있어라. 각 페이지마다 날짜를 찍어서 인쇄해라. 구멍을 뚫고 바인더에 넣어 두어라. 책의 등과 커버에 라벨을 인쇄해라. 그것들이 업데이트 되었을 때는, 개정된 페이지를 모두에게 제공하도록 하라. 같은 관점에서 헌 책을 버리고 새 책을 제공해 주어야 할 필요가 있을지도 모른다.
　

정리

영화 제작자들은 대본을 사용한다. 건축가들은 청사진을 사용한다. 음악가들은 악보를 사용한다. 오래된 증거에 따르면, 우주의 창조자도 디자인 문서를 만들었다고 한다. – 나중에 그는 몇몇 예언자들에게 살짝 보이게 해주었다-태초에 “빛이 있으라!” 그래서 게임 개발자들은, 천상의 모델을 본떠, 똑 같은 일을 할 수 있게 되었다. 지금 실천하고 남은 여정을 순탄하게 하라.


Tzvi Freeman은 캐나다, 밴쿠버에 있는 디지팬 컴퓨터 게임 스쿨에서 게임 기획과 문서작성을 가르치고 있다. 그는 몇몇 상업적 게임을 디자인했으며, 다른 많은 게임의 컨설턴트를 하기도 했다. 그의 연락처는 TzviF@aol.com이다.


출처 : Tzvi freeman