그림 AI갤에 게임 기획 공부한 거 올려봄


자극적인 글보다 건강한 이런 글은 어떠십니까

미식가들은 이런 글을 찾습니다.


어서오세요





과도한 계획자


실제로 많이 있는 유형일 듯?


게임에 대한 아이디어를 가지고 있다.

그 개발자는 제대로 만들고 싶어서

게으름 피우지 않도록 결정한다.


그는 자신이 아는 가장 체계적이고

성실한 방법으로 일하기 시작한다.


몇 달이 지나서 엄청난 문서가 완성되었다.

200페이지에 달하는 문서는 완벽해 보인다.


실제로 제작을 시작하고

누군가에게 게임을 플레이하게 한다.

그리고 그때 많은 것이 엉망이 된다.


가장 어려운 적이 단순한 회피 전략에 당한다.

플레이어는 람머스마냥 굴러다니느라 감동적인 이야기를 놓친다.


플레이어는 가장 단순한 메카닉을 이해하지 못하고

가장 복잡한 메카닉을 적극적으로 사용한다.


좋은 일도 일어난다.

플레이어는 퍼즐에 대한 더 새로운 해결책을 찾는다.

조연 캐릭터에게 반한다.


기획자는 곤경에 처한다.

완벽하다고 생각했던 문서가 있고,

예상치 못한 발견과 실패가 있다.

어느 쪽도 선택하기 어렵다.


이 케이스의 근본적인 실수는

과도하게 계획한 것이다.


(난 계획보다 무지성 개발을 하는 편이라

공감이 안된다;;

이런 케이스는 데미지가 클 듯함)


부족한 계획자


또 다른 케이스도 있다.

이 또한 자주 있는 케이스이다.


팀이 게임 개발을 시작한다.

그들은 아이디어를 검토하는 회의를 갖고

바로 작업에 뛰어든다.


아티스트들은 캐릭터 모델, 환경, 컨셉 아트를 만들어 낸다.

코더들은 AI, 알고리즘, 물리 엔진을 조립한다.

기획자는 레벨을 구축하고 메카닉을 설계한다.

진행이 빠르고 창의적이다.


그러나 시간이 지나면서 상황은 악화된다.

여러 프로그래머가 각자 게임의 성능 자원을

사용하면서 프레임이 끊긴다.


분명한 게임의 아이디어가 없기 때문에

투자자를 찾기 힘들고 펀딩도 어렵다.

게임은 프랑켄슈타인의 괴물 같은 게임이 되어

전체적으로 합쳐지지 않는다.


이 케이스의 근본적인 실수는 계획 부족이었다.


(이런 식으로 하다가

대학 프로젝트 박살 난 적이 있어서

공감된다;;)


계획 부족과 계획 과잉


계획이 없으면 팀과 게임의 다른 부분이

반대로 작동하면서 프로세스가 붕괴된다.

이것이 계획 부족이다.


그러나 우리가 과도하게 자세한 계획을 세우면,

현실과 접촉했을 때 그 계획은 무너진다.

이것이 계획 과잉이다.


계획 부족의 비용


계획 부족이 만드는 몇 가지 문제를 알아보자.


계획 부족은 버려져야 하는 작업을 하게 만든다.

작업은 불필요했거나 나중의 진행에 의해

쓸모 없어진다.

계획이 있으면 이 문제를 방지할 수 있다.


계획 부족은 팀 조정을 해친다.

계획은 팀을 조정하는 데 필요한 부분이다.

두 명의 개발자로 구성된 팀조차도

다음 시간에 무엇을 할 것인지에 대해 이야기해야 한다.


계획이 부족한 프로젝트에서,

사람들은 자신의 작업이 전체에 어떻게

맞는지 명확한 생각 없이 작업한다.


이러면 표준을 따르지 않는 캐릭터 모델이나

너무 많은 메모리를 사용하는 하위 시스템 등의

문제가 생길 수 있다.


이런 통일성의 부재는 게임을

