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

[SierraT..(etd2013)]

우선 이 글은 원본 포스팅 작성자가 자기 방식을 공유하고 조언을 얻고자 쓴 글이고, 이건 맞고 저건 틀리다를 논하는 글이 아닌걸 명심해주셈

1인 개발 워크플로우 관련해서 찾다가 유익해보여서 갖고옴

관련 자료를 최대한 찾아가면서 번역하긴 했는데 빼먹은게 있을수도 있으니 만약 그런게 있으면 댓글로 알려주면 수정함

그리고 포스팅이 분량이 겁나 많아서 2~3번으로 나눠서 올려야 될 거 같음.. 추가로 번역하는대로 올림 ㅜ

원본 링크 : https://www.reddit.com/r/gamedev/comments/74oz7q/workflow_for_solo_indie_dev/

Workflow for Solo Indie Dev 한국어번역 - 1

안녕하세요. 여기 오기 전에 아주 많은 조사를 해 봤어요. 

보통 저는 질문을 받고 거기에 답변하는 걸 좋아하기도 하고, 이 주제에 대해서 충분히 많은 지식을 모았지만 제가 찾는 정보들은 없었어요.

1인 인디 개발자들을 위한 실용적인 워크플로우를 알아보고자 하는데요 

전 컴퓨터 프로그래머/음악가 출신이고, 제 게임의 모든 아트워크는 구매하거나 외주로 맡길 겁니다.

이런 관점을 주는 이유는, 워크플로우는 상황에 따라서 유기적으로 구성되어야 한다고 생각하기 때문이에요.

현재 제 워크플로우는 다음과 같습니다

1. 전체적인 일정을 기술해놓은 Trello board를 가지고 있습니다. (예 : 프리 프로덕션, 알파, 베타, 출시)

2. 현재 진행중인 일정에는 표식을 달아놓거나 색으로 강조합니다. (현재는 프리 프로덕션입니다.) 그리고 현재 작업중인 일정 내의 상위 항목들에 대한 리스트를 따로 작성 해 놓았습니다. 지금같은 경우엔 레벨(맵) A 디자인이라던가, 그런 종류의 것들이 올라가 있죠.

3. 그 상위 항목들 중 현재 작업중인 안건을 표시해 놓고, 거기서 또 세분화시켜 완료 표시를 남길 수 있을 정도로 작은 규모의 작업들을 리스트로 가지고 있습니다.

4. 전체적인 일정들과 상위 항목들에는 마감 기한을 정해놓았습니다. 하위 항목들에는 따로 정해놓지 않았구요.

5. 그렇게 모든 상위 항목을 완료하면, 한 단계의 일정이 완료되며 다음 일정으로 넘어갑니다.

지금까지 이 방법으로 아주 수월하게 해내고 있고, 특히 Trello가 정말 좋아요.

제가 헷갈리는 부분은 좀더 이상적인 반복 방법과 작업 과정에 대한 거에요. 예를 들어서, 프로토타입을 제작하는 것이 현명한 일일까요? 만약 그렇다면 여러분은 몇 종류의 프로토타입을 만드나요?

이 기사를 보시면 <기사> 프로토타입에 상대적으로 더 많은 노력을 들여서 게임이 재미있고 의도한 모든 것이 작동하는지를 검증하되, 거기까지만 하고 다른것은 모두 graybox 처리하며 아트는 마지막에 할 것을 제안합니다.

저는 이 접근이 굉장히 마음에 들었고 현재 따르고 있는 방법이기도 한데, 문제는 결국 더 많은 디자인 작업을 하게 될 것 같단 거에요.

지금 제 작업 일정을 설명드리자면

1. 프로토타입 - 게임플레이의 샘플을 빌드하고 재미있는지를 검증합니다. (완료) - 이 과정은 완료하였는데, 모든 게 정상 작동했지만 이쁘진 않았습니다. 처음부터 끝까지 핵심 목적은 실현 가능한지를 검증하는 것에 맞춰져 있었습니다. 게임이 잠재적으로 가질 수 있는 최대 분량의 데이터를 저장하는 것이 가능한지 알아보기 위해 세이브 시스템 또한 만들었습니다. 평소같았으면 세이브 시스템은 뒤로 미뤘을 텐데, 게임의 느낌을 결정하는 데 아주 중요한 사안이었기 때문에 구현시켰습니다.

2. 프리 프로덕션 - 월드의 구성을 디자인합니다. 현재 제가 작업중인 단계입니다. 레벨의 구조물, 분석, 요소들이 어떻게 어우러질지, 퍼즐 같은 것들을 구상하고 있는데, 모든 과정은 종이와 Trello를 통해 작업중입니다.

