Egloos | Log-in


프로토타입은 어떻게 만들어야 하는가 (2)

순서상으로는 Strategy를 보강하는 방식과, Strategy를 기반으로 프로토타입을 제작하는 세부를 먼저 봐야 겠지만, 내용이 복잡한 만큼 좀 더 나중에.

일단은 발생하기 쉬운 또 다른 문제들 부터 살펴보자.



프로토타입 vs 코어 모듈

프로토타입이라는 딱지만 붙었지 프로토타입 -> 클베로 변질 되어가기 위한 초석으로 사용하는 물건애초에 프로토타입이 아니다.

이런 건 차라리 '코어 모듈'이라 부르는 편이 맞으며, 기초 게임 플레이를 실제로 검증할 필요 없을 정도로 '재미있을' 물건이라면 방식 자체가 잘못 된 건 아니지만 어쨌든 프로토타입은 아니다.

실제로 검증할 필요가 없는 형태라는 건 기존 모델이 이미 있다던지, 논리적인 사고로 충분히 확장이 이루어진 완성형의 게임플레이를 검증할 수 있다던지 하는 형태로, 당연히 실제 검증은 불필요하다. 이럴 경우에는 완전히 폭포식 개발 방식으로 쫙 짜맞춰진 개발을 행하거나 좀 더 안전하게 만들기 위해 '코어 모듈'을 최대한의 품질 관리 속에서 만드는 것이 좋다.

그러나 발견할 수 있는 모델이 없거나 있다고 해도 한 가지 이상의 드라마틱한 변화가 가져다 줄(그리고 개발 리스크가 큰) 효과를 보고 있다면 이 경우는 프로토타입으로 우선 검증을 하고 출발하는 것이 옳다.

그리고 개발 과정에서 발생할 리스크들을 모두 경험하고 게임 플레이를 검증한 뒤 자양분으로 삼기 위한 것이므로 프로토타입은 완성 후 버려야 한다.



다시 말한다. 프로토타입은 그냥 버려야 한다.

당연히, 진짜로 프로토타입 제작 과정에 만들어진 코드, 문서, 그래픽 리소스의 재활용이 전혀 불가능 한 건 아니다. 그러나 애초에 버릴 각오로 짜기 시작하는 물건과 원래 남겨두려고 만드는 물건은 개발 단가에 큰 차이가 발생하기 때문에 애초에 버릴 생각으로 만들어야 한다.

뭐라도 재활용 할 부분이 있다면 프로토타입 개발 과정에서 자칫하면 개별 목표가 '품질'이 되면서 '프로토타입을 위한 QA'가 발생하게 되고 왠 난데없이 개발자들의 피드백을 수용하기 시작한다. '이거보다 이건 어때요?' '이런거 더 집어 넣으면 더 간지날 것 같지 않아요?' '이걸 추가합시다!' '캐릭터를 가지고 이런 행동을 하면 뻑나요! 고치고 합시다!' 등등.

자, 애초에 버릴 물건이라면 귀찮아서라도 이런거 안고치게 된다. :-p

피드백 수용은 모조리 뒤로 미루어지고 모든 프로세스는 '일단 돌아만 가는 프로토타입'에 맞춰지며 뭔가 상당히 거지같지만 게임은 만들어진다. 이건 애초에 생각했던 완성품에서 어딘가 거리가 있어 보인다. 그래도 좋다.

마음의 눈으로 봤을 때 부족한 부분을 채울 수 있고, 원래는 자동으로 처리 되어야 할 부분을 수동으로 처리해서라도 확인이 가능한 것. 그리고 두 번 실행시키면 한 번은 안 뻗고 실행하는 것.

이게 진짜 프로토타입이다.



프로토타입은 폭포식 개발 방식을 따르는 것이 가장 좋다.

개발 속도를 보장하기 위해 폭포식 개발 방식을 따르는 것이 좋다. (개발 규모가 작다면 폭포식 개발 방식이 개발 기간 상 가장 유리하다.)

