
게임기획은 시스템, 레벨, 콘텐츠, 밸런스처럼 세부 직무가 나뉘어 있어 처음에는 어디로 가야 할지 헷갈립니다. 입문 단계에서 각 분야 문서를 한 번씩 써 보고…
실수 1·2: 기능은 설명했는데 규칙과 의도가 없다
첫 번째 실수는 기획서가 기능 소개서처럼 쓰인 경우입니다. '장비를 강화하면 능력치가 오릅니다', '강화에 실패하면 재료가 사라집니다' 정도로 끝나는 문서가 대표적입니다. 이 문장만으로는 몇 단계까지 강화할 수 있는지, 성공 확률은 어떻게 정해지는지, 최대 단계에서 버튼은 어떻게 바뀌는지 알 수 없습니다. 개발자는 이 빈칸을 하나하나 다시 물어야 합니다.
고치는 방법은 기능마다 규칙, 조건, 예외를 나눠 적는 것입니다. 규칙에는 정상적인 흐름을, 조건에는 기능이 열리는 시점과 필요한 재화를, 예외에는 재화가 부족할 때나 인벤토리가 가득 찼을 때처럼 흐름이 깨지는 상황을 씁니다. 예외 항목이 충실할수록 평가자는 실무 감각이 있다고 판단합니다.
두 번째 실수는 기획 의도가 빠진 것입니다. 구조는 꼼꼼한데 이 시스템이 왜 필요한지, 유저에게 어떤 경험을 주려는지가 없으면 단순한 정리 문서로 읽힙니다. 문서 앞부분에 이 시스템이 해결하려는 문제와 목표를 두세 문장으로 적고, 뒤에 나오는 규칙들이 그 목표와 어떻게 연결되는지 보여 주세요.
실수 3·4: 데이터 테이블이 없거나 문서와 따로 논다
세 번째 실수는 데이터 테이블이 아예 없는 포트폴리오입니다. 시스템 기획자의 결과물은 문서와 테이블이 한 쌍입니다. 강화 시스템이라면 단계별 성공 확률, 필요 재료, 능력치 증가량이 표로 정리되어 있어야 문서의 규칙이 실제로 작동하는 모습을 보여 줄 수 있습니다.
네 번째 실수는 테이블이 있어도 문서와 맞지 않는 경우입니다. 문서에서는 최대 강화 단계를 열 단계라고 해 놓고 테이블에는 열두 단계까지 있거나, 문서에서 쓰는 용어와 테이블의 항목 이름이 다른 경우입니다. 이런 불일치는 꼼꼼함에 대한 신뢰를 크게 떨어뜨립니다. 제출 전에 문서의 숫자와 용어를 하나씩 테이블과 대조하고, 자주 쓰는 용어는 문서 앞에 정의해 두는 것이 좋습니다.
테이블을 넣을 때는 항목마다 무엇을 뜻하는지 짧은 설명을 붙여 주세요. 항목 이름만 봐서는 의미를 알기 어려운 경우가 많고, 다른 테이블을 참조하는 관계가 있다면 그 연결도 함께 표시해 두면 데이터 구조를 이해하고 있다는 점이 드러납니다.
실수 5: 분석만 있고 내가 설계한 것이 없다
다섯 번째 실수는 기존 게임 분석으로 포트폴리오 대부분을 채운 경우입니다. 분석은 게임을 보는 눈을 보여 주는 좋은 자료지만, 그것만으로는 직접 설계할 수 있는 사람인지 판단하기 어렵습니다. 특히 분석 대상의 구조를 그대로 옮겨 적은 문서는 평가자에게 큰 인상을 남기지 못합니다.
고치는 방법은 분석을 설계로 이어 가는 것입니다. 분석에서 찾은 문제점이나 아쉬운 점을 하나 고르고, 그것을 개선하는 시스템을 직접 설계해 보세요. 분석, 문제 정의, 개선안, 개선안의 문서와 테이블이 한 흐름으로 이어지면 생각하는 과정과 설계 능력을 함께 보여 줄 수 있습니다. 포트폴리오 안에서 분석과 설계의 비중은 설계 쪽이 더 크도록 구성하는 편이 좋습니다.
직접 설계한 시스템이라도 기존 게임과 거의 같은 구조라면 차별점을 짧게라도 적어 주세요. 어떤 부분을 바꿨고, 그 변화가 유저 경험에 어떤 차이를 만드는지 설명하면 단순한 재현이 아니라 판단이 들어간 설계로 읽힙니다. 반대로 아주 새로운 시스템을 만들었다면 기존 시스템과 어떻게 맞물리는지를 보여 주는 것이 중요합니다. 혼자 동떨어진 시스템은 실제 게임에 들어가기 어렵기 때문입니다.
설계한 시스템이 다른 시스템에 미치는 영향을 한 장으로 정리해 두는 것도 좋습니다. 재화, 성장, 보상 가운데 무엇과 연결되는지 표시하면 시스템 전체를 보는 시야가 드러납니다.
실수 6·7: 흐름도가 읽히지 않고 핵심이 뒤에 묻힌다
여섯 번째 실수는 흐름도를 생략하거나 너무 복잡하게 그린 경우입니다. 시스템의 동작은 글보다 흐름도로 볼 때 훨씬 빨리 이해됩니다. 하지만 선이 엉키고 분기가 너무 많으면 오히려 읽기 어렵습니다. 흐름도는 정상 흐름을 먼저 한 줄로 그리고, 예외 분기는 다른 색이나 별도 그림으로 나누면 훨씬 깔끔해집니다.
일곱 번째 실수는 분량 조절에 실패한 것입니다. 열심히 만든 자료를 모두 넣고 싶은 마음에 문서가 길어지고, 가장 잘한 작업이 뒤쪽에 묻히는 경우가 많습니다. 평가자는 짧은 시간 안에 많은 포트폴리오를 봅니다. 맨 앞에 전체 목차와 대표 작업의 요약을 두고, 가장 자신 있는 시스템을 첫 번째로 배치하세요. 덜 중요한 자료는 과감히 빼거나 부록으로 옮겨도 괜찮습니다.
제출 전에 일곱 가지 실수를 걸러 내는 방법
포트폴리오를 다 만들었다면 아래 항목을 하나씩 확인해 보세요. 혼자 보는 것보다 기획을 모르는 친구에게 문서를 읽게 하고 이해되지 않는 부분을 표시해 달라고 하면 빈칸이 더 잘 보입니다.
- 기능마다 규칙, 조건, 예외가 나뉘어 적혀 있는가
- 문서 첫머리에 시스템의 목적이 두세 문장으로 정리되어 있는가
- 문서와 짝이 되는 데이터 테이블이 있는가
- 문서의 숫자와 용어가 테이블과 모두 일치하는가
- 분석에서 그치지 않고 직접 설계한 시스템이 중심에 있는가
- 흐름도에서 정상 흐름과 예외가 구분되어 보이는가
- 가장 자신 있는 작업이 앞쪽에 배치되어 있는가
체크리스트를 통과해도 내 문서가 개발자 눈에 어떻게 읽힐지 확신이 서지 않는다면, SBS아카데미게임학원 게임기획 과정 상담에서 시스템 문서와 데이터 테이블의 구성을 함께 점검해 보세요.
자주 묻는 질문
시스템 기획 포트폴리오에는 시스템을 몇 개 넣어야 하나요?
정해진 개수는 없습니다. 여러 개를 얕게 넣기보다 깊이 있게 설계한 시스템 몇 개를 중심에 두는 편이 평가에 유리합니다.
문서는 어떤 형식으로 제출하는 것이 좋나요?
회사 공고에 정해진 형식이 있다면 반드시 따릅니다. 따로 없다면 열어 보기 쉬운 문서 파일로 정리하고, 데이터 테이블은 스프레드시트 파일을 함께 첨부하는 경우가 많습니다.
가까운 캠퍼스에서 게임기획 알아보기
사는 곳과 가까운 캠퍼스를 고르면 수업 내용, 오시는 길, 상담 신청을 한 번에 볼 수 있습니다.