[💬] 1인 개발자를 위한 워크플로우 - 레딧 포스팅 3부[完] (한국어번역)

<1부>

<2부>

bkbl

게임 개발자 몇분이 말해준건데, 피보탈 트래커(Pivotal Tracker)를 몇 달간 사용하면 정확히 들어맞기 시작한대요. (당신의 작업 속도를 학습하는 방식인데, 제대로 사용하려면 숙달될 필요가 있긴 해요.) 그 외에는 Trello에 한 표 던집니다.

ㄴpTricked

제안 고마워요! 잠깐 살펴봤는데 첫 인상으로는 거의 기존의 소프트웨어 모델이나 팀을 대상으로 한 소프트웨어 같아요. 게임 개발 팀에는 아주 좋을 것 같은데, 1인 작업에 적용하기엔 너무 과한 감이 있는 것 같네요. 덧붙이자면 저도 Trello를 진짜 좋아해요

<정보) Pivotal Tracker : Pivotal Labs에서 개발한 애자일 방식의 프로젝트 스케줄링을 지원해주는 툴.

가입 후 첫 30일간은 제한 없이 무료고, 3인 이하의 팀은 2GB의 저장 공간 내에서 2개의 프로젝트까지 무료로 사용할 수 있음.>

Eymrich

제가 프로토타입을 만드는 법칙은 "에셋 없이도 재미있고 완벽하게 조율된 게임플레이를 만드는 것"입니다. 색도 입히지 않고 오직 큐브만 사용해요.

필요한 경우에 간단한 사운드 정도만 넣어주고요. 이 방법으로 재미있게 만들 수 있다면 문제가 전혀 없는거죠. 작성자님도 그 길을 비슷하게 걸어오신 것 같네요.

그건 그렇고, 핵심적인 게임플레이를 한 주 정도만에 만들 수 없다면 그건 진행할 가치가 없어요. 물론 예외는 있습니다만, 가장 중요한건 완성까지 수 년 단위로 들어가는 게임은 피하자는 거에요.

"세련된 프로토타입"은 보통... 제 기준으로는 앞서 말씀하신 수직적 단면(Vertical Slice)이라고 보는데, 모든게 정상적으로 돌아가는걸 확인하고 커밋을 한 '후'에 하는 건 정말 좋은 아이디어에요. 최종 완성된 수준의 게임플레이를 5분에서 10분 정도의 분량으로 만들어 보는거죠. (사운드, 그래픽 에셋 전체를 포함한 완벽한 게임플레이로) 레벨(맵)의 경우에는 게임 초반부보다는 좀 심도 있는 수준의 레벨을 만드는게 좋아요. (분명 재밌을 거에요)

이 방법으로는 2가지 목표를 달성할 수 있는데,

1) 에셋 전체를 만드는 데 얼마나 걸릴 지를 좀 더 잘 이해하게 될것이며, 시각적으로 보여지는 부분의 코드를 아마도 좀 더 현명하게 이해할 겁니다.

2) 잠재적인 퍼블리셔들이나 기자, 유투버들 등의 흥미를 끌 수 있을만한 보여줄 거리가 "항상" 있을겁니다.

다른 어떤것보다 시간을 제일 중요하게 고려해야 해요. 저는 그부분에서는 아직 미숙하지만, 알파 단계에 도달하기 위한 시간은(주된 게임플레이 제작이 다 끝나고, 가공이 남은 단계) 게임 전체를 만드는 데 걸리는 시간의 1/3.14도 안돼요. 물론 많은 요소들에 의해서 좌우되긴 하는데, 그렇더라도 "충분한 테스트를 거쳤고, 세련되어 있으며, 버그가 없는 게임"을 만드는 것 보단 거의 무조건 적게 들죠.

<정보) 수직적 단면(Vertical Slice) : 쉽게말해 데모라 보면 될듯. 최종 출시되는 퀄리티로 제작된 짧은 시간의 게임플레이를 뜻함.>

ㄴpTricked

고마워요!

제가 했던 다른 질문(가공된, 단편적인 프로토타입)을 정말 잘 짚어 주셨군요 (사람마다 다른 방식을 쓴다는 걸 알아요)

1인 인디 개발자들에게는 단편적인 게임플레이를 제작하는 것이 전체적인 진행과정을 미리 판단할 수 있고, 추가로 게임을 소개할 때 사용할 수 있다는 점에서 충분히 가치가 있다는 말씀 같군요.

