게임제작개론 : #9 라이브 서비스

• 1. 게임 제작 개론 #9 라이브 서비스 NHN NEXT 구승모

게임제작개론 : #9 라이브 서비스 from Seungmo Koo

• 2. Agenda • 라이브 서비스 • 게임 지표 • 협업 마인드 • 게임 제작 개론 포스트모템
• 3. 학습 목표 • 라이브 서비스와 프로덕션의 차이를 안다 • 라이브 팀의 역할과 책임을 안다 • 라이브에 있어서 통계 분석이 갖는 의미를 이해한다 • 직접 게임 플레이를 하는 것이 왜 중요한지 안다 • 일의 우선순위를 결정할 수 있다 • 여러 가지 게임 지표를 알고 이해할 수 있다 • 팀워크를 위해서 어떤 자세를 가져야 하는지 이해한다
• 4. 라이브 서비스에 대한 이해
• 5. 라이브(Live) 서비스 • 온라인 게임의 경우 오픈(Launch) 이후의 모든 과정 – 만들어진 게임을 더 잘 되도록 하는 것이 목적 • 온라인 게임의 장기 집권을 가능하게 하는 것 – OBT부터는 게임 개발이 아니라 “서비스”라고 생각해야 함 • 계속되는 방어전 • 진정한 개발의 시작 – 버그 수정 및 개선 – 유저들의 각종 요구사항 처리 – 차기 업데이트 콘텐츠 개발 – 이벤트 계획과 실행 • 각종 특수 시즌(여름 방학 등)을 고려 • 경쟁 업체의 신작 또는 대규모 업데이트 고려
• 6. 게임 제작과의 차이? Production? Live Service?
• 7. 달리는 자동차의 바퀴를 교환하는 것과 같음 http://youtu.be/dvBDeaUMddI
• 8. 라이브 서비스의 자세 • 기존 콘텐츠 개선 > 새로운 콘텐츠 투입 – 콘텐츠를 많이 만들어 서비스를 유지하려고 생각하면 안됨 • 유저의 콘텐츠 소비 속도를 절대로 따라가지 못하기 때문 • 소비형 콘텐츠보다 커뮤니티형 콘텐츠에 집중 – 잘 개선한 콘텐츠 하나가 열 업데이트 안 부럽다 • 유저의 감정 대응도 중요하다고 인식 – 유저의 반응을 살피고 컨트롤하는 것에 집중 – 별일 아닌 것임에도 유저들의 화를 부를 수 있음 • 근거 없는 소문, 타 게임 알바(?)들의 조직적인 방해 가능성 • 솔직하게 원인과 의도를 설명하고 해결 방안을 미리 공지하는 방법 • 경청 그리고 또 경청 – 유저가 원하는 게임 > 개발사가 만들고 싶은 게임 – 유저 자신들의 이야기를 들어주기(소통) 그 자체를 원하는 경우
• 9. 라이브 팀 구성 • 차기 업데이트를 담당하는 팀(DEV)과 반드시 분리 – 개발 조직을 Short-term팀과 Long-term팀으로 나누는 형태 – 기존의 개발 조직이 담당하면 민첩한 의사 결정이 힘들기 때문 – 자체 문제 해결 능력(개발력)을 갖추는 것도 중요 • (아트 + 프로그램 + 게임 디자인) + 라이브 분석 • DEV팀의 손을 빌리지 않고 긴급한 패치가 가능해야 하기 때문 • 이벤트에 해당하는 콘텐츠를 직접 제작할 정도는 되어야 함 – 라이브 브랜치 책임 • 국가별로 다른 라이브 환경 등 • 민첩한 대응 (긴급 버그 수정 등) • 이벤트 콘텐츠 DEV KR LIVE US LIVE Launch RR R R Trunk bug fix 이벤트버그수정이벤트 이벤트
• 10. 라이브 팀의 필수 조건 • 빠른 의사결정 프로세스 – 책임과 역할(R&R)을 명확히 • 이에 적합한 팀 구성을 라이브 서비스 시작 전에 미리 하도록 – 의사 결정부터 대응까지의 turn-around time을 최적화를 위해 • (cf.) 게임 제작 프로덕션은 길게 보고 최적화(global optimization)한 다는 면에서 라이브 서비스와 다름 • 위기 대응 매뉴얼 – 일종이 판례집(law reports) • 라이브 상황에서의 각종 사례와 대응, 그리고 결과 – 라이브팀의 대응 내용과 know-how는 반드시 기록(archiving) • 관련 인원의 교대(rotation)시 똑같은 실수를 반복할 수 있기 때문 • 유저 관찰 – 통계 분석, 게임 플레이, 커뮤니티 모니터링
• 11. 통계 분석 • 과거의 분석을 통해 미래의 라이브를 올바르게 이끌기 위함 • 전문적으로 분석할 수 있는 전담 조직 필요 – 수치화된 통계 데이터를 항상 열람 가능하도록 – 의사결정자들이 통계 결과를 받아들이기 어려운 경우가 있음 • 서로 다른 결론의 도출 가능성이 있는 통계 지표는 지양 • 콘텐츠 제작시 어떤 통계 값을 볼 것인지 미리 설계 – 잘 되고 있다는 것을 알기 위해 어떤 지표를 뽑아야 할까? • (예) 전장 사용률은 전투 깃발 아이템 사용량으로 본다? • F2P의 경우 연관성이 높은 상품 찾기 – 어떤 아이템으로 구성된 패키지가 잘 팔릴까? • (예) 바니걸 귀 액세서리 + 수영복이 최고 매출 조합? • 정량화의 늪에 빠지지 않도록 할 것 – 통계 분석은 서비스를 위한 필요조건이지 충분조건이 아님 – 유저들의 목소리에 대한 근거로 활용해야 함
• 12. Gameplay First! • 통계 보다 더 중요한 것 – 라이브 팀 및 콘텐츠 개발자는 반드시 직접 플레이 할 것 – 직접 플레이 해야만 알 수 있는 것들이 있기 때문 • 통계 지표로는 알 수 없는 것들이 존재: 유저의 “감정”에 대한 정보 • 커뮤니티, 게시판 상의 반응을 해석 검증할 필요가 있음
• 13. Bot(오토) 단속 • 게임에 대한 신뢰를 무너뜨리는 무서운 적 – 라이브 팀은 봇의 영향을 항상 모니터링 하고 대응해야 함 • (예) 게임 내 전체 통화량의 증가 추세 등 – 게임 디자인으로 막는 방법이 가장 효율적 • 단순 반복의 경우 효율이 낮도록 밸런싱
• 14. 일의 우선 순위 • 4가지 카테고리 – 긴급하고 중요한 일 • (예) 아이템 복사 버그, 지속적 접속 불가 상황 – 긴급하지만 크게 중요하지 않은 일 • (예) UI 스탯 동기화 문제, 인던 몬스터 길찾기 오류 및 끼임 현상 – 긴급하지 않지만 중요한 일 • (예) PvP 밸런싱, 위험요소가 있는 걸레 코드 리팩토링 – 긴급하지도 중요하지도 않은 일 • (예) 시스템 메시지 에러, 특정 메쉬 텍스처 깨지는 경우 • Discussion – 위의 4가지 경우의 우선 순위는 어떻게 될까? – 우선순위대로 왜 잘 지켜지지 않을까? • 우선순위가 잘 지켜지도록 하려면 어떻게 해야 할까?
• 15. Case-Study • TERA – OBT 때의 아카칼리쉬 사건 – 정식 서비스 시작시 HP 회복 옵션 밸런스 0.1로 너프 사건 – 만렙 원양어선용 중형 몬스터 드랍률 너프 – 파멸의 마수 업데이트시 봉인/재봉인 및 명품 아이템 추가 – 전장 어뷰징을 통한 강력한 전장템 공급 증가 • 질문 – 어떤 문제가 있었기에 이런 결정을 하게 되었을까? – 이 결정으로 얻은 것과 잃은 것은 무엇일까?
• 16. 추천 참고 자료 • MMORPG 동접 개선을 위한 개발 이야기 – 여형욱, BDC 2011 – http://m.blog.naver.com/bo0wy19/80143714046 • 그라나도 에스파다 운영에서 배운 점들 – 김학규, KGC 2011 – http://www.slideshare.net/lesely/kgc2011-1 • 던전 앤 파이터의 사례를 통한 게임 운영과 통계 – 윤명진, NDC 2011 – http://ndc.nexon.com/150111779525 • 데이터마이닝 기법을 게임 통계에서 활용해보기 – 김범주, NDC 2012 – http://ndc.nexon.com/150142371049
• 17. 게임 지표에 대한 이해
• 18. 각종 게임 지표 용어 • MCU: Maximum Concurrent User – 특정 기간 (보통 24시간 기준) 최대 동시 접속자 수 • UV: Unique Visitor – 특정 기간 (보통 일주일 기준) 동안의 순 방문자 수 – 재방문율과 이탈율 계산의 기준 지표 • (예) 지난주 UV vs 이번주 UV • PU: Paying User – 특정 기간 동안 돈 낸 사람 수 • ARPU: Average Revenue Per User – 1인당 평균 결제 금액 • ARPPU: Average Revenue Per Paying User – PU 중에서 1인당 평균 결제 금액 • TS: Time Spent – 유저의 특정 콘텐츠 플레이 시간
• 19. Case-Study
• 20. 온라인 게임 지표 서비스 • PC방 게임 순위 – www.gametrics.com – www.gamenote.com
• 21. 협업 마인드
• 22. Listening Courteously • 팀의 일원 – 적게는 십수명 많게는 수백명의 팀워크가 필요함 – 게임 제작은 정말 다양한 사람들이 모여서 일하게 됨 • 원만한 대인관계 – 사고 방식이 상당히 다른 아티스트, 게임 기획자와 잘 통해야 함 – 자신의 실력이 아무리 좋아도, 성격이 나쁘면(?) 협업이 곤란 – 게임은 혼자서 만들 수 있는 물건이 아니기 때문 – 핵심 비법은? • 경청: 귀를 기울여 듣는 습관 • 경청은 동료간 신뢰의 지름길 – Coworker와의 신뢰가 무너지면 • 특정 콘텐츠가 유기성 없이 분리된 느낌으로 그대로 드러남
• 23. Ownership • 내 할 일만 하면 된다? – 물론, 자신의 맡은 업무를 충실히 하는 것은 필요조건 – 자기에게 떨어진 일만 하고 다른 부분은 ‘나몰라라’하는 경우 • 수동적 자세의 월급쟁이는 환영 받지 못함 • 주인 의식(ownership)이 필요 – 일종의 충분조건 • “내가 만드는 작품이다”라는 마인드 • 주인의식은 만드는 과정 속에서 재미를 느낄 수 있어야 가능 • “이렇게 좀 더 바꿔보면 더 재미있지 않을까?” • 게임 만드는 사람이 재미를 못 느끼면? – 절대 재미있는 게임이 나오지 못함
• 24. Leadership • 다양한 사람들로부터 팀워크를 이끌어 내기 위함 – 존중을 바탕으로 구성원들이 잠재력을 발휘할 수 있도록 • 리더의 진정한 힘은 구성원들의 신뢰에서 우러나옴 – Servant Leadership • 뛰어난 리더는 다른 구성원들을 섬기는 법부터 배움 • Senior 개발자 이상이라면 꼭 읽어봐야 할 책 PD Director Team Lead Senior Developer Developer 호갱님 고갱님 PD Director Team Lead Senior Developer Developer
• 25. 끝 • 학습 목표 체크 – 라이브 서비스와 프로덕션의 차이 – 라이브 팀의 역할과 책임 – 라이브에 있어서 통계 분석이 갖는 의미 – 직접 게임 플레이를 하는 것의 중요성 – 일의 우선 순위에 대한 이해 – 여러 가지 게임 지표에 대한 이해 – 팀워크를 위한 마음가짐 • Q & A
• 26. 참고 자료 • 참고 링크 – 성공하는 라이브조직의 6가지 공통점 • http://www.inven.co.kr/webzine/news/?news=56484 – 메이플스토리: 라이브게임 개발스토리 • http://parkpd.egloos.com/3300918 – 70명이 커밋하는 라이브 개발하기 • http://www.slideshare.net/innover/70-20109362 – 작업장(오토) 탐지에 통계 활용의 예 • http://www.slideshare.net/LeeEunJo/r-14930327 – 서번트 리더십 • http://imaginations.tistory.com/19
• 27. 게임 제작 개론 포스트모템
• 28. 회고의 시간 • 한 학기 동안 수고 많으셨습니다 • Post Mortem – 좋았던 것 – 아쉬웠던 것 – 추가 또는 개선 되었으면 하는 것