적어도 프로토타입에 대해서는 완성 전까지 기획자가 모든 칼자루를 쥐고 완성 시점까지의 가이드라인을 상세하게 적어 넣은 뒤 만약 모듈화가 필요한 부분이 있다면 그를 서포트 하기 위한 스크립트 문법 디자인 까지 - 가급적이면 프로토타입에서는 문법형 스크립트를 과용하는 것을 추천한다. - 싸그리 다 해서 전달하고,

기획자는 귀를 막고 완성본의 모습을 계속 상상하며 실수한 것이 없나만 계속 검증하는 것이 좋다. (물론 정확한 설명은 필요할 때 마다 해 줘야 하고 문법형 스크립트를 나누어 받았다면 그걸 가지고 만들어야 하지만 :-( )

아무리 저렇게 만들고 가혹한 일정이 그들을 병들게 할지라도 정말 착한 프로그래머들은 병목이 발생하여 스스로가 놀고 있을 때 테스트가 엉망이 될 부분을 서포트 해 준다.(우리 프로그래머들은 정말이지 날 만나기 전까지만 해도 충분히 착한 사람들이었다. :-)) 그야말로 최소 품질을 맞춰 주며 경우에 따라서는 스스로 나서서 뭔가 기능을 추가해 주기도 한다.

착하지 않은 프로그래머들이라고 해도 일정을 어길 수는 없다.(일정이라는 건 윗분이 시키는 거다.) 여기선 퀄이 떨어지더라도 시간만 맞추라는 요구에 맞춰 주는 것이 그들의 의무이다. 음? 정말 나쁜 프로그래머에게 걸렸다고? 하늘을 탓해라. 당신은 게임을 개발할 수 없는 상황에 놓인 거다. (차라리 스스로 플래쉬로 만드는 수 밖에 :-p)

하지만 행운을 기대하진 말고 최소 품질에 최고속 개발만을 염두해라. 만약 이가 빠진 부분이 있어도 별로 고민하지 말고(어차피 계획이 빠져 있던 부분은 별로 중요하지 않은 부분이다.) 기획에 대해서도 최소 품질을 유지하자. 프로토타입의 가치는 빠른 것이지 품질이 아니다.



프로토타입이 완성 된 다음에 귀를 열어라

만드는 동안에는 '플레이어가 충분히 주의를 기울여야만 발생하지 않는 버그' 까지도 고치지도 말고, 완성과 실험에만 집중한다.
'두 번 실행 시키면 한번은 게임을 뻗게 만드는 버그'조차도 고치지 않는다. (물론 테스트에 프로그래머가 참여하면 스스로 열받아서 고쳐 주기도 한다 lol)

물론 프로토타입 제작 과정에서 어딘가에 병목이 발생하여 놀고 있는 개발자가 발생한다면 나름의 품질 관리 - 그래픽 리소스를 붙여 본다던지, 버그 중 너무 빈번히 발생하는 놈을 잡는다던지 - 를 해도 되고 여유가 있을 때 가장 큰 효과를 볼 만한 작은 변화를 추가 요청해도 괜찮다.

그리고 아무리 '폭포식 개발 어쩌구' 하고 떠들었어도 뻔히 완성본이 가질만한 치명적인 게임플레이 문제를 제작 도중에 눈치챘으면 모두에게 사과하고 즉시 수정해야 한다. (개발기간이 연장 되고 당신에 대한 신뢰도는 하락한다. 그리고 윗분들은 슬슬 당신의 급여를 깎고 싶어할 것이지만...... 그래도 참자. 아직 쫓아낼 수준은 아닐 것이다. :-p )

또 100% 뻗는 버그는 당연히 고쳐야 한다. 돌아는 가야 테스트를 하던지 말던지 할 것 아닌가.

그래도 항상 염두해 둘 것은 개발 속도다. 모든 피드백을 씹고 독재자처럼 굴어라. 개발 속도를 위해 모든 것을 희생해라.



어쨌든 돌아는 가는 프로토타입 자체가 완성 되어 버렸다면 이제 귀를 열......

