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