핵심 없는 누더기로 만든다.


마지막으로, 외부 관계자들에게 정보를 공급하지 못한다.

예를 들어, 투자자들에게 게임을 제대로 설명하지 못하거나,

크라우드 펀딩에서 매력 어필에 실패할 수 있다.


계획 과잉의 비용


조금 과한 계획이 나쁘지 않다는 보편적 생각이 있다.

그러나 과한 계획은 여러 방식으로 프로젝트를 박살 낸다.


우선 계획을 작성하는 데 리소스를 많이 쓴다.

계획을 수립하고, 토론하고, 기록하고, 편집해야 한다.

이것은 많은 리소스를 잡아먹고 부담이 된다.

개발할 때 써야 할 노력을 계획 작업에 쓰게 된다.


또한, 불가피하게 실패할 때 계획을 취소하는 것도

비용이 많이 든다.


아이디어 취소는 정치적 자산을 필요로 한다.

그리고 1인 개발이라도 아이디어 취소는

심적으로 괴로운 일이다.


하지만 계획 과잉의 진짜 문제는

미래에 대한 거짓된 확실성을 만들어낸다는 것이다.


당연히 이런 일이 일어나고 저런 일로 연결된다는

가정으로 가득 차 있다.


그 가정에 의존하는 게임 개발은

그 가정이 거짓으로 판명 나면 무너진다.


이 대가는 비싸다.

게임 시스템은 그물망처럼 연결되어 있으며,

한 곳에서의 변경이 다른 곳에서 많은 변경을 일으킨다.


단순한 점프 높이의 변경은 레벨 경계, 적의 움직임,

점프 퍼즐. 점프 효과 등의 추가 변경을 의미한다.


실패한 계획의 영향은 파문처럼 퍼져나가며,

아트, 코드, 메카닉, 설정을 비틀어버린다.


개발 프로세스 반복하기


우리는 전부 계획할 수 없다.

그렇다고 계획이 없으면 전복된다.

우리에겐 중간 지점이 필요하다.

개발 프로세스를 반복해야 한다.


반복법은 단기 계획을 세우고,

그것들을 구현하고,

테스트하는 걸

반복하는 방법이다.


전통적인 창조는 선형으로 이루어진다.


계획 → 제작 → 실험


이 순으로 제품이 완성된다.


반복법은 다르다.

순서대로가 아닌 반복적으로 실행된다.


계획 → 제작 → 실험

→ 계획 → 제작 → 실험...


이는 먼 미래에 일어날 일을

예측할 필요가 없음을 의미한다.


현재 반복의 끝까지만

기획하면 된다.


게임을 테스트할 때마다

우리는 가정과 현실을 비교할 수 있다.


이렇게 진행한 현실 검증으로부터

다음 반복을 위한 계획에 참고로 할 수 있는

신뢰 가능한 지식을 얻을 수 있다.


반복법 예시


일단 기본적인 전투를 설정한다.

원하는 방향은 있지만

제1 목표는 가능한 한 전투를 빨리

전투를 플레이하는 것이다.


몇 시간 안에, 돌아가는 전투를 만들었다.

그리고 그것은 당연하게도 끔찍하다.


아주 개판이라 플레이어는

항상 이긴다.


그러나 그것의 조악한 품질에도 불구하고,

첫 번째 버전은 목적을 달성한다.

반복 루프를 마무리했으니까.


이제 전투는 더 이상 머릿속 허상이 아니다.

실제로 플레이하는 전투가 되었다.


이 시도는 성공적이다.

이제 그것을 플레이하면서,

아이디어가 떠오르고

구체적이고 실질적인 생각이 든다.


이제 영감이 떠나지 않고

무기, 적, 엄폐물 등을 수정해서

테스트해보게 된다.


그렇게 전체적인 게임을 수정하며

반복 루프를 거치면

자체 테스트의 한계를 보게 된다.


자신의 작업을 테스트하는 것에서