3. 프로덕션 / 알파 - 2번째 과정에서 나온 모든 요소들을 'graybox'하여 게임이 시작부터 끝까지 모두 작동하는 지 알아보는 과정으로 하려 했던, 하지만 아직 아무런 아트 과정도 거치지 않은 단계입니다. 

4. 프로덕션 / 베타 - 이 과정에서 아트를 거쳐 게임을 꾸미고 동시에 버그를 수정하려고 했습니다.

5. 출시 - 베타 직후부터 출시까지 버그 수정만 거치게 될 단계입니다.

프리 프로덕션이 좀 과하게 힘든 과정이 될 것 같아 보이는 동시에 충분한 수준으로 구현되지 못할 것 같아요. 거대 스튜디오가 아닌 1인 개발의 특성상 일종의 반복적인 접근이 좀 더 낫지 않을까 하는 생각이 듭니다.

다른 솔로 인디 개발자(혹은 였던)분들의 조언과, 여러분들은 전체 개발 과정에서 어떤 방법이 가장 효과적이었는지를 듣고 싶어요.

고마워요!

(정보 1 : Trello : 일정 관리 툴)

(정보 2 : 'graybox'하다 : 사진 참고)

astrallurker

아주 잘 파악하신 것 같군요. 사실 저도 이 포스팅에서 몇 가지 배우고 갑니다.

제 의견을 말씀드리자면 단순 반복적인 방법이 효율적인 것이 있고, 계획적으로 짜여진 작업이 효율적인 것도 있다 생각합니다.

저는 이전에 레벨 디자인 쪽으로 경험이 좀 있었는데 게임 개발의 단계는 딱 중간부터 시작하는 것이 최고라고 판단했습니다. 

50종류의 단계가 있다고 칩시다. 그러면 25단계부터 시작해서 양방향으로 제작하는 것입니다. 25단계는 기술적으로 완전하며 밸런스가 잘 짜여진 상태여야 합니다. 그보다 낮은 단계로 내려가면, 기술적인 요소들이 점차적으로 빠지고 단계적으로 레벨이 단순화되어 끝에는 튜토리얼 레벨같이 보이는 지점까지 도달합니다. 25단계보다 높은 단계로 올라간다는 것은 점점 더 엄격하게, 대충 넘어가는 일이 없이 만드는 것을 의미합니다. 이 과정에서는, 밸런스와 관련된 작업은 많이 덜게 되며 과도하거나 평평한 수준의 학습 곡선을 방지할 수 있습니다. 

컨트롤의 느낌과 요소들 간의 상호 작용을 디자인하는 과정만 반복적인 작업이 필요하다고 생각하는 부분입니다. 

게임 출시일 직전까지 컨트롤의 느낌을 만지는 걸 반복하고 있대도 놀랄 일이 아니에요.

프로토타입 쪽에서는, 그냥 많이 만드는 것보단 모듈러 형식으로 만들어서 어떤 기능을 먼저 진행하고 나중에 진행할지 결정하는 것을 선호합니다. 만약 어떤 기능이 게임을 어수선하게 만들거나 불필요한 것이라면 저평가시키기도 합니다. 각 기능의 중요도를 점수로 매겨서 게임을 밸런싱하는 데 도움이 될 수 있게끔 해보세요.

ㄴ pTricked

댓글 고마워요!

 프로덕션 과정 중에 말인데요, 최종 아트 작업 같은건 마지막에 하시는 거겠죠? 개발 중에 너무 과하지 않을 정도로 적당한 디자인 요소를 작업하는 정도를 어떻게 조절하면 좋을 지 고민중이에요. 구현에 들어가기도 전에 디자인 관련 문서가 산처럼 쌓이는 일은 피할 수 있게요. 