아, 잠깐. 당신은 한동안 세상에서 가장 나쁜 사람이 되어 있었을 것이다. 말 안듣는 벽창호에 재수없는 새끼, 재미 없는 게임 혼자 다 만드네 지랄, 이 자식이 지말대로 만들면 재미있을 거라고 했잖아? 병신 아냐? 등등.

자신이 들을 수 있는 가장 심한 욕설들을 스스로에게 실컷 내 뱉았는가?

그럼 이제 진짜로 귀를 열어라. :-)



악몽의 테스트

선별된 집단이라고 해도, 플레이 해볼 때 꼭 시키지 않은 짓을 하거나 하지 말라고 귀에 못이 박히도록 설명한 짓을 무조건 하는 사람들이 있다. '그건 정식 서비스에서는 치트니까 쓰지 말라니까?!' '아니 그렇게 하면 뻗는다고 말했잖아!' '한 번 마법을 쓰고 나면 무조건 채팅창에 /dmp 10 을 치라고 시켰잖아!'

피드백은 받지 않는 부분이라고 아까 그렇게 주의를 줬어도 큰 소리로 떠들며 계속 외친다. '여기 뻗었어!' '이거 왜 이래?' '아니 매번 채팅창에 뭘 치라니...... 이런 게임이 어딨어?!'

안다. 나도 안다.

하지만 세상에서 가장 말 안 듣는 사람들도 윗분을 대동해서 강제로 시키면 테스트가 시작될 수가 있다.:-p 그리고 테스트가 반복되면 결국에 가서는 잠잠해 지기도 한다. 이 때 까지 기다려라. (다른 방법은 아직 모른다.)

그리고 품질 문제로 인한 실수가 사라진 뒤 '진짜 테스트'가 되기 시작해서 게임에 대략 1분이라도 사람들이 집중한 모습 - ※ 극히 중요! 모두의 입을 단속한 상태에서다. 떠들면서 파티 분위기로 진행 되는 게임은 '어떤 게임이라도 재미있다.' - 을 발견한다면, 그건 틀림없이 무언가 괜찮은 Strategy를 가진 게임이라는 뜻이다.

(※ 다시 강조한다. 떠들면서 파티 분위기로 진행 되는 게임은 세상에서 가장 재미 없는 게임이 아닌 한 뭐라도 재미있다. 조금이라도 제대로 검증하고 싶다면 조용한 분위기에서 게임이 진행 되어야 한다!)

1분이라도 집중한 모습을 확인했다면(보다 더 좋은 검증 방식은 나중에) 어느 정도는 안심해도 좋다. 테스트가 종료된 뒤 피드백을 받을 준비를 한다.

확인 못했다면? 이미 틀렸다. 반성하고 다음 기회를 노리도록.



Feedback - 사방은 모두 적이다

구두로 피드백을 받을 상황이라면 - 가능하면 웹 등의 매체를 추천하지만 - 이미 대처 방안을 마련해 둔 내용은 미리 언질을 두어 불필요한 회의 시간을 줄이는 것이 좋긴 하다. 

기초 피드백을 받기 전에 Simple, Gathering에 대한 내용은 문서로 전달 해 두면 오해를 막을 수가 있고 Synchronization에 관련된 내용은 제작 도중에 이미 그래픽 팀과 상의해 스틸 샷을 한 장이라도 받아 두는 것이 불필요한 피드백을 줄일 수가 있다.

자, 이런 대처 방안이 미리 마련 되어 있는 상태에서 핵심 Strategy가 괜찮은 부분이 있다고 해도 욕설만 잔뜩 들을 가능성도 물론 있다. 세상에는 까칠한 사람 많다. :)

그래도 닥치고 들을 때다. 특히 다음 타입을 염두해 두자.

아까 방안이 있다고 한 부분을 꼭 말하거나
말한 내용 다시 말하거나
지나치게 감성이 다르다고 찍혀 있는 사람이 엉뚱하게 말한 내용들에 대해

괜히 정면에서 열내며 이야기 하지 말고 무조건 조용히 적어 두자. 물론 위에 언급 된 타입의 내용들은 씹어도 되긴 하지만 어쨌든 모조리 자산이 된다. (가급적이면 당장의 피드백 이외에 별도로 브레인 스토밍도 이때 집중적으로 개최할 것을 권한다.)



