쩌는 게임 기획서, 이렇게 쓴다(How to write great design documents) from GDC 2008 (Korean)
•Download as PPT, PDF•
170 likes•63,578 views
Recommended
More Related Content
What's hot
What's hot (20)
Similar to 쩌는 게임 기획서, 이렇게 쓴다(How to write great design documents) from GDC 2008 (Korean)
Similar to 쩌는 게임 기획서, 이렇게 쓴다(How to write great design documents) from GDC 2008 (Korean) (20)
More from Kay Kim
More from Kay Kim (20)
쩌는 게임 기획서, 이렇게 쓴다(How to write great design documents) from GDC 2008 (Korean)
- 1. 쩌는 게임 기획서 , 이렇게 쓴다 (How to Write a Great Design Document) 역자주 Damion Schubert Bioware Austin www.zenofdesign.com
- 2. 강연자 소개 (About Me) • 10 년 경력의 MMO 게임 디자이너 . – 대부분 경우 , 리드 게임 디자이너의 역할을 수 행 . • 매우 복잡한 시스템하에서 개발 . • 좋은 문서화 프로세스를 반기게 됨 . • ‘ 문서화 전문가 (doc guy)’ 가 되는 것이 자 신의 경력에 도움이 된다는 사실을 발견 . • 아직도 어떻게 해야 제대로 하는 것인지에 대해서 배우고 있는 중 .
- 3. 기획서에 대한 편견 (What I hear) • “ 기획서 작성은 시간 낭비야 .” • “ 아무도 기획서를 읽지 않는다고 .” • “ 우리 프로그래머들은 기획서 검토가 노 가다나 다름 없다고 하더군 .” 이런 이야기들은 문서화에 대한 일반론이 아니라 , 여러분이 작성한 문서에 대한 평판입니다 .
- 4. 잔혹한 사실들 (The Harsh Truth) • 분명히 모든 게임 디자이너들은 자신들의 생각을 다른 사람들과 공유하고 싶어합니다 . • 모든 프로그래머들 ( 과 다른 팀원들 ) 은 분 명 자신들이 만들고 있는 게 무언지 알고 싶어합니다 . • 그럼에도 불구하고 , 대부분의 기획서는 그 리 훌륭하지 못하며 , 대부분의 문서화 프 로세스는 재미를 발견해가는 게임 개발의 반복적인 속성을 무시하고 있습니다 .
- 5. 이 강연의 내용 (This Talk) • 이 강연의 목표는 무엇인가 ? • 왜 좋은 기획서를 찾기 힘든가 ? • 어떤 규칙에 따라 게임 기획서를 작성 하는 게 좋은가 ? • 리드들 (Leads) 역자주 이 게임 기획서 문서 화 절차를 마련할 때 , 어떤 점들을 고려해야 하는가 ?
- 6. 강연의 초점 : (Presentation Focus) • 임원용 요약문 혹은 비전 문서 (Executive Summaries/Vision Documents) 역자주 • 기획서 총람 혹은 상세 기획 검토 (Design Overview Documents/DDRs) • 테스트 계획 (Test Plans) • 시스템 기획 문서 (Systems Design Document) 다음은 제외 :
- 7. 좋은 기획서의 목표 (Goals of Good Docs) • 기획에 대한 합의를 담고 있습니다 . • 부서간 핵심 비전을 공유하는 통로가 됩니 다 . • 일정 관리를 손쉽게 해줍니다 . • 개발에 촛점 (focus) 을 제공합니다 . • 향후 업무간의 연관관계 및 기획상의 상충 되는 부분들을 미리 확인할 수 있게 해줍 니다 .
- 8. 좋은 기획서는 왜 그렇게 찾기 힘들까 ? (Why is good design documentation so rare?) • 기획서들이 너무 복잡하게 서로 연결된 시스템들을 다룹니다 . • 게임 디자이너들이 너무 많이 기획하는 경향이 있습니다 . – 시스템을 구축하는 것보다 , 기획하는 게 시간이 더 적게 걸립니다 . – “ 바보 대전 (Big Book of Stupid)” • 기획서들이 점진적이고 반복적인 개발 을 포용하지 않습니다 . • 프로젝트 진행에 따른 변화가 기획서에 거의 반영되지 않습니다 .
- 9. 좋은 기획서 작성을 위한 규칙 들 (Rules of good Design Documentation)
- 10. 다른 개발자들 왈 , (What other devs say:) “ 그저 짧고 , 목표가 분 명한 최신 문서를 좀 건내줘 .” “ 난 그냥 내가 할 일들 만 죽 나열된 목록을 원 해 .” “ 짧고 , 정확하고 , 코딩 할 부분을 쉽게 찾을 수 있는” .
- 11. 1. 독자를 파악하라 (Know your Target) • 기획서에 관심이 있는 사람들 : – 기획팀 . 기획에 대해 합의하려고 . – 프로그래밍팀 . 게임을 구현하려고 . – 프로듀서들 . 일정을 세우고 , 예산을 할당받 으려고 . – 품질보증 부서 (QA). 테스트 계획을 수립하려 고 . – 외부 파트너들 . 개발팀을 귀찮게 하려고 .
- 12. 1. 독자를 파악하라 (Know your Target) • 프로그래머들이 가장 중요한 독자입니다 . – 실제 게임을 구현하는 사람들이기 때문이죠 . – 또한 다른 독자들에게는 대체로 다른 문서들이 더 유용하기 때문이기도 합니다 . • 프로그래머들에게 무엇이 필요한지 물어보 세요 . – 만약 프로그래머들이 제 규칙들 중 하나를 무시 하라고 한다면 , 그렇게 하셔도 무방합니다 .
- 13. 2. 짧게 써라 (Keep it Short) 짧은 문서는 : •읽기 더 쉽고 , •쓰기 더 쉽고 , •관리하고 더 편하고 , •정치적으로 다루기가 더 용이하고 , •모순될 가능성이 더 적고 , •단순한 기획이 될 가능성이 더 높습 니다 .
- 14. 2. 짧게 써라 (Keep it Short) • 군더더기 (the fluff) 를 제거하 세요 . • 빈 항목들을 제거하세요 . • ‘ 복사해서 붙여넣기’를 피하세요 . • 그 자체로 분명한 시스템에 불필 요하게 덧붙인 설명을 제거하세요 .
- 15. 2. 짧게 써라 (Keep it Short) • 길드 초대 확인 UI. 플레이어가 길드를 생성하면 확인 UI 가 나타납니다 . 확인 UI 는 “이 길드에 가입하시겠습니 까 ?” 라고 묻고 , ‘ 확인’ 버튼과 ‘취소’ 버튼이 달려 있습니다 . • 확인 버튼 . 확인 UI 에는 확인 버튼이 달려 있고 , 이 동작을 승인합니다 . • 취소 버튼 . 확인 UI 에는 취소 버튼이 달려 있고 , 길 드 생성을 방지합니다 . • 닫기 버튼 . 확인 UI 의 오른쪽 상단에는 ‘ X’ 버튼이 달려 있고 , 취소 버튼과 동일한 역할을 합니다 . • Esc. 이스케이프를 누르면 이 동작을 취소하고 , 취소 버튼을 누르는 것과 같습니다 . 너무 깁니다
- 16. 2. 짧게 써라 (Keep it Short) • 길드 초대 확인 UI. 플레이어들이 길드에 초대를 받으면 , 확 인창이 열립니다 ( 일반 대화창 .doc 참조 ). 이게 더 좋습니다
- 17. 2. 짧게 써라 (Keep it Short) • 아이템 제작세 . 대장장이의 신 , 헤파이스토스는 아테네의 장인들에게 자신의 뜻을 가르쳤고 , 모든 장인들은 그의 위 대함을 경배합니다 . 그런 의미에서 아이템을 제작하고자 플 레이어라면 누구나 그의 은혜를 입기 위해서 헤파이토스의 신전에 십일조를 바쳐야 합니다 . 단 , 신들의 해머와 같은 아이템을 갖고 있으면 , 제작세를 면제받을 수 있습니다 . 누가 신경이나 쓰나요 ?
- 18. 2. 짧게 써라 (Keep it Short) • 아이템 제작세 . 아이템을 제작할 때마다 , 플레이어는 해당 지역의 신전에 십일조를 납부해야 합니다 . • 제작세 면제 . 플레이어들이 어떤 아이템들을 소지하고 있으면 , 제작세가 면제됩니다 . 이게 더 좋습니다
- 19. 2. 짧게 써라 (Keep it Short) • 명심하세요 : – 프로그래머들은 거의 언제나 짧은 목록을 좋아한답니다 . – ( 프로그래머들은 목록에 있는 것들 을 지워나가는 걸 좋아한다고 할 수 있죠 .)
- 20. 3. 우선순위를 부여하라 (Prioritize the Design) • 피처역자주 에 우선순위를 부여하고 , 단계별로 쪼갭니다 . • 문서에 후반부 피처를 명백히 분 리해놓으세요 .
- 21. 3. 우선순위를 부여하라 (Prioritize the Design) • 플레이어는 소지품 창에서 아이템을 장착할 수 있습 니다 . • 플레이어가 아이템을 장착하면 , 전투력이 변경됩니 다 . • 플레이어가 장비를 입으면 , 겉으로 표시됩니다 . • 플레이어들의 장비는 특수 효과가 부여될 수도 있습 니다 . • 플레이어는 자신의 방패에 자신이 속한 길드의 문장 을 그려넣을 수 있습니다 . 구려요 !
- 22. 3. 우선순위를 부여하라 (Prioritize the Design) • (1 단계 ) 플레이어는 소지품 창에서 아이템을 장착할 수 있습니다 . • (1 단계 ) 플레이어가 아이템을 장착하면 , 전투력이 변경됩니다 . • (2 단계 ) 플레이어가 장비를 입으면 , 겉으로 표시됩 니다 . • (2 단계 ) 플레이어들의 장비는 특수 효과가 부여될 수도 있습니다 . • (4 단계 ) 플레이어는 자신의 방패에 자신이 속한 길 드의 문장을 그려넣을 수 있습니다 . 아직도 별로입니다
- 23. 3. 우선순위를 부여하라 (Prioritize the Design) 기본 장비 ( 프로토타입 ) • 플레이어는 소지품 창에서 아이템을 장착할 수 있습니 다 . • 플레이어가 아이템을 장착하면 , 전투력이 변경됩니다 . • 플레이어가 장비를 입으면 , 겉으로 표시됩니다 . • 플레이어들의 장비는 특수 효과가 부여될 수도 있습니 다 . • 플레이어는 자신의 방패에 자신이 속한 길드의 문장을 그려넣을 수 있습니다 . 고급 장비 (2 단계 ) 장비와 길드 문장 (4 단계 ) 이게 더 좋습니다
- 24. 3. 우선순위를 부여하라 (Prioritize the Design) – 1 단계 : 피처를 프로토타이핑합니다 . • ( 게임 아이디어를 검증 / 시연하는 게 필 수 .) – 2 단계 : 핵심 피처를 구현합니다 . • ( 컨텐트 생성과 관련된 피처와 도구들이 여 기에 해당합니다 .) – 3 단계 : 출시 시점에 반드시 들어갈 것 들 . • (2 순위 피처들에 관련된 피처들이 포함 ) – 4 단계 : 희망 사항 , 아마도 확장팩 . – 5 단계 : 야 ~ 신난다 ~
- 25. 3. 우선순위를 부여하라 (Prioritize the Design) • 우선순위 결정은 단순히 각각의 피 처에 대한 것이 아니라 , 프로젝트 전체에 대한 것입니다 – 전체 피처 나 기획서는 2 단계 , 3 단계 혹은 4 단계의 피처들로 구성되어 있을 수도 있습니다 .
- 26. 4. 보여주어라 (Illustrate) • 백문이 불여일견 . • 요령 : – 유사한 피처들을 가진 다른 게임들 의 스크린샷 – Visio 다이어그램 – ‘ 예제’ 텍스트
- 27. 4. 보여주어라 (Illustrate) • 플레이어는 자신의 기술표에서 기술을 삭제할 수 있으며 , 특수 NPC(the ‘mindwiper’) 를 찾아가서 지우고 싶은 기술을 선택하면 됩 니다 . • 기술 삭제에는 금전적인 비용이 듭니다 . • 다른 기술의 전제 조건이 되는 기술은 삭제할 수 없습니다 . 조 밥은 기초 초능력과 고급 초능력을 잊어버리기로 결정했고 , mindwiper 를 찾아갔습니다 . 그는 기초 초능력을 삭제하려고 했 지만 실패했는데 , 그 이유는 고급 초능력의 전제 조건이었기 때 문입니다 . 그래서 이번에는 고급 초능력을 삭제한 후 , 기초 초능력을 삭제했고 , 둘 다 문제 없이 삭제되었습니다 . 예제
- 28. Visio 객체라 보이지 않습니다 다운로드받아서 보세요 . 4. 보여주어라 (Illustrate) 여기서 무엇이 잘못 되었을까요 ?
- 29. • 그림이 더 추상적일수록 , 독자가 자신의 관점을 투사하기가 더 쉬 워집니다 . • UI 아티스트에게 기능적으로 정 확한 것을 전해주고 싶겠지만 , UI 아티스트가 미학적인 부분을 결정하도록 놔두어야 합니다 .
- 30. Visio 객체라 보이지 않습니다 다운로드받아서 보세요 . 5. 다른 사람이 어떻게 작업해야 하는지 대해 시시콜콜 적지 말라 (Don’t tell others How to do their jobs) 믿기지 않을 수도 있지만 , 이게 더 좋습니다 .
- 31. 5. 다른 사람이 어떻게 작업해야 하는지 대해 시시콜콜 적지 말라 (Don’t tell others How to do their jobs) “ 퀘스트 .doc” • 퀘스트 변수는 캐릭터 오브젝트에 있는 비트 벡터의 연결된 목록에 저장됩니다 . 이건 여러분이 상관할 문제가 아닙니다 !
- 32. 5. 다른 사람이 어떻게 작업해야 하는지 대해 시시콜콜 적지 말라 (Don’t tell others How to do their jobs) “ 퀘스트 .doc” • 퀘스트 변수와 메모리에 대해서 고려할 사항들 . • 게임에는 약 2,500 개의 퀘스트들이 있습니다 . • 플레이어들은 진행중인 퀘스트를 한 번에 최대 20 개 까지 갖고 있을 수 있습니다 . • 플레이어들은 한 퀘스트에서 최대 10 번의 선택을 하게 되며 , 각 선택지에서 한 결정은 퀘스트가 끝 날 때까지 저장되어 있어야 합니다 . • 나중에 어떤 퀘스트를 완료했느냐에 따라서 컨텐트 의 잠금이 해제될 수 있으므로 , 각 퀘스트의 완료 상태와 그 결과가 저장되어야만 합니다 . 이게 여러분이 할 일입니다 . 나머지는 코더들이 해결하도록 하세요 .
- 33. 6. 사용자 스토리를 활용하라 (Use user stories) 스크럼의 사용자 스토리 규칙 ( 약자 INVEST 를 기억하세 요 ) •독립적인 (Independent) – 다른 사용자 스토리들과 겹치 지 않는 . •절충가능한 (Negotiable) – 세부사항이나 구현은 최종 사용자의 만족에 비하면 덜 중요함 . •사용자에게 가치있는 (Valuable) – 최종 사용자의 시각 에서 쓰여진 . •추정가능한 (Estimatable) – 프로그래머가 구조를 설계 하고 (architect) 일정을 잡을 수 있을정도로는 상세한 . •작은 (Small) – 1 주일 이상 걸리지 않는 . •검증가능한 (Testable) – 기획팀과 프로그래밍팀이 함께 완료여부를 확인하고 동의가능한 .
- 34. • 플레이어의 레벨이 상승할 때 , 플레이어는 효과음을 듣는다 . 너무 짧다 ! • 플레이어는 새로운 우주 대사 (ambassador) 를 선출할 수 있다 . 너무 의미가 넓어 ! • 플레이어의 레벨이 상승하면 , 플레이어는 효과음을 듣 고 , 파티클 효과를 보고 , 3 점의 속성 점수를 얻고 , 5 점의 기술 점수를 얻으며 , 10 레벨일 경우 특등석을 이 용할 수 있게 된다 . 너무 길다구 ! 6. 사용자 스토리를 활용하라 (Use user stories)
- 35. 6. 사용자 스토리를 활용하라 (Use user stories) • 경험치가 해당 레벨의 한도를 넘으면 , 플레이어는 레벨이 상승 합니다 . • 플레이어는 ‘딩’하는 효과음을 듣습니다 . • 플레이어는 파티클 효과를 봅니다 . • 플레이어는 자신의 능력치를 상승시킬 수 있는 속성점수 5 점을 얻습니다 . • 플레이어는 기술에 투자할 수 있는 기술 점수 3 점을 얻 습니다 . • 만약 플레이어가 10 레벨에 도달하면 , 특등석을 사용 할 수 있게 됩니다 ( 특등석 .doc 참조 ) 저희는 사용자 스토리 1 개에 몇개의 세부 요구사항을 추가 해서 사용하며 , 프로그래머가 대략 2~5 일 정도 작업할 분량입니다 . 모든 문장이 ( 개발자가 아닌 ) “ 플레이어”로 시작한다는 점을 기억하 세요 .
- 36. 7. 콘텐트로부터 코드를 분리하 라 (Separate Code from Content) • 제작 도구 . 어떤 제작 기술은 도구가 필요하며 , 없을 경우에는 그 기술을 사용할 수 없다는 메시지가 출력됩 니다 . • 제련 . 제련에는 대장장이의 망치와 부젓가락이 필요 합니다 . 고급 망치와 부젓가락이 있으면 , 더 다양 한 아이템을 만들 수 있습니다 . • 재단 . 재단사가 되려면 베틀이 필요합니다 . • 연금술 . 연금술에는 시험관 세트가 필요합니다 . 고급 시험관 세트를 갖고 있으면 , 더 다양한 아이 템을 만들 수 있습니다 . • 조각 . 조각에는 망치와 끌이 필요합니다 . 공포의 글머리 기호 !
- 37. 7. 콘텐트로부터 코드를 분리하 라 (Separate Code from Content) • 제작 도구 . 어떤 제작 기술은 도구가 필요하며 , 없을 경우에는 그 기술을 사용할 수 없다는 메시지가 출력됩 니다 . • 고급 도구 . 어떤 제작 기술은 더 강력한 도구를 사 용해서 더 강력아 아이템을 제작할 수 있습니다 . 요구사항을 딱 2 가지로 – 쉽죠잉 !
- 38. 7. 콘텐트로부터 코드를 분리하 라 (Separate Code from Content) • 사람들이 필요한 정보를 찾아 헤 매게 만들지 마세요 . • 컨텐트는 부록이나 표로 분리하세 요 .
- 39. 8. 좋은 서식에 시간을 투자하라 (Invest in a good Format) • 팀 공용 서식을 사용하세요 . • 보기 좋은 서체로 변경하세요 . • 가로 구분선을 사용하세요 . • 예제에는 설명선 (callout) 상자역자주 를 사용하세요 . • 글머리 기호를 사용하세요 . • 그러나 서식의 노예가 되진 마세 요 .
- 40. 뭐가 다른지 아시겠어요 ? (Viva la Difference) • 이것은 Microsoft 파워포인트의 기본 서 식입니다 – 그다지 예쁘지 않죠 , 그렇지 않나요 ? – 약간의 시간을 들여 기본 서체를 바꾸거나 , 워터마크를 더하는 것만으로도 여러분의 문 서가 전문가 삘이 나는데 큰 도움이 될 겁니 다 .
- 41. 9. 명확한 용어를 사용하라 (Use Clear Terminology) • 이 주문은 높은 DPS 를 갖고 있지만 , 증 오 감소 효과를 갖고 있어서 레이드에서 어그로를 감소시킵니다 . • Superchunk 하나당 최대 6 명의 spawn agent 만 있을 수 있습니다 . 독자가 이미 알고 있을 거라고 전제하지 마 세요 !
- 42. 8. 명확한 용어를 사용하라 (Use Clear Terminology) • 평범하고 쉬운 어휘를 사용하세요 . • 오덕 용어는 피해주세요 . • 회사 내부 용어도 삼가하세요 . • 새로운 용어를 사용할 때는 일관 적으로 사용하세요 . • 용어집 (glossary) 을 만드는 것 도 고려해보세요 .
- 43. 10. 중복을 제거하라 (Kill Redundancy) • 중복은 악이며 , 혼란을 야기하고 , 오류 를 발생시킵니다 “ 전투 능력치 .doc” • 근력은 플레이어의 공격력을 근력 /2 만큼 증가시킵니다 . • 민첩성은 플레이어의 정확도를 민첩성 /3 만큼 증가시킵니다 . • 체취는 플레이어가 NPC 를 유 학할 확률을 체취 /2 만큼 감소 시킵니다 “ 아이템 .doc” • 근력은 플레이어의 공격력을 근력 /2 만큼 증가시킵니다 . • 민첩성은 플레이어의 정확도 를 민첩성 /3 만큼 증가시킵니 다 . • 체취는 플레이어가 NPC 를 유 학할 확률을 체취 /2 만큼 감 소시킵니다 중복된 부분을 제거하세요 !
- 44. 10. 중복을 제거하라 (Kill Redundancy) • 중복은 악이며 , 혼란을 야기합니다 . “ 전투 능력치 .doc” • 근력은 플레이어의 공격력을 근력 /2 만큼 증가시킵니다 . • 민첩성은 플레이어의 정확도를 민첩성 /3 만큼 증가시킵니다 . • 체취는 플레이어가 NPC 를 유 학할 확률을 체취 /2 만큼 감소 시킵니다 “ 아이템 .doc” • 마력이 부여된 아이템을 착용 할 경우 , 플레이어의 능력치 가 증가할 수 있습니다 . 자 세한 것은 전투 능력치 .doc 를 참고하세요 . 한 문서를 ‘주’ 문서로 만들고 , 다른 문서 가 그 문서를 참조하게 하세요 .
- 45. 11. 애매한 표현 금지 (No Weak Language) • 플레이어는 이성 NPC 에게 구애할 수 있을지도 모릅니다 . • 훗날에는 , 낭만적인 사랑의 노래를 불러서 여성을 꼬실 확률을 높힐 수 있는 기능을 추가할지도 모릅니다 . • 이게 구현이 되면 , 아마도 플레이어 들은 자신의 사랑 노래를 작곡할 수도 있습니다 . 금지 !
- 46. 11. 애매한 표현 금지 (No Weak Language) NPC 와 연애하기 ( 프로토타입 ) • 플레이어는 대화를 통해서 이성 NPC 를 꼬실 수 있습니다 • 또한 플레이어는 자신이 배운 노래를 불러줌으로써 , 이성 NPC 를 꼬실 수 있습니다 . 연애 고급 (4 단계 ) • 플레이어는 연애 시스템에서 사용할 자신만의 노래를 만들 수 있습니다 . 이게 더 좋습니다 !
- 47. 11. 애매한 표현 금지 (No Weak Language) • 명확한 평서문을 사용하세요 . – 금지어 : “ 아마도” , “ 가능할 수도” 혹은 “그 럴지도 모릅니다” – 심지어 “할 수도 있습니다”도 피하세요 . • 여러가지로 해석가능한 표현을 쓰지 마세 요 . • “ 우리”라는 말을 쓰지 마세요 . • 기획에서 방향을 명확히 선택하세요 • ‘ 아마도’에 해당하는 피처는 개발 후반으 로 미루세요 .
- 48. 12. ( 결정의 ) 이유를 포함시켜라 (Capture your Reasoning) • 그러나 구분해 두어라 . • 플레이어는 아이템을 땅에 떨어뜨릴 수 없습니다 . 이렇게 하면 지저분한 것들이 눈에 않고 , 수백 개의 아이템 들이 걸리적 거리지 않게 해줄 겁니다 . 삐빅 !
- 49. 12. ( 결정의 ) 이유를 포함시켜라 (Capture your Reasoning) • 그러나 구분해 두어라 . • 플레이어는 아이템을 땅에 떨어뜨릴 수 없습니다 . … 자주 질문하는 것들 : 왜 플레이어는 아이 템을 땅에 떨어뜨릴 수 없나요 ? 이렇게 하면 지저분한 것들이 눈에 않 고 , 수백 개의 아이템들이 걸리적 거 리지 않게 해줄 겁니다 . 이게 훨씬 더 좋습니다 !
- 50. 12. ( 결정의 ) 이유를 포함시켜라 (Capture your Reasoning) • 이유를 포함시키는 것은 장기 프로젝 트에 유용한데 , 그 이유는 왜 그렇 게 하기로 했는지를 말 그대로 종종 잊어버리곤 하기 때문입니다 . • 더 나아가 , 이유를 포함시키면 같은 이슈에 대해서 논쟁이 재발하는 횟수 를 줄여줍니다 .
- 51. 리드들을 위한 조언들 (Tips for Leads)
- 52. 1. 점진적이고 반복적인 기획을 수 용하라 (Embrace Iterative Design) • 바로 다음에 올 개발 단계를 아주 상세하게 기획하세요 . • 다른 개발 단계는 맨 - 먼스 수준 으로 간단하게 기획하세요 . • 한참 뒤에 개발할 피처에 너무 집 착하지 마세요 . • 기획이 바뀌고 , 반복적으로 개발 될 때마다 , 문서를 재검토하세 요 .
- 53. 2. 검색가능하게 하라 (Make it Searchable) • 기획서는 개발자들이 필요한 것을 찾 을 수 있을 경우에만 자료로서 가치를 가집니다 . • 추천하는 방법들 : – 위키 (Wiki) 역자주 – 데스크탑 검색 (Desktop Search) – 기획 바이블 (Design Bibles) 역자주
- 54. 3. 가능한 자동화하라 (Automate what you can) • 증거가 필요하신가요 ? – Thottbot, Wowhead, Allakhazam역자주 • 문서 자동화의 장점들 : – 정확도 ( 특히 , 포스트스크립적으로 ) – 검색 가능 – 감사 (auditing) 나 보고서를 추가하기 쉬움
- 55. Visio 객체라 보이지 않습니다 다운로드받아서 보세요 . 4. 기획서는 협업의 산물이다 (Design Documentation is a collaborative Process) 외부의 비평없이 허공 에서 쓰여진 기획서는 ‘적과의 접전’에서 거 의 살아남지 못합니다 .
- 56. 5. 언제나 개시 회의로 시작하라 .(Always start with a Kickoff Meeting) • 게임 디자이너들이 리드 게임 디자 이너를 만나서 , 다음 3 가지 질문 에 대답을 합니다 : – 이 시스템의 목표는 무엇입니까 ? – 이 문서가 반드시 답변해주어야 하는 질문들 ( 담고 있어야 하는 내용 - 역 자주 ) 은 무엇입니까 ? – 이 시스템이 얼마나 더 복잡해질 수 있을까요 ?
- 57. 개시 회의 (The Kickoff Meeting) • “ 이 시스템의 목표는 무엇입니까 ?” – 해당 시스템의 존재 가치를 찾습니다 . – 울타리 기둥 (fencepost) 문제역자주 를 결정하도록 도와줍 니다 . • 예시 : 두 목표들은 가치가 있지만 , 사전 에 충분히 고려하지 않을 경우 서로 충돌됩 니다 : – “ 아이템 제작은 시간을 때우기 위한 부업으로 서 , 필드에서도 할 수 있다 .” – “ 대장장이는 작업장과 대장간을 소유할 수 있 고 , 다른 플레이어를 도와줌으로써 부와 명성을 얻을 수 있다 .”
- 58. 개시 회의 (The Kickoff Meeting) • “ 이 문서가 반드시 답변해주어야 하는 질문들은 무엇입니까 ?” – 결국 모든 시스템들은 서로 연관되어 있기 때문에 , 이 문서가 어디까지만 다룰 것인 지역자주 를 결정하는 것이 중요합니다 . – 리드들 (Leads) 이 문서화를 일정에 포함시키 도록 합니다 . – 졸속 기획 (jumping the gun) 을 방지합니다 . – 다른 시스템이 해야 할 일을 가로채는 일 (claim jumping) 을 방지합니다 . – 해당 피처 (feature) 역자주 의 첫 버전에 집중 합니다 .
- 59. 개시 회의 (The Kickoff Meeting) • “ 얼마나 더 복잡해질 수 있을까요 ?” – 단순한 표현 (Token Representation). 우리는 텍스트 상자에 글 머리 기호 기능을 추가하길 원합니다 . – 경쟁력을 갖출까 (Competitive). 우리는 1 등이 하고 있는 것을 약간 개선하길 (minor tweaks) 원하지만 , 너무 위험한 선택을 하길 원치는 않습니다 . – 대안이 될까 (Alternative). 엄청 크진 않지만 , 경쟁자와 는 확연히 다르게 합니다 . – 혁신적이어야 하나 (Innovative). 우리는 이 피처를 구현 해서 , 경쟁자들을 밟아버리고 , 그들의 연인이나 부인의 통곡을 들을 것입니다 .
- 60. 6. 승인 과정을 거쳐라 (Have an Approval Process) • 기획을 단계별로 걸러내세요역자주 – 리드 게임 디자이너가 먼저 승인합니다 . – 그 다음에 기획 부서가 승인합니다 . – 마지막에는 시니어 리드들 / 다른 부서들 (Senior Leads/Cross-Team) 이 승인합니다 . • 이렇게 하면 , 기획 부서가 완성된 기획에 대해서 하나의 목소리를 낼 수 있게 됩니다 . • 항상 새로운 절차를 도입하고 운영하는 것 은 어려운 일이지만 , 한 번 탄력을 받고 나면 동료들이 가치를 인정하게 될 겁니다 .
- 61. 7. 전문가와의 상담을 의무화하라 (Mandate expert consultation) • 게임 디자이너가 ( 주변 사람과 상의 없이 ) 고립된 상태로 문서를 작성하는 것을 금지 하세요 . 반드시 내부 전문가를 찾아야 합 니다 . – 팀 내의 다른 게임 디자이너들 . – 해당 피처를 구현할 프로그래머들 . – 특수한 전문 지식 / 기술을 가진 아티스트나 프 로그래머 – 도구에 대한 문서라면 , ‘( 그 도구의 ) 사용자들 ’ – 다른 프로젝트의 개발자들 ( 그들의 통찰이 특별
- 62. Visio 객체라 보이지 않습니다 다운로드받아서 보세요 . 8. 진척 상황을 시각화하라 (Have a visual Method of Tracking Progress) ( 저는 포스트 - 잇을 좋아합니다 )
- 63. 9. 변경 승인 절차를 만들어라 . (Have a change Process) • 게임이 반복적으로 개발되면서 , 기획 이 바뀌게 됩니다 . 팀의 의사결정자 들에게 이 변경사항들을 알리는 절차 가 필요합니다 . • 수석 리드들의 승인이 필요한 변경 사 항이 발생했을 때 , 보통 리드 게임 디자이너가 중재자가 됩니다 .
- 64. 10. 가끔 프로세스를 재검토하라 (Occasionally audit the process) • 기획 문서화 절차는 반드시 팀에게 효과가 있어야 합니다 . 만약 팀이 문서화 절차가 억압적이라고 여긴다면 , 그 절차는 결국 폐지될 겁니다 . • 다음을 절대 잃어서는 안됩니다 : – 간단 명료 – 항상 최신을 유지 – 프로그래머 친화적 • 4-6 주마다 , 자신 ( 혹은 동료 프로그래머 들 ) 에게 어떤 게 효과가 있거나 없는지 물
- 65. 질문이 있으십니까 ?
- 66. 부록 : GDC 2007 에는 있었지만 , GDC 2008 의 앵콜 강연에서는 사라진 슬라이드들
- 67. 아이디어 (The Idea)
- 68. 5. 늘 연구하라 (Research) • 이전 게임들을 살펴보세요 . – 특히 , 실패작들을 ! • 게임이 아닌 분야의 정보들도 살펴보세요 . – 만약 요리 게임을 만들고 있다면 , 요리의 철인 (Iron Chef) 역자주 를 시청하세요 ! • 해당 분야의 전문가와 만나보세요 . – 다른 팀이나 다른 회사에 있는 분들이라도요 !
- 69. 6. 브레인스토밍하라 (Brainstorm) • 많은 브레이스토밍 기법들을 모두 같 은 일반적인 원칙들을 공유하고 있습 니다 : – 여러 명의 참가자들 (6-8 인 ). – 틀에서 벗어나서 생각하길 권장하세요 . – 나쁜 아이디어란 없습니다 . – 사람들의 공감을 얻은 아이디어를 찾아내 세요 .
- 70. 7. 약점을 제거하라 (Cull the Weak) • 이제 , 어떤 아이디어는 나쁜 아이디어입니다 . • 제거할 아이디어들 : – 구현 불가능한 , – 너무 야심찬 , – ( 게임 / 목표 ) 와 일치하지 않거나 , 서로 상충하는 , – 그냥 말그대로 이상한 아이디어들 . • 개시 회의 (kickoff meeting) 때 , 도출된 결론들 을 기준 (your razor) 으로 사용하세요 . • 아주 흥미로운 (intriguing) 아이디어는 어딘가 창고 같은 곳에 보관하고 싶을 수도 있습니다 . • 살아남은 아이디어들에 우선순위를 매기기 시작하 세요 .
- 71. 8. 단순하게 만들어라 (Keep it simple) • 최소한 처음에는 그렇게 시작하세요 . • 핵심에 집중하고 , 가능한 빨리 플레이테스 트가 가능한 것을 만드는 데 힘을 기울이세 요 . • 피드백을 수렴해가며 반복적으로 기획하다 보면 기획이 점점 복잡해질 겁니다 . 만약 다른 사람들이 여러분의 기획서를 읽고 뭐라고 말할까 두려워하고 있다면 , 그것은 분명 기획서가 너무 복잡하거나 너무 이상 하기 때문일 겁니다 .
- 72. 9. 반복적인 개발을 수용하라 (Embrace Iteration) • 어떤 게임 기획도 현실과 부딪혀서 상처 입지 않고 살아남을 수 없습니다 . • 게임 기획의 어떤 부분에도 미련을 갖 지 마세요 . • 일단 여러분의 기획이 구현이 되면 , 다시 갈아엎을 준비를 하십시요 (prepare to iterate).
- 74. 1. 개시 회의를 의무화한다 (Enforce the Kickoff Meeting) • 3 가지 질문 : – 목표는 무엇인가 ? – 이 기획서가 다루어야 할 범위는 어디까지 인가 ? – 이 피처의 수용가능한 야심적인 목표는 무 엇인가 ? • 목표는 잘 정의된 방식으로 ‘상자의 경 계’를 정함으로써 , 게임 디자이너들에 게 자율권을 부여해줍니다 .
- 75. 9. 아이스 께끼를 조심하세요 (Be Prepared to drop Trou) • 언제 외부인들이 기획서를 보고 싶어할지 미리 알 수가 없습니다 . • 문서는 반나절 정도 미리 알려주면 제공가능해야 합니다 . • ( 혼란을 야기시키실 수 있으므로 기획에 대한 ) 기획팀 내부의 갈등이 기획서에서 드러나지 않도록 하거나 , 손쉽게 삭제할 수 있어야 합니다 . 결코 외부에 알려서는 안되는 게 있는지 , 반드시 사 전에 프로듀서들과 확인하세요
- 76. 10. 유효 기간을 고려하라 (Consider expiration Dates) • 길을 잃은 아이디어들 : – 모든 문서는 6 개월까지만 유효하며 , 그 다음 에는 게임 디자이너들이 그 문서들을 재검토하 고 아직도 유효한지 확인해야 합니다 • 기획상의 변경을 확인합니다 • 우선순위의 변경을 확인합니다 • 구현된 기획이 있는지 확인하고 , 제대로 구현되었는 지 확인해줍니다 • 검토해야 할 문서가 많을수록 더 힘듭니다
- 77. 문서를 최신 상태로 유지할 필요가 있을까 ? (Does your documentation need to stay up to date?) • 여러분의 상황에 따라 다릅니다 : – 대형 프로젝트에는 필요합니다 . – 긴 수명을 가진 게임들 ( 라이브 서비스나 확장 판 ) 이나 이직률이 높은 팀들도 마찬가지입니다 . – 만약 외부 파트너들이 자꾸 귀찮게 군다면 , 역 시 필요합니다 .
- 78. 스크럼과 문서화 (Scrum and Documentation)
- 79. 짤막한 소개 (Brief Overview) • 여러 분야의 전문가들로 구성된 작은 팀들 • 자신의 운명을 스스로 관리 • 구현할 피처들과 세부 피처들로 구성된 제 품 백로그 – 제품 책임자 ( 보통 프로듀서나 수석 게임 디자 이너 ) 가 우선순위를 결정 – 핵심은 팀은 항상 가장 중요한 것을 먼저 작업 한다 • 스크럼은 ‘가벼운 문서화’를 지향 – 심지어 소수의 지지자들은 ‘문서 자체를 만들지 말아야 한다’고 주장
- 80. 그래서 어떻게 바뀌었을까 ? (So what does this change?) • 많이 놀라울 정도는 아님 – 아직도 배급사와 외부 계약 파트너를 만족시키 기 위한 문서화가 필요 – 아직도 QA 테스트 계획수립을 위한 문서화가 필요 – 아직도 아이디어를 산출하는 절차가 필요 • 촛점의 변화 – 반복적인 개발과 사후 - 구현이 중요해짐 . – 비 - 프로그래머 독자들이 중요해짐 . • 가장 중요한 변화 – 문서화에 사용자 스토리를 사용
- 81. • 번역 – 김기웅 ( http://twitter.com/KayKimTwit ) • 원문 출처 : – GDC 2008 & GDC Vault: http://goo.gl/Y1780
Editor's Notes
- [ 역자주 ] 원래 2007 년 번역을 시작할 때 “위대한 ( 게임 ) 기획서를 쓰는 법”으로 번역했지만 , 2013 년에 먼지를 털어내고 다시 번역을 시작하면서 ‘ 2013 년 삘’을 살리기 위해서 이렇게 번역했다 . 절대 유행에 영합하려고 한 거 아니라능 . ( 진짜 ?)
- === About Me MMO Designer for 10 years Lead Designer for most of them Used to working with very complex systems Grew to appreciate good documentation processes. Found being the ‘doc guy’ very good for my career Still learning about how to do it right
- === What I hear “ Design documentation is a waste of time” “ No one reads design docs.” “ My programmers find reviewing design documents a total time sink.” This is probably a statement about your documentation, not a true testament of documentation in general.
- === All designers should want to share their ideas All programmers (and other team members) should want to know what they’re building. On the other hand, most design documentation isn’t very good, and most documentation processes ignore the iterative nature of finding fun.
- [ 역자주 ] 리드들 (Leads) 이란 , 각 부문의 책임자들로 , 예를 들면 , 리드 게임 디자이너 , 리드 아티스트 , 리드 프로그래머들을 말한다 . 한국식으로 말하면 , 팀장에 가까우나 , 그 역할이 다소 다른 면이 있다 . === The Goals The Problem Generating The Idea Function Form The Process The Scrum
- [ 역자주 ] 각 문서들의 의미와 역할에 대해서는 게임 제작 최전선 ( 2 부 8 장 게임 디자인 문서와 “ 3 부 14 장 비전 문서” ) 을 참고하세요 : http://book.naver.com/bookdb/book_detail.nhn?bid=1556081 === Presentation Focus: Systems Design Document Talk is not about: Executive Summaries/Vision Documents Design Overview Documents/DDRs Test Plans
- === Goals of Good Docs Capture design consensus Primary vision conduit between departments Aid in scheduling Offer focus Give visibility to future dependencies and design conflicts
- === They deal with complex, interconnected systems. Designers tend to overdesign. Systems take less time to design than to build. “ Big Book of Stupid” They don’t embrace iteration. They are rarely kept up to date as the project progresses.
- === “ Just give me something that’s short, targeted, and up-to-date.” “ Short and accurate, easy to find the code bits”. “ I just want a bullet list of things to do.”
- === People interested in a design doc: Design team. To achieve design consensus. Programming team. To build the game. Producers. To schedule and go get money. QA. To build test plans. External partners. To reach quota of annoying demands.
- === Programmers are the most important target. It’s how the game gets made. Often, other documents are more useful for other audiences. Ask them what they want If they say to ignore one of my rules, do it!
- === Easier to read Easier to write Easier to maintain Easier to handle politically Less likely to be contradictory More likely to be simple designs
- === Kill the fluff Kill empty sections Kill ‘cut and paste’ stuff Kill unnecessary text of obvious systems
- === Guild Invitation Confirmation UI. Players get a Confirmation UI when creating a guild. This asks “Do you really want to join this guild?” and has an ‘ok’ button and a ‘cancel’ button. OK Button. The confirmation UI has an OK button, which confirms the transaction. Cancel. The confirmation button has a cancel button, which prevents the guild from being formed. Close button. There is an ‘X’ button in the upper right hand corner of the UI, which is identical to the cancel button. Esc. Pressing escape will cancel the transaction, and performs identically to hitting the cancel button.
- === Guild Invitation Confirmation UI. Players get a confirmation dialogue when invited to a guild (see CommonDialogs.doc ).
- === Crafting Tithe. Hephaestus, the god of the forge, has instituted his will upon the craftsmen of Athens, and all are humbled by his greatness. As such, any players who wish to craft any items must pay a tithe to the temple of Hephaestus to earn his favor, unless he has found an item like the Hammer of the Gods, which allows the player to bypass these tithes.
- === Crafting Tithe. Players who craft items must pay a tithe to the local temple when crafting. Bypassing tithes. Certain tools allow the player to bypass the tithe.
- === Remember: Programmers almost always want a short bullet list
- [ 역자주 ] 피처 (feature) 란 , 해당 게임의 특징을 말한다 . 그것은 기획의 어떤 요소 ( 예 : 공선전 ) 일 수도 있고 , 코드상의 기능 ( 예 : 100 만 폴리곤 ) 일 수도 있으며 , 그래픽 ( 예 : 김형태 씨의의 원화 ) 이나 음악과 관련된 것 ( 예 : 뉴욕 필 하모니 오케스트라가 참여한 OST) 이거나 , 홍보 요소 ( 예 : 유명 게임의 후속작 ) 일 수도 있다 . === Give the features a priority, break them into phases Be sure document clearly separates out later phase features.
- === Players can equip items on the inventory screen. Equipped items change their combat stats. Player equipment is visible when worn. Player equipment may be enchanted with special effects Players may have their guild insignia drawn on their player shields.
- === (Phase One) Players can equip items on the inventory screen. (Phase One) Equipped items change their combat stats. (Phase Two) Player equipment is visible when worn. (Phase Two) Player equipment may be enchanted with special effects (Phase Four) Players may have their guild insignia drawn on their player shields.
- === Basic Equipment (Prototype) (Phase One) Players can equip items on the inventory screen. (Phase One) Equipped items change their combat stats. Advanced Equipment (2 단계 ) (Phase Two) Player equipment is visible when worn. (Phase Two) Player equipment may be enchanted with special effects Guild Insignia on Equipment (4 단계 ) (Phase Four) Players may have their guild insignia drawn on their player shields.
- === 1 단계 : Prototype feature. 2 단계 : Core feature. 3 단계 : Must be in shipped product 4 단계 : Wishlist, possibly expansion 5 단계 : Yeah, right
- === Prioritization is across the project, not the feature – an entire feature or document may be full of phase 2, phase 3, or phase 4 features. === Prioritization is across the project, not the feature – an entire feature or document may be full of phase 2, phase 3, or phase 4 features.
- === A picture is worth a thousand words. Tactics: Screens of other games with similar features. Visio diagrams ‘ Example’ text
- === Players can remove a skill in their skill tree by going to a special NPC (the ‘mindwiper’) and selecting that skill. Removing a skill has a monetary cost in credits. The player cannot remove a skill that is a prerequisite for another skill in his skill tree. Joe Bob decides that he wants to unlearn Basic Psionics and Advanced Psionics, so he goes to a mindwiper. He tries to remove the Basic Psionics skill tree, but the transaction fails, as it is a prerequisite for Advanced Psionics. So Joe Bob unlearns Advanced Psionics and then Basic Psionics. In this case, both boxes are successfully removed.
- === The more abstract a picture is, the easier it is for a reader to project his own viewpoint. You want to give your UI artist something that is functionally accurate, but let HIM decide the aesthetics.
- $
- === “ Quests.doc” Quest Variables will be stored in a linked list of bit vectors on the character object.
- === “ Quests.doc” Memory considerations of quest variables. There will be approximately 2500 quests in the game. Players may have 20 open quests at a time. Players can make up to 10 decision points in one quest, the status of which must be stored until the quest is completed. Players may find content later which is unlocked by quests they have already completed – the completion state (and outcome) of a quest must be stored.
- === I ndependent – doesn’t overlap other user stories N egotiable – details and implementation are less important than end user satisfaction. V aluable – written with the end user in mind. E stimatable – detailed enough for programmers to architect & schedule S mall – no more than a week. T estable – design and programming can agree when it’s done.
- === The player hears a sound effect when he gains a level. Too small! The players can elect a new space ambassador. Too boundless! When the player gains a level, he hears a sound effect, sees a particle effect, gains 3 attribute points, gains 5 skill points and gains access to a prestige class if he is level 10. Too long!
- === We use 1 user story with subrequirements, equal to 2-5 programming days of work. The player gains a level when he crosses the experience point threshold. The player hears a ‘ding’ sound effect. The player sees a particle effect. The player gains 5 attribute points to be spend on his stats. The player gains 3 skill points to be spent on his skill tree. If the player has reached level 10, he can apply his Prestige Class (see PrestigeClasses.doc )
- === Scary wall of bullet points! Crafting tools. Some crafting skills will require crafting tools to be used, or the player will get an error message saying he cannot use that skill. Blacksmith. Using blacksmith skills requires a blacksmith hammer and tongs. Players may eventually find more advanced hammer and tongs, that give access to more crafting options. Tailor. Being a tailor requires a loom. Alchemy. Alchemy requires a test tube set. Players may eventually find more advanced test tubes, that give access to more crafting options. Sculpture. Sculpture requires a hammer and chisel.
- === Only two requirements – easy! Crafting tools. Some crafting skills will require crafting tools to be used, or the player will get an error message saying he cannot use that skill. Advanced tools. Some crafting skills let the player craft more powerful items with more powerful tools. Crafting Skills and Tools Skill Tools Advanced Tools Smithing Hammer and Tongs Yes Tailoring Loom Alchemy Test Tube Set Yes Sculpture Hammer and Chisel
- === Don’t make people hunt for the information they want. Separate content into appendices, or into tables.
- [ 역자주 ] callout 상자란 , 짧막한 설명을 선이나 화살표와 함께 글의 일부를 설명하거나 독자의 주의를 끌기 위해서 사용한다 . http://en.wikipedia.org/wiki/Callout === Use a team template Change the font Use horizontal lines Use callout boxes for example Use bullet lists Don’t be a slave to your format
- === This is the default Microsoft Powerpoint template Not very good looking, is it? Taking a little time to change out your fonts or add a watermark can have a huge impact on how professional your documents feel.
- === This spell has a high DPS, but also has a hate reduction component to reduce aggro in raids. There can only be six spawn agents per superchunk.
- === Use plain english Avoid Wonky terms Avoid company-specific terms Use new terms consistently Consider a glossary
- === Duplication is the devil, leads to confusion, update errors. Redundant department of Redundancy “ CombatStats.doc” Strength increases the player’s damage by STRENGTH/2. Dexterity increases the player’s accuracy by DEXTERITY/3 Body odor reduces the player’s chance to seduce NPCs by BODYODOR/2 “ Items.doc” Strength increases the player’s damage by STRENGTH/2. Dexterity increases the player’s accuracy by DEXTERITY/3 Body odor reduces the player’s chance to seduce NPCs by BODYODOR/2
- === Duplication is the devil, leads to confusion. Make one doc the owner, point others to it. “ CombatStats.doc” Strength increases the player’s damage by STRENGTH/2. Dexterity increases the player’s accuracy by DEXTERITY/3 Body odor reduces the player’s chance to seduce NPCs by BODYODOR/2 “ Items.doc” Enchantments on an item can increase the players stats when worn. See CombatStats.doc for more details.
- === 금지 Players might be able to woo NPCs of the opposite sex. In the future, we may add the functionality to increase your chances to woo women by playing sappy love songs. If this is implemented, maybe players can write their own love songs.
- === Romancing NPCs (Prototype) Players can attempt to romance NPCs of the opposite sex by dialogue options Players can also attempt to romance NPCs of the opposite sex by serenading them with songs they’ve learned. Advanced Romance (Phase Four) Players can craft their own songs for use in the romance system.
- === Use strong, declarative language No ‘maybe’, ‘could’, ‘might’ Even avoid ‘may’. Don’t be ambiguous Don’t say ‘we’ Choose a direction Move ‘maybe’ features to later phases
- === Players may not place items on the ground. This is to help reduce visual clutter and ensure that players may not be disruptive through the placement of hundreds of items.
- === Players may not place items on the ground. … FAQ: Why can’t players place items on the ground? This is to help reduce visual clutter and ensure that players may not be disruptive through the placement of hundreds of items.
- === Capturing your reasoning is especially useful for longer projects, where the team may literally forget why they chose one side or the other. Capturing your reasoning, by extension, reduces the number of times contentious issues are reopened.
- === Design the next immediate phase to fine-tooth detail Design other phases to man-month degree` Don’t emotionally invest in far-off features Revisit documentation as the design shifts and iterates.
- [ 역자주 ] 개인적으로는 Google Sites( http://sites.google.com ) 이나 PB Works(http://pbworks.com/ ) 를 추천합니다 . [ 역자주 ] 기획 바이블 (Design Bible) 이란 , 게임의 핵심을 망라한 문서를 말하며 , 개발 초기 ( 주로 사전 제작 기간 ) 에 작성합니다 . === Design docs will only be used as a reference if the user can find what he needs. Possible means: Wiki Desktop Search Design Bibles
- [ 역자주 ] 3 가지 사이트 모두 World of WarCraft( 이하 , WoW) 의 비공식 데이터베이트로서 , WoW 클라이언트에 추가로 설치된 플러그인이 자동으로 정보를 수집해서 해당 사이트들에 업로드합니다 . 자세한 설명은 아래의 링크들을 참고하세요 : http://en.wikipedia.org/wiki/Thottbot http://en.wikipedia.org/wiki/Wowhead http://en.wikipedia.org/wiki/Allakhazam === Advantages of Documentation Automation: Accuracy, even postscriptively Searchable Easy to add auditing and reports
- === Design documents written in a vacuum almost never survive ‘contact with the enemy’.
- === Get with your Lead Designer, and ask these three questions: What are the goals of this system? What are the questions this document should answer? How complex can this system be?
- [ 역자주 ] 울타리 기둥 (fencepost) 이슈란 , 효율적인 동작을 방해하는 예상 밖의 입력 값에 대한 규칙을 말한다 . 예를 들어 , “ 길이가 100m 인 잔디밭의 한 변에 울타리를 세우려고 한다 . 기둥 사이의 거리가 10m 라면 , 울타리 기둥 (fence post) 이 몇 개나 필요한가 ?” 라는 질문의 답은 무엇일까를 생각해보라 . 10 그루 (100m/10m) 라고 생각했다면 , 오답일 수도 있다 . 양끝에 가로수를 심을 것인가에 따라서 9 개나 11 개가 될 수도 있기 때문이다 . 이러한 해석의 문제는 게임 디자이너의 의도와 프로그래머 ( 혹은 아티스트 ) 의 구현 사이의 격차를 벌려 놓고 , 그로 인해 오류 , 재작업과 일정 지연으로 이어질 수 있으므로 주의해야 한다 . === Do this with your lead designer in the kickoff meeting Justify the system Help decide fencepost issues Example: the following two goals are worthy, but contradictory, unless the design plans for it up front. “ Crafting is a sideline activity, to fill downtime, and can be done on the field.” “ Dedicated crafters can own their own forges and blacksmith shops, and achieve fame and fortune serving other players.”
- [ 역자주 ] 문서의 첫머리에 해당 문서의 목적 ( 이 문서를 쓰는 이유 ) 과 목표 ( 목적 달성을 위해서 문서가 해야 하는 것들 ) 을 기술해두면 , 문서가 불필요하게 비대해지는 것을 막아주고 , 문서를 읽는 사람들도 내용 파악이 쉬워진다 . === Do this with your lead designer in the kickoff meeting Since all systems touch each other eventually, important to decide where a document ends. Allows leads to schedule the documentation process. Prevents jumping the gun, design ‘claim jumping’ Highlights Phase 1 features
- === Do this with your lead designer in the kickoff meeting Token Representation. We just want the bullet point on our box Competitive. We want what the market leader has with minor tweaks, but we don’t want to be too risky. Alternative. Nothing too big, but definitely different from our competitor. Innovative. This feature will crush opponents, and we will hear the lamentations of their women.
- [ 역자주 ] 구체적인 승인 과정은 프로젝트나 팀의 문화에 따라 다를 수 있다 . 핵심은 게임 디자이너의 할 일은 멋들어진 기획서를 쓰는데서 끝나는 것이 아니라 , 그 기획서를 매개체로 팀 및 팀을 둘러싼 의사 소통하고 , 합의를 도출하는데 있다는 점이다 . === Should telescope out Lead Designer Approval First Design Team Approval Next Senior Leads/Cross-Team Approval Next This approach allows the design team to speak with one voice about a finished design. Is always tough to get up and running, but usually accelerates once teammates find value.
- [ 역자주 ] LD 는 리드 게임 디자이너 (Leader game Designer) 를 , SL 은 시니어 리드들 (Senior Leads) 를 의미합니다 . === (I like using post-it notes)
- === Designs will shift as the game iterates. A process is necessary to ensure that design changes are disseminated to decision makers on the team. The Lead Designer can usually act as the arbiter of when a change needs to be approved by the Senior Leads.
- === Design documentation procedures must work for the team. If the team sees the documentation process as oppressive, the design documentation process will end up subverted. Never lose sight of your goals: Short Up-to-date Programmer Friendly
- [ 역자주 ] 요리의 철인 (Iron Chef) 은 후지 TV 에서 방송한 요리를 테마로 한 예능 프로그램입니다 . 요리 강좌가 아닌 요리사끼리의 대결을 전면에 내세운 것이 특징입니다 . 가상의 단체 " 미식 아카데미”가 맛있는 음식을 먹고 , 요리법 아카데미 소속의 요리사와 도전자를 대결시킨다는 설정입니다 . 자세한 설명은 여기를 참고하세요 : http://goo.gl/8aBUl === Look at previous games. Especially what didn’t work! Look at non-game subject matter information If you’re making a cooking game, watch some Iron Chef! Talk to subject matter experts Even on other teams and/or at other companies!
- === Many brainstorming techniques, all sharing the same general principles Multiple (6-8) people Encourage out of the box thinking No idea is a bad idea Identify the ideas that resonate.
- === Now , some ideas are bad ideas. Ideas to cut Unbuildable Over-ambitious Conflicting with goals, or with each other Just plain weird ideas Use kickoff meeting results as your razor Might want to save the intriguing ones in a ‘morgue’ somewhere. Begin prioritizing the Darwinian survivors.
- === At least initially Focus on the essentials, emphasize getting something playtestable as fast as possible. Designs should become complex based upon feedback and design iteration. If you are afraid of what people will say when they read your design document, it is probably either too complex or too weird.
- === No game design survives contact with reality unscathed . Don’t get emotionally attached to any aspect of the design. Prepare to iterate on designs once they are coded
- === Three questions: What are the goals? What are the boundaries of this design document? What is the acceptable ambition level for this feature? Goal is to give designers autonomy in a well-defined way – to define the ‘boundaries of the box’.
- [ 역자주 ] drop Trou 는 감작스럽게 누군가의 바지 ( 혹은 속옷 ) 을 / 를 내리거나 치마를 들추는 장난을 말한다 . === You never know when external people will want to see your design documentation. Documentation should be ready to go on half-a-day’s notice. Design team conflicts should not be visible in design documentation, or should be easy to excise. You need to discuss with your producers what you will never show.
- === A stray idea: All documents ‘expire’ after 6 months, after which designers have to go back and verify that said documentation is still valid Check for changes in design Check for changes in priority Identify and signify aspects of design that have been implemented. Harder to do with a lot of documentation
- === Depends on your reality. Yes for large projects Yes for games with a long life (live components or expansions) and teams with high expected turnover. Yes if your external partners are especially annoying.
- === Small multidisciplinary teams Manage their own fates Product Backlog of features and subfeatures to implement Prioritized by ‘product owner’, usually producer or senior designer Idea is team is always working on the most important thing first Scrum is designed to be ‘documentation light’ Some advocates even claim it should be docless
- === Surprisingly not much Still need documentation to satisfy publishers and other external contract partners Still need documentation for QA test plans Still need the process that generates the ideas Focus changes Iteration and post-implementation becomes a priority. Non-programmer audiences become a priority. Most important change Structure documentation to use user stories