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

 안녕하세요. '호랭이 물어갈 기획놈들' 입니다. 아바타 조합 시스템 기획서 해부 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 메인 아바타 등록 필요 아이템[큐브] 슬롯 오픈(큐브 자동 등록) 재...

  안녕하세요. '호랭이 물어갈 기획놈들' 입니다. 프로그래머, 아트 파트와 피 튀기는 조립 과정을 거쳐 드디어 게임이 화면 위에서 정상적으로 돌아가기 시작했습니다.  신입 기획자는 "아, 드디어 내 글자와 그림 쪼가리가 실제 게임으로 완성됐구나!"라며 안도의 한숨을 내쉽니다. 하지만 착각하지 마십시오.  진정한 지옥은 이제부터 시작입니다. 유저의 마인드로 빙의해 게임을 갈기갈기 찢어발기는 개발 후반부의 최종 보스, 'QA(Quality Assurance) 파트'와의 피 말리는 전쟁이 기다리고 있습니다. 오늘은 16년 차 실무자의 시선에서, 기획자의 멘탈을 부수는 QA 테스트의 현실과 대처법을 뼈 때리게 해부해 드립니다. 살아있는! '버그 제조기' QA 파트는 절대 일반 유저 처럼 얌전하게 게임을 플레이 하지 않습니다.  그들은 기획자의 상식을 파괴하는 '살아있는 버그 제조기'이자 극한의 테스터들입니다. 보상 받기 버튼을 0.1초 만에 50번 연타 하는 것은 기본입니다. 아이템 받기 버튼 후 보상 획득 팝업 창으로 넘어가는  중간에 AOS Back 버튼을 미친 사람에 빙의해 연타 후 앱을 강제로 꺼버리고, 절대로 동시에 눌릴 리 없다고 생각했던 UI에 출력 된 네 개의 모든 버튼을 자기 옆 사람의 손가락까지 이용해 기어코 동시에 눌러버립니다. 기획서에 적힌 '아름답고 정상적인 플로우' 따위는 이미 그들의 머릿속에 존재하지 않습니다. 기획자가 미처 생각하지 못했던 시스템의 구멍, 룰과 룰이 충돌하는 심연의 공간에서만 살아왔던 사람처럼 집요하고 잔인하고 처절할 정도로 파고들어 기어이 클라이언트 또는 서버에서 크래쉬를 뱉게 만듭니다. 내가 만든 완벽하고 아름다운 내 자식 같은 게임이 QA 파트의 손에 넘어가자마자 걸레짝이 되어버리는 것을 실시간으로 목격할 때, 신입 기획자의 멘탈은 그야말로 산산조각이 납니다. 사적으로 만나면 정말 선하고 가정에 충실한 사람들이 개발자와 기획자의...