사실 제 질문에 정확한 답이 있는지도 모르겠어요. 그냥 개인 취향 차이의 문제일 수도 있겠죠. 제 내면 한편에서는 게임 전체를 계획하고, 구현한 다음에 보완 및 아트 작업을 하길 원하는데, 또 다른 한편으로는 전통적인 소프트웨어에서 배운 요소들을 활용해서 내가 가는 대로 만들어나가고 싶은 부분도 있어요.

 그 방법을 고려해보기 위해서, 지난번 Ludum Dare에서 금요일 밤에 게임을 디자인하고 주말간의 작업을 계획했어요. 토요일에는 정확히 계획한 대로 실행했고 오후 1시쯤에 하루 일과를 마쳤어요. 일요일에는 계획했던 것을 끝낸 뒤에 엔트리를 제출했구요. 결과는 31등이었고 기간 중에 단 한번도 과로나 지치는 일이 없었는데, 이 방법을 장기 프로젝트에 적용했을 때 얼마나 괜찮은 방법이 될지 모르겠어요. 내가 디자인하고 있는 게임플레이에 대해서 직접 느낄 수 없으면, 폭포수 개발 모델을 차용하던 시절로 회귀한 기분이에요. 그 모델이 결국 어떻게 됐는지 보세요. 

 소프트웨어 개발자 신분으로 있었을때 제 생활은 항상 디자인 반 구현 반이었고 특히 "제대로 만들기 어려운"부분을 디자인할 땐 아주 많은 시도를 해야 했거든요. 게임 개발은 저에겐 완전히 새로운 분야라서 디자인과 구현의 사이에서 한쪽에 너무 치우치지 않고 딱 적절한 균형을 찾고 있어요. 

격주 개발같은 방법이 효과적일수도 있을까요? 한 주 동안은 월드와 게임플레이를 구현하고 디자인을 검증하는 데 쓰고, 다른 한 주는 디자인한 걸 수정하고 개발 주간에 배운 것들을 받아들이는 시간으로 사용하는 거죠.

(정보 : 학습 곡선은 어떤걸 성취하는 데 있어서 시도/시간 대비 달성률을 표로 나타낸 것을 의미)

(정보 : 폭포수 모델은 사진같은 개발방식임. 1970년 생겨났고 사업부 주도의 개발방식이라고 함)

ㄴㄴastrallurker

<1문단 답변>

아트는 외주로 돌리기로 하셨으니까, 이 경우엔 최소 2단계의 아트 개발 과정이 유효해요.

첫 단계는 당연히 작성자님이 아트스타일을 직접 결정하시고, 외주 작업자들이 그걸 가공하는 과정이 될거구요,

둘째 단계에서는 1단계에서 나온 컨셉아트를 기준으로 게임에 필요한(작성자님이 원하는 거 말구요) 모든 종류의 아트를 리스트로 정리해야 합니다.

저는 아티스트 출신으로 혼자 게임을 개발중인데, 다른 아트들은 어떤 게 필요한지를 정의할 수 있을 정도로 충분한 수준의 프로토타입이 완성된 뒤로 미루되 컨셉아트는 MVP 단계에(뜻은 뒤에 나옴) 제작해야 한다고 생각해요.

<3문단 답변>

1인 개발의 최대 장점은 일정 관리의 유연성이에요. 개발 주기를 격주로 고정하는건 팀 개발에서만 효과가 있을 것 같아요. 제가 틀린 걸 수도 있지만 지금 저는 전체적인 디자인 일정을 짠 뒤에, 우선 순위를 부여하고 몬테 카를로 트리로 정리하는 식으로 나눠 분류한 다음 그 몬테 카를로 트리에서 쭉 내려가는 식으로 구현합니다.

(정보 : 몬테 카를로 트리는 의사 결정 알고리즘을 노드와 루트로 나타내는 거라고 함)

ㄴㄴㄴpTricked

그러면 전통적인 폭포수 모델로 디자인을 하고, 그 다음 몬테 카를로 트리를 사용해서 우선 순위에 기반한 구현을 하시는건가요?

아트를 시작하기 전에 게임 전체를 플레이 가능하게끔 프로토타입을 제작하는 과정을 두시나요? 개발 초기에 컨셉 아트 과정을 거치는 건 이점이 있어 보이는데, 아트 이전에 게임 전체를 graybox로 제작하는 방법이 정말 마음에 들었거든요. 

제가 생각하던 방법이랑 일맥상통했던게,

1. 전 아티스트는 아니지만 눈이 정말 좋아요(눈이 낮다던지 비위가 좋다던지 그런 뜻인듯). 

그래서 게임을 이쁘게 꾸미는 건 뒤로 미룰 수 있고, 만약 못생긴 CSG graybox에서 플레이할 때 재밌다면 아트와 사운드이펙트, 음악을 삽입한 뒤에도 재미있을 거라는 걸 알기 때문이에요.

2. 불필요한 작업, 돈, 시간 등등을 예방해줘요.

ㄴㄴㄴㄴ astrallurker

<전통적인 폭포수 모델로 디자인을 하고, 그 다음 몬테 카를로 트리를 사용해서 우선 순위에 기반한 구현을 하시는건가요?>

