(8-1) 시스템 기획
게임 기획(=게임 디자인)
현재 출시되는 게임과 10년전 게임을 비교해보면, 발전 속도도 빠르지만 게임의 수도 빠르게 늘어난다.
이전엔 기획과 개발이 구분되지 않았음.
그러다 스페이스 인베이더가 탄생했다.
프랑스의 다큐멘터리, 일본의 슈팅게임에 대해서
https://www.youtube.com/watch?v=RIg1Qececp8
일단, 기획과 개발이 나뉜 이유는
기획의 전문성이 점점 요구되었기 때문.
게임 볼륨이 커지고, 콘텐츠 비중이 커지면서 독자적인 업무 역할로 다뤄지기 시작.
스페이스 인베이더 이후 부터 전문적인 디자이너가 작업하기 시작
우린 지금(RPG메이커)까지 시스템 기획을 많이 건드리지 않았다.
시스템이란?
필요한 기능을 시행하기 위한 집합체(단일이 아니다).
시스템 안에는 요소란게 있다.
시스템은 누군가가 설계한 것이다
먹이사슬/생태계도 (자연이 설계한)시스템이라고 볼 수 있다.
그럼 '게임 시스템'은?
요소간의 결합을 만드는 것, 그것이 코딩.
정교하게 작동하는 기계장치를 만드는 것. 쉽진 않지...
유니티는 스크립팅 작업이 들어가기 때문에 시스템 배우는 데 도움이 좀 더 된다.
시스템과 기능은 혼용되어 사용된다.
(시스템 기획이 만든 것을 잘 활용하는 콘텐츠를 만드는 것이 게임 디자인)
그래서 기획자는 소통 능력이 중요하다.
시스템 기획은 다른 기획에 비해서 비싸다. 만드는 시간이 더 오래걸리고 수정이 오래 걸리기 때문에.
역기획서는 사람마다 동일해야 한다. 분석이랑 다르다.
각자 만든 게임 역기획을 할건데 시스템 기획을 만들거임
회사의 업무 시스템은 시스템을 먼저 만들고 컨텐츠 만듦(아무 것도 없으니까....).
기반기술: 기초가 되는 것
장식적 기술: 데코레이션.
우린 지금 장식적 기술을 먼저 배우고(쉬우니까) 기반기술로 향하는 것이다.
어렵게 구현한 시스템을 개발 이후 거의 사용하지 않는다면 잘못 만들어진 것.
단순한 기능이라면 시스템은 필요 없다.
장기적으로 사용한다면 시스템으로 만들어야 한다.
튜토리얼에 많이 관여해야 될 듯?
잘 만들어진 시스템은 완성도가 높아진다. 시스템이 크고 복잡한 게임일수록 중요하다. 때문에 최근 중요해지고 있다. RPG게임은 현실세계를 모방해서 만들어지기 때문에 복잡하다.
돈이 오고가고, 인플레이션이 존재하고...
기능의 완성도가 올라가면 시스템의 결함이 줄어들고, 결함이 줄어들면 수정할 상황도 적어진다.
개발 시간이 길어질 수록 수정해야 하는 비용이 매우 커진다.
기획자가 직접 데이터를 조정할 수 없으면 개발자에게 수정 요청을 지속적으로 요청해야 하는 상황이 발생한다. 기획은 자주 수정이 발생하는데 너무 잦게 요청해야 하면 개발자와 사이가 나빠질 수밖에 없다...
밸런스 조정 작업 만큼은 개발자가 아니라 기획자가. 그래서 기획자도 어느정도 코딩을 할 줄 알아야 하는 것.
프로그래머는 기능 구현과 툴 만드는 데 집중 하고, 기획자가 밸런스 조정이나 기획.
예전엔 아이디어만 있어도 게임을 만들 수 있다.
그러나 최근은 디테일, 종류, 모션, 등 시스템 기획으로 경쟁력을 챙기고 있다. 게임들이 상향평준화중.
많은 유저가 좋아한다고 해서 반드시 좋은 시스템은 아니지만
더 편리하고 낫다고 만든 시스템에 대해 모든 유저가 좋아하는 것은 아니다
시스템 기획은 게임 개발을 하면 반드시 한 번은 하게 된다.
게임 기획자는 전달력이 좋아야 한다. 나의 머릿속의 추상적인 개념을 전달해야 하는데 그걸 말과 글로 전달해야 한다.
개발자에게 설명하기 위해 게임에 필요한 기능을 도출하는 방법
-아이디어로부터 출발: 추상적인 단계부터 출발. 게임의 개요부터 출발. 게임의 특징과 목표를 구체적으로 어떤 기능으로 유저에게 보여줄지. 조건에 따른 애니메이션, 모션...
ex) 스카이림을 vr로 만든다면: 오픈월드를 위한 심리스, 많은 종류의 NPC, 몬스터 등
컨셉을 구체적으로 쓰는 것. 그러나 그것도 추상적일 수 있음. 다만 하나 구체화하겠다고 집착하지 말고 전체적인 시스템을 기획해야 함. 구체적인 기능을 찾을 때 자료가 됨.
-벤치마킹으로부터 출발: 한 마디로 차용하는 것. 다른 게임의 시스템을 분석하며 접근. 이미 성공한 게임 참고. 아이디어는 이게 완성도 있을지 좋을지 판단이 어려운데 벤치마킹은 그 점에 대해 결과를 근거삼을 수 있음. 이미 검증된 시스템. :=:시스템 역기획. 다만 완벽하게 가져오는 게 어렵고 너무 많이 차용하면 카피게임이 됨.
-경험으로부터 출발: 자신이 플레이했던 게임의 경험이나 지식으로 기능 검토. 벤치마킹과 비슷. 대부분 자신이 알고 있는 내에서 만들기 때문에 경험에서 만듦. 게임 플레이 경험이 많을수록 유리. 개발자의 기호가 반영. 능력과 이해력에 따라 결과품의 폭이 크게 차이남. 객관성과 대중성이 결여될 수 있음.
개발 조직 내 다른 작업자랑 합의, 본인이 주장한 기능의 장단점, 기능엔 우열관계가 없으니 결정자가 필요할 수 있음.
시스템 기획은 최종적인 톱니바퀴까지 도달하는 과정. 상세한 개념까지 하향식으로 도출한다.
나온 기능을 그룹핑. 구조화.
이걸 뒷받침하려면 뭐가 필요할까? => 최종적으로
기획을 해도 실제 구현했을 때 달라질 수 있다.
개발이 먼저 이루어진 후에 역으로 기획서를 작성하는 경우도 있다.