정말 좋은 아이디어라고 생각했는데, 이게 프로젝트 중반쯤에 준비되게끔 해야 하는 건지, 초반에 준비해야 하는 건지, 아니면 언제 준비해야 하는 건지 궁금했어요. 마케팅적인 측면에 대해서는 여기서 지겹도록 토론되는 걸 알고는 있지만, 어떻게 기업들은 매번 다른 단면을 소개하는 듯 보이는지가 항상 의문이였죠. 다른 모든 부서가 게임의 최종 디자인을 작업할 때, 게임 코드에서 따로 분화되어서 데모를 제작하는 데에만 투자하는 부서가 있는 게 아닐까 하는 생각을 해요. 일부 게임들은 수명주기 초반에 이런 데모들을 볼 수 있는데, 가끔씩 출시된 결과물이 그것과 딴판일 때는 정말 이해가 안돼요. 뭐 AAA급 타이틀에서만 일어나는 일일수도 있겠지만요

ㄴㄴEymrich

제 경우는 어떤 게임을 만드는지에 따라서 가장 많이 좌우돼요. 우선 "큰" 프로젝트에서 그렇게 해요. 1년 이상의 프로젝트에서라고 말해두죠.

두번째로, 저희 작업선에 있지 않은 사람들에게 보여줄 필요가 있을 때 사용해요. 예를 들어서, 제가 특정한 게임을 정말 만들고 싶어요. 그리고 제가 아는 음악가를 프로젝트에 반드시참가시키고 싶어요. 그 사람은 저한테 자기는 비디오게임에 관해서는 하나도 아는 게 없다고 말했어요. 그러면 제가 해야 되는 게 단면적인 게임플레이를 제작하는거에요. 게임이 어떻게 만들어질지를 보여주는 "아주 잘 가공된 프로토타입"이죠. 그 사람이 게임을 많이 하던, 조금 하던 아무 문제가 없는 방법이에요. 주변의 다른 게임과 비교해볼 수도 있고, 그가 신뢰하는 다른 사람에게 보여주면 그들이 "괜찮네요. 해보세요"라고 말해주겠죠. 최소한은요...제 희망이에요 :D:D:D:D

그리고, 이 방법은 그래픽 파이프라인에 많은 스트레스를 줄 거에요. 초기 단계에서 처리해야 할 문제가 산더미같을거구요. 게임 중반에 있는 레벨을 만드는 거기 때문이죠(레벨이 10개정도 있다면 7번째 정도 맵을 단면 게임플레이로 만드는거에요).

마지막으로 말씀하신건, 상황에 따라 달라요. 이 방식으로 작업하는 스튜디오를 많이 들어봤어요.

1) 주요 행사의 한달 전까지 게임을 작업합니다.

2) 이벤트용 데모를 제작합니다.

3) 데모 시연 이후에는 과정 2에서 했던 걸 고치고 쓸모없는 부분을 버립니다.

씻어내고 반복한다... 제 기억이 맞다면 이게 결국 No Man's Sky와 다른 많은 프로젝트들에 기대했던 사람들을 맥빠지게 만들어놓은 원인이죠.

제가 지금 작업중인 게임에서도 문제가 되는 부분인데, 프로듀서와 리드 디자이너는 항상 세련된 버전을 보여줄 수 있는 걸 원하거든요... 그게 모든 작업을 10배씩 더 오래 걸리게끔 만들어요.

ㄴㄴㄴpTricked

명백히 보이네요. 작업중인 버전을 세련된 상태로 유지하는건 시간을 많이 소모하죠. 그래도 세련된 프로토타입이 가치를 발휘하는 부분에 대해서 짚어주신 건 이해했어요. 아마 내년 중반에 IGF나 Indiecade에서 컨퍼런스를 진행해 볼 수도 있을 거 같은데 개발 주기가 1년이기 때문에 그 때쯤 베타 릴리즈가 될 수도 있어서, 그 중 하나를 진행할 때는 충분히 세련된 게임플레이 경험이 필요할 거에요.

ㄴㄴㄴㄴEymrich

무슨 말씀을요, 그리고 모든 걸 우리랑 공유해주셔서 고마워요! :D

zer0sumgames

전 그냥 구글독스에 거대한 To-Do 리스트를 두고 작업해요. PM은 그것만 있어도 되거든요.

ㄴpTricked

그 방법이 어느 정도는 유효한 거 같은데, 동시에 개발 주기가 필요보다 더 길어질 것 같기도 해요.

기존의 소프트웨어 수명주기에선 시간이 지날수록 점점 진화해요. 예를 들면, 제가 몸담았던 소프트웨어 사업에선 전세계 각지의 콜센터에서 사용하는 제품을 가지고 있었어요. 주단위로 새로운 기능들을 추가했고, 사람들은 그걸 좋아했죠. 처음 출시했을 땐, 물론 정상작동하긴 했지만 현재의 모습과는 많이 달랐어요. 아주 많이요. 시간을 거치면서 정말 많이 진화했거든요.

그걸 기존의 게임 개발 주기와 대조해보면, 최종적으로는 100% 완성된, 아주 세련되어 있는 게임이 탄생해야 해요. Destiny같은 게임들이 그런 모델을 표방했지만 큰 성공을 거두진 못했구요, WOW같이 이 방법을 성공적으로 해낸 게임들은 확신컨대 초기 릴리즈부터 완벽한 상태였고, 시간이 지나면서 확장된 경우에요. 어느 경우가 됐던간에, 이 경우 우리는 거의 다 완성된 게임을 발매해야 하는 거죠.

