프로그래머에게 사랑받는 게임 기획서 작성법

프로그래머에게 사랑받는 게임 기획서 작성법 from Lee Sangkyoon (Kay)

• 1. 프로그래머에게 사랑 받는 게임 기획서 작성법 ㈜블루홀 이상균
• 2. 이 프레젠테이션은 ㈜블루홀 내부 주니어 개발자용 교육 자료를 기반으로 작성되었습니다. Ⓒ 임신형 Ⓒ 이상균
• 3. 시작하기 전에
• 4. ⒸCasper Cruz 먼저 조사를 해보겠습니다 손을 들어주세요
• 5. 이 세션은 게임 기획 경력자 대상 강연으로, 업계 실무 경력이 없으면 이해나 공감이 좀 어려울 수도 있습니다 그래도 끝까지 들어 주세요 마지막에 재밌게 해드릴께요
• 6. 발표자 소개 - 이상균 1985 초등학교 5학년 때 MSX 컴퓨터로 프로그래밍 시작 2001 서강대학교 컴퓨터 공학과 졸업 2003 서강대학교 컴퓨터 공학 대학원 졸업 2001 – 2003 매크로임팩트㈜ 분산 DB 네트워크 모듈 개발 (파트타임) 2003 – 2005 삼성전자 DVS 사업부 선임 프로그래머 DVD 레코더용 펌웨어, 양산 공정 제어 프로그램 개발
• 7. 발표자 소개 - 이상균 7 2005-2011 넥슨, <마비노기 영웅전> 크리에이티브 디렉터 2012-2015(현재) 블루홀, 미공개 프로젝트 디렉터 누적 경력 11년차의 게임 기획자/디렉터
• 8. • 발표자의 특징 – 절반은 프로그래머, 절반은 게임 기획자(Game Designer) – 학창 시절을 프로그래머로 살았으나, – 밥벌이는 게임 기획자로 하고 있음 • 오늘 할 얘기 – 프로그래머와 게임 디자이너를 모두 이해하는 입장에서, – 프로그래머와 잘 소통하기 위해 – 게임 기획자가 알면 좋은 것들 • 실무 기획자들은 한번 쯤 생각해봤던 내용일겁니다…
• 9. 기획서는 왜 잘 쓰기 어려울까
• 11. • 기획서 잘 쓰는 방법에 대한 자료는 정말 많다 – 웹서핑 몇 분만으로도 방대한 자료 획득이 가능 • 하지만, – 대부분의 개발팀은 신입 기획자를 뽑으면, – 문서 쓰는 방법 부터 가르쳐야 한다 생각한다 기획서는 왜 잘 쓰기 어려울까?
• 12. 상품 개발 프로세스 • 기획은 개발의 선행 작업 – 제조업, 보험업, 교육업 등등 기존 산업에선, – 기획이 확정된 후 개발을 시작한다 • 게임은 어떤가? Ⓒ 메리츠 생명
• 13. 얼마전에 발표된 블리자드 신작 게임입니다. <워크래프트 레전드>, 워크래프트의 영웅이 되어 아제로스를 떠도는 게임 Ⓒ Derak Sakamoto, Blizzard Entertainment
• 14. • 스톰윈드에서 게임을 시작합니다 • 월드엔 수 많은 적들이 준비되어 있군요 이 게임 아시는 분? Ⓒ Derak Sakamoto, Blizzard Entertainment
• 16. 지금까지 본 스크린샷은 하스스톤의 UI 디자이너 데릭 사카모토의 GDC 2015 세션에서 발췌한 것입니다 Ⓒ Derak Sakamoto Ⓒ GDC Vault
• 17. 게임은 기획대로 만들기 어렵다 • 워크래프트 레전드 VS 하스스톤 – 블리자드 조차 초기의 기획과 최종 상품이 다름 • 게임 개발 – 확정된 기획으로 상품을 만들어 내는 다른 산업과 달리, – 반복적인(Iterative) 통합(Integration)을 통해 공학적 예술품을 만들어 내는 것이 게임 개발
• 18. • 게임 기획서를 쓰기 어려운 이유 – 다른 산업에서 기획이란 개발(혹은 실행) 이전의 작업 – 게임 산업에서는 개발과 동시 진행되는 작업 • 기획서가 아니라 변경 가능한 설계도를 쓴다고 생각해야 함 Ⓒ 메리츠 생명
• 19. • 오늘 할 얘기 – 게임 기획서 작성의 특수성을 인지한 상태에서, – 쉽게 읽히는 기획서 작성 법에 대해 얘기합니다 (시스템 기획서 특화) – 프로그래머와 잘 소통하는 법에 대해 얘기합니다 • 이런 얘기는 나오지 않습니다 – 컨텐츠 디자인 잘 하는 법 – 시나리오 잘 쓰는 법 – 게임 기획 잘 하는 법 (알면 저 좀…) ※ 개발/라이브, 회사와 팀 문화에 따라 이 강연 내용은 실천 가능하지 않을 수 있습니다
• 20. 완전성에 대한 환상을 버리자
• 21. • 혹시 이 PT를 보신적 있는 분?
• 22. 이 시절엔, 규칙 뿐만이 아니라 기획서도 완전함이 목표여야한다 생각 어렸었습니다… ( -_-)y~3
• 23. 완전성에 대한 환상 • 게임 기획서는 완전할 수 없다 – 실 제작 이후 방향 수정이 당연하다는 것을, 디렉터, 기획자, 프로그래머 등등이 받아 들여야 함 – 절대 변하지 않을 기획서(X) – 변동 범위를 예측 가능한 기획서(O) • 팀 문화 – 완전성에 대한 환상을 버리고, 변동 가능성을 받아들이려면 – 유연한 팀 문화의 빌드업이 선행되어야 함
• 24. 조직 문화 빌드업에 대해 다룬 강연은 많으니, 이 강연에서는 다루지 않습니다. Ⓒ Reed Hastings, NetflixⒸ 안미루, 넥슨
• 25. • 가끔 이렇게 말하는 프로그래머를 봅니다 • 라이브  개발로 이동한 프로그래머에게 보이는 경향 • 다시 말하지만 완전한 사양서는 존재하기 어렵다 – 최초의 상품 기획과 설계 대로 완성되는 공산품이 아님 – 게임이 완성되고, 라이브를 시작한 후에는 비로소 정확도 높게 예측 가능 25 완전한 사양서를 가져다 주세요 프로그래머가 상상하지 않게 해주세요
• 26. • 목표가 선명해졌다 – 완전성이 환상이라면, – 목표는 완전한 기획서를 쓰는 것이 아니라 – 이후 변동 범위를 예측하기 쉬운 기획서를 쓰는 것 • 어떻게 하면 그런 기획서를 쓸 수 있을까?
• 27. 의도를 전달하자
• 28. • 모든 부대에는 “전시 행동 강령”이라는게 있다 – 전시에 특별한 지시 없이도 군대가 일사분란하게 움직이도록 – 군대 다녀온 분들은 다 알 것 • 발표자는 미8군 한국군지원단(카투사) 신병계 – 모든 문서를 파기하고, 하드디스크를 뽑아 들고, – 용산 고등학교 운동장에서 헬기를 타는 것이 전시 행동 강령 28
• 29. • 그런데 만약, • 폭격으로 용산 고등학교가 사라졌다면? 29
• 30. • 지휘관의 의도(Commander’s Intent) – 1980년대 미 육군사관학교 톰 콜티츠 대령이 만든 개념 – 대부분의 전시 행동 강령과 작전 계획이, 전투가 시작됨과 동시에 무용지물이 된다는 걸 깨닫고 대안으로서 제시한 개념 • 동작 원리 – 모든 명령서의 최 상단에 의도를 짧게 서술 – 강령보다 의도 중심 – “하드디스크를 들고 용산 고등학교로 가라”(X) – “최신 카투사 신병 자료를 캠프 헨리의 작전 본부까지 옮겨라”(O) 30
• 31. • 지휘관의 의도를 몰랐다면, – 파괴된 용산 고등학교 주변을 배회했을 지도 • 지휘관의 의도를 알았다면, – 자동차를 타든, 버스를 타든, 걸어서든, – 캠프 헨리까지 가려고 했을 것이다. 31 ⓒGde-Fon.com
• 32. • 기획서에 자주 누락되는 “의도” – 대개 최초의 의도는 디렉터에게 있다 – 게임 디자이너가 의도를 스펙으로 바꾸는 동안, – 의도는 문서 안에서 희석되거나 사라지기 쉽다 – 혹은 처음부터 의도가 전달되지 않았을 수도 있다 32
• 33. 고기 시스템 기획서 • 플레이어는 고기를 소비해 영웅을 던전에 보낼 수 있습니다 • 던전 난이도와 관련 없이 한 번에 고기 1개를 소비합니다 • 고기는 오전 9시, 오후 12시, 오후 6시, 오후 9시에 채워집니다 • 고기는 한 번에 8개가 충전됩니다 • 충전 시간까지 소비되지 않은 고기는 버려집니다 우리 게임은 글로벌 원빌드 인데, 북미에서도 한국 서버 시간을 기준으로 하나요? 프로그래머 A
• 34. 기획서 첫 줄에 의도를 명시한다 고기 시스템 기획서 • 출근(등교), 점심 시간, 퇴근(하교),자기 직전 시간에 게임 플레이를 유도하고 싶습니다. • 플레이어는 고기를 소비해 영웅을 던전에 보낼 수 있습니다 • 던전 난이도와 관련 없이 한 번에 고기 1개를 소비합니다 • 고기는 오전 9시, 오후 12시, 오후 6시, 오후 9시에 채워집니다 • 고기는 한 번에 8개가 충전됩니다 • 충전 시간까지 소비되지 않은 고기는 버려집니다 프로그래머 A 그렇다면 고기 지급은 클라이언트 로컬타임을 기준으로 해야겠구나.
• 35. • 의도를 전달하면, – 프로그래머가 더 좋은 구현 방법을 생각해낼 수 있게 된다 – 앞으로 기획의 확장 방향을 예측할 수 있게 된다 – 무엇보다 안돼요를 줄일 수 있게 된다 (뒤에 설명합니다) • 만약 의도 칸에 쓸 말이 없다면? – 디렉터가 의도를 전달하지 않은 경우입니다 – 디렉터를 찾아가서 이 시스템의 의도를 물어봅시다 35
• 36. 단계별로 작성하자
• 37. 37 몬스터 AI 기획서 • 몬스터는 각자 고유의 AI를 가지고 있습니다 • AI의 종류 • 평화 상태 – 플레이어를 인식하지 못한 상태 • 경계 상태 – 플레이어를 인지하고 공격 거리까지 접근하는 상태 • 공격 상태 – 플레이어와 전투 공방을 하는 상태 • 도주 상태 – 체력이 낮아져 스폰 포인트를 향해 도주하는 상태 • 동료를 부름 – 어떤 종류의 몬스터는 울음 소리를 내 동료를 부릅니다 • 광폭화 – 체력이 낮아져도 도망치지 않습니다 • 몬스터는 보스와 자코 AI를 갖습니다 • 보스 AI가 공격할 때는 자코 AI들은 뒤로 물러섭니다 • 보스의 체력이 낮아지면 자코들이 보스를 보호합니다 • 여러 그룹으로 나뉘어진 AI입니다. • 상호 정보를 교환하며 메타 AI인 종족 AI의 통제를 받습니다
• 39. 39 몬스터 AI 기획서 1단계 - 10월 빌드 • 몬스터는 각자 고유의 AI를 가지고 있습니다 • AI의 상태는 다음과 같습니다 • 평화 상태 – 플레이어를 인식하지 못한 상태 • 경계 상태 – 플레이어를 인지하고 공격 거리까지 접근하는 상태 • 공격 상태 – 플레이어와 전투 공방을 하는 상태 • 도주 상태 – 체력이 낮아져 스폰 포인트를 향해 도주하는 상태 2단계 - 11월 빌드 • 특수 AI • 동료를 부름 – 어떤 종류의 몬스터는 울음 소리를 내 동료를 부릅니다 • 광폭화 – 체력이 낮아져도 도망치지 않습니다 • 그룹 AI • 몬스터는 보스와 자코 AI를 갖습니다 • 보스 AI가 공격할 때는 자코 AI들은 뒤로 물러섭니다 • 보스의 체력이 낮아지면 자코들이 보스를 보호합니다 3단계 – 미정 • 군대 AI • 여러 그룹으로 나뉘어진 AI입니다. • 상호 정보를 교환하며 메타 AI인 종족 AI의 통제를 받습니다 이번 구간에 만들기로 확정된 부분 확정되지않았고,방향만있는부분 ※ 개발 프로젝트를 기준으로 한 얘기이며, 라이브는 좀 다를 수 있습니다
• 40. 기획의 구성 • 완성된 사양 – 이미 시스템으로 제작된 것 – 완성된 부분의 스펙이 변경되는 건 가능하면 피해야 • 눈 앞의 사양 – 이번 구간에 만들기로 한 것 – 구간 안에서는 확정된 사양 • 미래의 비전 – (아마도) 디렉터의 머릿 속에만 있는 것 – 눈 앞의 사양의 성과에 따라 모습이 달라질 수 밖에 없다 40 눈앞의 사양 + 미래의 비전 완성된 사양 +
• 41. • 단계별 사양서 – 이 세 모습을 한 눈에 알아볼 수 있게 함 – 변경 가능성 있는 것과 그렇지 않은 것을 알 수 있음 – 확정되지는 않았지만 미래를 예측할 수 있음 • 단계별 사양서를 작성하면, 프로그래머가 변동 범위를 예측 가능 41 눈앞의 사양 + 미래의 비전 완성된 사양 +
• 42. 프로그래머 분들께 • 특히 툴 같은 것을 개발할 때 많이 나오는 말 • 무리하게 완전한 사양서를 요구한 경우 • 이럴 땐 단계별 사양서를 요청하자 모든게 다 되는 시스템을 만들어 주세요 기획자 A
• 43. • 게임 기획자가 단계별 사양서를 못 주면? – 이 게임이 어떻게 생겼는지 비전이 불명확 한 경우 – 기획자 자신도 이 시스템이 어떻게 변할지 예측을 못하는 경우 • 디렉터가 비전을 전달하지 않은 탓 디렉터를 찾아갑시다 43
• 44. 기획서를 소모품으로 쓰자 이 파트는 디렉터/PD도 대상으로 하고 있습니다
• 45. • 마일스톤이 완료되면 – 두개의 결과물을 가지게 된다 • 문서(사양서등)와, 빌드(코드+데이터) – 이 두개가 일치할 확률은? 기획서 사양서 회의록 QA 목록… 문서 데이터코드 빌드
• 46. • 많은 개발팀이 문서화에 많은 시간을 쓰고 있다 – 잘못된 것 아님 – 긴 라이브 기간 동안 멤버가 바뀔 수도 있고, – 이후 업데이트 때 이전의 결정에 대한 맥락도 파악해야 하고, – 회의 자리에 없었던 멤버들도 내용을 공유 받아야 하고, – 기타 등등… • 그럼에도 불구하고 문서와 빌드의 불일치는 피하기 어려움
• 47. • 문서/빌드가 불일치 하면, – 프로그래머는 어느 문서가 최신인지 항상 묻게 되고, – 누군가 문서를 통제해야 하며, – 때로는 지난 문서 업데이트 때문에 우선 순위가 변경되기도 하고, – 심지어 프로그래머가 문서를 기다리느라 코딩을 멈추기도 한다 – 문서의 유지 보수 때문에 기획자를 더 뽑아야 하는 상황도 • 그럼에도 불구하고, – 문서화 그 자체는 여전히 가치있다 – 여러분의 팀이 대형 MMORPG를 개발/유지 보수 하는 팀이라면
• 48. • 하지만 아니라면? – 대형 MMORPG를 개발/유지보수하는 팀이 아니라, – (대략 30명 이하) 소규모 모바일 게임을 만드는 팀이라면? – 빠른 의사 결정, 기민한 시장 대응이 필요한 팀이라면? – 반복적인 빌드와 조립으로 완성도를 높이는 것이 목적인 팀이라면? • 문서에 대해 다르게 접근해볼 필요가 있다
• 49. 다시 고기 시스템 • 이 시스템을 실제로 만들고 나면, 고기 시스템 기획서 • 출근(등교), 점심 시간, 퇴근(하교),자기 직전 시간에 게임 플레이를 유도하고 싶습니다. • 플레이어는 고기를 소비해 영웅을 던전에 보낼 수 있습니다 • 던전 난이도와 관련 없이 한 번에 고기 1개를 소비합니다 • 고기는 오전 9시, 오후 12시, 오후 6시, 오후 9시에 채워집니다 • 고기는 한 번에 8개가 충전됩니다 • 충전 시간까지 소비되지 않은 고기는 버려집니다
• 50. • 우리 손에는, • 이런 것 들이 남게 된다 고기 시스템 기획서 • 출근(등교), 점심 시간, 퇴근(하교),자기 직전 시간에 게임 플레이를 유도하고 싶습니다. • 플레이어는 고기를 소비해 영웅을 던전에 보낼 수 있습니다 • 던전 난이도와 관련 없이 한 번에 고기 1개를 소비합니다 • 고기는 오전 9시, 오후 12시, 오후 6시, 오후 9시에 채워집니다 • 고기는 한 번에 8개가 충전됩니다 • 충전 시간까지 소비되지 않은 고기는 버려집니다 기획서 등 문서 그리고 코드 스크립트, 시트, 리소스 등 데이터 ⓒ도탑전기
• 51. • 기획서 내용 중 시스템은 코드로, • 컨텐츠는 데이터로 정리되는 것 • 즉, 빌드는 이미 온전히 기획서를 포함하고 있다 • 그렇다면 이제 기획서는 버려도 되는 것이 아닐까? 기획서 사양서 회의록 QA 목록… 문서 데이터코드 빌드
• 52. 이렇게 한 번 해 보세요 • 문서를 크게 세 그룹으로 나눈다 – 예전 빌드 문서 모음 (완성된 사양) – 현재 빌드 스펙 (눈앞의 사양) – 기획서/비전서 (미래의 비전) • 빌드가 끝나면, – 눈앞의 사양 문서 중 일부를 기획서로 흡수 – 나머지는 예전 빌드 문서로 밀어 넣는다(버린다) – 예전 빌드 문서는 현재 빌드 상태와 일치하지 않을 수 있음 • 남겨야 하는 문서? – 시스템의 의도가 담긴 문서 눈앞의 사양 + 미래의 비전 완성된 사양 +
• 53. • 정말 될까?
• 54. 기획서의 형식을 없애자
• 55. • 보통 팀에는 기획서 양식이라는 것이 있다 문서 제목 작성자 작성일 리비전 수정 내용 개요
• 56. • 이런 기획서 양식이, – 문서를 유지 보수하는데 도움이 될까? – 다른 멤버에게 기획 내용을 전달하는데 도움이 될까? – 프로그래머가 문서를 이해하는 데 도움이 될까? • 지금까지 우리는, – 기획서의 완전성과 불변성에 대한 환상 대신, – 반복적인(Iterative) 통합(Integration)을 통해 개발되는 게임의 특성에 잘 맞는 문서 다루는 법에 대해 얘기했다
• 57. 기획서의 본질은 전달 • 게임 기획은, – 발상 – 설계 – 전달 • 세 단계로 이루어진다 – 이 중, 설계가 끝난 기획을 전달하기 위해 작성하는 것이 기획서 – 즉 기획서의 본질은 전달에 있다고 할 수 있다 자세히 얘기하면 이 얘기만 두시간짜리 Ⓒ 이상균
• 58. • 이런 방법은 어떤가? 사회성 부족한 프로그래머들을 위해 프로그래밍 치어리더를 고용한다는 중국 개발사에 대한 기사 Ⓒ Trending in China Facebook
• 59. 프로그래머의 취향은 다양하다 • 기획서에 대한 취향도 모두 다름 – 어떤 프로그래머는 천천히 읽을 수 있는 정갈한 문서를 좋아하고, – 어떤 프로그래머는 PPT로 윤곽을 파악한 후, 체크 리스트 형태로 기능을 클리어하는 걸 좋아하고, – 어떤 프로그래머는 그런거 필요 없고 게임 디자이너가 문서 들고 찾아와서 하나씩 설명해주는걸 좋아하고, – 어떤 프로그래머는 기획 회의부터 들어가는 걸 좋아한다 • 기획서의 본질이 전달이라면, 꼭 한가지 방법을 고집해야 할 이유가 없다
• 60. 실제로 써 본 방법 명함으로 보드게임 만들기 설명 한 줄 없는 슈도 코드 기획서
• 61. 프로그래머에게 물어보세요 • “이번 기획서, 어떻게 준비할까요?” • 예상 외로 다양한 대답이 돌아 올 겁니다 – “일단 원하는 걸 불릿 리스트 형식으로 5~6줄 써 오세요” – “회의실 가서, 원하는 걸 간단하게 먼저 설명해 주세요” – “비슷하게 동작하는 게임이 있으면 찾아서 알려주세요” – “문서보다 데이터 시트를 먼저 주세요”
• 62. • 우리는 앞서, 빌드후 문서를 버릴 수 있을까에 대한 얘기를 했다 • 버리겠다 마음 먹으면, 그 문서의 형식이 중요하진 않을 것 • 기획서의 본질은 전달에 있다 기획서 사양서 회의록 QA 목록… 문서 데이터코드 빌드
• 63. 안돼요에 대하여 이 파트는 프로그래머도 대상으로 하고 있습니다
• 64. • 안돼요 – 프로그래머의 궁극기 – 게임 기획자를 포함, 타 직군 사람들이 가장 두려워하는 답변 1순위 – 왜 안돼요를 그렇게 두려워할까 64
• 65. 우리가 보는 프로그래머 강철의 연금술사 아이언맨 창조신(神) 신기함 놀라움 간지(멋있음) 뭔지 모르겠는 걸 할 수 있음 기대 부러움 존경스러움 ⓒ 임신형, 블루홀
• 66. 실체화 능력 – 기획이 실체화 되려면 코드가 필요 – 아무리 훌륭한 아트와 기획이 있어도, 그것 만으로는 게임이 되지 않음 – 먼저 얘기했듯, 게임은 공학적 예술품 ※ 당연히 타직군 업무가 덜 중요하다는 뜻은 아닙니다 강철의 연금술사 ⓒ 임신형, 블루홀
• 67. 메타 개발 • 메타 개발 – 개발이 가능하도록 하는 개발 – 툴, 프로세스 등의 개발 • 생산성, 생산력의 향상 – 더 큰 게임, 더 높은 퀄리티 게임 아이언맨 ⓒ 임신형, 블루홀
• 68. 가능성의 오픈 – 이 전에는 할 수 없었던 개발의 가능성을 열어주는 일 – 반대로 말하면 프로그래머가 해 주지 않으면 그 가능성은 없어진다창조신(神) “나의 권능으로, 리비전 18903부터 본 개수 250개 이상인 몬스터의 제작을 허하노라.” ⓒ 임신형, 블루홀
• 69. • 그래서 안돼요는 선고 같은 것 – “이 대화를 종결하노라” 같은 답변 – 쓰면 안된다(X) 안되는 이유를 충분히 설명한다(O) 69
• 70. • 안돼요에 대해 좀 더 자세히 살펴봅시다 – 프로그래머는 왜 안된다고 할까요? – 프로그래머가 왜 안된다고 하는 알아야, 커뮤니케이션을 잘 할 수 있다 70
• 71. 진짜 불가능한거예요 • 기획자가 정말 불가능한 걸 요구했을 때 • 내가 의도를 제대로 전달했는지 생각해보자 71 ⓒ마우리츠 코르넬리스 에셔
• 72. “시간이 너무 많이 걸려요” • 가장 많은 안돼요의 이유 • 현재 더 우선 순위 높은 업무를 진행중일 때 • 게임 디자이너의 요구와 마감 시한이 모순될 때 72
• 73. • 그런데 이렇게 생각해보자 – 시간이 많이 걸리는, 시스템상 중대한 업무 혹은 변화를 갑자기 챙겨야 할 상황이란 어떤 상황인가? • 대개 이 두 가지 경우 – 디렉터가 변덕을 부렸거나, – 미리 예측 못한 예외 상황 때문일 때가 많다 • 만약 자주 발생하지 않을 예외 상황 때문이라면?
• 74. • 이 시스템의 빈도에 대해 언급하자 – 프로그래머가 항상 하드코딩을 기피하는 것은 아님 – 프로그래머는 앞으로도 계속 이 문제로 추가 하드코딩이 예상될 때 안돼요라고 한다 이번만 예외입니다. 비슷한 경우가 없을거예요 기획자 A
• 75. 추천 프레젠테이션 • 바로 이 주제를 심도 깊게 다룬 PT ⓒ하지훈, 넥슨
• 76. 너무 많은 걸 변경해야 해요 • 실은 “안돼요”가 아닌 “싫어요” 76 <월드오브워크래프트: 대격변>
• 77. 프로그래머의 코드 오너십 • 코드 오너십 – 프로그래머는 본인이 짠 코드에 큰 애착을 갖고 있다 – 아티스트가 마음에 들든 안들든 본인 작품에 애착을 갖는 것 처럼 • 하지만 앞서 얘기했듯, 게임은 – 반복적인(Iterative) 통합(Integration)을 통해 개발됨 • 완성된 사양 또한 변경될 수 있다 눈앞의 사양 + 미래의 비전 완성된 사양 +
• 78. • 어쨌든 괴로운 상황 • 어떻게 하면 좋을까? – 정답이 없는 상황이지만, 저는 이럴 경우 의도를 전달하고 깊게 토론하는 것을 추천합니다 고기 시스템 기획서 • 출근(등교), 점심 시간, 퇴근(하교),자기 직전 시간에 게임 플레이를 유도하고 싶습니다.
• 79. 다시 등장한 의도 • ToDo List 보다 맥락을 전달한다 – 왜 이런 변경을 해야 하는지 맥락을 전달한다 – 의도를 만족시키는 다른 방법이 없나 함께 찾아본다 – 디자인을 약간 변경하여 기능 추가 등으로 마무리 할 수 없나 찾아본다 – 이 때 중요한 것이 의도를 전달하는 것 • 시스템 변경의 의도를 모르겠다면 – 물론 디렉터 탓입니다. 디렉터를 찾아갑시다
• 80. 잘 모르겠어요 • 할 수 있는지 없는지 공부해 봐야 해요 – 프로그래머는 “모르겠다”라는 말을 하기 싫어함 – 기획자가 하고 싶은 것이 될지 안될지 지금 당장은 모르겠는데, 그 모른다는 말이 하기 싫다 – 그래서 답변을 바로 준다면 “안돼요” – 주니어 프로그래머들에게 가끔 나타나는 경향 하지만 이게 가장 나쁜 “안돼요” 왜 가장 나쁠까? 80
• 81. • 타 직군 사람들이 가장 두려워하는 답변 1순위 • 그럼 프로그래머가 가장 싫어하는 말 1순위는? 81
• 82. • 프로그래머 A님은 된다던데요? – 왜 A님을 찾아갔을까? – 될 것 같은데 안된다는 답변을 들었기 때문 – 정말 안되는 것인지 확인하고 싶었기 때문 – 이미 신뢰를 잃었다 사소한 오해에서 갈등이 시작될 수 있기 때문에, 가장 나쁜 “안돼요”라고 할 수 있다 82
• 83. • 이 경우, 기획자가 할 수 있는 것은 없다 • 오직 프로그래머만이 이 문제를 해결할 수 있음 당장은 된다 안된다 말씀 못드리겠군요. 제가 좀 살펴보고 말씀드릴께요. 프로그래머 A
• 84. 그 밖의 짧은 조언들
• 85. 피드백을 부탁하자 • 피처의 개발이 끝나면, 프로그래머에게 묻자 • 분명히 유의미한 피드백을 받을 수 있을 것 이번 기획서는 어떠셨나요? 다음 번엔 제가 어떻게 하면 좋을까요? 기획자 A
• 86. 파라메터를 명확히 하자 고기 시스템 기획서 • 던전 난이도와 관련 없이 한 번에 고기 1개를 소비합니다 • 고기는 오전 9시, 오후 12시, 오후 6시, 오후 9시에 채워집니다 • 고기는 한 번에 8개가 충전됩니다 고기 시스템 기획서 • 던전 난이도와 관련 없이 한 번에 고기 1개를 소비합니다 • 고기가 채워지는 시간은 MeatParam.RegenTime 에 정의되어 있습니다 • 고기는 한 번에 Misc.MeatMax 개가 충전됩니다 프로그래머가 문서로부터 하드코딩할 것과 그렇지 않을 것을 구분할 수 있다
• 87. 기술을 선택하지 말자 바닥에 뿌려진 피가 좀 입체적으로 보였으면 좋겠습니다 피 데칼에 노말맵을 넣을까요? 혹은 3D 메시를 다이나믹 스폰할까요? ① 퍼포먼스를 생각하면 노말맵이 낫겠습니다 ② 퀄리티를 위해선 3D 메시가 좋을 것 같네요 ③ 제가 결정할 일이 아닌 것 같네요. TA를 부를께요 ⒜
• 88. 진척 상황을 체크하자 • Deadlock – 두 작업이 서로의 작업이 끝나기를 기다리고 있는 교착 상태를 나타내는 프로그래밍 언어 • 어떤 작업이 시작된 후 별 진전이 없을 때, – 기획서, 리소스, 데이터, 코딩이 서로를 기다리고 있는게 아닌지 체크 • 프로그래머의 컨텍스트 스위칭 비용은 비싸다 – 적절함과 휴먼 매니지먼트의 영역
• 89. 끝으로
• 90. 이런 얘기들을 했습니다 • 완전성에 대한 환상을 버리자 • 의도를 전달하자 • 단계별로 작성하자 • 기획서를 소모품으로 쓰자 • 기획서의 형식을 없애자 • 안돼요에 대하여 • 피드백을 부탁하자 • 파라메터를 명확히 하자 • 기술을 선택하지 말자 • 진척 상황을 체크하자
• 91. • 게임 산업은 계속 변화합니다 – 대형 MMORPG가 주류를 이뤘을 때는, 이런 기획서 관리법이 목소리를 내지 못했을거예요 – 작고 빠른 개발팀이 주류가 된 현재에 와서야 의미가 생긴 방법론 • 따라서 이 발표도 영원한 진리를 담고 있지는 않습니다 – 새로운 방법론들이 계속 시도되고, 발표되고, 토론되길 기대합니다
• 92. 게임 기획자(Game Designer) 여러분의 건승을 빕니다 우리 같이 힘 냅시다