더 이상 새로운 것을 찾아내지 못하는 지점에 도달한다.

그러면 이제 실제 플레이어들의

플레이를 관찰해야 한다.


항상 기획은 실패한다.

플레이어가 무빙으로 적들을 다 지나치거나

의미 없이 바닥을 치고 있다. (실화임)


테스트 플레이를 거치면

크고 작은 문제가 보인다.

이런 식으로 더 반복한다.


반복하면 다양한 실력 수준과

플레이 습관의 플레이어들이

게임에 적응할 수 있게 된다.


이제야 아트에게 넘겨줄 준비가 된 것이다.

그리고 이젠 다른 개발 분야를

포함하는 반복을 돌아야 한다.


사운드, 아트, 서사 등을 포현하는

방법을 찾기 위해 다시 반복해야 한다.



계획의 지평


반복 루프는 얼마나 길어야 할까?

매일? 매주??


루프가 너무 길다면,

계획을 너무 과도하게 하고 있는 것이다.


루프가 너무 짧다면 계획이 부족한 것이다.


계획 지평은 기획자가 미래에 대해

계획하는 시간의 길이이다.


긴 계획 지평은 다음 테스트 전에

다음 달의 작업을 계획하고 실행하는 것이다.


짧은 계획 지평은 테스트를

분 단위로 테스트하며 짧게 계획을 세우는 것이다.


계획 지평 선택의 기준은

계획의 불확실성을 고려하는 것이다.


독창적이지 않은 아류 게임들은

이미 지식이 확립되어 있기 때문에

상대적으로 멀리까지 계획할 수 있다.


반면 참신한 게임은 아직 발견되지

않은 것들이 많기 때문에

단기 지평까지만 계획할 수 있다.


자기가 어떤 게임을 만들고 있는지

확인하고 그에 맞는 지평을 사용하자.


적절한 계획 지평은 프로젝트가 진행되면서

점점 길어지는 경향이 있다.


큰 틀을 설계하는 프로젝트 시작점에는

변화가 잦다.


하지만 후반엔 큰 틀이 잡히고

미세한 변화를 고민하게 되기 때문이다.


테스트 프로토콜


반복적 프로세스는

계획, 제작, 테스트의 순환 과정이다.


그러나 모두가 계획과 제작에 집중하고,

테스트는 종종 무시한다.

하지만 테스트 단계는 실제 세계로부터

교훈을 얻는 메카닉이라 중요하다.


좋은 테스트는 큰 비용 없이

엄청난 교훈을 준다.


좋은 데이터를 얻는 핵심은

올바른 테스트 프로토콜을 사용하는 것이다.


테스트 프로토콜이란, 플레이 테스트를

수행하기 위한 규칙 및 절차의 모음이다.


나쁜 테스트 프로토콜은 수없이 많다.

이런 프로토콜은 쓸모없는 것보다

더 나쁜 결과를 낸다.

잘못된 지식을 낳는 것이다.


예를 들어, 플레이어 그룹이 오랫동안

방에서 게임을 플레이하는 프로토콜이 있었다.


그 프로토콜은 인터넷의 낯선 사람들끼리

플레이할 때의 기획 실패를 찾지 못했다.

결국 그 게임은 찾지 못한 정보로 인해 실패했다.


기본적인 테스트 프로토콜

몇 가지를 살펴보자.


1) 자가 테스트

혼자 플레이하는 것이다.

게임에 대한 기획자의 지식에 의해

편향되어 있을지라도,


단순히 게임 시스템이 작동하는 것을

관찰하는 것만으로 엄청난 이해를 얻을 수 있다.


반복적 과정의 초기 루프는 자가 테스트로

마무리하기 좋다.


2) 플레이 테스트


플레이 테스트는

기획자가 다른 플레이어들을 관찰한다.


플레이 테스트는 자가 테스트보다 낫다.

왜냐하면, 플레이어들이 다양할 수 있고


기획자처럼 게임에 대한 완전한 지식을