이러한 기대로 미루어 볼 때, 기존의 이터레이티브한 접근법을 통해서 소비자의 피드백을 받는 것과 게임을 성장시키는 것은 서로 비슷하게 작용하는 것 같지 않아요.

얼리 액세스를 한다면 좀 더 이터레이티브한 접근법을 통해서 잘 해낼 수 있을 거라고 생각해요. 만약 그게 싫다면, 99.99% 수준으로 완성되었으며 세련된 게임을 발매하는 편이 더 좋을 거에요.

자, 제 문제로 돌아가보자면, 게임이 출시되었을 때 완전히 세련된 경험을 제공해 줄 수 있어야 한다는 기대감과 동시에, 우리는 개발 과정에 그 부분을 반드시 고려해야 해요.

개발 기간 중에 이터레이트를 너무 많이 해버린다면, 출시는 영원히 불가능할거에요. (Feature creep이라던가요) 만약 이터레이트를 충분히 하지 않고(좀 더 폭포수 모델 방식) 처음 디자인했던 대로만 만든다면, 우리가 시간 계산만 제대로 한다면 결과는 썩 좋진 않을진 몰라도 제 시간에 완성될 거에요. (보통 개발자들은 그렇지 못하거든요)

게임을 출시해본 경험이 있는 다른 인디 개발자분들에게 제가 듣고 싶은건, 개발 과정은 어떻게 진행되었는지, 그리고 제 시간에 발매하였는지 등의 여부에요.

<정보) 이터레이트(Iterate) : 워낙 광범위한 용어라 자세히는 나도 모르겠는데, 맥락으로 판단해보면 게임을 피드백해서 기존 디자인에서 부족한 부분을 향상시키는 일을 말하는듯. 이전 포스팅들에서도 격주 개발 같이 개발/피드백을 반복하는 방식이라고 소개했었음>

ㄴㄴLaserDinosaur

구글 독스를 사용한다고 모두 폭포수 모델인 건 아니에요!

저는 개발 과정이란 해당 프로젝트의 성격에 맞추어 짜야 된다고 생각해요. 게임의 hook/apex는 장르나 복잡성, 프로젝트의 범위에 따라 크게 달라져요.

원하시면 저희 방식과, 했던 일들을(2인 팀입니다) 공유해드릴 수 있어요. 보시고 납득이 가신다면 작성자님의 프로젝트와 목표에 기반해서 조언을 해 주세요. 아무튼 관심 있으시면 메시지 보내주세요.

ㄴㄴㄴpTricked

맞아요. 구글독스가 폭포수 모델이란 뜻은 아니었어요. 잘못 표현한 거 같네요.

제 뜻은 상위로 어떤 구조도 갖지 않고 그저 방대한 To-Do 리스트를 갖고 작업한다면 저는 좀 Feature Creep 문제에 부딪힐 것 같다는 거였어요. 계속 리스트 마지막에 새로운 항목을 추가하게 되거든요.

지금은 Trello로 작업하는데, 새로운 기능을 추가할 때 디자인에 맞춰야 되는 구조로 되어있어요. 현재 진행중인 마일스톤에 맞추기 위해서는 상위 작업들을 새로 추가해야 되고, 그 항목들에는 또 기한이 있거든요. 그렇게 되면 결국 이전에 다른 일정에 할당했던 마감기한이 전체적으로 늦춰지게 되고, 그러면 저는 모든 일정의 마감 기한을 일일히 재조정해 주어야 해요. 그러면 결과적으로 출시 기한까지 미뤄지게 되는데, 그건 진짜 싫어요.

당연히 구글 독스로도 제 방식과 비슷하게 작업할 순 있지만, 별 생각 없이 새로운 것들을 추가하고 싶은 유혹이 존재해요.

드디어 끝났다

학교플젝에 개인플젝에 시험이니 뭐니 많이 겹쳐서 늦음 ㅈㅅ

번역하면서 나도 많이 배웠다.. 지금 나는 에버노트에다 항목별로 노트를 만들어서 쓰고 있음. Trello도 좋아보이긴 하는데 마감 기한을 지킬 수 있는 상태가 아니라

(필요할 때마다 만드는 기타 항목 제외하고 큰것들만 나열하면 전체 타임라인, 단기 타임라인, 개발 로그(언제 뭘 구현했는지), 아이디어 노트, 기능구현 노트)

인겜갤러들은 어떤 방식으로 개발하는지 공유해보는 건 어떨까?

[💬] 1인 개발자를 위한 워크플로우 - 레딧 포스팅 3부[完] (한국어번역)

댓글 2

다른 게시글