여기까지 오게 된 것이 '완성 된 프로토타입'이다.

여전히 게임플레이가 검증되지 않았다고 보이거나 뭔가 문제가 있어 Strategy 자체를 보강해야 할 부분이 있고, 피드백 내용을 종합한 결과 기존 프로토타입에 약간의 첨부로 확인해 볼 것이 있다면 프로토타입 보강(정확히는 이미 Strategy가 깨졌으므로 실질적으로는 다른 프로토타입 개발 계획이나 다름 없다.)이 발생한다.

보강에 보강을 몇 차례 해 봐도 싹수가 안보인다면 이미 틀렸다는 내용이다. 기획자도 울고 그를 믿었던 윗분도 같이 우는 수밖에.

반대로 Strategy 자체가 '코어 모듈'로 만들어도 손색이 없을 게임 플레이가 검증이 되었다면 이젠 '진짜 개발'의 시작이다. 이 때 버린 물건을 모두 잘 봐 두도록. 그걸 만들 때 머릿속에 떠오른 수 많은 잡념과, 허접한 결과물을 토대로 개최한 브레인 스토밍, 피드백, 그리고 게임의 성공 가능성이 진짜로 '완성된 프로토타입의 자산'이다.

프로토타입은 경험과 구조. 그리고 보증을 남기는 물건이지 유형의 그 무엇도 남기지 않는 것이라는 이야기다.



아, 물론 프로토타입이 완성 된 상태에서 아무리 가능성을 보았더라도 윗분들 보시기에 나쁘면 물론 접히는 거고. :-(

by fieldkim | 2007/05/10 01:30 | GameDesign(고급) | 트랙백 | 덧글(10)

트랙백 주소 : http://fieldkim.egloos.com/tb/3163624
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
Commented by 글강 at 2007/05/10 11:02
본문의 내용과는 조금 동떨어지지만...;;;

윗분이 프로토타입을 보시매 잘 돌아가는 것이 보기 좋더라. 그리하여 가라사대.
'게임 거의 다 만들었네? 한 두어달 있으면 런칭할 수 있겠지?'
... 충격과 공포지만 의외로 자주 발생하죠 ㄱ-
아 물론 '이건 프로토타입이라 이걸 그대로 게임에 쓰지는 못합니다'같은 비겁한 변명(?)은 윗분들께 먹히지 않죠... ( ..)
Commented by 보노 at 2007/05/10 17:45
방안에 몰아 넣고 장시간 스토밍하던 기억이 나는근.
일단 다 듣고 맘대로 하는 필드의 센스가 난 좋아. >.<
놀리는거 아니고, 정말 그래.

안 듣고 결국 맘대로도 못하고,
후에 변명꺼리나 생각하는 사람들도 많아서리..

난 재수가 좋근, 생각해보니 첫단추가 훈륭했어.(홍홍하근)
Commented by fieldkim at 2007/05/10 21:34
글강/
실수로 퀄리티가 높은 프로토타입이 나오면 일부러 퀄 다운 시키는 테크닉도 고려해 볼만 하죠 :)

과하게 낮으면 접히고, 과하게 높으면 한 두어 달 뒤에 런칭 명령을 받게 되니 윗분을 잘 만나거나 잘 파악하는 것도 중요할 듯. :-)



보노/
난 확실히 변명쟁이는 아니라고 자부하지만...... 그래도 이상한 칭찬을 받으니 낯이 좀 뜨겁군;;

...... 지금 기획자는 그런 부분에서 골치 아픈가 혹시?;

재량이 있다면 '왜 XXX 게임이 잘 팔리고 YYY가 못 팔렸는가'를 말하려고 시도하는 기획자만 뽑더라도 그 사태를 상당히 막을 수 있을 터이지만 자네에게 인사권이 있을리는 만무하고;;
Commented by 윌리엄 at 2007/05/11 09:33
프로토타입은 폭포수식으로 잘 만들었지만 그 이후에 프로토타입의 진정한 필요성을 간과한 경험이 있습니다. 정말 팍팍 와닿네요. 그런데, 실 개발로 들어가서 이런 상황은 어떻게 해석해야
하나요?

