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