맞기도 하고, 아니기도 합니다. 저는 어떤 기능이 선결 조건이고 어떤 게 특징인지를 인지한 상태에서 1인 프로젝트를 해나가는 게 훨씬 쉬워요. 몬테 카를로 트리는 제가 한 방향으로 쭉 나아가야 하는지, 아니면 아직 미구현된 핵심 기능을 개발하기 위해서 가지를 확장해 나가야 하는 지 결정하는 걸 돕기 위한 거에요. 복잡하게 들릴 수도 있지만 저의 경우에는 색으로 강조된 To-Do 목록이나 간트 차트를 가지고 있는 것보다는 이 방법이 훨씬 효과적이었어요. 예전에는 작성자님과 비슷한 색강조된 일정표를 가지고 있었는데, 몬테 카를로에 맞게끔 큰 그림들로 바꿨어요.

<아트를 시작하기 전에 게임 전체를 플레이 가능하게끔 프로토타입을 제작하는 과정을 두시나요?>

저도 그 과정을 두고 있는데, 차이점이 있다면 그걸 MPP(Minimum Playable Product, 플레이 가능한 최소 수준의 제품)라고 부른다는 점이에요. 여기선 색으로 구분된 히트박스들만 사용해요. 여기서 컨셉 아트를 추가하면 MVP(Minimum Viable Product, 최소 기능 제품)가 됩니다. 아트를 직접 하시는 거라면 마지막 단계에 하는 것도 괜찮아요. 그런데 작성자분의 경우엔 외주를 주시는 경우이니 아티스트들이 MVP 단계를 플레이할 수 있게 해 주시거나, 게임을 플레이하는 영상을 제공해주는 것이 출시일을 많이 앞당겨 줄 거에요. 아트 작업은 시간이 오래 걸리기 때문에 이 단계에서 작업을 전체적으로 시작하는 게 더 효율적이라 생각해요.

<2문단 답변>

개발에 시간을 더 쏟을 여유가 있다면 사실 말씀하신 방법이 더 낫습니다. 이전에 제가 몸담고 있었던 프로젝트의 경우가 어느 시점부터 프로그래머의 작업거리가 다 떨어져 우리 3명이 아트와 음악 작업을 하는 동안 그는 컨트롤 작업만 계속 반복하기 전까지 이 방법을 사용했는데, 어느 날 프로그래머가 아트를 훨씬 일찍 시작했어야 했다고, 괜히 3달동안 아트가 끝나길 기다리면서 진부한 반복 작업만 하게 됬다고 말한 적이 있어요.

ㄴㄴㄴㄴㄴpTricked

와.. 진짜 유익한 조언 감사합니다. 이 몬테 카를로 구조라는 게 어떻게 생겼을 지 궁금하네요.

특정한 툴을 쓰시나요?

ㄴㄴㄴㄴㄴㄴastrallurker

따로 쓰는 건 없구요, 종이랑 펜으로 작성합니다. 예전엔 Trello로 작성하곤 했는데 몬테 카를로 방식으로 관리하는 새 방법이 마음에 들어서 현재는 쓰지 않아요.

제 로그북은 공유하기엔 너무 복잡한 상태라 몬테 카를로 트리를 넓은 벽 같은 데에 하나로 배치하면 어떤 모양이 될지 나와있는 사진을 첨부합니다.

ㄴㄴㄴㄴㄴㄴㄴpTricked

올려주셔서 감사합니다. 처음 보기엔 되게 복잡해 보이는데, 분명 이걸 쉽게 이해할 수 있게 해주는 원리가 있을 것 같네요.

(2부에서 계속)

[asdasd(124.61)]

이것은 매우 좋은 번역! Reddit 에서도 좋은 평가 얻다. 감사하십시오!

[익명(49.161)]

아 나도 위에 댓글 달라고 했는데....

[地鬼(dczlatan)]

25단계 좋다

[익명(221.162)]

와 너무 좋으니까 다음에도 또 해주셈 ㅡㅡ

[익명(221.162)]

장난이고 잘보고갑니다 고마워용

[새우맨(222.120)]

장난아니다 이런 엄청난 번역을...

[굳(211.36)]

굳

[카일라(118.216)]

외주는 어떤사이트나 경로로 구하시나요??

[SierraTi(etd2013)]

그건 저어도 안해봐서 모름.. 아마 보통 포럼같은데서 구하거나 아님 프리랜서로 일하시는분들이나 전문업체 같은데 맡기지 않을까여?