D: '프로토타입에서 구현했던 기능인데, 구현에 문제가 있나요?
P: ' 몰라요. 프로토타입은 다 잊었어요.
Commented by 보노 at 2007/05/11 11:01
요즘 한창 포스팅 중이근. 업뎃 속도가..

낮이 뜨거워도 어쩔수 없어, 안탑깝게도 첫 단추를 잘못낀 사람들은 많단다. 적어도 나는 운이좋았다고 생각해줘야지.
Commented by fieldkim at 2007/05/11 23:33
윌리엄/

프로그래머가 의도적으로 악의를 가지고 한 경우라면 뭐 막장이죠;
그렇지 않다면 프로그래머가 진심으로 실력이 없던가,
아니면 프로토타입의 가치를 전혀 인식하지 못했을 경우군요.

프로토타입을 했든 안했든, 애초에 프로그래머는 적어도 '구현에 문제가 있나요?'의 질문에 대해서는 대답할 의무가 있다고 봅니다. 정직하게 말해 주지 않는다면 어차피 전멸입니다 :-(

기술적으로 불가능한 경우라면 프로그래머가 프로토타입 제작 이전에 딴지를 걸어야 했을 부분이지만, 경험부족으로 잘 모르고 끝까지 만든 상황에서 발생핬다면......

죄송합니다. 저로써는 답을 못찾겠군요. 어차피 프로그래머가 못 짤 게임은 만들 수가 없습니다. :-(



보노/
땡스 얼랏;;;
Commented by 로딘 at 2007/05/17 14:13
맞아. 나도 운이 좋았지. 여전히 운은 이어지고 있는 것 같기도 하고...
'악몽의 테스트' 파트는 정말 공감가옵니다... 흑흑.

우리의 경우는 위에 글강님이 말씀하신 상황이 당연히 생길꺼라 '충분히' 예측할 수 있는 상태라...
애초에 프로토타입 따위는 쥐쥐. 기한을 길게 잡고 님이 말한 코어 모듈(조엘 아찌는 '예광탄'이라 하더만) 방식으로 갔지.
덕분에 기획하는 아찌가 좀 피곤해졌지만 일정 관리 면에서는 꽤나 유리한 수를 가지게 되는 듯.
Commented by fieldkim at 2007/05/17 21:26
로딘/
너에게 듣고나니 확실히 그 케이스가 피부에 와 닿는군;
'어쩔 수 없이 코어 모듈식'......

쐬기후니가 죽을 것 같데?
음. 아마 마음 같아서는 이것 저것 고치고 싶을텐데 고치자니 개발 기간이 늘어날까봐 못 고치고 있고.......

내 눈에 떠오르는 이미지가 맞을 것 같은데 :-(

아마 프로그래머들도 같이 죽어나갈 형편이긴 하겠지만:)
Commented by 오린간 at 2007/07/20 23:21
제 글에 관련글 자동검색이 되서 와봤습니다.
지금 술이되가꼬 글을 자세히 읽지는 못했지만요....
프로토타입을 버릴각오로 만드는것 전적으로 동의합니다!!!

저의 경우 ....만약 버릴 각오로 만들지 않게되면
프로토타입이 너무 늦게 만들어지거나....
머 기타 등등 ㄱ- 시간이 가장 중요하죠....

머 그렇게 만든뒤에 은근히 잘 만들어진거면
(그런일이 잘은 없지만...확실히 있기도 하고)
수정해가면서 쓰는것이고......
대체로 완전 새로 만들어야할지도 ㄱ-
Commented by 667787 at 2013/03/20 20:11
.
.
.
심심할때 할만한 바둑이/맞고 게임 추천해 드려요.

.
[신규오픈 바둑이게임] ==> http://me2.do/GMwnR29
.
.
.
.

:         :

:

비공개 덧글

◀ 이전 페이지          다음 페이지 ▶