가지고 있지 않기 때문이다.


플레이 테스트에서 가장 큰 위험은

그들이 가지고 있지 않아야 할 정보를

제공함으로써 테스트를 오염시키는 것이다.


이 때문에 기획자는 반드시 침묵해야 한다.

말하지 말고 웃지 말아야 한다.


'왜 자꾸 의미 없이 땅바닥을 때리는 거야?

아오 답답해!! 제발 살려줘!!!' 싶어도 참아라...

꾸우우욱 참아야 한다...


준비물인 플레이 테스트해줄 친구는

다들 하나씩 가지고 오셨죠?


샘플 사이즈


한 번의 플레이 테스트 결과에 집착하기 쉽다.

하지만 첫 번째 테스트는 경험의 크고 다양한

세트 중 중요하지 않은 부분일 수 있다.


플레이 테스트를 잘하는 것은

많이 테스트하는 것인 이유이다.


좋은 기획은 기획자가 게임이 생성할 수 있는

모든 다양한 경험에 대한 이해를 쌓았을 때만

내릴 수 있다. 그러므로 많은 테스트가 필요하다.


품질의 역설


전통적인 작품은 천천히, 주의를 기울이며

작업하면 품질 좋은 제품이 나온다.

프로세스의 모든 단계를 천천히 해야 한다는 뜻이다.


하지만 게임은 반복 루프의 수만큼 발전한다.

모든 단계의 품질에 집착하면 반복 작업이 늦어지고

더 나쁜 게임으로 이끌린다.


이것이 초기 반복에서 불완전한 작업을

거부하는 것이 자주 하는 실수인 이유이다.


완벽하지 못해서 한 단어도 적지 못하는

소설가와 같은 실수를 범하는 셈이다.


게임 기획에서는 최종 품질에 도달하기

전에 모든 것이 여러 번 수정되고 다시 만들어진다.


초기 반복 주기에서 하는 작업은 최종 게임을

구축하는 것이 아니다.

최종 게임의 정거장을 만드는 것이다.


비전의 오류


비전의 오류란 경험의 머릿속의 영화가

그 경험을 생성하는 시스템의 설계와

동일하다는 생각이다.


프로그래머가 기획자한테

어떤 게임을 만들지 물어봤더니


"아~ 우리 게임은 플레이어가 즐거워하고~

전 세계가 놀라며~ 배경 환경이 아름답고~

게임 플레이가 너무 재밌는 게임이야."

라고 하는 것과 같다.


사람은 본능적으로 머릿속의 영화를

사용하여 결정을 내린다.


게임 기획에서 그것을 플레이하는 것을

상상하며 게임의 잠재력을 평가할 때 쓸 수 있다.

이런 걸 비전이라고 부른다.


하지만 이런 비전은 오해될 수 있다.

비전은 경험을 정의한다.


하지만 게임은 경험 자체가 아니라,

'경험을 생성하는 시스템'이다.


완벽한 경험을 완벽한 게임과 혼동하거나

멋진 게임 경험의 비전을

훌륭한 게임의 기획과 똑같이 생각하면 안 된다.


비전은 경험 뒤에 있는 시스템이 얻는 것과

잃는 것을 말해주지 않는다.



중요한 건 꺾이지 않는 반복


계획하는 습관을 극복하기는 어렵다.

이런 글을 읽어도 어려운 일이다.


사실 직접 경험해 보기 않으면

깨달을 수 없는 것들이 있기 때문이다.


이런 경험은 게임을 완성까지 가져가는 경험이다.

작은 게임들은 계획에 저항하기 쉽다.


하지만 팔리는 게임, 규모가 큰 게임은 어렵다.

기획자에게 친절할 이유가 없는 플레이어에게

노출되어야 기획자는 감정적 믿음을 바꾸는

고통스러운 피드백을 받을 수 있다.





a76500ab1f3fb350af3406709a2cf0b6073a7d0a138800cca9d9a482990e3851c688