현업(게임) 시스템 기획자의 실무 노트

 안녕하세요. '호랭이 물어갈 기획놈들' 입니다. 아바타 조합 시스템 기획서 해부 3부작의 마지막 시간입니다.  1편에서는 시스템의 목적(BM)과 룰을 짰고, 2편에서는 그것을 서버가 알아들을 수 있는 데이터 테이블(ItemMixTable)로 번역했습니다. 이제 완벽할까요? 아닙니다.  이대로 프로그래머에게 기획서를 넘기면 욕을 한 바가지 먹고 반려 당합니다.  유저가 우리가 의도한 대로만 얌전히 버튼을 눌러줄 리도 없고 프로그래머 아저씨들도 예외 사항에 대한 질문을 쏟아낼 생각만 하기 때문입니다.  그렇지 않으면 혼자 고민하고 개발하면 이거 아닌데요 바꿔주세요! 라고 개선 요청을 하기 때문입니다. 그럼 오늘은 기획자가 QA 테스트 시 쏟아지는 버그 리포트 재앙과 프로그래머의 이건 어떻게 해요? 라는 예외 사항을 처리하기 위해 반드시 설계해야 하는 'UI/UX 흐름(Flow)'과 '예외 처리(Exception)' 파트를 뜯어보겠습니다. UI/UX: 물 흐르듯 흘러가는 흐름 설계 신입 시절에는 UI 기획을 하라고 하면, 단순히 화면에 네모난 슬롯 몇 개 그리고 "여기에 아이템을 올리세요"라고 씁니다.  하지만 실무의 UI 기획은 '어떤 순서로 조작하게 만들 것인가'를 통제하는 과정입니다. 당시 제 기획서의 [UI 슬롯 오픈 순서]를 살펴보겠습니다. [조합 UI 조작 순서] 초기 UI 오픈 시, 메인 아바타 슬롯(1번)만 활성화되고 나머지는 잠금 처리. 유저가 1번 슬롯에 '일반' 등급 아바타를 등록. 시스템이 등급을 체크한 뒤, 촉매제(큐브) 슬롯에 필요한 아이템을 자동 등록하고, 서브 아바타 슬롯(2번)을 활성화. 2번 슬롯에는 1번과 동일한 '일반' 등급 아바타만 등록 가능하도록 필터링. ItemMix UI의 슬롯이 열리는 순서 No 상황 표시 1 UI를 열었을 때 메인 슬롯만 표시 2 메인 아바타 등록 필요 아이템[큐브] 슬롯 오픈(큐브 자동 등록) 재...

  안녕하세요. '호랭이 물어갈 기획놈들' 입니다. 데이터 테이블에 더미 데이터를 꽉꽉 밀어 넣고 잠시 꿀 같은 휴식을 취했다면, 이제 신입 기획자들의 멘탈을 산산조각 낼 '2차 위기'가 찾아올 시간입니다. 타 파트에서 개별적으로 제작되던 UI, 아트 리소스, 그리고 클라이언트와 서버의 패킷 통신이 드디어 하나의 게임으로 조립되는 시점입니다.  기획서엔 없었던 치명적인 맹점들이 터져 나오는 리소스 조립 단계의 현실을 16년 차 실무자의 시선으로 해부해 드립니다. 1. 무더기 예외 사항 작업이 어느 정도 진행되면 아트 팀에서 이미지 리소스와 이펙트 리소스 , UI 까지 쏟아져 나오고 , 클라이언트 프로그래머는 기획서의 룰에 맞춰 서버 담당자와 패킷 ( 데이터 ) 을 주고받는 연동 작업을 시작합니다 . 그리고 바로 이 시점에 , 별일 없을 줄 알았던 기획서에 숨겨져 있던 알지 못했던 이슈들이 나 좀 해결해 달라고 미친듯이 나타납니다 . " 보상 획득 팝업에 버튼을 눌러 보상을 받는 중 출력되는 0.5 초의 애니메이션 중간에 클라이언트를 강제로 꺼버리면 , 보상은 지급해야 하나요 롤백해야 하나요 ?" " 서버 지연으로 패킷이 늦게 도착해서 랭킹이 변경될 수 있는데 되는데 이건 어떻게 처리하죠 ?" 머릿속으로 상상만 하며 문서를 쓸 때는 절대 보이지 않았던 , 물리적인 리소스와 네트워크 환경이 맞물리면서 발생하는 ' 무더기 예외 사항 ' 이 쏟아집니다 . 프로그래머들의 날카로운 질문 공세 속에서 , 신입 기획자는 자신의 문서가 얼마나 단순한 예외처리 몇 개만 작성한 반쪽짜리 문서인지 처절하게 깨닫게 됩니다 . 이때 당황해서 프로그래머에게 잡아 먹힐 행동은 절대 하지 마세요 ! 추가로 이것도 모르냐는 헛소리로 프로그래머를 자극시키지 마십시오 .  발생한 예외 사항들을 리스트업 하고 , 룰의 충돌을 막는 예외 사항 처리 방식을 기획서에 빠르게 추가 업데이트 하는 것이 진짜 실무 기획자의 몫...